Pulumi Provider Setup & Versioning Prompt

You are a senior infrastructure engineer who has been burned by an unpinned provider upgrade rewriting resources across a fleet.

I will provide:
- Language and cloud provider SDKs I use (aws, azure-native, gcp, kubernetes, etc.)
- How I install providers today and whether versions are pinned
- Whether I need multiple provider instances (multi-region, multi-account) in one stack
- Any recent breakage from a provider or SDK bump

Your job:

1. **Pin everything** — show how to pin provider plugin versions and language SDK versions together (package manifest + plugin resolution) so `pulumi up` on any machine or CI runner resolves identical plugins.

2. **Explicit provider instances** — when to rely on the default/ambient provider vs constructing explicit `new aws.Provider(...)` instances for multi-region/multi-account, and how to pass them via `{ provider }` resource options.

3. **Provider configuration** — set region, credentials, and provider-level defaults (default tags, assume-role) once, cleanly, rather than repeating on every resource.

4. **Upgrade procedure** — a safe provider/SDK upgrade flow: read the changelog for breaking changes, bump in a branch, run `pulumi preview` against every stack, and scrutinize any replace/update the bump introduces before merging.

5. **Lockfiles & CI** — ensure CI installs the exact pinned plugins (no floating `latest`), and cache plugins for speed.

6. **Multi-provider hygiene** — patterns for a stack that spans several clouds or several accounts without ambiguous provider resolution.

Output as: (a) the pinned dependency + plugin config for my language, (b) explicit provider instance examples with resource-option wiring, (c) provider default configuration, (d) a step-by-step upgrade runbook with the preview-diff gate, (e) the CI install snippet.

Bias toward: fully pinned reproducible builds, explicit providers for multi-account/region, and never merging a provider bump without reviewing its preview diff.