Cargando...
Cargando...
Master every AWS-native deployment strategy, pipeline pattern, and exam trap to ace DevOps and Developer certification questions
CI/CD on AWS combines CodeCommit, CodeBuild, CodeDeploy, and CodePipeline into automated delivery workflows, but the real exam value lies in knowing WHICH deployment strategy (blue/green, canary, rolling, in-place) to apply for a given scenario and WHY. AWS certifications test your ability to select the right pipeline pattern based on constraints like zero-downtime requirements, rollback speed, cost sensitivity, and the target compute platform (EC2, ECS, Lambda, Elastic Beanstalk). Understanding the full service ecosystem and how they integrate — including third-party tools like Jenkins and GitHub — is essential for both the Developer Associate and DevOps Engineer Professional exams.
Exams present scenario-based questions requiring you to select the correct deployment strategy and pipeline architecture given specific constraints — speed of rollback, traffic shifting method, cost, and target platform are the primary differentiators.
In-Place (Rolling) Deployment
CodeDeploy stops the old application version and installs the new version on the SAME set of instances. Instances are temporarily taken out of service during deployment. With EC2/On-Premises, you can configure batch size (e.g., one at a time, half at a time, all at once) to control availability impact.
Cost-sensitive workloads where you cannot afford duplicate infrastructure. Acceptable to have brief capacity reduction. Best for non-critical internal services where a few minutes of degraded capacity is tolerable.
Rollback is slow — CodeDeploy must redeploy the previous version to all instances. No true zero-downtime unless behind a load balancer with careful batch sizing. Risk of mixed-version serving during the rollout window.
Blue/Green Deployment
Two identical environments (blue = current, green = new) run simultaneously. Traffic is shifted from blue to green all at once (or gradually). For EC2, CodeDeploy creates a new Auto Scaling Group. For ECS, the new task set is created alongside the old one. For Lambda, a new function version is published and traffic is shifted via aliases.
Zero-downtime requirements, fast rollback needs, production workloads where you cannot tolerate errors reaching all users. Required when the exam mentions 'instant rollback' or 'minimize downtime.'
Costs roughly 2x infrastructure during the transition window. Requires stateless architecture or shared data layer to avoid split-brain. Database schema changes must be backward-compatible.
Canary Deployment
A small percentage of traffic (e.g., 10%) is shifted to the new version first. If CloudWatch alarms stay green for a bake period, the remaining traffic is shifted. CodeDeploy supports canary configurations for Lambda (e.g., LambdaCanary10Percent5Minutes) and ECS. AWS CodeDeploy + CloudWatch Alarms can trigger automatic rollback if error rates spike.
High-risk releases where you want real-user validation before full cutover. Ideal when the question mentions 'test with a subset of users,' 'gradual traffic shift,' or 'automatic rollback on errors.'
More complex to configure. Requires robust monitoring and alarm thresholds. Users may experience inconsistent behavior if sessions are not sticky. Not natively supported for EC2 in-place — use ALB weighted target groups instead.
Linear Deployment
Traffic is shifted in equal increments at regular intervals (e.g., 10% every 10 minutes until 100%). CodeDeploy provides built-in Linear configurations for Lambda and ECS (e.g., LambdaLinear10PercentEvery1Minute). More controlled than canary's two-step approach.
When you need predictable, steady traffic migration with continuous monitoring at each step. Choose over canary when the exam mentions 'equal increments over time' or 'gradual and consistent traffic shift.'
Slower full cutover than canary. Old and new versions serve traffic simultaneously for longer, increasing complexity of logging and tracing.
All-at-Once (Immutable) Deployment via Elastic Beanstalk
Elastic Beanstalk offers multiple deployment policies: All-at-once (fastest, has downtime), Rolling, Rolling with additional batch (maintains full capacity), Immutable (new instances in new ASG, then swap), and Blue/Green (swap environment URLs via CNAME swap). Immutable is the safest Beanstalk option for production — new instances are launched, health-checked, then swapped in.
Elastic Beanstalk-managed applications. Use Immutable when zero downtime AND fast rollback are required within Beanstalk. Use Blue/Green Beanstalk when you need full environment isolation and DNS-level cutover.
Immutable doubles instance count temporarily. Blue/Green Beanstalk swaps CNAMEs which can have DNS TTL propagation delays. All-at-once is only acceptable for dev/test environments.
Pipeline Orchestration with CodePipeline
CodePipeline orchestrates multi-stage pipelines: Source → Build → Test → Deploy. Stages contain actions that can run sequentially or in parallel. Supports manual approval actions, Lambda invoke actions, and cross-account/cross-region deployments. Integrates with CodeCommit, S3, GitHub, Bitbucket as sources; CodeBuild for build/test; CodeDeploy, CloudFormation, ECS, Elastic Beanstalk for deploy.
Any scenario requiring automated, multi-stage software delivery with audit trails, manual gates, or cross-account deployments. The default AWS-native answer for 'fully managed CI/CD pipeline.'
CodePipeline itself does not build or deploy — it orchestrates other services. Each pipeline action has a timeout; long-running builds should use CodeBuild with appropriate timeout configuration. Cross-region actions require artifact replication to regional S3 buckets.
Infrastructure as Code Pipeline (CDK/CloudFormation + CodePipeline)
CDK Pipelines (a construct library) or CloudFormation StackSets deployed via CodePipeline enable infrastructure delivery alongside application code. CloudFormation change sets can be created and reviewed before execution, enabling a manual approval gate on infrastructure changes.
When the exam asks about deploying infrastructure changes safely with human review gates, or managing multi-account/multi-region infrastructure rollouts. Key pattern for DevOps Professional exam.
CloudFormation stack updates can fail mid-way, leaving stacks in UPDATE_ROLLBACK_FAILED state requiring manual intervention. CDK Pipelines add abstraction complexity but reduce boilerplate.
STEP 1 — Identify the compute target:
• EC2/On-Premises → CodeDeploy in-place or blue/green (new ASG). ECS → CodeDeploy blue/green (new task set) or rolling update. Lambda → CodeDeploy canary/linear via aliases. Elastic Beanstalk → use Beanstalk deployment policies directly. |
STEP 2 — Assess downtime tolerance:
• Zero downtime required → eliminate in-place/all-at-once. Must choose blue/green, canary, or linear. |
STEP 3 — Assess rollback speed requirement:
• Instant rollback needed → blue/green (just shift traffic back). Slower rollback acceptable → rolling or in-place. |
STEP 4 — Assess cost sensitivity:
• Cannot afford 2x infrastructure → avoid blue/green. Use rolling with additional batch (Beanstalk) to maintain capacity without doubling. |
STEP 5 — Assess risk tolerance for new release:
• High risk, want real-user validation → canary or linear. Low risk or internal service → rolling or all-at-once. |
STEP 6 — Check for automatic rollback requirement:
• Automatic rollback on CloudWatch alarm → CodeDeploy with alarm-based rollback for Lambda/ECS canary/linear. |
• STEP 7 — Multi-stage pipeline needed → CodePipeline. Manual approval gate → CodePipeline Manual Approval action with SNS notification.
CodeDeploy blue/green for Lambda does NOT create new infrastructure — it publishes a new Lambda version and shifts traffic between the old and new version via the function alias. 'Infrastructure' in Lambda blue/green is just alias weights.
CodeDeploy appspec.yml is REQUIRED for all CodeDeploy deployments. For EC2/On-Premises it defines lifecycle hooks (BeforeInstall, AfterInstall, ApplicationStart, ValidateService). For ECS it defines the task definition, container name, and port. For Lambda it defines the function name and alias. The file location and structure differs per platform — this is a common exam question.
Elastic Beanstalk Blue/Green is NOT a native CodeDeploy deployment type — it is done by cloning the environment and swapping CNAME URLs. This means DNS TTL can cause a delay in full traffic cutover. Exam questions that say 'instant cutover' for Beanstalk should point to Immutable, not Blue/Green.
CodePipeline actions within the same stage run in PARALLEL by default. Actions in different stages run SEQUENTIALLY. To run two build actions simultaneously, put them in the same stage. This is frequently tested in pipeline design questions.
CodeDeploy appspec.yml structure and lifecycle hooks differ per compute platform (EC2, ECS, Lambda) — memorize which hooks exist for each platform and what CodeDeploy blue/green means differently for each (new ASG for EC2, new task set for ECS, alias weight shift for Lambda).
CodePipeline is an ORCHESTRATOR only — it never builds or deploys code itself. Always identify CodeBuild for build failures and CodeDeploy/CloudFormation for deployment failures when troubleshooting pipeline issues.
Elastic Beanstalk Immutable = fastest rollback (terminate new ASG, no DNS delay). Blue/Green Beanstalk = full environment isolation but CNAME swap has DNS TTL delay. Never confuse these two for rollback speed questions.
CodeBuild uses buildspec.yml to define build phases (install, pre_build, build, post_build) and artifacts. If buildspec.yml is not in the root of the source code, you must specify its location in the CodeBuild project configuration. Environment variables can be stored in SSM Parameter Store or Secrets Manager and referenced in buildspec.
For cross-account CodePipeline deployments, the pipeline's S3 artifact bucket must have a bucket policy granting the target account access, AND the CodeDeploy/CloudFormation role in the target account must have a trust policy allowing the pipeline's account. KMS CMK encryption of artifacts is required for cross-account scenarios.
CodeDeploy 'Rolling with additional batch' in Elastic Beanstalk launches extra instances FIRST before taking any existing instances out of service — this maintains 100% capacity throughout the deployment. Standard 'Rolling' temporarily reduces capacity by the batch size. Know the difference for capacity-sensitive exam scenarios.
CodeCommit triggers can invoke Lambda or send SNS notifications on repository events (push, PR creation). CodePipeline source stage detects CodeCommit changes via CloudWatch Events (EventBridge) — NOT polling. This is important for understanding latency and architecture of the source detection mechanism.
Manual Approval actions in CodePipeline send an SNS notification. The approver must respond within a configurable timeout or the pipeline execution expires. You can include a custom approval URL and comments. This is the correct answer for 'human gate before production deployment' scenarios.
Common Mistake
CodePipeline performs the build and deployment itself — it's an all-in-one CI/CD tool.
Correct
CodePipeline is ONLY an orchestrator. It delegates build to CodeBuild (or Jenkins), deployment to CodeDeploy (or CloudFormation, ECS, Beanstalk), and source to CodeCommit/S3/GitHub. CodePipeline itself has no build or deploy capability.
Exam questions often describe a build failure and ask which service to investigate — the answer is CodeBuild, not CodePipeline. Confusing orchestration with execution leads to wrong service selection in troubleshooting scenarios.
Common Mistake
Blue/Green deployment means zero cost overhead because you just rename the environments.
Correct
Blue/Green requires running TWO full environments simultaneously during the cutover window. For EC2-based workloads, this doubles instance costs for the duration. For Lambda and ECS, the overhead is minimal since you're shifting traffic weights, not running duplicate infrastructure at scale.
Cost-optimization questions will describe a scenario where blue/green is proposed for an EC2 fleet — the correct answer flags the temporary cost doubling as a tradeoff, not a free feature.
Common Mistake
Canary deployments on Lambda require custom traffic-shifting logic in the function code.
Correct
Lambda canary and linear traffic shifting is fully managed by CodeDeploy using Lambda Aliases. You configure the deployment preference type (Canary10Percent5Minutes, Linear10PercentEvery1Minute, etc.) in the CodeDeploy deployment group and appspec.yml. No application code changes are needed.
Candidates try to implement traffic shifting in application logic when CodeDeploy handles it natively via alias weights. This leads to over-engineered solutions on the exam and in practice.
Common Mistake
CodeDeploy automatically rolls back if a deployment fails on any instance.
Correct
Automatic rollback in CodeDeploy must be EXPLICITLY configured — either trigger on deployment failure OR trigger on CloudWatch Alarm thresholds being breached. By default, a failed deployment stops and leaves successfully-updated instances on the new version while failed instances remain on the old version, creating a mixed-version state.
This mixed-version state is a critical exam concept. Questions about 'what happens when a rolling deployment fails halfway' test whether you know that without rollback configuration, you get version inconsistency across your fleet.
Common Mistake
You can use CodeDeploy to deploy to ECS Fargate using the same in-place deployment type used for EC2.
Correct
ECS deployments via CodeDeploy ONLY support the Blue/Green deployment type (ECS_BLUE_GREEN). There is no in-place deployment for ECS. CodeDeploy creates a new task set, shifts traffic via the ALB listener rules, and then terminates the old task set after a configurable wait time.
Selecting 'in-place' for an ECS CodeDeploy question is a trap. ECS container-based architecture makes in-place meaningless — containers are immutable by design, so blue/green is the only supported model.
Common Mistake
Elastic Beanstalk Immutable and Blue/Green deployments are the same thing with different names.
Correct
Immutable launches new instances in a NEW Auto Scaling Group within the SAME Beanstalk environment, then merges them. Blue/Green in Beanstalk creates an entirely SEPARATE environment and swaps CNAMEs. Immutable rollback is instant (terminate the new ASG). Blue/Green rollback is a CNAME re-swap which has DNS propagation delay.
Exam questions about 'fastest rollback in Elastic Beanstalk' should point to Immutable, not Blue/Green, because Immutable rollback doesn't depend on DNS TTL propagation.
SCBD Pipeline = Source → Code(Build) → (Code)Deploy via (Code)Pipeline — the four Code* services in order
For deployment strategy selection: 'DIRT' — Downtime tolerance, Infrastructure cost, Rollback speed, Traffic risk → maps to In-Place, Rolling, Blue/Green, Canary
AppSpec file = 'A Perfectly Specific Config' — different for each platform (EC2 hooks, ECS task def, Lambda alias)
CodePipeline stages are SEQUENTIAL, actions within a stage are PARALLEL — 'Stages Swim in Series, Actions Act in Parallel'
Selecting 'in-place' CodeDeploy deployment for ECS workloads — ECS via CodeDeploy ONLY supports Blue/Green (ECS_BLUE_GREEN). Simultaneously, candidates confuse CodePipeline as the service that 'does the building' when it only orchestrates CodeBuild and CodeDeploy.
CertAI Tutor · · 2026-02-22
Key Services
Comparisons
Guides & Patterns