This message was deleted.

I may be mistaken, but I’m not sure you’re going to be able to completely alleviate the behavior(s) you’re describing. Regardless of the tool in use (Pulumi or something else), the root issue is that the AWS API prevents you from deleting a subnet that has resources attached. If it’s necessary to delete/recreate a subnet in Stack A and resources from Stack B are using that subnet, there’s not much Pulumi can do. If I may ask, why are you using different stacks? What requirements led you to using separate stacks for A and B?

I am currently conducting a POC to assess if Micro-stacks are suitable for our needs. My objective is to test scenarios where changes in the output of a stack could impact dependent stacks. In my proof of concept, I replaced the VPC in Stack A, which I understand could cause foundational issues. Now I'm trying to determine the impact on Stack B. I'm wondering if the Automation API can help me solve this issue.

I don’t think Automation API will help unwind/untangle cloud resource dependencies, especially across stacks. If there aren’t major reasons to have resources in separate stacks (refer to https://www.pulumi.com/blog/iac-recommended-practices-structuring-pulumi-projects/ for some considerations about when to use/when not to use multiple projects), you may find that having all your resources in a single project will work better for you.

Thanks @salmon-account-74572. As of now, we are considering a monolithic structure and working out which one would work best for us.

Gotcha. If I can be of help, please feel free to contact me.