DOP-C02 Configuration Management and IaC 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.

• ✗

  Hardcode the VPC and subnet IDs in the application template.

  Why it's wrong here

  Hardcoding VPC and subnet IDs in the application template couples the app to specific infrastructure values that may change between environments (e.g., dev, prod) or when the network stack is recreated. It also eliminates CloudFormation's ability to track and validate resource dependencies, so if the VPC is replaced, the app stack will silently reference a non-existent network. This approach undermines portability, increases manual maintenance, and risks configuration drift because the template must be edited and redeployed for each environment.

• ✓

  Export the VPC ID and subnet IDs from the network stack using the 'Export' field and import them in the application stack using Fn::ImportValue.

  Why this is correct

  Exporting the VPC and subnet IDs from the network stack via the 'Export' field and importing them into the application stack with Fn::ImportValue establishes a native CloudFormation cross-stack reference within the same account and region. This creates an explicit dependency between the stacks, ensuring the network stack is created before the application stack and that the latest exported values are resolved at stack operation time. It avoids hardcoding by letting CloudFormation manage the wiring, and it supports updates and reuse across multiple dependent stacks. This is the intended, first-class mechanism for sharing outputs between independent CloudFormation stacks.

• ✗

  Create the network stack as a nested stack inside the application stack.

  Why it's wrong here

  Creating the network stack as a nested stack inside the application stack tightly couples the lifecycle of the network resources to the application stack—every time the application stack is updated or deleted, the nested network stack is also updated or deleted. This is problematic when the network infrastructure is shared across multiple application stacks, because nested stacks cannot be referenced by other top-level stacks, limiting reuse. It also increases the blast radius and complexity of updates, as a change to the network layer would be rolled out within the application stack's operation. For independent infrastructure that must be managed and reused separately, top-level stacks with cross-stack references are the correct pattern, not nested stacks.

• ✗

  Store the VPC and subnet IDs in AWS Systems Manager Parameter Store and retrieve them using dynamic references.

  Why it's wrong here

  Storing VPC and subnet IDs in Parameter Store and retrieving them via dynamic references is a valid pattern for configuration. However, for CloudFormation stacks to share outputs within the same account and region, CloudFormation's `Fn::ImportValue` is the direct and intended mechanism, eliminating the need for the network stack to explicitly write its outputs to Parameter Store. This approach would be suitable for sharing values across AWS accounts or regions, or for non-CloudFormation managed configuration and secrets.

Go deeper

Related to this question