Day 51: Implement Production-Grade GitHub Actions Security & Deployment Concepts

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.

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
 
 ---