Diagnosing Pulumi Resource Drift from ignoreChanges Misconfiguration

Recognizable condition

When you run pulumi preview or pulumi up, the CLI reports no changes for a resource, but you know the live cloud resource has been altered outside Pulumi (for example, tags edited in the AWS console). This mismatch is called drift.

Cause and diagnostic table

Ordered checks

1. Run a detailed preview – In the project directory, execute:

   pulumi preview --diff --stack 

   You need read access to the stack and, if the resource is AWS, valid AWS credentials. Look for lines that contain the text "ignoring changes" followed by a property path (e.g., "ignoring changes: tags"). If such lines appear, Pulumi is deliberately skipping those properties.
2. Inspect the resource definition – Open the TypeScript/JavaScript/Python file where the resource is declared and search for ignoreChanges. Example snippet:

   new aws.s3.Bucket("my-bucket", {
     acl: "private",
     tags: {
       Environment: "dev"
     },
     ignoreChanges: ["tags"]
   });

   Verify that the array lists the exact property paths you intend to ignore. A common mistake is to include a top‑level resource name or an incorrect path, which causes Pulumi to ignore more than intended.
3. Compare live state with Pulumi state – Export the stack state and compare it with the current cloud resource:

   pulumi stack export --stack  > stack.json

   Then, using the cloud provider’s CLI or console, retrieve the live resource (e.g., aws s3api get-bucket-tagging --bucket my-bucket) and check whether the values differ from those in stack.json. A mismatch confirms drift.
4. Temporarily remove ignoreChanges – Comment out or delete the ignoreChanges line, save the file, and run the preview again:

   pulumi preview --diff --stack 

   If the preview now shows a diff for the previously ignored property, the ignoreChanges setting was the cause of the drift. Note: this is a code change only; it does not modify the live resource until you run pulumi up. To roll back, simply restore the comment or re‑add the line and repeat the preview.

Fixes tied to findings

• Narrow the ignore paths – If the array contains overly broad entries (e.g., ["*"] or a parent property that encompasses fields you want managed), replace them with the specific paths you truly want to ignore. Example: change ignoreChanges: ["tags"] to ignoreChanges: ["tags.Owner"] if only the Owner tag should be left untouched.
• Remove ignoreChanges when the property should be managed – If the resource drift indicates that the ignored property ought to reflect your configuration, delete the ignoreChanges option entirely. After saving, run:

  pulumi up --stack 

  Pulumi will propose an update to bring the live resource back into sync. Review the plan carefully; if the change would trigger a replacement (e.g., altering the bucket name), consider a more targeted approach or a maintenance window.

Escalation criteria

Proceed to escalation when:

• Drift persists after correcting ignoreChanges and re‑running pulumi up.
• The resource continues to be altered by external automation (e.g., a separate CI pipeline, Terraform, or manual scripts) despite the Pulumi configuration being correct.

In these cases, review the external processes that modify the resource. Options include:

• Coordinating with the owning team to stop out‑of‑band changes.
• Using Pulumi ESC (Environment Secrets Controller) to centralize configuration and prevent drift.
• Adopting a stricter lifecycle policy (e.g., protect: true) or importing the resource into a separate stack dedicated to external management.

Limitations and practical verification

The ignoreChanges feature only affects properties explicitly listed in the array. Deeply nested changes that are not referenced by a matching path will still appear in diffs. Additionally, ignoring a property does not prevent Pulumi from planning a replacement if other properties force it.

To verify that a fix has resolved drift:

1. Run pulumi preview --diff and confirm that the previously ignored property now appears in the diff.
2. Apply the change with pulumi up.
3. After the update succeeds, check the live resource (e.g., via AWS console or CLI) to see that the property matches the value defined in your Pulumi code.

Always test these steps in a non‑production stack or a separate preview branch before applying to production to avoid unintended replacements or downtime.