SOA-C02 Deployment, Provisioning, and Automation Practice Question

A DevOps engineer is troubleshooting a failed CloudFormation stack update. The stack includes an Auto Scaling group with a launch template. The update changed the AMI ID in the launch template, but the new instances launched with the old AMI. What is the most likely cause?

⚠ Common exam trap

SOA-C02 often tests the misconception that editing a launch template automatically updates the Auto Scaling group — candidates forget that launch templates are versioned and the ASG may be pinned to `$Default` or a specific version, so new AMIs only take effect after the version reference is updated.

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

✓

The launch template version is not set to use the latest version.

When a CloudFormation stack references a launch template by ID without pinning a version, the Auto Scaling group uses the template's default version. Updating the AMI in a new launch template version does not change the default version automatically, so the ASG continues launching instances from the old default version. The fix is to either set the new version as default or explicitly reference the version in the ASG's LaunchTemplate specification.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The Auto Scaling group is not configured to perform a rolling update.
Why it's wrong here
Incorrect. The scenario describes new instances launched with the old AMI, which indicates the Auto Scaling group is using an old launch template version. A rolling update would only replace existing instances, not affect the template version used for new instances.
✗
The new AMI ID is invalid or not available in the region.
Why it's wrong here
If the new AMI ID were invalid or unavailable in the region, any attempt to launch a new EC2 instance from that AMI would fail. The scenario states that new instances successfully launch, but they are using the old AMI, which means instance creation is working. An invalid or regional-unavailable AMI would produce a launch failure error, not a silent fallback to a previous version. Therefore, this cannot be the cause.
✗
The CloudFormation stack update did not successfully complete.
Why it's wrong here
If the CloudFormation stack update had failed, the stack would be in UPDATE_FAILED state and would typically roll back to the previous successful template. In that case, the launch template and AMI would remain unchanged, and both old and new instances would use the original AMI. The symptom of new instances using the old AMI while the stack update is reported as successful indicates that the update itself completed, but the ASG's reference to the launch template version was not updated. Therefore, an unsuccessful stack update does not match the observed behavior.
✓
The launch template version is not set to use the latest version.
Why this is correct
When an Auto Scaling group uses a launch template, it references a specific version of that template through the Version property. Updating the AMI inside the CloudFormation stack creates a new version of the launch template, but the ASG may still point to the old default version or a fixed version number. If the Version is not set to $Latest or explicitly updated to the new version number, any new instances launched by the ASG will continue to use the old template, and therefore the old AMI. This is exactly the behavior described, so this is the correct root cause.

Go deeper

SOA-C02 Deployment, Provisioning, and Automation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question