AWS DOP-C02 Domain 1 — SDLC Automation — the pipeline and its seams

The exam does not ask whether you can build a pipeline. It asks which of four pipelines survives a bad deploy at three in the morning.

The exam does not ask whether you can build a pipeline. It asks which of four pipelines survives a bad deploy at three in the morning.

§ IFrame: Opening the DOP at Its Heaviest Domain

The Cloud cert rotation opened on 08-02 with the AWS Solutions Architect Professional and the multi-account landing zone: Organizations, service control policies, Control Tower, cross-account roles. That lesson drew the map of where things are allowed to happen. This one takes up the DevOps Engineer Professional and asks the sequel question, which is how code gets from a commit into those accounts without a human carrying it.

Domain 1, SDLC Automation, carries 22 percent of scored content, the largest share of the six domains. The rest of the blueprint runs Configuration Management and IaC at 17, Security and Compliance at 17, Resilient Cloud Solutions at 15, Monitoring and Logging at 15, and Incident and Event Response at 14. Sixty-five scored questions, 750 to pass on a 100-to-1000 scale.

Those weightings understate Domain 1's actual reach. A Domain 5 question about an incident response that rolls back a bad release is a CodeDeploy question wearing different clothes. A Domain 6 question about how a build obtains a credential is a buildspec question. Domain 1 is the spine.

One correction belongs at the top of this lesson before any service is named. The DOP-C02 reference shelf has been reported empty for three consecutive cycles and escalated to the Sovereign at 🔴 this morning, with a request to acquire four texts. The report was wrong. The Sovereign-Bootcamp corpus that landed on 2026-07-28 carries three DOP study bodies totalling roughly half a megabyte, and this lesson is grounded in them. The 09-Tomes shelf is genuinely empty of DOP material; the shelf that matters is not. The gap that stood for three cycles was a lookup failure, not a procurement failure.

§ IIFoundations: Four Services and the Seams Between Them

The exam treats the Code-family as four services with sharp boundaries, and most wrong answers come from blurring those boundaries.

CodeCommit is a Git host. It fires CloudWatch Events on push and supports webhooks, which is how a commit becomes a pipeline execution. Exam relevance beyond triggering is mostly repository-level IAM and branch protections.

CodeBuild is a stateless build runner. It takes a source, a build environment, and a buildspec, and it produces artifacts. Compute type and image are project settings; everything about what runs lives in the buildspec.

CodeDeploy is a deployment agent and orchestrator. It never builds. It takes a revision produced upstream and installs it onto a compute platform under a deployment configuration.

CodePipeline is the state machine that sequences the other three. Stages run in order; actions inside a stage run in parallel unless runOrder orders them. Each action declares input and output artifacts, and every artifact crosses between actions through an S3 bucket the pipeline owns.

That last sentence is worth reading twice. The artifact store is the seam. Pipeline actions do not pass data to each other directly; they pass S3 object keys, and the pipeline's service role plus the bucket's KMS key govern the whole flow. A cross-region or cross-account pipeline question is nearly always answered by describing an artifact bucket in each region, replicated, with the KMS key shared to the target account. The 08-02 SAP lesson's cross-account role pattern is the same mechanism at a different altitude: the pipeline in the tooling account assumes a deployment role in the workload account, and the workload account trusts it because the landing zone said so.

§ IIIMechanism: The Buildspec Contract

The buildspec is a YAML file, buildspec.yml by default at the source root, and its phases run in a fixed order: install, pre_build, build, post_build. Each phase carries a commands list and an optional finally list that runs whether the commands succeeded or not, which is the correct home for teardown and for emitting a report.

The block that matters most for the exam sits above the phases.

version: 0.2

env:
  variables:
    APP_ENV: "production"
  parameter-store:
    DB_PASSWORD: "/hedronite/prod/db/password"
  secrets-manager:
    API_KEY: "hedronite/prod/api:key"

phases:
  install:
    runtime-versions:
      python: 3.12
    commands:
      - pip install --require-hashes -r requirements.txt
  pre_build:
    commands:
      - python -m pytest -q
  build:
    commands:
      - python -m build --wheel
  post_build:
    commands:
      - aws s3 cp dist/ s3://$ARTIFACT_BUCKET/$CODEBUILD_RESOLVED_SOURCE_VERSION/ --recursive
    finally:
      - python -m tools.emit_build_report

artifacts:
  files:
    - dist/**/*
    - appspec.yml

Read the env block against a plain environment variable and the exam's preferred answer becomes visible. Values under variables are stored in the project definition in plaintext and are visible to anyone with codebuild:BatchGetProjects. Values under parameter-store and secrets-manager are names, resolved at build start by the build's own service role. The credential never appears in the project definition, never appears in the pipeline definition, and rotates without any pipeline edit.

That is the same discipline today's Ops lesson draws in Python: what the configuration carries is a pointer, never the value. The buildspec is that rule expressed in YAML, and the CodeBuild service role is what enforces it. A DOP question that says "developers can see the database password in the console, fix it" is answered by moving the value from variables to parameter-store and granting ssm:GetParameters plus kms:Decrypt to the build role.

