Outputs for cross-stack references in AWS - Step-by-Step Execution

Process Flow - Outputs for cross-stack references

Create Stack A

↓

Define Output in Stack A

↓

Deploy Stack A

↓

Create Stack B

↓

Import Output from Stack A in Stack B

↓

Use Imported Value in Stack B

↓

Deploy Stack B

Stack A creates an output value. Stack B imports this output to use it, enabling communication between stacks.

Execution Sample

AWS

Stack A:
Resources:
  MyBucket:
    Type: AWS::S3::Bucket
Outputs:
  MyBucketName:
    Value: !Ref MyBucket
    Export:
      Name: MyBucketNameExport

Stack B:
Resources:
  MyBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket: !ImportValue MyBucketNameExport

Stack A exports a bucket name. Stack B imports that bucket name to attach a policy.

Process Table

Step	Action	Stack	Output/Import Name	Value	Result
1	Create Stack A with bucket resource	Stack A	-	-	Stack A created with bucket
2	Define Output 'MyBucketName' exporting bucket name	Stack A	MyBucketNameExport	my-bucket-123	Output defined and exported
3	Deploy Stack A	Stack A	-	-	Stack A deployed, output available
4	Create Stack B referencing output from Stack A	Stack B	MyBucketNameExport	my-bucket-123	ImportValue resolves to bucket name
5	Use imported value in Stack B resource	Stack B	-	my-bucket-123	Resource configured with imported bucket name
6	Deploy Stack B	Stack B	-	-	Stack B deployed using cross-stack reference

💡 Stack B deployment completes using output value exported by Stack A

Status Tracker

Variable	Start	After Step 2	After Step 4	Final
MyBucketNameExport	undefined	my-bucket-123	my-bucket-123	my-bucket-123
Stack A Deployment Status	not deployed	not deployed	deployed	deployed
Stack B Deployment Status	not deployed	not deployed	not deployed	deployed

Key Moments - 2 Insights

Why do we need to export an output in Stack A before Stack B can import it?

Stack A must explicitly export the output with a name so AWS CloudFormation can share it. Without export, Stack B cannot reference the value (see execution_table step 2 and 4).

What happens if Stack A is not deployed before deploying Stack B?

Stack B's import will fail because the exported value does not exist yet. Stack A must be deployed first to make the output available (see execution_table step 3 and 6).

Visual Quiz - 3 Questions

Look at the execution table, what is the value of 'MyBucketNameExport' after Step 2?

A undefined

B not deployed

C my-bucket-123

D -

💡 Hint

Check the 'Value' column in execution_table row for Step 2

At which step does Stack B successfully import the output value?

A Step 4

B Step 3

C Step 2

D Step 6

💡 Hint

Look at the 'Action' and 'Result' columns in execution_table for when ImportValue resolves

If Stack A was not deployed, what would happen when deploying Stack B?

A Stack B deploys successfully with default values

B Stack B deploy fails due to missing import

C Stack B ignores the import and continues

D Stack B creates Stack A automatically

💡 Hint

Refer to key_moments about deployment order and import availability

Concept Snapshot

Outputs in one stack can be exported with a name.
Another stack can import these outputs by that name.
Stack A must be deployed first to make outputs available.
Use Export in Outputs section and !ImportValue in other stacks.
This enables sharing resources between stacks safely.

Full Transcript

In AWS CloudFormation, one stack can share values with another stack using outputs and imports. First, Stack A creates a resource and defines an output with an export name. After deploying Stack A, this output becomes available. Stack B can then import this output by referencing the export name. Stack B uses the imported value to configure its resources. This cross-stack reference requires Stack A to be deployed before Stack B. If Stack A is not deployed, Stack B's deployment will fail because the import cannot resolve. This mechanism helps stacks communicate and share resource information safely and cleanly.

Practice

1. What is the main purpose of using Outputs in AWS CloudFormation stacks?

easy

A. To share important values like resource IDs between different stacks

B. To delete resources automatically after stack deletion

C. To increase the stack creation speed

D. To encrypt stack resources

Solution

1. Step 1: Understand Outputs role

   Outputs provide a way to expose key information from one stack.

2. Step 2: Identify sharing purpose

   This information can be used by other stacks to reference resources like IDs or names.

3. Final Answer:

   To share important values like resource IDs between different stacks -> Option A

4. Quick Check:

   Outputs share values across stacks = A [OK]

Hint: Outputs share values between stacks, not speed or encryption [OK]

Common Mistakes:

• Thinking Outputs delete resources
• Believing Outputs speed up stack creation
• Confusing Outputs with encryption

2. Which syntax correctly exports an output value named MyBucketName for cross-stack use in CloudFormation?

