In the DOP-C02 exam, deployment strategies are among the most heavily tested topics. Beyond knowing the names of strategies, you need to determine which strategy is optimal for specific business requirements — acceptable downtime, rollback speed, capacity maintenance during deployment, and cost constraints. Understanding the full flow from artifact management to deployment execution is essential.
Artifact Management Services
Amazon ECR - Container Image Registry
ECR is a fully managed container registry for storing Docker images. Key ECR topics for the exam:
Image tags vs image digests: The tag is mutable — a new image pushed to ECR with the tag doesn't guarantee that already-running tasks will use the new image, because ECS may use a cached version. Image digests (SHA256 hashes) are immutable identifiers that pin an exact image. Specifying an image as in an ECS task definition guarantees the same image is always used, regardless of caching behavior.
ECR image scanning: Basic scanning (automatic vulnerability check on push) and enhanced scanning (Inspector v2 integration with continuous monitoring). EventBridge can trigger automated responses when vulnerabilities are discovered.
Cross-account ECR access: Repository policies allow EC2 instances or ECS tasks in other AWS accounts to pull images, enabling centralized image management across organizational units.
AWS CodeArtifact - Package Repository
CodeArtifact provides private repositories for npm, pip, Maven, Gradle, and other package formats. Upstream connections to public registries (PyPI, npm registry, Maven Central) automatically cache packages, reducing internet dependencies and enabling security controls on which packages can be used in builds.
EC2 Image Builder - AMI Automation
EC2 Image Builder automates the creation, testing, and distribution of AMIs. An image recipe defines the base AMI, software components to install, and validation tests. Image pipelines run on a schedule to automatically produce updated AMIs. Integration with Elastic Beanstalk or ASG Launch Templates ensures the latest AMI is always used.
Exam scenario: "Instance startup after Auto Scaling scale-out takes 15 minutes due to large library installation, slowing responsiveness during traffic spikes." The solution is creating a Golden AMI with pre-installed libraries using EC2 Image Builder. This is explicitly different from .ebextensions runtime installation (which installs on each boot).
Deployment Strategy Comparison
EC2 Deployment Strategies
CodeDeploy In-place deployment options: AllAtOnce: All instances updated simultaneously. Fastest deployment. Downtime occurs during update. OneAtATime: One instance at a time sequentially. Slowest. Maximum availability maintained. No additional cost. HalfAtATime: Half the instances at a time. Balanced speed and availability.
CodeDeploy Blue/Green deployment: Provisions a new Auto Scaling group (Green) alongside the existing group (Blue). ALB target group switching transfers traffic instantly. Full capacity is maintained during deployment. Immediate rollback is possible by switching back. Temporary cost doubles due to running two complete environments.
ALB weighted target groups for canary: Register two ASGs as separate target groups and adjust weights in the ALB listener rule. Start with 5% weight on the new version target group and increase gradually. Setting the new version weight to 0 achieves instant rollback. This enables finer-grained traffic ratio control than Route 53 weighted routing, which has DNS TTL propagation delays.
ASG Instance Refresh: After updating the AMI in a Launch Template, start an Instance Refresh to automatically replace old instances with new ones while maintaining MinHealthyPercentage (default 90%). No separate agent installation or complex deployment group configuration required — a single API call initiates the process. The exam uses this for "hundreds of EC2 instances need new AMI without manual SSH access."
Elastic Beanstalk Deployment Strategies Deep Dive
Elastic Beanstalk offers five deployment policies. The exam requires precise differentiation between them.
| Policy | Downtime | Rollback | Cost | Key Characteristic | |--------|----------|----------|------|-------------------| | All at once | Yes | Redeploy required | None | Fastest, simplest | | Rolling | No (reduced capacity) | Redeploy required | None | Versions mixed during deploy | | Rolling with additional batch | No (full capacity maintained) | Redeploy required | Small temporary addition | Cost-efficient capacity maintenance | | Immutable | No | Immediate (terminate new ASG) | Temporary double | Safe rollback within single environment | | Traffic splitting | No | Ratio readjustment | Temporary additional | Canary A/B testing |
Immutable Deployment Key Characteristics
Immutable deploys new instances to a completely separate temporary ASG, isolated from the existing production ASG. After health checks pass, instances migrate to the existing ASG and the temporary ASG is deleted. If deployment fails, terminating the temporary ASG is all that's needed — the original instances are completely unaffected. Unlike Blue/Green (which requires a separate Beanstalk environment plus CNAME swap), Immutable operates within a single environment.
When to Use CNAME Swap vs Immutable
Both provide zero-downtime deployment and fast rollback. CNAME swap is optimal when two separate Beanstalk environments (staging and production) already exist — traffic switching is a DNS-level change with near-zero downtime. Immutable is appropriate when managing a single environment without needing a parallel staging environment.
!CNAME Swap versus Immutable deployment
Lambda Deployment Strategies
Lambda Aliases and Versions
A Lambda version is an immutable snapshot of code and configuration at a specific point in time. A Lambda alias is a pointer to a specific version (or two versions with weighted routing). When callers use the alias ARN, traffic can be shifted to different underlying versions without any code changes on the calling side.
CodeDeploy Lambda Deployment Configurations
LambdaCanary10Percent5Minutes: 10% of traffic to new version for 5 minutes, then 100% cutover LambdaLinear10PercentEvery1Minute: 10% more traffic to new version every minute, reaching 100% after 10 minutes
The BeforeAllowTraffic hook in appspec.yml runs a validation Lambda function before any traffic shifts to the new version. This can verify database schema migration completion, API endpoint readiness, or any other prerequisite. Failure triggers automatic rollback before any users experience the new version.
SAM AutoPublishAlias + DeploymentPreference
In a SAM template, setting AutoPublishAlias automatically publishes a new Lambda version on each deployment and attaches it to the named alias. Adding DeploymentPreference configures CodeDeploy canary or linear deployment automatically. The entire setup requires only YAML changes to the SAM template — the existing CI/CD pipeline requires no modification.
ECS Deployment Strategies
ECS Rolling Update
Updates the service by gradually replacing tasks with the new task definition. MinimumHealthyPercent and MaximumPercent control the replacement rate. Simple to configure but does not provide test listener isolation or instant rollback capability.
CodeDeploy ECS Blue/Green
Configures ALB with a test listener (port 8080) separate from the production listener (port 80/443). The new task set (Green) is validated through the test listener before any production traffic touches it. The AfterAllowTestTraffic hook runs automated tests against the Green environment. Only after successful validation does CodeDeploy shift production traffic. Problems trigger instant rollback to the Blue task set.
ECR image tagging discipline: Using tags on ECS task definitions is a documented anti-pattern — running tasks may use cached older images even after a new image is pushed. Pinning to image digests combined with bundling all dependencies in the Dockerfile at build time (not downloading at runtime) eliminates both the versioning ambiguity and the external dependency risk.
Exam Key Points
"replace AMI on hundreds of EC2 instances in Auto Scaling without downtime" -- ASG Instance Refresh (update Launch Template AMI, start refresh, maintains MinHealthyPercentage)
"maintain full capacity during Beanstalk deployment with minimal extra cost" -- Rolling with additional batch (more cost-efficient than Immutable)
"zero-downtime deployment with instant rollback in a single Beanstalk environment" -- Immutable deployment
"instant traffic switch between two Beanstalk environments with rollback capability" -- URL Swap (CNAME exchange)
"EC2-based canary deployment with fine-grained traffic ratio control" -- ALB weighted target groups (two ASGs, adjust weights in listener rule)
"Lambda new version 10% traffic first then gradual cutover with automatic rollback" -- CodeDeploy LambdaCanary deployment configuration + CloudWatch Alarm rollback trigger
"validate database schema readiness before Lambda traffic cutover" -- CodeDeploy BeforeAllowTraffic lifecycle hook (validation Lambda function)
"isolate and validate ECS Green environment before production traffic cutover" -- CodeDeploy ECS Blue/Green + test listener (port 8080) + AfterAllowTestTraffic hook
"reduce EC2 instance startup time from 15 minutes to seconds" -- EC2 Image Builder Golden AMI with pre-installed libraries
"guarantee exact image version used by ECS tasks" -- ECR image digest (sha256) pinning + bundle all dependencies in Dockerfile at build time