Two more buildspec facts carry exam weight. artifacts.files determines what leaves the build, and forgetting to list appspec.yml is the classic cause of a deploy stage that fails with a missing AppSpec. And CodeBuild caching, whether local layer caching or an S3 cache, is the standard answer to "builds take too long," ahead of any change to compute type.

§ IVWorked Example: Choosing a Deployment Type

The DOP corpus lays out six deployment types, and the exam's questions are almost always a translation exercise: a scenario states a constraint, and one type satisfies it.

In-place / all-at-once. Every target updated in one step. Outage during install. Rollback means re-deploying the previous revision, which takes as long as the deploy did. Correct answer only when the scenario says cost matters more than availability.

Minimum-in-service and rolling. Staged updates that keep a floor of healthy targets. No downtime, automated health checks between batches, and the ability to pause. Rolling is the slowest of the family, and a scenario complaining about deployment duration is often steering away from it.

Blue/green. Two full environments; traffic cuts over at the load balancer or by DNS; rollback is a second cutover and therefore fast and clean. Costs double environment capacity for the duration. The corpus names the property the exam tests: the green environment can be health-checked and performance-tested under real conditions before it takes production traffic.

Canary and linear (Lambda). Traffic shifts by percentage on a schedule. Canary moves a slice, waits, then moves the rest. Linear moves equal increments at a fixed interval. Both are Lambda-platform deployment configurations, and both hook into CloudWatch alarms for automatic rollback.

The compute platform constrains the choice, and this table is worth memorizing outright because the exam tests it directly:

ECS admits no other type. Traffic always shifts all at once between task sets, and no custom deployment configuration applies. A question offering "configure a linear deployment for the ECS service" is offering a distractor.

The AppSpec file

appspec.yml on EC2 and On-Premises, appspec.yaml on ECS and Lambda. The filename difference is a real exam detail and not a typo.

On ECS the AppSpec names the task definition ARN, the container and port the load balancer reroutes to, and optional lifecycle hooks bound to Lambda validation functions.

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:us-east-1:111222333444:task-definition/hedronite-api:7"
        LoadBalancerInfo:
          ContainerName: "hedronite-api"
          ContainerPort: 8080
Hooks:
  - AfterAllowTestTraffic: "ValidateOnTestListener"
  - BeforeAllowTraffic: "ValidateBeforeCutover"
  - AfterAllowTraffic: "ValidateAfterCutover"

The hook order is the answer to a whole family of questions. AfterAllowTestTraffic fires while the replacement task set is serving only the test listener, which is where integration tests belong. BeforeAllowTraffic is the last gate before production traffic moves. AfterAllowTraffic is where a post-cutover smoke test lives, and a failure there triggers rollback while the original task set is still running.

That structure is Gene Kim and colleagues' point about deployment telemetry made concrete (The DevOps Handbook, Part IV, pp. 315-316): a deployment is safe in proportion to the evidence available at the moment of cutover, and the hook sequence is where that evidence gets gathered while retreat is still cheap.

On EC2 the AppSpec instead carries a files section mapping source paths to destinations, plus hooks that run scripts on the instance: ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, ValidateService. Note that ApplicationStop runs from the previously deployed revision, which is why a broken ApplicationStop script blocks all future deployments until it is removed from the instance by hand. That fact appears on the exam.

§ VConnection to Prior Lessons

The 08-02 SAP lesson built the landing zone. This lesson's cross-account pipeline runs inside it: a tooling account holds the pipeline and the artifact bucket, workload accounts hold the deployment targets, and the trust flows through the roles the landing zone provisioned. SAP asks whether the boundary is drawn correctly; DOP asks whether the pipeline crosses it safely.

The 08-03 Terraform lesson built a plan artifact and a promotion gate on GitHub Actions with OIDC to AWS. The same shape appears here in AWS-native form: plan becomes a CodeBuild action producing an artifact, and the promotion gate becomes a manual approval action in the pipeline. The exam prefers manual approval actions plus SNS notification over any custom Lambda approval mechanism, so when both appear as options, take the native one.

§ VIPractice Questions

§ VIIClosing

Domain 1 rewards a specific kind of memory: which deployment type each compute platform permits, which lifecycle hook runs while retreat is still cheap, and where in the pipeline a secret is a name rather than a value. Three tables and one YAML block carry most of the 22 percent.

The lesson has a second finding attached to it, and it belongs in the record beside the technical content. A shelf reported empty for three cycles was full the whole time. The corpus landed on 07-28, the escalation kept firing, and nobody looked in the second place because the rubric named only the first. Today's cure is the mapping row; the discipline it argues for is broader. Check both corpora before declaring a gap.

Examine well the compute-platform table. Every deployment question on the exam begins by narrowing to one row of it.

Related

• Prior arc: AWS SAP — The Multi-Account Landing Zone
• Domain hub: 01-Earth-DevOps
• Grounding corpus: DevOps Professional Study Workbook — SDLC (Deployment Types · Buildspec · CodeDeploy · AppSpec)
• Paired Ops: Configuration and Secrets for Python Ops Tools
• Paired Dev: Python Performance in Depth