Task 2.2: Describe how Terraform uses providers

• ATerraform Core calls the AWS APIs itself and uses the provider only to look up argument names

  Incorrect

  Core is provider-agnostic; the API calls are the provider plugin's job.

• BThe AWS provider plugin turns the resource into AWS API calls and reports back to Core

  Correct

  Providers are plugins that implement resources and data sources for a service; Terraform Core talks to them over RPC and they make the API calls.

• CTerraform Core starts the provider plugin as a process and talks to it over RPC

  Correct

  Providers are plugins executed as separate processes that communicate with the Terraform binary over an RPC interface.

• DThe provider is a module in the Registry that contains a template for every AWS service

  Incorrect

  A provider is a compiled plugin binary, not a module of Terraform configuration.

• EThe provider runs inside AWS and receives the configuration files from Terraform Core

  Incorrect

  Providers run on the machine that runs Terraform, as separate local processes.

Terraform Core handles configuration, state and planning; provider plugins know each platform's API.

• AIt uses whichever provider block appears first in the configuration files

  Incorrect

  Block order is irrelevant; the resource type's prefix decides the default provider.

• BIt reads the provider from the dependency lock file entry for the bucket

  Incorrect

  The lock file lists provider versions and checksums, not which provider each resource uses.

• CIt reads the first word of the resource type as the provider's local name

  Correct

  If a resource does not say which provider configuration to use, Terraform interprets the first word of the resource type as the local name of its provider.

• DIt asks the Registry which provider publishes a type called google_storage_bucket

  Incorrect

  Terraform does not query the Registry per resource; the local name comes from the type prefix.

Using each provider's preferred local name lets resources pick their provider from the type prefix, so the provider argument is rarely needed.

• Aterraform version

  Incorrect

  version shows Terraform and the installed providers, not where each requirement comes from.

• Bterraform providers

  Correct

  terraform providers prints the provider requirements of the configuration, including those of its modules.

• Cterraform output

  Incorrect

  output prints the root module's output values; it says nothing about provider requirements.

• Dterraform graph -type=plan

  Incorrect

  graph prints the dependency graph in DOT format, not a list of requirements.

terraform providers answers "who needs which provider" across the module tree.

• AThey are meta-arguments, built into the Terraform language rather than the provider

  Correct

  Meta-arguments are built into the Terraform language; the provider developer decides only the resource's own arguments, which the provider documentation lists.

• BThey are deprecated arguments that providers have stopped documenting

  Incorrect

  None of them is deprecated; they are part of the current language and documented in the language reference.

• CThey come from a separate utility provider that the configuration must also require

  Incorrect

  No extra provider is involved; the language itself provides them in resource blocks.

• DThey need the provider to opt in to them, resource type by resource type

  Incorrect

  Meta-arguments belong to the language, not to the provider, so no provider has to add support for them.

The work is split: providers define resource types and their arguments, while repetition, ordering and lifecycle rules come from the language, so they look the same whichever provider a resource belongs to.

• Ainit downloads the hashicorp/terraform provider automatically for every configuration

  Incorrect

  hashicorp/terraform is an old, incompatible provider and should never be declared.

• BData sources never need a provider

  Incorrect

  Most data sources belong to providers that must be required.

• CIt belongs to the built-in terraform provider, which needs no declaration

  Correct

  One provider is built into Terraform itself; it does not need to be declared in required_providers.

• Drequired_providers is optional for providers used only in data blocks

  Incorrect

  Requirements apply equally to data sources and resources.

The terraform provider is built in, with the special address terraform.io/builtin/terraform.

• AProvider blocks cannot contain any expressions, only literal values

  Incorrect

  Expressions are allowed, including variables and locals.

• BA provider block can reference a resource only after declaring it in depends_on

  Incorrect

  Provider blocks have no depends_on; the value simply must be known at plan time.

• CRoles for providers must be created by a different provider type

  Incorrect

  The issue is when the value is known, not which provider creates it.

• DProvider arguments may use only values known before apply, such as variables

  Correct

  You can reference input variables and literal values in provider configuration, but not computed resource attributes.

Providers are configured before planning, so their settings must be known up front; split creation of the role into another configuration or pass it in as a variable.

• Aterraform validate -json prints the full schema of each resource type

  Incorrect

  validate checks the configuration; it does not print provider schemas.

• BThe schemas are stored in .terraform.lock.hcl after init

  Incorrect

  The lock file records versions and checksums only.

• Cterraform graph prints each resource type with its arguments

  Incorrect

  graph prints the dependency graph of the configuration.

• Dterraform providers schema -json prints those provider schemas

  Correct

  The providers schema command prints detailed schemas for the providers used in the current configuration as JSON.

• EThe schemas come from the provider plugins installed by terraform init

  Correct

  Each provider defines its managed resources and data sources, and Terraform reads the schemas from the installed plugins.

Provider schemas live in the plugins and are exposed as JSON by terraform providers schema -json.