SDLC Automation

SDLC Automation is Domain 1 of AWS's DOP-C02 exam guide, and it's the single largest domain on the test — roughly 22% of your score, more than any other of the six. It's also the domain that overlaps most directly with the concepts this course has already taught you: everything here is CI/CD pipelines, build & artifact management, and deployment strategies re-asked with a specific vendor's service names bolted on. This page is that translation layer — the tool-neutral concept on the left, the AWS service and configuration that implements it on the right.

What Domain 1 actually covers

☺ Like you're 10: One quarter of the whole exam is just "how do you build the pipeline, and how do you ship what it builds" — asked with AWS service names in the question.

AWS's own exam guide groups Domain 1 into roughly four task areas: designing and automating a CI/CD pipeline for a given business scenario, choosing a source-control strategy and wiring it to that pipeline, automating build and test, and choosing (and implementing) a deployment or rollback strategy. That's the whole domain in one sentence — it just happens to be worth more than a fifth of your final score.

These weights are checked against AWS's own exam guide as of this course's most recent revision — but AWS revises DOP-C02 periodically (it already replaced DOP-C01 with a materially different domain structure once), so confirm the current split on AWS's own exam-guide PDF before you build a study-time budget around these exact numbers.

Pipeline design: CodePipeline as the orchestrator

☺ Like you're 10: CodePipeline doesn't build or test anything itself — it's the conductor waving the baton, telling each specialist musician exactly when to play.

CodePipeline is AWS's release-orchestration service: it owns the sequence of stages (Source, Build, Test, Deploy, and so on) and, within each stage, one or more actions — each action naming a provider (CodeBuild, CodeDeploy, CloudFormation, S3, Elastic Beanstalk, a manual approval, or a third party like Jenkins). Actions inside a stage can run in parallel by sharing the same run order; stages themselves run strictly in sequence, and a stage only starts once every action in the one before it has succeeded. Artifacts pass between stages through an S3 bucket CodePipeline manages for you — each action declares the input artifacts it consumes and the output artifacts it produces, which is how the exact same build output that passed the test stage is the one that reaches deploy, unmodified, the same "build once, promote everywhere" idea from build & artifact management.

