2.3. Reflection Checkpoint: Core DevOps Practices on AWS

Key Takeaways

• A CI/CD pipeline's job is "flow" — a smooth, automated progression from commit to production across four core AWS services, each handling a distinct stage (source, build/test, deploy, orchestrate) — knowing which service owns which stage is heavily tested.
• Testing must be embedded at every pipeline stage (unit, integration, performance, security scans), not bolted on at the end — the cost of a bug reaching production compounds fast under load.
• Artifacts must be immutable and integrity-verified: if "version 2.3" behaves differently in production than staging, the artifact wasn't truly reproducible, and a compromised dependency can propagate silently through the whole pipeline.
• Deployment strategy is chosen by the service's operational model and the acceptable blast radius — an in-place update to a stateful EC2 fleet carries very different risk than a blue/green or canary release.
• Infrastructure as Code (CloudFormation, CDK, SAM, Terraform) is a recipe, not cooking by feel — the upfront cost of writing templates pays off the moment you need to replicate an environment across 50 accounts or roll back a bad change reliably.
• A single AWS account is a single blast radius — AWS Organizations, Control Tower, and Service Control Policies exist specifically so one compromised credential or misconfigured IAM policy in dev can't reach production.
• Systems Manager, Lambda, and Step Functions automate operational tasks (patching, credential rotation, compliance checks) with audit trails and rollback capability that ad-hoc scripting doesn't provide.

Connecting Forward

Phase 2 built the operational backbone: pipelines that ship code safely, and infrastructure managed as versioned, auditable code. Phase 3 goes deeper into what happens after deployment — designing for resilience at scale, achieving real observability, responding to incidents, and securing the whole system.

Self-Check Questions

• Your CI/CD pipeline builds and tests successfully, but the resulting container image behaves differently in production than it did in staging. What principle from this phase was violated, and which stage of the pipeline is responsible for catching it?
• A single compromised IAM credential in your development AWS account somehow triggered changes in production. What multi-account control should have prevented this, and why does "put everything in one account" fail at scale?