Module 3: Cloud Deployment & CI/CD: Case Studies
These case studies make the capstone deployable, auditable, and rollback-ready on a realistic solo-operator budget.
Case Study 1: Access Key In CI
Scenario: The capstone deploys with a long-lived cloud key stored in GitHub Actions secrets.
Source anchor: GitHub's OIDC security hardening documents how GitHub Actions can exchange an OIDC token for short-lived cloud credentials instead of storing static keys.
Module concepts: OIDC, CI identity, least privilege, deployment role.
Wrong Approach
Paste cloud access keys into CI.
Better Approach
Use OIDC:
GitHub workflow -> OIDC token -> cloud role trust policy -> short-lived credentials
Failure Mode
A leaked secret becomes a standing deployment credential, and the capstone cannot show modern CI identity or a clean audit story.
Project / Capstone Connection
Use this when wiring the deployment path for your capstone repository so cloud access is tied to repo, branch, and environment policy.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Static CI key | simple initial setup | rotation burden and larger blast radius | only when the platform cannot support federation |
| OIDC federation | short-lived credentials and better auditability | trust-policy setup effort | GitHub Actions deploys to a cloud provider that supports OIDC |
Required Artifact
Write an OIDC deployment identity note: repo, branch/environment, role, permissions, and audit event.
Case Study 2: Terraform State For A Solo Capstone
Scenario: The learner runs Terraform locally and loses the state file before the final demo.
Source anchor: Terraform backends explains remote state storage, locking support, and the operational consequences of backend choice.
Module concepts: state backend, locking, backup, blast radius.
Wrong Approach
Treat state as disposable generated output.
Better Approach
Choose a small safe backend:
remote state:
encrypted object storage or managed Terraform service
locking:
enabled if supported
backup:
versioned state bucket / provider history
Failure Mode
The team loses infrastructure truth, cannot safely change or destroy resources, and spends demo week reconstructing state from the cloud console.
Project / Capstone Connection
Use this for any capstone that provisions cloud resources with Terraform and needs repeatable changes across machines.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Local state file | minimal setup | easy loss and poor collaboration | throwaway experiments only |
| Remote backend | recoverability and shared truth | backend configuration overhead | the capstone has persistent infrastructure |
Required Artifact
Write a capstone IaC state plan with backend, access, lock recovery, and destroy policy.
Case Study 3: Rollback Not Rehearsed
Scenario: The app deploys successfully, but the first bad release takes 90 minutes to undo because rollback was never practiced.
Source anchor: Kubernetes Deployments documents rollout history and rollback behavior; the larger lesson is that rollback mechanics must be tested before a real incident.
Module concepts: rollback, smoke test, deployment marker, migration compatibility.
Wrong Approach
Assume rollback works because the platform supports it.
Better Approach
Rehearse:
deploy known good
deploy bad version
detect via smoke/SLO
rollback
time recovery
record steps
Failure Mode
Recovery commands, migration caveats, or health checks are wrong in the moment that matters, so a small release mistake becomes a long outage.
Project / Capstone Connection
Use this before your final capstone demo so you can show evidence that release failure has a practiced exit path.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Untested rollback assumption | saves time today | high recovery risk | never for demo-critical releases |
| Rehearsed rollback | faster incident response | setup time for practice release | the capstone is deployed and user-visible |
Required Artifact
Write a rollback runbook with trigger, command, expected time, DB migration caveat, and validation.
Case Study 4: Dev/Staging/Prod Budget Reality
Scenario: The capstone copies an enterprise three-environment setup and exceeds the monthly budget.
Source anchor: Environment strategy should come from costed deployment needs, not imitation; a capstone often proves enough with local development, a cheap shared staging space, and one real production target.
Module concepts: environment strategy, budget, preview environment, staging cutover.
Wrong Approach
Copy enterprise topology without cost justification.
Better Approach
Right-size:
dev:
local or ephemeral
staging:
shared low-cost environment
prod:
minimal but real
Failure Mode
Infrastructure spend and configuration overhead consume time that should have gone to reliability, documentation, and demo readiness.
Project / Capstone Connection
Use this when choosing how many environments your capstone genuinely needs to prove deployment competence.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Enterprise-like three-env stack | familiar separation model | higher spend and maintenance | funded team projects with shared QA workflow |
| Right-sized capstone topology | lower cost and simpler ops | less isolation between non-prod stages | solo capstones with limited budget |
Required Artifact
Write an environment matrix with monthly cost, purpose, data policy, and teardown rule.
Case Study 5: Feature Flag Becomes Permanent Architecture
Scenario: A feature flag saves a risky release. Three months later, old and new paths both still exist and tests must cover both.
Source anchor: Feature flags are useful because they decouple deploy from release, but only if each flag has an owner, an expiry signal, and a removal plan.
Module concepts: feature flag, release, cleanup, rollback.
Wrong Approach
Add flags without lifecycle.
Better Approach
Track:
flag:
new_ingestion_worker
owner:
capstone author
expiry:
after demo or two stable releases
cleanup:
remove old path and tests
Failure Mode
Temporary release controls harden into permanent complexity, raising test cost and making the system harder to reason about.
Project / Capstone Connection
Use this when a risky capstone change needs a reversible release switch without leaving long-term branch logic behind.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| No flag | less code complexity | harder rollback of risky behavior | release risk is already low |
| Flag with lifecycle | safer release and staged exposure | cleanup burden | the change is risky enough to justify temporary branching |
Required Artifact
Write a feature-flag registry with owner, purpose, default, expiry, and removal PR.
Source Map
| Source | Use it for |
|---|---|
| GitHub Actions OIDC | mapping GitHub Actions identity to short-lived cloud deployment access |
| Terraform backends | choosing remote state, locking, and recovery policy |
| Kubernetes Deployments | understanding rollout history and rollback behavior |
Completion Standard
- CI deploys without long-lived cloud keys.
- Terraform state plan is written.
- Rollback is rehearsed and timed.
- Environment cost matrix is complete.