diff --git a/AWS/README.md b/aws/README.md similarity index 100% rename from AWS/README.md rename to aws/README.md diff --git a/AWS/README2.md b/aws/README2.md similarity index 100% rename from AWS/README2.md rename to aws/README2.md diff --git a/AWS/assets/image-1.png b/aws/assets/image-1.png similarity index 100% rename from AWS/assets/image-1.png rename to aws/assets/image-1.png diff --git a/AWS/assets/image-2.png b/aws/assets/image-2.png similarity index 100% rename from AWS/assets/image-2.png rename to aws/assets/image-2.png diff --git a/AWS/assets/image-3.png b/aws/assets/image-3.png similarity index 100% rename from AWS/assets/image-3.png rename to aws/assets/image-3.png diff --git a/AWS/assets/image-4.png b/aws/assets/image-4.png similarity index 100% rename from AWS/assets/image-4.png rename to aws/assets/image-4.png diff --git a/AWS/assets/image.png b/aws/assets/image.png similarity index 100% rename from AWS/assets/image.png rename to aws/assets/image.png diff --git a/AWS/assets/image10.png b/aws/assets/image10.png similarity index 100% rename from AWS/assets/image10.png rename to aws/assets/image10.png diff --git a/AWS/assets/image11.png b/aws/assets/image11.png similarity index 100% rename from AWS/assets/image11.png rename to aws/assets/image11.png diff --git a/AWS/assets/image5.png b/aws/assets/image5.png similarity index 100% rename from AWS/assets/image5.png rename to aws/assets/image5.png diff --git a/AWS/assets/image6.png b/aws/assets/image6.png similarity index 100% rename from AWS/assets/image6.png rename to aws/assets/image6.png diff --git a/AWS/assets/image7.png b/aws/assets/image7.png similarity index 100% rename from AWS/assets/image7.png rename to aws/assets/image7.png diff --git a/AWS/assets/image8.png b/aws/assets/image8.png similarity index 100% rename from AWS/assets/image8.png rename to aws/assets/image8.png diff --git a/AWS/assets/image9.png b/aws/assets/image9.png similarity index 100% rename from AWS/assets/image9.png rename to aws/assets/image9.png diff --git a/GitHub-Actions/day46/README.md b/github-actions/day46/README.md similarity index 100% rename from GitHub-Actions/day46/README.md rename to github-actions/day46/README.md diff --git a/GitHub-Actions/day46/interview.md b/github-actions/day46/interview.md similarity index 100% rename from GitHub-Actions/day46/interview.md rename to github-actions/day46/interview.md diff --git a/GitHub-Actions/day47&48/Interview.md b/github-actions/day47&48/Interview.md similarity index 100% rename from GitHub-Actions/day47&48/Interview.md rename to github-actions/day47&48/Interview.md diff --git a/GitHub-Actions/day47&48/README.md b/github-actions/day47&48/README.md similarity index 100% rename from GitHub-Actions/day47&48/README.md rename to github-actions/day47&48/README.md diff --git a/GitHub-Actions/day49/README.md b/github-actions/day49/README.md similarity index 100% rename from GitHub-Actions/day49/README.md rename to github-actions/day49/README.md diff --git a/GitHub-Actions/day49/interview.md b/github-actions/day49/interview.md similarity index 100% rename from GitHub-Actions/day49/interview.md rename to github-actions/day49/interview.md diff --git a/GitHub-Actions/day50/README.md b/github-actions/day50/README.md similarity index 100% rename from GitHub-Actions/day50/README.md rename to github-actions/day50/README.md diff --git a/GitHub-Actions/day50/interview.md b/github-actions/day50/interview.md similarity index 100% rename from GitHub-Actions/day50/interview.md rename to github-actions/day50/interview.md diff --git a/github-actions/day51/README.md b/github-actions/day51/README.md new file mode 100644 index 0000000..f881bf1 --- /dev/null +++ b/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 +``` + diff --git a/github-actions/day51/interview.md b/github-actions/day51/interview.md new file mode 100644 index 0000000..ca486ea --- /dev/null +++ b/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. \ No newline at end of file diff --git a/terraform/day52/README.md b/terraform/day52/README.md new file mode 100644 index 0000000..c97700b --- /dev/null +++ b/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 diff --git a/terraform/day52/interview.md b/terraform/day52/interview.md new file mode 100644 index 0000000..e69de29