DVA-C02 Development with AWS Services Practice Question

A company uses AWS CloudFormation to deploy infrastructure. The developer needs to pass a list of security group IDs to an EC2 instance launch configuration. The security groups are created in another stack. How should the developer obtain the security group IDs?

⚠ Common exam trap

Watch out — candidates often confuse Fn::GetAtt and Fn::ImportValue, mistakenly thinking that GetAtt can retrieve attributes across stacks, when in fact it is strictly intra-stack, while ImportValue is the only native CloudFormation function for cross-stack references.

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

✓

Use Fn::ImportValue to import the exported outputs from the other stack.

Fn::ImportValue is designed to retrieve exported outputs from another CloudFormation stack. When security groups are created in a separate stack, the developer must export their IDs using the Export field in the Outputs section of that stack, and then use Fn::ImportValue in the current stack to reference those exported values. This is the standard cross-stack reference mechanism in CloudFormation, enabling decoupled infrastructure management.

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 Fn::GetAtt to retrieve the IDs from the other stack's resources.
Why it's wrong here
The Fn::GetAtt intrinsic function is designed to retrieve an attribute value from a resource *within the same CloudFormation stack template*. It operates exclusively on resources defined in the current template and cannot reach across stack boundaries to fetch attributes from resources deployed by a separate, independently managed CloudFormation stack. Therefore, it is unsuitable for referencing resources in a distinct 'other stack' that exists outside the current template's scope.
✓
Use Fn::ImportValue to import the exported outputs from the other stack.
Why this is correct
The Fn::ImportValue intrinsic function is the correct mechanism for referencing outputs from other CloudFormation stacks. It allows a stack to consume values that have been explicitly exported by another stack using the Fn::Export function in its `Outputs` section, referencing the unique name provided during export. This design pattern promotes modularity and enables decoupled infrastructure deployments by facilitating secure and managed cross-stack communication.
✗
Use a nested stack to include the security group resources in the same template.
Why it's wrong here
While nested stacks allow for modularity by breaking down a single application into multiple, smaller CloudFormation templates managed by a root stack, they are not ideal for referencing resources from an *already existing, separate* stack. Using a nested stack would imply either redeploying the security group resources as part of a new parent-child relationship or moving them, rather than simply referencing an independent, pre-existing infrastructure component. This approach changes the architectural relationship instead of providing a cross-stack reference mechanism for existing, decoupled resources.
✗
Use Fn::Ref to reference the security group IDs directly.
Why it's wrong here
The Fn::Ref intrinsic function is used to return the physical ID or a specific attribute (like the name) of a resource *within the same CloudFormation template*. It is limited to referencing resources declared in the current stack's template and lacks the capability to discover or reference resources that belong to an entirely separate, independently deployed CloudFormation stack. Consequently, Fn::Ref cannot be used to directly obtain the ID of a security group residing in a different stack.

Go deeper

DVA-C02 Development with AWS Services Practice Question

Why each option matters

Option-by-option breakdown

Related to this question