🧱 Pulumi Error: 'Resource Has a Problem' During Create

Exact Error Message

Diagnostics:
  aws:s3/bucket:Bucket (data-bucket):
    error: 1 error occurred:
        * creating S3 Bucket (my-app-data): operation error S3: CreateBucket,
          https response error StatusCode: 409, api error BucketAlreadyExists:
          The requested bucket name is not available.

error: update failed

The pattern is always the same: a resource URN, then error: ... has a problem or creating <resource>: <provider/cloud message> during a create step of pulumi up. The wrapped text after the colon is the real cause and comes straight from the cloud API (here, an S3 409 BucketAlreadyExists).

What It Means

When pulumi up creates a resource, it hands your inputs to the provider plugin, which calls the cloud API. If that API rejects the request, the provider returns an error and Pulumi reports the resource as having “a problem” during create. Pulumi itself did nothing wrong; it faithfully relayed a failure from AWS/GCP/Azure/Kubernetes.

Because the failure happened mid-create, the resource may not exist at all, or may exist in the cloud but not yet be recorded in your Pulumi state (a partial create). Both situations are recoverable, but the right recovery depends on which one you are in, so read the wrapped message first.

Common Causes

• The cloud API rejected the inputs: name collision, invalid value, unsupported region/type.
• Missing IAM/RBAC permission for the identity Pulumi is using (AccessDenied, Forbidden).
• A quota or limit was hit (LimitExceeded, TooManyRequests).
• A dependency was not actually ready despite Pulumi’s ordering (eventual consistency in the cloud).
• The resource already exists out-of-band and must be imported rather than created.

Diagnostic Commands

Re-run with full detail to see the complete provider/cloud error and request context:

pulumi up --logtostderr --logflow -v=9 2>pulumi.log

Preview to confirm exactly what Pulumi intends to create before retrying:

pulumi preview --diff

Check whether the resource landed in state despite the failure (partial create):

pulumi stack export --show-secrets | grep -A5 'data-bucket'

Verify out-of-band with the cloud’s own CLI whether the object actually exists:

aws s3api head-bucket --bucket my-app-data

Step-by-Step Resolution

1. Read the wrapped message after the colon. That single line (the cloud API error) tells you whether this is a name collision, permissions, quota, or bad input. Everything else follows from it.

2. Fix the specific cause. For a name collision, change the input; do not fight the cloud:

const bucket = new aws.s3.Bucket("data-bucket", {
  bucket: `my-app-data-${pulumi.getStack()}`, // make the name unique
});

3. For a permissions error, grant the missing action to the identity Pulumi runs as (check pulumi whoami and your cloud credentials), then retry.

4. If the resource already exists and you want Pulumi to manage it, import it instead of creating a duplicate:

pulumi import aws:s3/bucket:Bucket data-bucket my-app-data

5. If it was a partial create (the object exists in the cloud but not in state), either import it as above, or delete the orphaned cloud object and let Pulumi create it cleanly.

6. Retry the deployment and confirm the create succeeds:

pulumi up --diff

+ aws:s3:Bucket  data-bucket  created (1s)
Resources:
    + 1 created

7. For transient errors (throttling, eventual consistency), simply re-run pulumi up; Pulumi picks up where it left off and only creates what is still missing.

Prevention

• Make resource names unique per stack (interpolate pulumi.getStack()) so parallel environments never collide.
• Right-size IAM/RBAC for the deploying identity ahead of time; least privilege still needs the create actions.
• Watch cloud quotas and request increases before large rollouts to avoid LimitExceeded mid-apply.
• Import pre-existing resources rather than letting up collide with them.
• Add explicit dependsOn where the provider cannot infer ordering, to sidestep eventual-consistency failures.
• Start from validated resource definitions in the Pulumi prompt library so inputs are correct before the first up.

Related Errors

• resource already exists — a specific create collision; import instead of create.
• the stack has pending operations — an interrupted up that must be cleared before retrying.
• Diff failed: ... panic — a provider crash, not a rejected create.
• AccessDenied / Forbidden — the permissions subclass of this error, wrapped from the cloud API.

Frequently Asked Questions

Where is the real cause in this message? In the text after the last colon on the resource line. Pulumi wraps the raw cloud/provider error verbatim, so read that phrase (e.g. BucketAlreadyExists, AccessDenied) rather than the generic has a problem wrapper.

Did the resource get created even though up failed? Sometimes. If the cloud created the object but Pulumi could not record it, you have a partial create. Run pulumi stack export and check the cloud directly, then import or delete the orphan.

Is it safe to just re-run pulumi up? For transient failures (throttling, eventual consistency) yes, Pulumi resumes and only creates what is missing. For deterministic failures (bad input, name collision) it will fail again until you fix the cause.

How do I hand an existing resource to Pulumi after a collision? Use pulumi import <type> <name> <id> to bring the real resource under management instead of creating a duplicate.

Why do names collide across my environments? Static resource names are global or account-wide for many services. Interpolate the stack name so each environment gets a distinct name. For more create and import patterns, see the Pulumi guides.