setup: initialize Terraform project and development environment

github-actions/day51/README.md

@@ -0,0 +1,113 @@
+## DAY 51: GITHUB ACTIONS 
+
+## ENVIRONMENT VARIABLES 
+- we are setting environment variables 
+
+### WORKFLOW LEVEL ENV
+```
+name: CI
+on: 
+    push
+env:
+    APP_NAME: linux_sysmonitor
+```
+- APP_NAME can be accessed at the workflow level 
+
+### JOB LEVEL ENV
+```
+name: CI
+on:
+    push
+jobs:
+    buid:
+        env:
+            NODE_ENV: Production 
+```
+
+### STEP LEVEL ENV
+```
+name: CI
+
+on:
+    push
+
+jobs:
+    build:
+        steps:
+            - name: App name 
+                env: 
+                    APP_NAME = linux
+                run: echo $APP_NAME
+```
+
+> What happens if the same environment variable is defined at all three levels?
+```
+Workflow:
+APP_NAME=App1
+
+Job:
+APP_NAME=App2
+
+Step:
+APP_NAME=App3
+```
+> Which value does the step actually use?
+- Answer: App3
+
+## REPOSITORY VARS
+- Repository-wide configurations managed in GitHub settings
+- `secrets` are encrypted while `variables` aren't
+- This is the only difference, Vars arent encrypted while secrets are. The way of accessing `vars.APP_NAME` and all remains the same 
+
+## PERMISSIONS IN GITHUB ACTIONS
+- **Permissions are given to the entire workflow and can also be done to the jobs level**
+```
+name: CI
+on:
+    push
+permissions:
+    contents:read
+```
+
+> Why should you explicitly define workflow permissions?
+- Answer: To ensure the workflow receives only the **permissions it actually needs**. This reduces the impact of compromised workflows or third-party actions and follows the **Principle of Least Privilege.**
+
+> Should permissions be defined at the workflow level or the job level?
+- Answer: Use workflow-level permissions when the same permissions apply to all jobs. Use job-level permissions when specific jobs require additional or different access. This follows the Principle of Least Privilege by granting elevated permissions only to the jobs that need them.
+
+> Use workflow-level permissions when the same permissions apply to all jobs. Use job-level permissions when specific jobs require additional or different access. This follows the Principle of Least Privilege by granting elevated permissions only to the jobs that need them./
+- Answer: 
+- Branch Protection Rules protect the **source code** by requiring reviews, status checks, and other conditions before code can be merged into a protected branch like main.
+- Environment Protection Rules protect **deployments** by requiring approvals, branch restrictions, wait timers, or other checks before code is deployed to environments like Staging or Production.
+
+## PRODUCTION LEVEL 
+```
+                     Push
+                       │
+                       ▼
+                 Checkout Code
+                       │
+                       ▼
+                    Build
+                       │
+          ┌────────────┼────────────┐
+          ▼            ▼            ▼
+        Lint      Unit Tests   Security Scan
+          │            │            │
+          └────────────┼────────────┘
+                       ▼
+              Build Docker Image
+                       ▼
+                  Push to GHCR
+                       ▼
+              Deploy to Staging
+                       ▼
+                 Smoke Tests
+                       ▼
+              🛑 Manual Approval
+                       ▼
+            Deploy to Producti            ▼on
+
+          Notify Slack / Email
+```
+

github-actions/day51/interview.md

