SOA-C02 Deployment, Provisioning, and Automation Practice Question

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 the AWS CloudFormation console to directly update the stack with the new instance type and monitor the events.

  Why it's wrong here

  Directly updating the stack applies the new instance type immediately, with no prior summary of the exact resource-level actions CloudFormation will take. For an EC2 instance, a change to the instance type can trigger a replacement rather than an in-place update, causing potential downtime and loss of the original instance's physical ID. You can monitor events after the fact, but by then the change is already being applied, and you lose the chance to abort or revise before any disruption occurs.

• ✓

  Create a change set from the updated template, review the changes, and then execute the change set.

  Why this is correct

  A change set is generated from an updated template against the current stack, providing a detailed, resource-by-resource summary of whether CloudFormation will add, modify, or replace resources. Because changing an EC2 instance type typically requires replacement, the change set would explicitly flag a "Replace" action, letting the administrator assess the impact and even cancel before executing. Only after reviewing and confirming the change set is it executed, and the execution applies the exact changes that were previewed.

• ✗

  Use the AWS CloudFormation drift detection feature to check for differences between the stack and the template.

  Why it's wrong here

  Drift detection compares the actual live configuration of existing stack resources against the expected configuration defined in the current template, which is the opposite of what you need here. It reveals if someone manually modified infrastructure outside CloudFormation, not what a proposed template update would do. Since you haven't yet changed the template, drift detection would only report the current stack's compliance status and cannot preview whether an instance type change would cause replacement or downtime.

• ✗

  Modify the CloudFormation template locally and use the AWS CLI to validate it with 'aws cloudformation validate-template'.

  Why it's wrong here

  The validate-template command only performs a syntactic and structural validation of the template body, checking CloudFormation grammar, resource names, and some parameter constraints. It does not compare the template against the live stack, so it cannot indicate whether the instance type change would require replacing the EC2 instance or how the update would affect the existing infrastructure. Even a perfectly valid template can still cause an unwanted resource replacement, and validation alone gives no insight into those execution-level consequences.