Two CloudFormation stacks in a university account both create workloads in the same VPC. Each template currently pastes its own copy of the VPC id, and the copies have already diverged. How should both stacks get the id?
Select an answer to reveal the explanation.
Short Explanation
One street address, two clipboards, and the clipboards already disagree. You keep a single source: a parameter you pass in, or an export the network stack publishes and the other stack imports. Copying the id into both files is how you got here.
Full Explanation
A parameter or a cross-stack export gives both stacks the same VPC id from one place. When the network stack exports the id, the workload stacks import it and cannot silently carry an old copy. Pasting the id into each template is the habit that already diverged. A second VPC isolates the stacks from the shared network they were required to use. A public object exposes an account identifier and is not a stack reference CloudFormation will track. Caveat: an import fails if the export name changes or the exporting stack tries to delete while importers exist, so treat the export name as stable. Operational check: both stacks' resolved VPC id should match the network stack's output, with no hardcoded id left in the workload templates. Exports live on the exporting stack's outputs and must be unique in the Region and account. Importers store the export name, not a copy of the id, so a new VPC id in the network stack flows through on the next update. Parameters are the right tool when a person or a pipeline passes the id in and you do not want a hard dependency between stacks. Either way, delete the pasted ids so they cannot diverge again.