@@ -0,0 +1,106 @@
+# GitHub Actions - Day 51 Interview Questions
+
+## 1. What are Environment Variables (`env`) in GitHub Actions?
+
+**Expected Answer:**
+Environment variables are values defined at the workflow, job, or step level that can be reused throughout the workflow. They help avoid hardcoding values and improve maintainability.
+
+---
+
+## 2. What is the precedence order of environment variables?
+
+**Expected Answer:**
+Step `env` > Job `env` > Workflow `env`.
+
+The most specific scope overrides the broader scope.
+
+---
+
+## 3. What is the difference between `env`, `vars`, and `secrets`?
+
+**Expected Answer:**
+
+- **env** → Workflow-specific variables defined inside YAML.
+- **vars** → Non-sensitive configuration stored in GitHub Repository/Organization Variables.
+- **secrets** → Sensitive information such as passwords, API keys, and tokens stored securely in GitHub Secrets.
+
+---
+
+## 4. When should you use Repository Variables instead of Secrets?
+
+**Expected Answer:**
+Repository Variables should be used for non-sensitive configuration such as application names, AWS regions, ports, and Docker image names. Secrets should only be used for confidential information.
+
+---
+
+## 5. What is the `GITHUB_TOKEN`?
+
+**Expected Answer:**
+`GITHUB_TOKEN` is a temporary token automatically created by GitHub for every workflow run. It allows workflows to authenticate with GitHub APIs based on the permissions granted to it.
+
+---
+
+## 6. Why should workflow permissions be explicitly defined?
+
+**Expected Answer:**
+Explicit permissions follow the Principle of Least Privilege by granting workflows only the permissions they require, reducing the impact of compromised workflows or third-party actions.
+
+---
+
+## 7. What is the Principle of Least Privilege?
+
+**Expected Answer:**
+It is the security principle of granting users, applications, or workflows only the minimum permissions required to perform their tasks and nothing more.
+
+---
+
+## 8. What are GitHub Environments?
+
+**Expected Answer:**
+Environments represent deployment targets such as Development, Staging, and Production. They can contain environment-specific secrets, variables, and deployment protection rules.
+
+---
+
+## 9. What are Environment Protection Rules?
+
+**Expected Answer:**
+Environment Protection Rules secure deployments by enforcing policies such as required reviewers, branch restrictions, and wait timers before deployments can proceed.
+
+---
+
+## 10. What is a Manual Approval Gate?
+
+**Expected Answer:**
+A Manual Approval Gate pauses a deployment until an authorized reviewer approves it. It is commonly used before production deployments.
+
+---
+
+## 11. What is the difference between Branch Protection Rules and Environment Protection Rules?
+
+**Expected Answer:**
+
+- Branch Protection Rules protect source code before merging into protected branches.
+- Environment Protection Rules protect deployments after code has been merged by enforcing deployment approvals and restrictions.
+
+---
+
+## 12. Name some GitHub Actions security best practices.
+
+**Expected Answer:**
+
+- Never hardcode secrets.
+- Use Repository Variables for non-sensitive configuration.
+- Store sensitive data in GitHub Secrets.
+- Follow the Principle of Least Privilege.
+- Explicitly define workflow permissions.
+- Pin GitHub Action versions.
+- Use trusted third-party actions.
+- Protect production environments with approval gates.
+- Separate development and production credentials.
+
+---
+
+## 13. How would you design a production-grade CI/CD pipeline?
+
+**Expected Answer:**
+Checkout → Build → Lint/Test/Security Scan (parallel) → Package → Publish Artifact/Container → Deploy to Staging → Smoke Tests → Manual Approval → Deploy to Production → Notifications.

terraform/day52/README.md

@@ -0,0 +1,95 @@
+## TERRAFORM DAY 51
+
+### INFRASTRUCTRE AS CODE
+- Defining cloud resources through code is called IaC
+
+## DECLARATIVE vs IMPERATIVE
+1. **IMPERATIVE** 
+- Here we tell **HOW TO DO IT**
+- Example: Create a VPC, create a subnet, so on and etc
+
+2. **DECLARATIVE**
+- Here we tell **WHAT WE WANT** and we do not worry about how it is created
+- Example: I want a VPC, 2 Ec2 instances etc.
+
+- **IaC is declarative in nature**
+
+## HOW TERRAFORM WORK:
+```
+main.tf
+
+↓
+
+terraform init
+
+↓
+
+Downloads Provider
+
+↓
+
+terraform plan
+
+↓
+
+Compares Desired State
+
+↓
+
+Shows Changes
+
+↓
+
+terraform apply
+
+↓
+
+Creates Infrastructure
+
+↓
+
+Updates terraform.tfstate
+```
+
+## PROVIDER
+
+- By default, tf doesnt know about the provider and it needs to be defined explicitly as a plugin 
+
+- Example:
+provider "aws" {
+    region = "us-east-1"
+}
+
+## RESOURCE
+- Everything Terraform creates is a resource
+- Example:
+```
+resource "aws_s3_bucket" "logs" {
+
+}
+```
+- Here:
+    - aws_s3_bucket is resource type
+    - logs is the logical/resource name given 
+
+## STATE FILE
+- State files are used by terraform to **remember what was created by them**
+
+## DESIRED STATE
+- Terraform doesn't execute instructions one by one instead it tries to make the actual infrastructure match for the configuration we have written 
+- Example: We write we need 2 Ec2 instances, and we have 1 EC2 already so when we do `terraform apply` it will create 1 more matching the desired state 
+
+## TERRAFORM FMT
+- It automatically formats our terraform configuration file according to official terraform style guide
+
+## TERRAFORM VALIDATE
+- validates if the terraform configuration i syntactically and structurally correct
+
+## TERRAFORM INIT
+- it initializes the current working directory as a terraform project
+
+## TERRAFORM PLAN
+- It creates an execution plan that tell you exactly whay terraform would do when we do `terraform apply`
+
+## TERRAFORM APPLY
+- Executes the execution plan generated by terraform by creating, updating and deleting infrastructure