Skip to main content
Good morning, students. This lesson is a focused refresher of Domain 1 (SDLC automation). If any term or concept below feels unfamiliar, make a note and revisit the earlier material — every item here has been covered previously. This review is concentrated to reinforce what you need to know for the exam. Domain 1 covers roughly 22% of the exam (about 14–15 questions) and centers on automating the software delivery lifecycle. Core task areas are:
  • CI/CD pipelines and orchestration
  • Automated testing in pipelines
  • Artifact management and registries
  • Deployment strategies and rollout patterns

​
CI/CD pipeline fundamentals (AWS)

CodePipeline provides orchestration: it pulls source, invokes build/test stages, and triggers deployments. Typical AWS services used in a CI/CD pipeline include:
  • Source: CodeCommit (or external Git providers such as GitHub, GitLab, Bitbucket)
  • Build/Test: CodeBuild
  • Deployment: CodeDeploy (or other deployment steps)
  • Artifact storage: S3, Amazon ECR (container images), CodeArtifact (language packages)
Also study multi-account pipeline patterns (single-account, multi-account, cross-account) and how AWS Organizations integrates into CI/CD designs.
A slide titled "CI/CD Pipeline Fundamentals" showing four AWS service icons labeled AWS CodePipeline, AWS CodeCommit, AWS CodeBuild, and AWS CodeDeploy under a "Service Roles" header. Below is a "Multi-Account Patterns" bar listing Single-account, Multi-account, and Cross-account.
Tip: Whether you use CodeCommit or an external Git provider, CodeBuild, CodeDeploy, and CodePipeline remain central to AWS CI/CD patterns. Understand how to structure pipelines across accounts for security and separation of concerns.

​
CodeBuild and buildspec.yml

CodeBuild executes pipeline build steps using a buildspec.yml. Key concepts:
  • build phases: install, pre_build, build, post_build
  • other sections: artifacts, reports, cache, and env (including secrets)
  • Ensure test runners return non-zero exit codes on failure so the build fails correctly
  • Avoid plaintext credentials — inject secrets via Secrets Manager or Parameter Store
A slide titled "Buildspec.yml – The Heart of CodeBuild" showing a vertical flowchart of build phases (INSTALL → PRE_BUILD → BUILD → POST_BUILD → UPLOAD_ARTIFACTS → FINALIZING → COMPLETED). To the right is a boxed list of critical sections to master: Artifacts, Reports, Cache, and Secrets integration.
Example minimal buildspec.yml demonstrating phases and secrets integration:

​
Secrets management: Secrets Manager vs Parameter Store

A slide titled "Secrets Management Quick Reference" that compares AWS Secrets Manager (left) and AWS Systems Manager Parameter Store (right). Each column lists four numbered points about features, pricing, rotation capability, and recommended use cases.
  • Use AWS Secrets Manager when you require automated rotation or a managed secret lifecycle (database credentials, API keys with rotation requirements).
  • Use Systems Manager Parameter Store (SecureString) when cost is a concern and automatic rotation is not required.
Use Secrets Manager for rotation and automatic secret lifecycle management. For static secrets where rotation isn’t required and cost is a concern, Parameter Store (SecureString) is often sufficient.

​
Automated testing in pipelines

Know the test levels and where they fit in the pipeline:
  • Unit tests — fast, run frequently in build stages
  • Integration tests — validate component interactions
  • Functional / end-to-end tests — verify full user flows
  • Performance / load tests — run less frequently, often in dedicated stages/environments
  • Security tests — integrated throughout (SCA, SAST, DAST)
Configure the pipeline so failing tests return non-zero exit codes; this prevents faulty changes from progressing.
A presentation slide titled "Automated Testing in Pipelines" showing a colorful test pyramid labeled bottom-to-top: Security Tests, Performance Tests, Functional Tests, Integration Tests, and Unit Tests. A footer note mentions configuring buildspecs to return proper exit codes from test frameworks.

​
Artifact management

Know where pipeline outputs should be stored for durability, security, and traceability.
A slide titled "Artifact Management Essentials" showing a central circle of AWS services (S3, ECR, CodeArtifact, EC2) connected to four labeled quadrants for Pipeline outputs, Container images, AMIs, and npm/Maven/PyPI packages. It’s a visual overview of where build artifacts are stored and managed.

​
Deployment strategies and risk profiles

