Study guide
1.2 CodeBuild Projects, Build Environments & Pipeline Secrets
AWS Certified DevOps Engineer – Professional Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CI/CD Pipeline Architecture & Source Integration
1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models
2 Chapter 2: Automated Testing, Test Gates & Quality Verification
2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates
3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies
3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda
4 Chapter 4: CloudFormation, CDK & Reusable IaC Components
4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance
5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower
5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation
6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration
6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig
7 Chapter 7: High Availability & Multi-Region Resiliency
7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR
8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation
8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery
9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation
9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions
10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray
10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps
11 Chapter 11: Automated Observability & Event-Driven Monitoring
11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries
12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines
12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling
13 Chapter 13: Automated Remediation & Deployment Troubleshooting
13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures
14 Chapter 14: Identity, Access Management & Secrets at Scale
14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager
15 Chapter 15: Security Automation, Data Protection & Compliance Auditing
15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config
1.2 CodeBuild Projects, Build Environments & Pipeline Secrets
Key Takeaways Explain This Topic AI
AWS CodeBuild executes builds inside managed or custom ephemeral Docker containers governed by buildspec.yml, executing across four sequential phases: install, pre_build, build, and post_build.
Building container images within CodeBuild (Docker-in-Docker) strictly requires setting privilegedMode: true in the project environment configuration and granting ECR repository access to the build service role.
Attaching CodeBuild to a VPC enables private connectivity to internal resources like RDS databases and artifact repositories, but requires a NAT Gateway or VPC endpoints for internet access; containers in public subnets do not receive public IP addresses.
Build acceleration relies on dependency caching: Amazon S3 cache provides durable storage across distributed build fleets, while Local caching (LOCAL_DOCKER_LAYER_CACHE, LOCAL_CUSTOM_CACHE) delivers optimal speed for sequential builds on the same host.
Sensitive credentials must be retrieved dynamically in buildspec.yml using parameter-store for Systems Manager parameters and secrets-manager for Secrets Manager secrets, preventing secrets from leaking into source code or build logs.
Last updated: September 2026
AWS CodeBuild Fundamentals & buildspec.yml Anatomy
AWS CodeBuild is a fully managed, serverless build service that provisions isolated, ephemeral compute containers, executes specified commands, produces build artifacts, and streams logs to Amazon CloudWatch. CodeBuild scales elastically to handle concurrent build workloads without requiring management of dedicated build servers.
The buildspec.yml Lifecycle and Phases
A buildspec.yml file is a YAML-formatted configuration placed in the root of the source directory (or defined inline in the project). It coordinates the lifecycle of the build through four strictly ordered phases: version: 0.2
env:
variables:
- APP_ENV: "production"
- JAVA_OPTS: "-Xmx2048m"
parameter-store:
DB_USER: "/app/prod/db_user"
secrets-manager:
DB_PASSWORD: "prod/rds/credentials:password"
exported-variables:
- IMAGE_TAG
- BUILD_TIMESTAMP
phases:
install:
run-as: root
runtime-versions:
- java: corretto17
- nodejs: 20
commands:
- echo "Installing build dependencies and tools..."
- apt-get update && apt-get install -y jq
- npm install -g snyk
pre_build:
commands:
- echo "Executing pre-build verifications and authentications..."
- aws --version
- aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $REPOSITORY_URI
- COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
- export IMAGE_TAG=${COMMIT_HASH:=latest}
- export BUILD_TIMESTAMP=$(date +%s)
build:
commands:
- echo "Compiling application and running test suites..."
- mvn clean package -DskipTests=false
- docker build -t $REPOSITORY_URI:latest .
- docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
post_build:
commands:
- echo "Build completed on $(date)"
- docker push $REPOSITORY_URI:latest
- docker push $REPOSITORY_URI:$IMAGE_TAG
- printf '[{"name":"microservice","imageUri":"%s"}]' $REPOSITORY_URI:$IMAGE_TAG > imagedefinitions.json
reports:
surefire-reports:
files:
- '**/*'
- base-directory: 'target/surefire-reports'
- file-format: JUNITXML
artifacts:
files:
- imagedefinitions.json
- target/*.jar
- appspec.yml
- discard-paths: no
cache:
paths:
- '/root/.m2/**/*'
- '/root/.npm/**/*'
- Phase Behavior and Failure Control
Phase Sequence : install -> pre_build -> build -> post_build .
Failure Semantics : If any command within install , pre_build , or build exits with a non-zero status code, that phase immediately halts. By default, subsequent phases are skipped, and the build status transitions to FAILED .
The finally Block : Commands placed in a finally block execute regardless of whether commands in the main phase succeeded or failed. This is critical for releasing locks, flushing telemetry, or publishing test results.
on-failure: CONTINUE : Configuring on-failure: CONTINUE allows the phase to proceed even if individual commands fail, which is useful when generating test reports that must be evaluated downstream.
Custom Docker Build Environments & ECR
CodeBuild provides managed Docker images for standard runtimes (Amazon Linux 2, Amazon Linux 2023, Ubuntu). However, enterprise workflows frequently require custom compilers, specialized CLI tooling, or proprietary security agents.
Custom Docker Images from Amazon ECR
Organizations build hardened Docker images, store them in a private Amazon ECR repository, and configure the CodeBuild project environment to use the custom image:
ECR Permissions : The CodeBuild service role requires IAM permissions to authenticate and pull the image ( ecr:GetAuthorizationToken , ecr:BatchCheckLayerAvailability , ecr:GetDownloadUrlForLayer , and ecr:BatchGetImage ).
Cross-Account ECR : If the custom image resides in a shared security/tools account, the ECR repository policy must explicitly grant ecr:BatchGetImage and layer download permissions to the CodeBuild project service role in the build account.
Privileged Mode (Docker-in-Docker)
Important
DOP-C02 Exam Trap : If your CodeBuild project builds Docker images, interacts with the Docker daemon, or executes Docker Compose commands, you must explicitly enable the privilegedMode flag ( privilegedMode: true in CloudFormation/Terraform, or checking the "Privileged" box in the AWS Console). Without privilegedMode , the build container cannot access /var/run/docker.sock or launch the nested Docker daemon, resulting in the error: Cannot connect to the Docker daemon at unix:///var/run/docker.sock .
VPC Support for Private Resource Access
By default, CodeBuild containers execute in an AWS-managed VPC with direct access to the public internet, public AWS service endpoints, and public Git repositories. However, builds frequently require access to private VPC resources, such as:
Amazon RDS / Aurora databases to execute schema migration scripts.
Internal package repositories (e.g., self-hosted Sonatype Nexus or JFrog Artifactory).
Private Amazon ElastiCache clusters or internal microservices.
The VPC Public Subnet Internet Black Hole
When you configure CodeBuild to attach to a VPC, CodeBuild provisions Elastic Network Interfaces (ENIs) inside your specified subnets. [ CodeBuild Project in VPC ]
- │
- ▼ (Uses ENI)
- [ Private Subnet ]
- │
- Route: 0.0.0.0/0
- │
- ▼
- [ NAT Gateway ] ──> [ Internet Gateway ] ──> [ Public Internet ]
- │ (npm, pip, GitHub)
- ▼
- [ VPC Gateway/Interface Endpoints ] ──> [ S3, ECR, CloudWatch Logs ]
Caution
Critical VPC Networking Rule : CodeBuild ENIs never receive public IPv4 addresses. Even if you place CodeBuild in a public subnet with an Internet Gateway route ( 0.0.0.0/0 -> igw-xxx ), the build container cannot reach the internet because it lacks a public IP for address translation. External requests (e.g., npm install , pip install , docker pull ) will hang and time out!
To enable internet access for a VPC-attached CodeBuild project:
Attach CodeBuild to private subnets .
Configure the private subnet route table with 0.0.0.0/0 pointing to an Amazon VPC NAT Gateway in a public subnet.
Alternatively, for AWS-internal traffic, configure VPC Endpoints for Amazon S3, Amazon ECR, and CloudWatch Logs.
Dependency Caching Strategies
Build execution duration directly impacts developer feedback loops and AWS billing. CodeBuild supports two distinct caching mechanisms:
Cache Mechanism Scope Latency Recommended Use Case
Amazon S3 Cache Distributed across all build hosts; durable in S3 Moderate (S3 upload/download time on build start/end) Intermittent builds, multi-account build fleets, or builds distributed across multiple regions
Local Cache Stored on the local EC2 host running the build container Ultra-low (direct NVMe/SSD block storage access) High-frequency builds where successive builds likely run on the same underlying host
Local Cache Modes
Local caching offers three distinct configuration options:
LOCAL_DOCKER_LAYER_CACHE : Caches intermediate Docker build layers locally. Eliminates re-pulling and re-building unmodified layers in Dockerfile stages.
LOCAL_SOURCE_CACHE : Caches the Git source repository metadata, avoiding a complete re-clone of the entire repository on sequential builds.
LOCAL_CUSTOM_CACHE : Caches arbitrary directories defined in buildspec.yml under cache: paths , such as ~/.m2 (Maven), ~/.npm (Node), or ~/.cache/pip (Python).
Note : Local cache is maintained on a best-effort basis. If AWS provisions the build on a fresh underlying host due to scaling or maintenance, the local cache will be cold.
Secure Secrets Retrieval in CodeBuild
Hardcoding API tokens, database passwords, or private signing keys in buildspec.yml or source code is a critical security vulnerability. CodeBuild provides native integration with AWS Systems Manager Parameter Store and AWS Secrets Manager through the env block: env:
parameter-store:
- # Key: Environment variable name in build
- # Value: Parameter Store parameter name or ARN
- API_ENDPOINT: "/config/prod/api_endpoint"
- DATABASE_USER: "/config/prod/db_username"
secrets-manager:
- # Key: Environment variable name in build
- # Value: SecretName:SecretKey:VersionStage:VersionId
- DB_PASSWORD: "prod/app/rds:password"
- GITHUB_PAT: "prod/vcs/tokens:github_token"
- Operational and Security Benefits
Automatic Decryption : For SecureString parameters in Parameter Store and secrets in Secrets Manager, CodeBuild automatically requests decryption using the KMS key associated with the secret, provided the CodeBuild service role has kms:Decrypt permissions.
Log Masking : Secrets retrieved via parameter-store and secrets-manager are automatically masked in CloudWatch Logs output. If a command echoes $DB_PASSWORD , CloudWatch Logs displays *** instead of the plaintext credential.
Exported Variables : Values generated during the build (such as $IMAGE_TAG ) listed under env: exported-variables are exported to downstream CodePipeline actions, enabling dynamic variable propagation.
Compute Types, Architectures & Batch Builds
CodeBuild provides flexible compute configurations to balance cost and compilation performance:
Compute Types : BUILD_GENERAL1_SMALL (2 vCPU, 4 GiB RAM), BUILD_GENERAL1_MEDIUM (4 vCPU, 8 GiB RAM), BUILD_GENERAL1_LARGE (8 vCPU, 16 GiB RAM), BUILD_GENERAL1_XLARGE (36 vCPU, 72 GiB RAM), and BUILD_GENERAL1_2XLARGE (72 vCPU, 144 GiB RAM).
Architectures : x86_64 ( LINUX_CONTAINER ), ARM64 ( ARM_CONTAINER powered by AWS Graviton for native multi-architecture builds and cost efficiency), and Windows Server ( WINDOWS_SERVER_2019_CONTAINER ).
Batch Builds: Matrices and Graphs
For large-scale testing across matrix configurations, CodeBuild supports Batch Builds :
Build Matrix : Runs multiple parallel builds across permutations of operating systems, language versions, and test suites (e.g., testing across Node 18, 20, and 22 on both Linux and ARM64).
Build Graph (DAG) : Defines a directed acyclic graph of dependent builds where downstream builds execute only after upstream prerequisites succeed (e.g., compile code -> run unit tests & SAST in parallel -> package container image).