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.

• ✗

  Custom resources with Lambda

  Why it's wrong here

  This approach involves creating a Lambda function to perform custom logic, such as retrieving a value from a central store (e.g., S3, Parameter Store) or another CloudFormation stack, and then using a CloudFormation Custom Resource to invoke that Lambda. While technically possible, it introduces significant operational overhead, including managing Lambda code, permissions, and deployment, making it an overly complex solution for the straightforward task of sharing a value between CloudFormation stacks. AWS CloudFormation provides more direct and native mechanisms for this purpose.

• ✗

  Stack outputs

  Why it's wrong here

  CloudFormation stack outputs are designed to expose values from a stack, making them visible in the AWS console or accessible via the AWS CLI `describe-stacks` command. However, these outputs are inherently scoped to the stack they originate from. They cannot be directly referenced by *other independent CloudFormation stacks* unless explicitly marked for export, which is a specific feature distinct from merely defining an output. Therefore, simply defining an output does not enable cross-stack referencing.

• ✗

  Nested stacks

  Why it's wrong here

  Nested stacks are a CloudFormation feature where one stack (the parent) deploys other stacks (the children) as part of its own template. This creates a hierarchical relationship where the parent stack manages the lifecycle of its nested children, and values can be passed down or up within this specific parent-child structure. However, the question implies independent microservices applications, suggesting separate, standalone CloudFormation stacks that need to share values, not a tightly coupled parent-child deployment model. Nested stacks are for organizing components *within* a larger application, not for sharing values between truly independent applications.

• ✓

  Cross-stack references using Export and ImportValue

  Why this is correct

  This is the native and most efficient CloudFormation mechanism for sharing values between *independent* stacks. A stack can explicitly `Export` an output value, making it discoverable and consumable by other CloudFormation stacks within the same AWS account and region. These other stacks can then use the `Fn::ImportValue` intrinsic function to reference the exported value by its unique name, establishing a direct and managed dependency without requiring custom code or complex workarounds. This approach ensures proper dependency tracking and simplifies value propagation.

Go deeper

Related to this question