easy

A. "Outputs": { "BucketName": { "Value": "MyBucket", "Export": "MyBucketName" } }

B. "Outputs": { "BucketName": { "Value": { "Ref": "MyBucket" }, "ExportName": "MyBucketName" } }

C. "Outputs": { "BucketName": { "Value": { "Ref": "MyBucket" }, "Export": { "Name": "MyBucketName" } } }

D. "Outputs": { "BucketName": { "Value": { "GetAtt": ["MyBucket", "Name"] }, "Export": { "Name": "MyBucketName" } } }

Solution

1. Step 1: Check correct Export syntax

   The Export field must be an object with a Name key inside Outputs.

2. Step 2: Validate Ref usage and Export name

   "Outputs": { "BucketName": { "Value": { "Ref": "MyBucket" }, "Export": { "Name": "MyBucketName" } } } uses correct Ref and Export with Name key, matching CloudFormation syntax.

3. Final Answer:

   "Outputs": { "BucketName": { "Value": { "Ref": "MyBucket" }, "Export": { "Name": "MyBucketName" } } } -> Option C

4. Quick Check:

   Export uses Export: { Name: "..." } = A [OK]

Hint: Export must be an object with Name key, not a string [OK]

Common Mistakes:

• Using ExportName instead of Export with Name
• Setting Export as a string instead of object
• Incorrect Value reference syntax

3. Given two stacks, StackA exports an output named VpcId. StackB imports it using Fn::ImportValue. What will happen if StackA's export name changes but StackB is not updated?

medium

A. StackB will ignore the import and deploy without errors

B. StackB will automatically update to the new export name

C. StackB will use the old value cached locally

D. StackB deployment will fail because the import value no longer exists

Solution

1. Step 1: Understand ImportValue dependency

   StackB depends on StackA's export name to import the value correctly.

2. Step 2: Effect of changing export name

   If StackA changes the export name, StackB's import reference breaks and causes deployment failure.

3. Final Answer:

   StackB deployment will fail because the import value no longer exists -> Option D

4. Quick Check:

   ImportValue depends on exact export name = D [OK]

Hint: ImportValue needs exact export name; changes break import [OK]

Common Mistakes:

• Assuming imports auto-update with export name changes
• Believing imports cache old values
• Thinking imports are optional and ignored if missing

4. You have this output in StackA:

{
  "Outputs": {
    "SubnetId": {
      "Value": { "Ref": "Subnet" },
      "Export": { "Name": "SubnetId" }
    }
  }
}

When deploying StackB that imports SubnetId, you get an error about duplicate export names. What is the likely cause?

medium

A. StackB is missing the ImportValue function

B. Another stack already exports the name "SubnetId", causing a conflict

C. The export name "SubnetId" is invalid and not allowed

D. The Ref function is used incorrectly in the output

Solution

1. Step 1: Understand export name uniqueness

   Export names must be unique across all stacks in the same region and account.

2. Step 2: Identify cause of duplicate export error

   The error means another stack already uses "SubnetId" as an export name, causing conflict.

3. Final Answer:

   Another stack already exports the name "SubnetId", causing a conflict -> Option B

4. Quick Check:

   Export names must be unique = C [OK]

Hint: Export names must be unique across stacks to avoid conflicts [OK]

Common Mistakes:

• Thinking export names can be reused in different stacks
• Assuming ImportValue missing causes export conflict
• Believing Ref usage causes export name errors

5. You want to share a VPC ID from StackA to StackB using outputs and imports. StackA exports the VPC ID as VpcIdExport. StackB imports it with Fn::ImportValue: VpcIdExport. Later, you need to update StackA to create a new VPC and export its ID with the same name. What is the best practice to avoid deployment failures in StackB?

hard

A. Change the export name in StackA and update StackB to import the new name

B. Delete StackB before updating StackA, then redeploy StackB after update

C. Keep the export name the same and update StackB without changes

D. Remove the export from StackA and hardcode the VPC ID in StackB

Solution

1. Step 1: Recognize export name immutability

   Export names cannot be changed or deleted without affecting dependent stacks.

2. Step 2: Plan safe update

   To update the VPC and export a new ID, use a new export name and update StackB to import that new name.

3. Step 3: Avoid breaking dependencies

   This avoids deployment failures and keeps stacks consistent.

4. Final Answer:

   Change the export name in StackA and update StackB to import the new name -> Option A

5. Quick Check:

   Update export name and import to avoid conflicts = B [OK]

Hint: Change export name and update imports to avoid breaking stacks [OK]

Common Mistakes:

• Deleting dependent stacks before update
• Keeping export name same causing conflicts
• Hardcoding values instead of using imports