Choose a deployment strategy based on downtime tolerance, rollback needs, and risk:
A slide titled "Deployment Strategies Overview" showing four approaches: All‑at‑Once, Rolling, Blue/Green, and Canary. Each box notes downtime and rollback characteristics (All‑at‑Once: Downtime Yes / Rollback Redeploy; Rolling: Minimal / Slow; Blue/Green: Zero / Instant; Canary: Zero / Instant).
Prefer immutable deployments (replace instances/containers) over mutable in-place updates for predictable, reproducible rollbacks.

​
CodeDeploy and compute-specific considerations

CodeDeploy supports multiple compute targets and configuration options:
  • EC2 / On-prem
    • Replace instances one-at-a-time, half-at-a-time, or all-at-once
    • Use appspec.yml lifecycle hooks to run validations or health checks
  • ECS / ECR (containers)
    • Blue/Green via new task sets and ALB target group weight shifting
    • Integrates with CodeDeploy for traffic shifting and automated rollbacks
  • Lambda
    • Use versions + aliases for traffic shifting (linear or canary) or all-at-once deployments
A presentation slide titled "CodeDeploy Configurations by Compute" with three panels for EC2, ECR, and Lambda. Each panel lists deployment details like Blue/Green requirements, appspec.yml hooks, task/container specs, and versions/aliases or Lambda hooks for traffic shifting and rollback.

​
Blue/Green and traffic shifting (ECS example)

Blue/Green means deploying a new environment (GREEN) alongside the existing (BLUE) and then shifting traffic. Traffic-shifting modes:
  • Instant cutover — immediate full switch
  • Canary — small percentage initially, then increase
  • Linear — incremental increases at fixed intervals
For ECS, the flow typically registers a new task set with an ALB and shifts target group weights. Rollback is usually achieved by switching back to the previous task set.
A diagram showing a Blue/Green deployment flow for ECS. It depicts CodeDeploy registering with an ALB to shift traffic from the BLUE (old, v1) environment to the GREEN (new, v2) environment, with rollback and termination steps.

​
Troubleshooting deployment failures

Start with these common checks:
  • IAM permissions and service roles for CodePipeline / CodeBuild / CodeDeploy
  • CloudWatch Logs for build and deployment errors (build logs, agent logs)
  • ALB target group health checks — incorrect health checks often cause deployments to fail or roll back
A slide titled "Troubleshooting Deployment Failures" listing three numbered items: CodePipeline, CodeBuild, and CodeDeploy failures. Each item gives a short tip (check repo permissions/webhooks, review CloudWatch logs, and verify ALB target group health checks).
Quick checklist:
  • Confirm pipeline service role has required actions on S3, CodeBuild, CodeDeploy
  • Verify buildspec paths and artifact locations
  • Confirm target instances / tasks pass health checks before traffic shift completes

​
Exam scope and patterns to master

Be comfortable with:
  • CodePipeline stages and orchestration patterns
  • CodeBuild phases and buildspec.yml usage
  • CodeDeploy deployment types for EC2, ECS (from ECR), and Lambda
    • Note: Amazon EKS is usually managed with Kubernetes-native tools (kubectl, Helm, Argo CD) or pipeline steps applying manifests, not CodeDeploy directly
  • Artifact storage and management (S3, ECR, CodeArtifact)
  • Multi-account CI/CD patterns, zero-downtime deployments, gradual rollouts (canary/linear), and secrets management
  • Creating consistent, repeatable environments: immutable infrastructure and golden AMI pipelines
A slide titled "Domain 1 Exam Triggers – Final Review" showing that this domain is 22% of the exam. It lists must-know AWS CI/CD services (CodePipeline, CodeBuild, CodeDeploy, ECR/CodeArtifact/S3), common patterns (zero-downtime, gradual rollout, multi-account) and sample exam scenarios.

​
Key takeaways

  • Automation: Automate the software delivery lifecycle to reduce human error and increase repeatability.
  • Consistency: Favor immutable infrastructure and golden image patterns for predictable deployments.
  • Safety: Use IAM roles, KMS encryption, and proper secrets management; test before rollout; design for least privilege.
A presentation slide titled "Key Takeaways" with a blue gradient panel on the left. It lists three numbered points: 01 Automation (everything in the software delivery lifecycle), 02 Consistency (immutable infrastructure and golden AMI patterns), and 03 Safety (use IAM roles, KMS encryption, and secrets management).
Actionable study tips:
  • Recreate a simple pipeline: source → CodeBuild tests → push image to ECR → deploy to ECS with a blue/green test
  • Practice authoring a buildspec.yml and injecting secrets securely
  • Review exam scenarios that ask you to choose deployment strategies based on downtime and rollback requirements
This concludes the Domain 1 review. If any concept here felt unfamiliar, note it and review the relevant earlier material.

Watch Video