Following up on this message (https://pulumi-community.slack.com/archives/CRH5ENVDX/p1629414866112800) so that I can be sure my understanding is correct: I was able to use a third stack to manage the VPC peering. The reason this worked is because having the third stack create the VPC peering relationship (the requester and the accepter), add routes to an existing route table, add rules to existing security groups, etc., is because this third stack wasn’t actually changing anything in the “base” infrastructure stacks it was referencing via StackReferences. (Those are read-only, correct?) Instead, due to the way the AWS APIs work and the way the provider is written, these are “new resources” associated with existing (read-only) resources (like a route linked to a route table, or a security group rule linked to a security group). Is that a reasonable explanation of what’s happening here?

Essentially, yes. You’re not really modifying anything that is owned by the referenced stacks. As you mentioned, you’re creating new resources that are just referencing those by ID.

Is there a better or “more” correct way of explaining this? (I’m thinking of writing a blog post on the topic and want to be sure I am providing accurate information to readers.)