🚨 Pulumi Error Guide: 'inputs to import do not match' — Align Import Args With Live State

Overview

When you adopt a brownfield resource with pulumi import, Pulumi reads the live cloud resource, then checks that the inputs declared in your program would produce that exact resource. If they disagree, it refuses to import so it never silently plans a mutation you did not intend:

error: inputs to import do not match the existing resource; importing this resource will fail unless the inputs align
    - property tags.Environment: expected "prod" but got "production"
    - property versioning: expected true but got false

The import stops with a per-property list of every mismatch between what your code says and what the cloud actually has.

Symptoms

• pulumi import (or an inline import: on a resource) fails with a list of expected X but got Y properties.
• A subsequent pulumi preview would show an update or replace on the resource you are trying to adopt.
• The resource exists in the cloud and the ID is correct, but Pulumi still refuses.
• Auto-generated code from --generate-code differs from the code you hand-wrote.

Common Root Causes

• Hand-written inputs drift from reality — the code was written from memory or an old template, not the live resource.
• Default vs. explicit values — the cloud has an explicit value your code omits (or vice versa), so the provider computes a different input.
• Provider normalization — casing, ordering, or canonical forms (an S3 region, an ARN vs. name) differ from what you typed.
• Immutable property mismatch — a value that cannot change is different, which would force a replace and is blocked outright.
• Nested/computed blocks — sub-resources or provider-managed fields your code does not declare.

Diagnostic Workflow

Let Pulumi draft the correct inputs from the live resource and compare:

pulumi import aws:s3/bucketV2:BucketV2 my-bucket my-real-bucket-name --generate-code

The command prints the exact code that matches reality. Diff it against your program:

pulumi import aws:s3/bucketV2:BucketV2 my-bucket my-real-bucket-name --generate-code > imported.txt
diff <(sed -n '/const my-bucket/,/});/p' index.ts) imported.txt

Inspect the live resource directly with the cloud CLI to confirm the true values:

aws s3api get-bucket-versioning --bucket my-real-bucket-name
aws s3api get-bucket-tagging --bucket my-real-bucket-name

Preview after each edit to watch the mismatch list shrink toward zero:

pulumi preview --diff

Example Root Cause Analysis

An engineer imported an existing S3 bucket into a TypeScript stack. The import failed with property tags.Environment: expected "prod" but got "production" and property versioning: expected true but got false. The code had been copied from a sibling stack.

Running pulumi import ... --generate-code produced the authoritative inputs: the bucket’s real tag was production and versioning was disabled. The engineer had two truths to reconcile — the code and the cloud. Because both values were mutable and the intent was to adopt as-is first, change later, they edited the code to match reality (Environment: "production", versioning disabled), re-ran the import, and it succeeded with pulumi preview showing zero diff. A follow-up commit then flipped versioning on deliberately, as a reviewed change rather than a hidden side effect of import.

Prevention Best Practices

• Always start an import with --generate-code and adopt the generated inputs as your baseline, then refactor.
• Import to match reality first (zero-diff preview), and make intended changes in a separate, reviewed commit.
• Check the live resource with the cloud CLI/console before writing inputs, not from memory.
• Watch immutable properties especially — a mismatch there means adoption would require a replace.
• Import one resource at a time and confirm a clean preview before moving to the next.

Quick Command Reference

pulumi import <type> <name> <id> --generate-code   # draft matching inputs
pulumi import <type> <name> <id>                   # perform the import
pulumi preview --diff                              # confirm zero-diff after edits
pulumi stack export > snapshot.json                # snapshot before importing
aws s3api get-bucket-versioning --bucket <name>    # verify true cloud state

Conclusion

inputs to import do not match the existing resource is Pulumi protecting you: it will not adopt a resource while your code disagrees with reality, because that would smuggle in a mutation or replace. Use --generate-code to learn the authoritative inputs, edit your program to match the live resource for a zero-diff import, and make any real changes afterward as an explicit, reviewed step.