DVA-C02 Deployment 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.

• ✗

  Delete the stack and start over.

  Why it's wrong here

  Deleting the entire CloudFormation stack and recreating it is an unnecessary and inefficient approach. CloudFormation is designed to manage infrastructure as code, including updates to existing resources. If a stack fails due to an Availability Zone capacity issue, the template can be modified to address the specific problem, such as changing the AZ or subnet, and then an update operation can be performed, preserving existing resources that are not affected by the change. This method minimizes downtime and avoids the complete teardown and rebuild of potentially complex infrastructure.

• ✗

  Change the instance type to one that is supported.

  Why it's wrong here

  Changing the instance type to one that is supported might resolve the immediate deployment failure, but it doesn't address the root cause if the original instance type is indeed required for the application's performance or cost profile. The error typically indicates a capacity issue for the *specified* instance type within a *particular* Availability Zone, not that the instance type is universally unsupported in the region. Forcing a different instance type could lead to suboptimal resource allocation or increased costs, making it a less ideal solution than resolving the AZ constraint.

• ✓

  Update the stack to specify a different subnet or not specify an Availability Zone.

  Why this is correct

  Updating the stack to specify a different subnet or removing the explicit Availability Zone (AZ) specification is the most effective and flexible solution. If a specific AZ lacks capacity for the requested instance type, deploying into a different subnet, which is tied to another AZ, can resolve the issue. Alternatively, by not specifying an AZ, CloudFormation can automatically select an available AZ with sufficient capacity for the desired instance type, ensuring successful deployment while maintaining the intended resource configuration. This leverages CloudFormation's intelligence to handle underlying infrastructure constraints.

• ✗

  Create the stack in a different region.

  Why it's wrong here

  Creating the stack in a different AWS region is an overly drastic and often unnecessary measure. The reported issue, a capacity constraint for an instance type within an Availability Zone, is localized to the current region's infrastructure, not a global service unavailability. Migrating to a new region involves significant overhead, including re-configuring network settings, data migration, and potential latency impacts, none of which are required to resolve a simple AZ capacity problem within the existing region. The problem can be resolved by adjusting the AZ or subnet within the current region.

Go deeper

Related to this question