How do Pulumi stacks, stack references, and refresh operations affect production drift management?

Think of each stack as a branch office ledger. The network office can publish official subnet IDs, and the payments office can read them, but neither office should edit the other ledger by hand.

Pulumi uses stacks so the same infrastructure program can safely represent dev, staging, and production, or separate ownership domains. This design lets teams keep code reuse while preserving state isolation and access control.

During an update, Pulumi loads the program, reads stack config and secrets, evaluates resources, compares desired resources to state, asks providers for previews, and records resulting changes. Stack references expose selected outputs without merging ownership.

Production teams use stack policies, protected resources, explicit providers, CI previews, and scheduled refreshes. They monitor failed updates, pending operations, unexpected replacements, and drift in resources that are often modified manually during emergencies.

The tricky edge case is letting stack references become hidden global variables. If many application stacks read mutable network outputs, a network rename or replacement can cause broad downstream churn unless outputs are versioned and deprecation is planned.