Pulumi's classic aws, azure and gcp providers are generated from the equivalent Terraform providers via Pulumi's Terraform bridge. What does that mean in practice for resource coverage and for provider bugs?

## What the bridge is A Terraform provider is a plugin that knows a set of resource types, the schema of each one, and how to create, read, update and delete them against a cloud API. Pulumi's Terraform bridge takes such a provider and does two things: it wraps the plugin so Pulumi's engine can drive its CRUD operations, and it reads the provider's schema to generate typed SDKs — TypeScript, Python, Go, .NET, Java — that expose the same resources as constructors with typed argument objects. This is why Pulumi's `aws`, `azure`, `gcp`, `kubernetes` (partly), `cloudflare`, `datadog` and a long tail of other providers exist at parity with their Terraform counterparts without anyone hand-writing them. ## What it buys you **Coverage is a non-question.** "Does Pulumi support resource X?" almost always resolves to "does the upstream Terraform provider support it?" — and for the major clouds, it does. New resources land in the Pulumi provider when the bridge is regenerated against a newer upstream version and released, which is routine and frequent. **Documentation transfers.** The argument names are the same identifiers with a naming-convention translation applied. What Terraform documents as `versioning_configuration` on a resource appears as `versioningConfiguration` in TypeScript and stays `versioning_configuration` in Python. Nested block types become object types. Once you know that mapping, a Terraform provider doc page is usable as-is. **Semantics transfer too.** Diff behaviour, which changes force replacement, and the provider's idea of what is computed versus configured all come from the same schema, so the resource *behaves* the same in both tools. ## What it costs you **Shared bugs.** This is the part candidates miss. If the upstream provider mis-handles an in-place update, drops an attribute on read, or has a perpetual-diff on some field, the bridged Pulumi provider inherits it — it is literally executing that provider's code. "We hit a provider bug, let's switch tools" is not a fix; both projects are downstream of the same repository, and you either wait for the upstream release or work around it (pin a version, or ignore the offending field's changes). **A release lag on brand-new features.** A cloud service ships an API, the upstream provider adds support, then the bridge is regenerated and a Pulumi provider version is published. That gap is usually small, but it exists, and it means Pulumi is structurally not *ahead* of Terraform on bridged surfaces. **Ergonomic seams.** Generated SDKs sometimes surface things that felt natural as HCL blocks in a slightly awkward shape — a list of one object where a block was more readable, or a stringly-typed field that a hand-written SDK would have made an enum. It is minor, but it is visible. ## The native providers are a different code path Pulumi also publishes providers generated directly from cloud API metadata rather than from a Terraform provider: `aws-native` (built on the AWS Cloud Control API), `azure-native` (from Azure's resource manager specifications) and `google-native`. These do not go through the bridge, so they can expose new resources very quickly after the cloud publishes them, and they do not inherit upstream Terraform provider bugs. They come with their own tradeoffs. `aws-native` can only manage what Cloud Control exposes, so coverage is narrower than the bridged `aws` provider and gaps are real; `azure-native` is the recommended Azure provider and is comprehensive, but a machine-generated API surface can be less curated than one that has absorbed years of practitioner feedback. In practice teams mix: the bridged provider for the everyday resources, the native one where it fills a gap. That mixing is normal and both providers can manage resources in the same program. ## The misconception to defuse A surprisingly common belief is that Pulumi "transpiles to HCL" or "shells out to `terraform apply`". It does not. Pulumi has its own engine, its own state representation, its own diff and its own CLI. What it reuses is the *provider plugin* — the piece that talks to the cloud — and only for bridged providers. Saying this clearly is often the whole point of the question: it shows you understand where the boundary between engine and provider actually sits. ## How to answer it in an interview One sentence for the mechanism ("generated from the upstream provider through the bridge"), one for the upside ("so coverage and semantics track Terraform's, and the docs map across"), one for the downside ("so provider bugs are shared and there is a small release lag"), and one for the exception ("the native providers are generated from cloud APIs instead"). That is a complete answer and it takes twenty seconds.