Deployment, Provisioning, and Automation
Images, Infrastructure as Code, Sharing, and Controlled Deployment
CoreCreate governed machine and container images, operate CloudFormation/CDK and third-party IaC, troubleshoot deployment failures, distribute resources, and choose a recoverable rollout strategy.
Aligned to AWS Certified CloudOps Engineer - Associate (SOA-C03) Version 1.1, verified August 24, 2026.
Why this matters
Repeatability does not guarantee safety. Images, templates, state, identities, capacity, cross-account scope, rollout health, and rollback evidence must agree.
Must Know
- Use EC2 Image Builder pipelines for repeatable versioned image components, tests, distribution, and lifecycle. Build container images reproducibly, scan them, store them in ECR, and retain immutable release provenance.
- CloudFormation owns declarative stack lifecycle through templates, parameters, change sets, events, outputs, updates, and rollback. AWS CDK synthesizes applications into CloudFormation artifacts and does not bypass those semantics.
- Read stack events to find the first failed resource and its service message. Distinguish invalid configuration, dependency, execution-role authorization, and subnet/IP capacity failures.
- AWS RAM shares supported existing resources; StackSets provisions managed stack instances across selected accounts and Regions. Sharing is not replication.
- Canary shifts a small traffic share, blue/green switches between parallel environments, and rolling replaces capacity in batches. Each needs explicit health gates and rollback behavior.
- Third-party IaC needs protected remote state and locking, reviewed plans, immutable source provenance, short-lived scoped roles, and deliberate drift reconciliation.
Compare and Distinguish
- An AMI packages a machine baseline; a container image packages a container filesystem and metadata.
- CloudFormation directly defines stacks; CDK produces CloudFormation; Terraform uses its own configuration and state model.
- RAM grants principals access to one supported resource; StackSets creates stack instances in target accounts and Regions.
- Canary limits initial traffic; blue/green isolates environments; rolling preserves a chosen amount of capacity while mixing versions.
Scenario examples
- Scenario: A stack rolls back after one resource fails. Read events from the first failure, fix that exact dependency or permission, preview the change, and retry.
- Scenario: An Organization needs the same baseline in several Regions. Use StackSets with explicit targets, permissions, concurrency, failure tolerance, and drift review.
- Scenario: A release must switch back quickly. Validate green beside blue, shift traffic, monitor health, and retain blue through the rollback window.
Exam traps
- Do not retry an unchanged failed stack without reading events.
- Do not grant permanent administrator access to repair one execution-role denial.
- Do not use RAM when the requirement is to create independent copies.
- Do not delete image versions or the blue environment before the rollback window ends.
Key takeaways
- Version source, image, template, and deployed artifact together.
- Diagnose the first concrete deployment failure.
- Choose sharing versus provisioning deliberately.
- Make health and rollback first-class rollout settings.
How it works
- Resolve the exact image version, template, parameters, execution role, and target account and Region before deployment.
- Review the planned change and follow stack or tool events to the first failed resource and service message.
- Use rollout health gates and rollback behavior, then confirm the deployed artifact and workload health.
When to use it
- Build an AMI for a reusable machine baseline; build a container image when the deployable artifact is the container filesystem and metadata.
- Define and operate stacks directly with AWS CloudFormation, use AWS CDK when code should synthesize CloudFormation, and use Terraform only with its separate configuration and state model.
- Use AWS RAM to share one supported existing resource with principals; use CloudFormation StackSets to create and manage stack instances across target accounts and Regions.
- Choose a canary rollout to limit initial traffic, blue/green to isolate old and new environments, or rolling deployment to replace capacity in batches while versions coexist.
Security and governance implications
- Protect image provenance, third-party IaC state, and deployment artifacts from unauthorized replacement or disclosure.
- Separate build, deployment, stack-execution, and cross-account roles so each can affect only its intended resources.
Failure signals and diagnosis
- For image rollout failures, verify version, architecture, permissions, distribution, and referenced digest or AMI.
- For stack failures, use events and service errors before changing unrelated resources.
- For third-party IaC drift, protect state, inspect a plan, and reconcile through reviewed configuration rather than deleting state.
More detail
- Maintain versioned, tested AMI and container-image provenance through the image pipeline and distribution path.
- Understand that CDK synthesizes CloudFormation artifacts and that stack events, change sets, updates, and rollback still govern deployment.
- Distinguish sharing an existing supported resource with AWS RAM from provisioning stack instances with StackSets.
Ready for the quiz?
- A newly deployed workload starts from the wrong artifact. Which version or digest evidence distinguishes an EC2 Image Builder or AMI mismatch from an Amazon ECR container-image mismatch?
- Which stack event evidence separates invalid configuration, execution-role denial, dependency failure, and subnet address exhaustion?
- When several accounts need the same capability, what requirement makes AWS RAM sharing correct instead of StackSets provisioning?
Related objectives
- D3.1 — Task 3.1: Provision and maintain cloud resources.
- 3.1.1 — Create and manage AMIs and container images (for example, EC2 Image Builder).
- 3.1.2 — Create and manage AWS resources by using CloudFormation and the AWS CDK.
- 3.1.3 — Identify and remediate deployment issues (for example, subnet sizing issues, CloudFormation errors, permissions issues).
- 3.1.4 — Provision and share resources across multiple Regions and accounts (for example, AWS Resource Access Manager [AWS RAM], CloudFormation StackSets).
- 3.1.5 — Implement deployment strategies and services.
- 3.1.6 — Use and manage third-party tools to automate resource deployment (for example, Terraform, Git).