AWS CI/CD Pipeline Architecture — Overview
A CI/CD (Continuous Integration / Continuous Delivery) pipeline automates the build, test, and deployment of applications. On AWS, this is a core architecture pattern for DOP-C02 (DevOps Professional) and frequently appears in SAP-C02 questions around deployment strategies, rollback mechanisms, and multi-environment promotion.
GitHub / GitLab
S3 (artifacts)
Compile + Unit Test
Docker Build
SAST / SCA
Integration Tests
DAST / Load Test
Deploy to Staging
Blue/Green
Canary / Rolling
CloudFormation
X-Ray
Alarms → Rollback
Dashboard
Secrets Manager (creds)
IAM Roles (least-privilege)
ECR Scan (container vuln)
S3 (pipeline artifacts)
ECR (container images)
CodeArtifact (packages)
CloudFormation / CDK
Terraform
StackSets (multi-account)
Pipeline Stages — Deep Dive
1. Source Stage
- CodeCommit — AWS-managed Git (being deprecated — use GitHub/GitLab connections)
- GitHub / GitLab / Bitbucket — via CodeStar Connections (OAuth-based)
- S3 — Triggered on object upload (for artifact-based pipelines)
- ECR — Trigger on new image push (for container deployments)
- Trigger: EventBridge rule on push → starts pipeline automatically
2. Build Stage (CodeBuild)
- Managed compute — No servers to manage, scales automatically, pay per build-minute
- buildspec.yml — Defines build commands (install, pre_build, build, post_build phases)
- Tasks: Compile code, run unit tests, build Docker image, run SAST (CodeGuru/Snyk), generate artifacts
- Caching: S3 or local cache for dependencies (reduces build time 50-70%)
- Reports: Test reports (JUnit XML), code coverage reports integrated into CodeBuild console
3. Test Stage
- Integration tests — Deploy to staging, run API/E2E tests against live environment
- DAST (Dynamic testing) — Run security scans against deployed staging environment
- Load testing — Verify performance with realistic traffic patterns
- Manual approval — Optional gate requiring human sign-off before production
4. Deploy Stage
| Strategy | How It Works | Rollback | Best For |
|---|---|---|---|
| In-Place (Rolling) | Replace instances one at a time | Redeploy previous version | EC2 with minimal downtime tolerance |
| Blue/Green | Deploy new (green) alongside old (blue), switch traffic | Switch back to blue (instant) | Zero-downtime, instant rollback |
| Canary | Route small % of traffic to new version, monitor, expand | Route back to 100% old | Gradual validation, risk-averse deployments |
| Linear | Increase traffic in equal increments (e.g., 10% every 10min) | Route back to old | Predictable, time-boxed rollouts |
| All-at-Once | Replace everything simultaneously | Redeploy (downtime) | Dev/test environments only |
5. Monitor & Rollback
- CloudWatch Alarms — Monitor error rates, latency P99, 5xx count post-deployment
- Auto-rollback — CodeDeploy rolls back if CloudWatch alarm triggers during deployment
- X-Ray — Distributed tracing to identify performance regressions
- CloudWatch Synthetics — Canary scripts that validate endpoints post-deploy
Deployment Targets
| Target | Deploy Tool | Strategy Support |
|---|---|---|
| EC2 | CodeDeploy Agent | In-place, Blue/Green (with ASG) |
| ECS (Fargate/EC2) | CodeDeploy + ECS | Blue/Green, Canary, Linear |
| Lambda | CodeDeploy + Lambda aliases | Canary, Linear, All-at-Once |
| EKS / Kubernetes | kubectl / Helm / Flux / ArgoCD | Rolling, Blue/Green (via service mesh) |
| CloudFormation/CDK | CloudFormation action in pipeline | Stack updates, ChangeSets with review |
Cross-Account CI/CD Pipeline
Production-grade pipelines deploy across accounts (Dev → Staging → Prod in separate accounts):
- Pipeline in Tooling/Shared Services account — Centralized pipeline with cross-account roles
- S3 artifact bucket — Encrypted with KMS key shared to target accounts
- Cross-account IAM roles — Pipeline assumes deployment role in each target account
- KMS key policy — Allow target account roles to decrypt artifacts
- Manual approval — Required before production account deployment
Exam Tips by Certification
| Exam | Focus Areas |
|---|---|
| DOP-C02 | Deployment strategies (Blue/Green vs Canary vs Rolling), auto-rollback triggers, cross-account pipelines, buildspec.yml, CodeDeploy appspec, pipeline troubleshooting |
| SAP-C02 | Multi-region deployment pipelines, StackSets for multi-account IaC, deployment strategy selection for specific availability requirements, DR-aware deployments |
AWS Certification Exam Practice Questions
Question 1:
A company deploys a microservices application on ECS Fargate. They need zero-downtime deployments with the ability to roll back within seconds if the new version shows elevated error rates. Which deployment strategy should they use?
- ECS rolling update with minimum healthy percent 100%
- CodeDeploy Blue/Green deployment with ECS and CloudWatch alarm-triggered rollback
- CodeDeploy Canary (10% for 5 minutes) with ECS
- In-place deployment with health checks
Show Answer
Answer: B – Blue/Green with ECS creates a new task set (green) alongside the old (blue). Traffic switches via the ALB target group. If CloudWatch alarms fire (elevated errors), CodeDeploy instantly routes all traffic back to blue. Rollback is seconds (just a target group switch). Canary works too but rollback isn’t as instantaneous since traffic is split.
Question 2:
A DevOps team’s CodePipeline deploys to three accounts: Dev, Staging, and Production. The pipeline’s artifact bucket is in the Tooling account. Deployments to Staging and Production fail with “Access Denied” on the artifact. What is MOST likely missing?
- The artifact S3 bucket policy doesn’t allow the cross-account roles to GetObject
- The KMS key policy doesn’t grant decrypt permissions to the Staging/Production account roles
- The pipeline execution role doesn’t have sts:AssumeRole for target accounts
- CodeDeploy is not installed in the target accounts
Show Answer
Answer: B – Cross-account pipelines encrypt artifacts with KMS. Even if the S3 bucket policy allows access, the target account roles also need kms:Decrypt on the CMK. This is the most commonly missed configuration in cross-account pipelines. Both S3 bucket policy AND KMS key policy must grant access, but KMS is the more common oversight.
Question 3:
A team wants their Lambda function deployments to gradually shift traffic from the old version to the new — 10% initially, wait 10 minutes, then 100%. If errors spike during the 10% phase, it should automatically roll back. Which configuration achieves this?
- Lambda versioning with manual alias update
- CodeDeploy with deployment preference Canary10Percent10Minutes
- CodeDeploy with deployment preference Linear10PercentEvery10Minutes
- API Gateway canary release with 10% traffic
Show Answer
Answer: B – Canary10Percent10Minutes shifts 10% of traffic to the new version, waits 10 minutes monitoring CloudWatch alarms, then shifts the remaining 90% if no alarms fire. If alarms trigger during the wait, it automatically rolls back to 100% on the old version. Linear would shift 10% every 10 minutes incrementally (10→20→30…) which is slower.
Question 4:
A company needs their CI/CD pipeline to automatically detect security vulnerabilities in application dependencies before deployment. If critical vulnerabilities are found, the pipeline should stop. What should they add to the Build stage?
- Amazon Inspector scan on the deployed EC2 instances
- CodeBuild step running Software Composition Analysis (SCA) with a fail condition on critical findings
- AWS Config rule checking for unpatched instances
- GuardDuty findings integration with CodePipeline
Show Answer
Answer: B – SCA tools (Snyk, OWASP Dependency Check, npm audit) run during CodeBuild to scan dependencies for known CVEs. The buildspec.yml can include a step that fails the build if critical vulnerabilities are found, stopping the pipeline before deployment. Inspector scans deployed resources (too late), not source dependencies.
Question 5:
A company uses CloudFormation to manage infrastructure. Before deploying changes to production, they want to review exactly what will change without applying it. Which pipeline action enables this?
- CloudFormation Deploy action with CHANGE_SET_EXECUTE mode
- CloudFormation Deploy action with CHANGE_SET_CREATE mode + Manual Approval + CHANGE_SET_EXECUTE
- CloudFormation Validate action followed by Deploy action
- CloudFormation Detect Drift action before Deploy
Show Answer
Answer: B – CHANGE_SET_CREATE generates a change set showing exactly what will be added, modified, or deleted — without executing it. Adding a Manual Approval gate allows a human to review the changes. Only after approval does CHANGE_SET_EXECUTE apply the changes. This is the standard review-before-deploy pattern for production IaC.
Frequently Asked Questions
What is the difference between CodePipeline and CodeCatalyst?
CodePipeline is the traditional CI/CD orchestrator (pipeline stages + actions). CodeCatalyst is a newer unified development platform that includes project management, repositories, CI/CD workflows, dev environments, and team collaboration. CodeCatalyst uses a different workflow engine (YAML-based) and is designed for full software development lifecycle, not just deployment.
When should I use Blue/Green vs Canary deployment?
Use Blue/Green when you want instant rollback capability and zero-downtime cutover (best for critical applications). Use Canary when you want to validate with a small percentage of real traffic first before full rollout (best for risk-averse, gradual validation). Blue/Green switches 100% at once; Canary tests with a small slice first.
How do I handle database schema changes in CI/CD?
Use backward-compatible migrations: deploy code that works with both old and new schema, apply schema migration, then deploy code that uses only the new schema. Tools like Flyway or Liquibase in a CodeBuild step handle this. Never make breaking schema changes in a single deployment.