Skip to content
advanced Phase 20 · AWS Capstone Project

Implementation & Deployment

Implement the AWS architecture with IaC, CI/CD, and monitoring.

3h
0 problems
Topic Progress 0%

Infrastructure as Code

Infrastructure as Code

Every resource the architecture needs — VPC, ALB, ASG/ECS service, RDS, IAM — lives in Terraform, CDK, or CloudFormation. Structure by environment with shared modules: dev and prod differ by variable files, not copy-pasted blocks. Nobody clicks in the console; a manual change becomes drift, detected by the next terraform plan showing an out-of-band edit.

The review workflow is the point: pull requests carry terraform plan output so reviewers see exactly which resources change, what is destroyed, and what IAM is granted. Keep state remote and locked (S3 + DynamoDB locking for Terraform), encrypt it, and run plan in CI on every push — a plan that only exists on someone's laptop is not a control.

Pipeline and Delivery

Pipeline and Delivery

A credible path: lint and unit tests → build image, push to ECR with scan gate → terraform apply to staging → integration tests against real infrastructure → manual approval → apply to production. The approval gate sits where risk first becomes expensive — after automated evidence, before customer impact.

Deploy strategies need mechanics, not slogans: blue/green swaps target groups behind the ALB so rollback is repointing traffic; canary shifts a slice of traffic via weighted target groups or Lambda aliases and aborts on alarm. Tag every artifact (image digest, commit SHA) so a rollback selects a known-good build rather than rebuilding hope.

Never deploy without an automatic tripwire: error-rate or latency alarm wired to halt the rollout.

Monitoring and Operations

Monitoring and Operations

Instrument from day one: CloudWatch alarms on ALB 5xx rate and target latency, custom business metrics, and a dashboard per service showing the four golden signals. SNS (or Chatbot) routes pages to the on-call channel; synthetic canaries catch the failures that never trip user alarms until churn follows.

Operational maturity shows in the unglamorous artifacts: runbooks with actual commands, SLOs with error budgets that justify feature freezes, and scheduled game days that prove rollback and failover still work. Logging strategy (retention, structured JSON, correlation IDs) decides whether an incident is a five-minute trace or a five-hour grep.

Interview: walk the commit-to-production path and name each gate — tests, scan, plan, approval, canary — and its rollback.

Quiz

1. Why run terraform plan in every pull request?

Question 1 options

2. What makes a blue/green rollback fast?

Question 2 options

3. What should halt a canary automatically?

Question 3 options

Flashcards

Question

Drift

Answer

Manual console changes diverging from code — surfaced by the next plan, fixed by re-applying code.

Question

Remote state + lock

Answer

Shared encrypted state with locking (e.g., S3+DynamoDB) so applies never collide.

Question

Delivery gates

Answer

Tests → image scan → staging apply → integration → approval → prod apply.

Question

Blue/green vs canary

Answer

Swap target groups (full flip) vs weighted slice with alarm-triggered abort.

Question

Four golden signals

Answer

Latency, traffic, errors, saturation — dashboarded with alarms and runbooks.

Revision Notes

Key Takeaways

  • 1. If it is not in version control, it does not exist — plan output belongs in PR review
  • 2. Delivery strategy plus automatic tripwires is what makes rollback real
  • 3. Alarms, runbooks, and game days convert architecture into operability

Interview Tips

  • • Tell the commit-to-production story with each gate and its rollback in order
  • • Describe a rollback you have actually rehearsed — including how long it took

Cheat Sheet

IaC: remote state+lock; plan in PRs; envs via variables. Pipeline: tests → ECR scan → staging → integration → approval → prod; canary/blue-green + alarm tripwire. Alarm 5xx/latency; runbooks.

Continue Learning