Step 1 — SDLC & CI/CD
If you’ve shipped software to production more than a handful of times, you already know the uncomfortable truth this exam is built around: the pipeline is the product. DOP-C02 doesn’t ask you to name services — it asks you to defend architectural decisions about how code moves from a developer’s laptop to a fleet serving live traffic, without waking anyone up at 3 a.m. This step is about building that judgment.
Why the Pipeline Is the Unit of Design
Associate-level thinking treats CI/CD as “CodePipeline connects CodeBuild to CodeDeploy.” Professional-level thinking treats the pipeline as a distributed system with its own failure modes: partial deployments, stale artifacts, permission boundaries between stages, and rollback semantics that have to work even when the thing that broke is the deployment mechanism itself.
A pipeline you’ll be expected to reason about looks like this:
Source Stage Build Stage Test Stage Deploy Stage────────────── ────────────── ────────────── ──────────────────CodeCommit / GitHub ─► CodeBuild ─► CodeBuild (test) ─► CodeDeploy (webhook trigger) - compile - integration - EC2/ASG - unit test - security scan - ECS - package artifact - CFN lint - Lambda - push to ECR/S3 - traffic shift │ ▼ CloudWatch Alarms │ ┌─────────┴─────────┐ ▼ ▼ Healthy → proceed Unhealthy → rollbackNotice what’s implicit in that diagram: the deploy stage doesn’t just push code, it watches an alarm and decides whether to keep going. That’s the professional-level shift — deployment is a control loop, not a one-way push.
CodePipeline Mechanics Worth Internalizing
CodePipeline is an orchestrator, not a build tool and not a deployment engine. Every stage runs actions in parallel unless you sequence them, and every action reads input artifacts from and writes output artifacts to an S3 bucket that CodePipeline manages on your behalf (or one you supply with a KMS key for cross-account encryption — more on that shortly).
A few mechanics the exam leans on hard:
- Stage transitions can be disabled manually. Useful for freezing a pipeline during an incident without deleting anything.
- Manual approval actions pause the pipeline until a human (or a Lambda function invoked via the approval API) approves. Commonly placed before a production deploy stage.
- Pipeline executions are superseded, not queued indefinitely. If commit B arrives while commit A’s execution is still running, and A hasn’t reached the stage B is entering, B’s execution can supersede A’s. This matters for questions about “which commit actually gets deployed” under rapid pushes.
- CodeStar Connections (now just called Connections) is the modern way to link GitHub, GitLab, or Bitbucket — replacing the old OAuth token approach. Expect DOP-C02 to test third-party source integration using this mechanism.
Multi-Account, Multi-Region Pipeline Architecture
This is where the exam stops being about a single pipeline and starts being about an organization’s software delivery system. The standard pattern, and the one you should default to when a scenario mentions “separate environments” or “compliance boundary between prod and non-prod”:
Tooling Account (CI/CD hub) ┌───────────────────────────────────┐ │ CodePipeline │ │ CodeBuild (build/test) │ │ Artifact S3 bucket (KMS CMK) │ └───────┬─────────────┬───────────────┘ │ │ cross-account role cross-account role │ │ ┌───────────▼───┐ ┌─────▼───────────┐ │ Dev Account │ │ Staging Account │ │ CodeDeploy │ │ CodeDeploy │ └───────────┬─────┘ └─────┬────────────┘ │ │ auto-promote manual approval gate │ │ └───────┬───────┘ ▼ ┌───────────────────┐ │ Prod Account │ │ (us-east-1 + │ │ eu-west-1 fanout) │ │ CodeDeploy │ └───────────────────┘Two things make this work, and both are exam favorites:
- Cross-account IAM roles, not shared credentials. The tooling account’s CodePipeline service role assumes a role in each target account (
AssumeRolewith a trust policy scoped to the pipeline’s role ARN). CodeDeploy and CloudFormation actions in the pipeline specify aRoleArnthat points at the target account’s deployment role. - A customer-managed KMS key on the artifact bucket, with a key policy that explicitly grants
kms:Decryptto the target accounts’ roles. Forgetting this step is the single most common reason cross-account pipelines fail in the real world — and it’s tested directly. The default AWS-managed S3 key cannot be shared across accounts.
For multi-region deployment (say, an app that must run active-active in two regions), CodePipeline supports a cross-region deploy action natively — you specify the region on the action and CodePipeline replicates the artifact into a regional support bucket automatically. You don’t need to hand-roll replication.
Deployment Strategies and How CodeDeploy Implements Them
This is the highest-yield topic in this entire step. Know not just the names but the mechanics and failure behavior of each.
| Strategy | How it works | Rollback granularity | Typical use case |
|---|---|---|---|
| In-place | CodeDeploy stops the app on each instance, installs new revision, restarts, health-checks, moves to next instance (per configured batch size) | Per-instance; requires redeploying old revision | EC2 fleets without spare capacity, cost-sensitive workloads |
| Blue/Green (EC2/ASG) | New ASG launched with new revision; traffic cut over via ALB target group swap once healthy | Instant — shift traffic back to old ASG | Zero-downtime EC2 deploys, easy full rollback |
| Blue/Green (ECS) | New task set launched alongside old; CodeDeploy shifts ALB listener traffic between task sets | Instant — reroute listener | Containerized services, most common professional pattern today |
| Canary (Lambda/ECS) | Fixed percentage of traffic shifts to new version, waits, then shifts remainder | Automated via CloudWatch alarm during wait window | Lambda functions, ECS services where partial exposure is acceptable |
| Linear (Lambda) | Traffic shifts in equal increments on a fixed interval (e.g., 10% every 3 minutes) until 100% | Automated, same alarm mechanism as canary | Gradual exposure with predictable, steady ramp |
| All-at-once | Every target updated simultaneously | None — full redeploy required | Dev/test environments only; never recommend for prod in an exam answer |
For Lambda specifically, CodeDeploy uses traffic-shifting configurations with predictable names you should recognize instantly: Canary10Percent5Minutes, Linear10PercentEvery1Minute, AllAtOnce. These map directly to an alias’s weighted routing between two Lambda versions — CodeDeploy just automates what you could otherwise do manually with UpdateAlias and a weight.
The rollback trigger in all traffic-shifting strategies is the same idea: CodeDeploy watches one or more CloudWatch alarms you attach to the deployment group during the “bake time.” If an alarm goes into ALARM state before the bake time expires, CodeDeploy automatically stops shifting traffic and rolls back — no human required. This is the mechanism behind “automated rollback” answers on the exam, and it’s worth tracing through in your head: alarm on 5xx rate → deployment group config → automatic rollback → CloudWatch event fires → EventBridge can notify or trigger further automation (which we cover in Step 4).
Canary deployment timeline (Lambda, 10% / 5 min bake)
T+0min T+5min T+5min+ ┌─────────┐ ┌─────────────────────┐ ┌─────────┐ │ 10% new │──►│ Bake: watch alarms │──pass──►│ 100% new │ │ 90% old │ │ (error rate, latency)│ │ │ └─────────┘ └──────────┬──────────┘ └─────────┘ │ alarm fires ▼ ┌───────────────────┐ │ Rollback: 100% old │ └───────────────────┘AppConfig and Feature Flags as a Deployment Safety Layer
CodeDeploy traffic shifting protects you at the infrastructure layer — new code, small blast radius. AWS AppConfig protects you at the behavior layer — same code, feature toggled off. The two are complementary, and the exam will test whether you know when to reach for which. If a bug is in the binary itself, you need CodeDeploy’s rollback. If the binary is fine but a new feature is misbehaving under load, AppConfig lets you flip it off in seconds without a redeploy, and it has its own gradual-rollout and alarm-based automatic rollback mechanism — the same canary/linear philosophy applied to configuration instead of code.
Artifact Management
Artifacts are the thing every pipeline stage passes to the next, and treating them as an afterthought is how you end up debugging “why did staging deploy a build from three commits ago.”
Key points the exam expects:
- Every CodeBuild project should produce an immutable, versioned artifact. For containers, tag images with the CodeBuild build ID or commit SHA — never rely on
latestin a pipeline that promotes the same artifact across environments. - “Build once, deploy many” is the correct professional pattern. You build a single artifact in the pipeline’s build stage and promote that exact artifact through dev, staging, and prod. Rebuilding per environment risks environment drift and breaks the audit trail between what was tested and what shipped.
- CodeArtifact is the answer whenever a question mentions private package repositories (npm, PyPI, Maven, NuGet) with upstream fallback to public registries — it sits in the build stage, not the deploy stage.
- ECR image scanning (basic or enhanced, the latter backed by Amazon Inspector) should be wired into the build or test stage as a gate — fail the pipeline on critical CVEs rather than discovering them in production.
Third-Party Tool Integration
DOP-C02 explicitly expects you to know that AWS-native tooling isn’t the only answer. CodePipeline supports custom actions and Lambda-backed actions specifically so you can plug in Jenkins, GitHub Actions, Terraform, or a security scanner that isn’t an AWS service. The pattern is always the same: CodePipeline invokes a Lambda function (or polls a custom action job worker) at the appropriate stage, waits for a success/failure signal via the CodePipeline API (PutJobSuccessResult / PutJobFailureResult), and proceeds or halts accordingly. Recognize this pattern when a scenario says “our organization already has an established Jenkins pipeline and wants to integrate AWS deployment” — the answer is almost always a Jenkins plugin or Lambda action inside CodePipeline, not a rip-and-replace.
Exam Focus: What Questions Test From This Step
- Matching a scenario’s risk tolerance and traffic pattern to the correct CodeDeploy strategy — in-place vs blue/green vs canary vs linear — including the exact percentage/time configuration names for Lambda
- How CodeDeploy’s automatic rollback works: CloudWatch alarms attached to a deployment group, bake time, and what triggers a halt
- Cross-account pipeline architecture: which account owns the artifact bucket, why the KMS key policy must explicitly trust target accounts, and how cross-account roles are assumed
- Cross-region deployment actions within a single CodePipeline definition
- “Build once, deploy many” as the correct artifact-promotion pattern versus rebuilding per environment
- When to use AppConfig feature flags versus a CodeDeploy rollback — behavior-layer safety versus code-layer safety
- Integrating third-party CI/CD tools (Jenkins, GitHub Actions) via custom or Lambda-backed CodePipeline actions
- Manual approval actions and pipeline execution supersession behavior under rapid commits