AWS DevOps Engineer Professional Training Course

You already know what a pipeline is. What DOP-C02 tests is whether you can reason about one as a system with properties — latency, blast radius, reversibility, auditability, cost — and trade those properties against each other when a scenario forces you to. Almost every question in this domain gives you two or three designs that would all work, and asks which is best along a dimension the scenario names in a single clause. Learning to find that clause is worth more than memorizing another service.

The four properties the exam keeps testing

Blast radius. When a bad change ships, how much is affected before anything stops it? An all-at-once deployment to a fleet has a blast radius of the whole fleet. A canary that routes 10% of traffic for ten minutes has a blast radius of 10% of requests for ten minutes. When a scenario says "minimize the number of users exposed to a defect," it is asking about blast radius, and the answer will be the option with the narrowest initial exposure — even if it deploys more slowly.

Reversibility. How fast, and how reliably, can you get back to the previous known-good state? This is not the same as blast radius. A rolling deployment has a moderate blast radius but poor reversibility, because rolling back means another rolling deployment through the same fleet. A blue/green deployment has excellent reversibility — the old environment still exists, so rollback is a traffic shift — at the cost of running two environments. When a scenario says "roll back in seconds" or "without redeploying," it is asking about reversibility, and the answer almost always keeps the previous version alive.

Operational load. How much ongoing human work does the design create? The exam consistently prefers managed services and event-driven automation over scheduled scripts on an instance somebody has to patch. When two options are functionally equivalent and one requires you to run infrastructure, the managed option is usually the intended answer.

Auditability. Can you prove, later, what shipped and who approved it? Professional-tier scenarios frequently attach a compliance requirement to an otherwise ordinary pipeline question. That requirement usually eliminates options that bypass a recorded control — a developer pushing directly to a deployment service, an artifact built outside the pipeline, a change with no approval action.

Continuous integration, delivery, and deployment are not synonyms

Continuous integration ends at a validated artifact. Code merges frequently, and every merge triggers a build and an automated test suite. The output is an artifact you have evidence about.

Continuous delivery extends that to a deployable state: the artifact is automatically promoted through environments and is always ready to release, but a human decides when production happens. On AWS that human decision is usually a CodePipeline manual approval action.

Continuous deployment removes the human. Every change that passes its gates goes to production automatically. The exam treats this as a legitimate goal but expects you to compensate for the missing human with stronger automated gates — canary traffic shifting, CloudWatch alarms wired to automatic rollback, and a tested rollback path.

Read the scenario for which of the three the organization is actually asking for. A requirement that "changes must reach production without manual intervention" rules out every option containing an approval action, no matter how sensible that approval looks.

The immutable artifact rule

One principle underlies most of the correct answers in this domain: build once, promote the same artifact. The thing you tested in staging must be bit-for-bit the thing you run in production. Rebuilding per environment reintroduces the variable you were trying to eliminate, because the build can pick up a different dependency version, a different base image, or a different compiler.

Environment-specific behavior therefore has to come from configuration injected at deploy or run time — Parameter Store, Secrets Manager, AppConfig, task definition environment variables — not from a differently built binary or image. When an option rebuilds an image for production, that option is usually wrong, and when an option promotes an image by digest rather than by a mutable tag such as latest, that option is usually right.

Where the AWS services fit

• Source — CodeCommit, or a third-party repository connected through AWS CodeConnections. The pipeline's source action produces the input artifact.
• Build and test — CodeBuild, driven by a buildspec.yml, producing output artifacts and reports.
• Package storage — CodeArtifact for language packages, Amazon ECR for container images, S3 for build artifacts.
• Deploy — CodeDeploy for EC2, on-premises, ECS, and Lambda; CloudFormation for infrastructure; Elastic Beanstalk and ECS/EKS native deployment controllers where those are already in play.
• Orchestration — CodePipeline, holding the stages and the approval and gating logic, with EventBridge carrying pipeline state changes out to notification and automation.

AWS revises this product family regularly, including availability of new CodeCommit repositories for new accounts, so treat the specific tool names as the current shape rather than a permanent one and confirm details in the AWS documentation. The reasoning — source, build, store, deploy, orchestrate, observe — is what the exam is really testing, and it survives every rename.

Reading a scenario efficiently

Under time pressure, work backwards. Find the sentence that states the constraint — "with the least operational overhead," "with no downtime," "must be able to revert within five minutes," "must satisfy an auditor." Then eliminate options that violate it outright. You will usually be left with two, and the difference between them will be exactly the property the constraint named. Choosing between two plausible options along a stated dimension is the entire skill this exam measures.