Amazon SOA-C02: Deployment, Provisioning, and Automation — Study Guide

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Part of the AWS SysOps Administrator Associate SOA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

This domain covers the methods and tooling used to provision, update, and operate AWS infrastructure and application deployments reliably and repeatedly. It emphasizes declarative, idempotent provisioning, automated pipelines for releases, and operational automation that reduces manual toil while preserving auditability and security. Operators must balance safety (rollbacks, change policies) with velocity (immutable images, automated patching), and choose patterns that support compliance and recoverability.

CloudFormation and Infrastructure as Code patterns

Use CloudFormation (or CDK/Terraform) to declare infrastructure as code so stacks are idempotent: a template describes desired state and the engine converges resources. Prefer declarative resources and parameters over imperative scripts. Typical CLI patterns:

Create and inspect a change set: aws cloudformation create-change-set –stack-name my-stack –template-body file://template.yaml –parameters ParameterKey=Env,ParameterValue=prod –change-set-name cs1
Review and execute: aws cloudformation describe-change-set –change-set-name cs1 && aws cloudformation execute-change-set –change-set-name cs1
Deploy convenience: aws cloudformation deploy –template-file template.yaml –stack-name my-stack –parameter-overrides Key=Value –capabilities CAPABILITY_NAMED_IAM

Design decisions:

Use nested stacks or modules for reuse and limits; move mutable secrets and large binaries out of templates (SSM Parameter Store / Secrets Manager).
Use stack policies, termination protection, and rollback triggers for safety; enable drift detection with aws cloudformation detect-stack-drift and aws cloudformation describe-stack-drift-detection-status.
Grant the CloudFormation service role a scoped IAM policy to create resources; avoid giving CloudFormation broad administrator permissions.

When comparing IaC approaches:

CloudFormation/CDK: native, integrated with AWS change sets and drift detection, requires CAPABILITY_NAMED_IAM for IAM resources.
Terraform: provider-agnostic, state file management required, good for mixed-cloud environments.
Imperative scripts (CLI/SDK): suitable for one-off operations but not idempotent and harder to audit.

CI/CD and deployment automation practices

Implement repeatable pipeline stages: source -> build -> test -> deploy. Use AWS CodePipeline integrating CodeBuild, CodeDeploy, or third-party tools (Jenkins, GitHub Actions). Key configurations:

CodeBuild: define buildspec.yml for phases and artifacts; grant project role least privilege (s3:GetObject for inputs, s3:PutObject for artifacts).
CodeDeploy: use deployment groups and AppSpec.yml; choose deployment type—in-place or blue/green. For EC2/ASG, prefer blue/green to reduce risk.
ECR + ECS/EKS: push images from CI, tag immutably (semantic or build ID), and reference the image tag or digest in task definitions.

Decision criteria for deployment strategies:

Use blue/green or canary with traffic shifting when you need near-zero downtime and safe rollback; CodeDeploy or Application Load Balancer (ALB) weight shifts support this.
Use rolling or in-place updates for smaller, stateless fleets where capacity can be reduced during update.
Ensure pipeline roles are scoped: pipeline execution role, CodeBuild service role, and deployment role (instance profile) each with minimal permissions.

Manage secrets and parameters securely: store parameters in SSM Parameter Store (SecureString) or AWS Secrets Manager; give pipeline roles kms:Decrypt and ssm:GetParameter or secretsmanager:GetSecretValue as needed.

AMI baking, immutable images, and AMI management

Immutable infrastructure means creating a new AMI with all OS and application patches baked in, then replacing instances instead of mutating them. Use EC2 Image Builder or Packer in CI to produce AMIs automatically:

EC2 Image Builder pipelines can run on schedule, install packages, run tests, and produce AMIs with versioned naming conventions and tags.
Packer integrates into CI (CodeBuild/Jenkins) to execute build scripts and output AMI IDs; store the latest AMI in SSM Parameter Store (e.g., /ami/app-prod) for reference.

Manage AMI lifecycle:

Tag images with build metadata and expiration; automate deregistration and snapshot deletion after retention period.
Use Launch Templates/ASG with a version update to roll out new AMIs; for immutable deploys, create a new ASG referencing the new Launch Template version and switch target groups.

Compare mutable vs immutable:

Immutable (new AMI/new ASG): safer, easier rollback by switching to previous ASG or AMI, consistent lifecycle.
Mutable (patch in place): faster to apply small fixes but higher drift and harder to reproduce; use only when constraints demand it.

