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/README.md b/README.md index f224d5c..18bb49d 100644 --- a/README.md +++ b/README.md @@ -64,13 +64,6 @@ No copy-pasted theory. Everything here was typed and run by me. - [x] Day 29 — Pre-commit hooks — lint before every commit - [x] Day 30 — git bisect, git blame, git stash -#### Python & Bash (automation focus) -- [ ] Day 31 — Variables, loops, functions, error handling -- [ ] Day 32 — File handling, reading/writing, argparse -- [ ] Day 33 — HTTP requests with httpx, parse JSON responses -- [ ] Day 34 — boto3 — interact with AWS from Python -- [ ] Day 35 — CLI tools with click or typer - #### AWS Deep Dive - [x] Day 36 — EC2 — launch, SSH, security groups, user data - [x] Day 37 — S3 — buckets, policies, versioning, presigned URLs @@ -94,8 +87,8 @@ No copy-pasted theory. Everything here was typed and run by me. - [x] Day 47 — Docker build and push to GHCR in pipeline - [x] Day 48 — Caching pip deps, measuring speed improvement - [x] Day 49 — Manual approval gates for production deploys -- [ ] Day 50 — Matrix builds, reusable workflows, artifacts -- [ ] Day 51 — Secrets and environment variables in pipelines +- [x] Day 50 — Matrix builds, reusable workflows, artifacts +- [x] Day 51 — Secrets and environment variables in pipelines #### Terraform (Infrastructure as Code) - [ ] Day 52 — First .tf file — provider, resource, plan, apply @@ -138,6 +131,13 @@ No copy-pasted theory. Everything here was typed and run by me. - [ ] Day 81 — Grafana Loki — structured logs, LogQL queries - [ ] Day 82 — Alertmanager — fire Slack alert on error spike +#### GoLang (Cloud Platform Kit Focus) +- [ ] Day 31 — Variables, data types, loops, functions, structs, interfaces, error handling +- [ ] Day 32 — File handling, JSON, environment variables, packages, modules (`go mod`) +- [ ] Day 33 — HTTP client/server (`net/http`), REST APIs, routing, middleware +- [ ] Day 34 — AWS SDK for Go (v2), IAM authentication, S3, STS, CloudWatch basics +- [ ] Day 35 — CLI tools (Cobra), logging, configuration management, project structure + **Phase 2 milestone:** Green CI pipeline on every push, ArgoCD deploying from Git, Grafana dashboard live ---