CodePipeline also supports cross-region actions (deploy the same pipeline's output into multiple regions, each needing its own artifact bucket and a multi-region KMS key) and cross-account pipelines (a shared services account runs the pipeline, target accounts grant it a deployment role and an artifact-bucket policy). A manual approval action — which can notify an SNS topic and pause the pipeline until a human clicks approve or reject — is the AWS-specific implementation of the human gate that separates continuous delivery from continuous deployment, the exact distinction CI/CD pipelines draws in tool-neutral terms.

Source-control triggers: from a push to a running pipeline

☺ Like you're 10: A trigger is what wakes the conveyor belt up — you want it woken by an alarm going off, not by someone walking past to check on it every five minutes.

How a pipeline starts is its own exam-relevant decision. The mechanism AWS wants you to prefer is event-driven: an Amazon EventBridge rule watches for a repository-state-change event (a push, a pull request, a tag) and starts the pipeline execution within seconds. The older mechanism is polling — CodePipeline checks the source on a fixed interval, historically five minutes — which still works but adds exactly the kind of avoidable latency the exam expects you to flag as the wrong answer whenever a scenario asks for "fast feedback," the same principle CI/CD pipelines calls the fast-feedback principle in tool-neutral terms.

Newer CodePipeline V2 pipelines can declare Git triggers directly in the pipeline definition — branch push filters, tag-creation filters, and pull-request filters — instead of relying on a separate EventBridge rule resource:

# CodePipeline V2 — declarative Git triggers, no separate EventBridge rule to manage
PipelineType: V2
Stages:
  - Name: Source
    Actions:
      - Name: GitHub_Source
        ActionTypeId:
          Category: Source
          Owner: AWS
          Provider: CodeStarSourceConnection   # provider name kept for compatibility
          Version: '1'
        Configuration:
          ConnectionArn: arn:aws:codeconnections:us-east-1:111122223333:connection/abc-123
          FullRepositoryId: acme/checkout-service
          BranchName: main
        OutputArtifacts: [{ Name: SourceOutput }]
Triggers:
  - ProviderType: CodeStarSourceConnection
    GitConfiguration:
      SourceActionName: GitHub_Source
      Push:
        - Branches: { Includes: [main] }
      PullRequest:
        - Branches: { Includes: [main] }
          Events: [OPEN, UPDATED]

Build & test automation: CodeBuild

☺ Like you're 10: CodeBuild is a brand-new, empty computer that spins up, reads a recipe card, does exactly what it says, and then disappears.

CodeBuild is AWS's managed build service: a container spins up on demand, runs the phases defined in a buildspec.yml file checked into the repo (or supplied inline), and tears back down when it's done — you pay per build-minute, not for an idle server. The four phases run in order — install (runtime setup), pre_build (dependency install, lint), build (compile, unit test, image build), and post_build (push the image, notify) — and a reports block surfaces structured test output (JUnit XML, Cucumber JSON) directly in the CodeBuild console rather than leaving it buried in a log stream:

# buildspec.yml — same four phases every build runs, in a fixed order
version: 0.2
env:
  parameter-store:
    DB_PASSWORD: /checkout/prod/db-password   # pulled from SSM Parameter Store, never hardcoded
phases:
  install:
    runtime-versions: { nodejs: 20 }
  pre_build:
    commands:
      - npm ci
      - npm run lint
  build:
    commands:
      - npm test -- --reporters=jest-junit
      - docker build -t $REPO_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION .
  post_build:
    commands:
      - docker push $REPO_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION
reports:
  jest-reports:
    files: [ junit.xml ]
    file-format: JUNITXML
cache:
  paths: [ 'node_modules/**/*' ]   # or an S3-backed cache across ephemeral build hosts
artifacts:
  files: [ imagedefinitions.json ]

A handful of CodeBuild knobs come up repeatedly on the exam: compute type (from small general-purpose instances up to Lambda-based compute for very short builds), privileged mode (required whenever the build itself runs Docker, i.e. building an image inside the build container), VPC configuration (when a build needs to reach a private resource like an RDS instance or an internal artifact mirror), and batch builds (running a matrix, graph, or list of related build configurations from one buildspec, with explicit dependencies between them) for fanning one trigger out into several parallel or sequenced builds.

Artifact management: CodeArtifact & ECR

☺ Like you're 10: Two different warehouse shelves for two different kinds of boxes — ingredients and parts on one shelf, sealed finished containers on the other — and the exam loves asking which shelf a given box belongs on.

AWS splits artifact storage into two services along exactly the line build & artifact management calls the artifact repository's job — a system of record for build outputs, versioned and immutable. CodeArtifact is a package-format repository: it speaks npm, pip, Maven/Gradle, NuGet, and a generic format, organized into domains (a billing and access-control boundary) containing repositories, and repositories can chain to an upstream — including a public registry like npmjs.com — so a request for a package your team has never fetched before is proxied, cached, and from then on served internally, giving you both dependency caching and a single point to block a known-bad package company-wide. ECR is the container-image counterpart: private and public registries, per-repository image scanning (basic OS-package CVE scanning is free; enhanced scanning adds Inspector-driven language-package coverage), lifecycle policies to expire untagged or aged-out images automatically, and cross-region or cross-account replication for multi-region deployments.

Deployment-automation strategies: CodeDeploy configs & Lambda traffic shifting

☺ Like you're 10: Same four strategies from the deployment-strategies lesson — rolling, blue-green, canary, and one-shot — except now each one is a named config you pick from a dropdown, and the exam wants you to know exactly which dropdown item is which.

CodeDeploy is the AWS-specific implementation of everything deployment strategies teaches conceptually, and it behaves differently depending on the compute platform underneath it.

For EC2/on-premises, CodeDeploy supports two deployment types. In-place deployments update instances where they stand, governed by a deployment configuration: AllAtOnce (fastest, zero fault tolerance — a rolling deployment's riskiest possible setting), HalfAtATime, OneAtATime (slowest, most conservative), or a custom minimum-healthy-host percentage. Blue/green deployments provision a fresh set of instances (or reuse a specified set), reroute a load balancer's traffic to them — all at once or over a wait window — and then terminate the originals immediately or after a delay, giving you the near-instant rollback deployment strategies attributes to blue-green in general. Both deployment types read an appspec.yml that defines lifecycle hooks in a fixed order — BeforeInstall, AfterInstall, ApplicationStart, ValidateService, plus BeforeAllowTraffic/AfterAllowTraffic when a load balancer is involved — so you can run a database migration or a smoke test at the exact right moment in the rollout.

For Lambda, CodeDeploy shifts traffic between two function versions behind a single weighted alias — never between raw version numbers directly, and never against $LATEST — using one of three preset shapes: AllAtOnce, linear (a fixed percentage added every fixed interval, e.g. LambdaLinear10PercentEvery1Minute), or canary (one jump to a percentage, a hold, then the rest, e.g. LambdaCanary10Percent5Minutes). A validation Lambda can hook into BeforeAllowTraffic and AfterAllowTraffic to check the new version before and after it starts receiving real traffic:

# appspec.yml — Lambda, canary traffic shift via a weighted alias
version: 0.0
Resources:
  - checkoutFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: checkout-prod
        Alias: live
        CurrentVersion: '41'
        TargetVersion: '42'
Hooks:
  - BeforeAllowTraffic: preTrafficValidationFn
  - AfterAllowTraffic: postTrafficValidationFn
# DeploymentConfigName: CodeDeployDefault.LambdaCanary10Percent5Minutes
# 10% of traffic to version 42 for 5 minutes, watched against a CloudWatch alarm,
# then the remaining 90% — or an automatic rollback to version 41 if the alarm trips.

For ECS, CodeDeploy-managed blue/green stands up a second task set behind a second target group — optionally validated through a test listener before it ever sees production traffic — then shifts the load balancer's production listener over using the same linear/canary/all-at-once shapes as Lambda. (Amazon ECS has since added a native blue/green deployment option that doesn't require CodeDeploy at all — another naming and ownership detail worth confirming against current documentation rather than assuming CodeDeploy is the only path.)

Automatic rollback only fires when a CloudWatch alarm is explicitly attached to the deployment group — adding an alarm somewhere else in the account does nothing for a deployment it isn't wired to, and CodeDeploy can also be configured to roll back on a deployment failure alone, with no alarm at all. Both triggers are configured per deployment group, not globally.

Where the exam likes to trip you up

☺ Like you're 10: The exam isn't testing whether you've heard of these services — it's testing whether you know the one specific detail that separates the right answer from the very-similar wrong one.

• Polling vs. events. Any scenario emphasizing fast feedback or low-latency pipeline starts wants an EventBridge-triggered pipeline, not a polling one — polling is a legitimate fallback, never the "best" answer when the question asks for speed.
• CodeArtifact vs. ECR. Dependencies and packages go in CodeArtifact; container images go in ECR. A question describing "a company wants to cache and scan its npm dependencies" is not an ECR question, no matter how much the scenario also mentions containers elsewhere.
• Deployment-config minimums. OneAtATime is the most fault-tolerant in-place config and the slowest; AllAtOnce is the fastest and the least fault-tolerant. A custom minimum-healthy-host percentage sits between them — know which direction each dial turns.
• Lambda traffic shifting needs an alias. CodeDeploy shifts traffic between two versions through a single alias — a scenario that skips the alias and tries to route between raw Lambda ARNs is describing something CodeDeploy cannot do.
• Rollback needs an explicit alarm on the deployment group. A CloudWatch alarm that exists elsewhere in the account does not trigger an automatic rollback unless it's attached to that specific deployment group's rollback configuration.

SDLC Automation gives you the mechanics of the pipeline itself. What that pipeline provisions and configures underneath the application is the next domain, where the same "declare it, don't click it" instinct from infrastructure as code gets its own AWS-specific treatment.