AWS Systems Manager automation, Run Command, and patching

Systems Manager (SSM) centralizes operational tasks: Run Command for ad-hoc commands, State Manager for desired state, Patch Manager for scheduled OS patching, and Automation for complex workflows. Common CLI patterns:

Send ad-hoc: aws ssm send-command –instance-ids i-0123456789abcdef0 –document-name “AWS-RunShellScript” –parameters commands=’[“yum update -y”]'
Start predefined automation: aws ssm start-automation-execution –document-name “AWS-ApplyPatchBaseline” –parameters “InstanceIds=[‘i-…’]”
Use State Manager associations to enforce configuration (e.g., SSM Agent config, cron jobs) and Patch Manager baselines for approval rules and compliance scans.

Configuration details and decision points:

Use Patch Manager with Baselines and Maintenance Windows for predictable, compliant patching; choose auto-approval days and reject unapproved AMI images if using immutable strategy.
For instances without SSM agent or limited network, consider session manager with VPC endpoints to avoid opening SSH ports.
Always require an instance profile with AmazonSSMManagedInstanceCore policy for SSM access; scope additional permissions as needed.

Change management, drift detection, and rollback

Implement change control that integrates pipeline runs, tags, and approvals. Use CloudFormation change sets for previewing diffs and stack policies to reject destructive updates. CLI patterns:

Detect drift: aws cloudformation detect-stack-drift –stack-name my-stack and aws cloudformation describe-stack-resource-drifts –stack-name my-stack
Use stack policy to protect critical resources during updates and set RollbackConfiguration with rollback triggers to notify on failed updates.

Rollback strategies:

For CloudFormation: automatic rollback on failure is default; use rollback triggers and retain resources when required.
For applications: prefer blue/green or canary with traffic shift to enable instant rollback by reweighting ALB/Route53 or reinstating previous task sets.
Maintain immutable artifacts (AMI IDs, container images) and preserve previous versions in registries/SSM so rollbacks are deterministic.

Decision criteria:

If stateful data migrations are involved, include reversible migration scripts or use feature flags to separate code release from schema migration.
Use deployment health checks and automated smoke tests as pipeline gating to trigger rollbacks early.

Common Pitfalls and Decision Criteria

Making manual out-of-band console changes that drift IaC state: enforce drift detection (aws cloudformation detect-stack-drift) and require fixes to be applied via IaC templates; use IAM controls to restrict console edits.
No safe rollback plan for releases: adopt blue/green or canary deployments and keep previous artifacts/AMIs available to revert instantly.
Overly-permissive IAM for pipelines and roles: apply least privilege; split roles (pipeline service role, build role, instance profile) and grant only necessary ssm:GetParameter, secretsmanager:GetSecretValue, kms:Decrypt, and s3 access.
Storing secrets directly in templates or plain text: move secrets to Secrets Manager or SecureString SSM Parameter Store and reference them at deployment time with proper decryption permissions.
Patching production in-place without testing: bake AMIs in CI with updated packages and smoke tests, then roll out immutable images via ASG or blue/green pipelines.
Ignoring drift and stateful resource protection: use stack policies and detect drift regularly; for stateful resources, require manual approval and snapshots before destructive changes.

Practical Problem: Use-Case Scenario

Acme Payments must deploy a PCI-compliant API service, apply monthly OS patches, and be able to roll back quickly if a deployment causes errors during business hours.

Implement an immutable pipeline: use CodePipeline/CodeBuild to bake AMIs with EC2 Image Builder (or Packer), tag AMIs, and publish AMI ID to SSM Parameter Store.
Deploy via CloudFormation templates that reference the SSM parameter for the AMI and create a new ASG + Launch Template version for each release; use change sets for pre-flight review.
Use CodeDeploy or ALB target-group blue/green traffic shifting with health checks and automated smoke tests; configure automatic rollback on health check failure.
Schedule Patch Manager via Systems Manager Maintenance Windows for non-peak patch application; perform bake-and-deploy for patched images to avoid in-place patching of production.
Enforce least-privilege IAM for pipeline roles, store secrets in Secrets Manager, and enable CloudFormation drift detection and stack policies for critical resources.

Rationale: Baking images and deploying immutably separates build and run concerns, giving reproducible artifacts and safe rollback paths; automated patching via SSM plus immutable deploys minimizes risk and supports compliance while maintaining recoverability.

← High Availability · All domains · Security →

Practice these questions → · Timed practice on ExamRoll.io →