DOP-C02 Configuration Management and IaC Practice Question
A company uses AWS CloudFormation to manage infrastructure. They have a stack that includes a VPC, subnets, and EC2 instances. They want to update the AMI ID of an EC2 instance without causing downtime. Which TWO approaches meet this requirement?
⚠ Common exam trap
Many exam-takers confuse the 'AutoScalingRollingUpdate' policy with a generic EC2 instance update, not realizing it only applies to Auto Scaling groups, and they may incorrectly assume that setting 'MinInstancesInService' to 0 is acceptable for zero-downtime updates.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use a CloudFormation update with a rolling update policy on the Auto Scaling group.
Option C is correct because attaching an AutoScalingRollingUpdate policy to the Auto Scaling group resource lets CloudFormation replace instances in batches, keeping a configurable number of instances in service (MinInstancesInService) so the AMI change is applied without downtime. Option D is correct because a custom resource backed by a Lambda function can orchestrate an in-place or rolling update via AWS Systems Manager (for example, SSM Run Command or Automation), allowing the AMI to be changed while maintaining availability. Option A is not correct because setting MinInstancesInService to 0 allows all instances to be taken out of service simultaneously, which causes downtime. Option B is not correct because deleting and recreating the stack destroys the existing resources, causing downtime and data loss. Option E is not correct because spreading instances across Availability Zones does not by itself update the AMI or guarantee zero-downtime replacement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use CloudFormation stack update with 'UpdatePolicy' set to 'AutoScalingRollingUpdate' and 'MinInstancesInService' set to 0.
Why it's wrong here
Setting MinInstancesInService to 0 in an AutoScalingRollingUpdate policy explicitly tells CloudFormation it may bring all instances down before new ones are launched. This defeats the purpose of a rolling update because it offers zero capacity guarantee during the replacement, effectively causing full application downtime. A proper rolling update should set MinInstancesInService to at least 1 (or your desired minimum) to preserve service availability throughout the batch-by-batch replacement.
- ✗
Delete the stack and recreate it with the new AMI.
Why it's wrong here
Deleting the entire CloudFormation stack and recreating it is a 'rip and replace' approach that removes all resources in the stack, including the Auto Scaling group, launch template, and related dependencies. This causes complete downtime for the duration of deletion and recreation, and it also discards any incremental state or resources not defined in the template, such as data stored on instance volumes or managed resources. It is not a safe or minimal-impact way to update an AMI, as it takes the whole stack offline rather than updating the ASG in a controlled, incremental manner.
- ✓
Use a CloudFormation update with a rolling update policy on the Auto Scaling group.
Why this is correct
Configuring an UpdatePolicy with AutoScalingRollingUpdate on the AWS::AutoScaling::AutoScalingGroup resource is the native CloudFormation way to replace instances with a new AMI while maintaining availability. CloudFormation automatically batches instance replacements by terminating old instances and launching new ones that use the updated launch template or configuration, with MinInstancesInService and MaxBatchSize controlling how many instances remain available. This integrates cleanly with the stack update workflow and is the recommended pattern for AMI rollouts in CloudFormation-managed Auto Scaling groups.
- ✓
Create a custom resource backed by a Lambda function that updates the instance using AWS Systems Manager.
Why this is correct
A Lambda-backed custom resource in CloudFormation can execute arbitrary update logic during a stack update, including invoking AWS Systems Manager to run automations or commands on the instances. This can perform in-place configuration changes, patch applications, or even orchestrate a more customized replacement process that cannot be expressed with built-in resource update policies. However, this approach does not literally change the AMI of an existing instance (the root volume is fixed at launch), so its use case is typically for updating application state or performing a custom workflow that still ultimately replaces instances via SSM automation; it is valid but adds complexity and maintenance overhead compared to a simpler rolling update.
- ✗
Deploy the instances across multiple Availability Zones and update each zone separately.
Why it's wrong here
Splitting instances across multiple Availability Zones and updating each zone separately is not a CloudFormation feature, nor does it automatically avoid downtime. Updating an Auto Scaling group per AZ would require custom scripting to suspend or modify capacity per zone, and without an UpdatePolicy or Instance Refresh mechanism, terminating old instances and launching new AMI-based instances in each zone still occurs outside of CloudFormation's update semantics. This approach is mainly relevant for multi-AZ database maintenance (e.g., RDS), not for EC2 instances in an ASG, and it does not leverage CloudFormation's native update capabilities.
Visual reference
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,298-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company uses AWS CloudFormation to manage infrastructure. They have a production stack that creates an Auto Scaling group. They want to update the launch configuration to use a new Amazon Machine Image (AMI) ID without causing downtime. Which update policy should they set on the Auto Scaling group?
medium- A.AutoScalingScheduledAction
- B.AutoScalingReplacingUpdate
- ✓ C.AutoScalingRollingUpdate
- D.AutoScalingBatchUpdate
Why C: The AutoScalingRollingUpdate policy allows CloudFormation to update the Auto Scaling group's launch configuration by gradually replacing instances in batches, ensuring that a minimum number of instances remain in service throughout the update. This prevents downtime by terminating old instances and launching new ones with the updated AMI in a controlled, rolling fashion.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.