Terraform fundamentals: providers and state basics
Free HashiCorp Certified: Terraform Associate (004) practice — 6 questions on Terraform fundamentals: providers and state basics, with explanations. No sign-up. Full 12-question mixed test →
Your team's Terraform configuration currently pins the AWS provider to version 4.0.0. You want Terraform to automatically pick up new minor and patch releases (e.g., 4.1.0, 4.5.2) but must never allow the provider to upgrade to the 5.x major version line. Which version constraint should you use in the required_providers block?
The pessimistic constraint operator behaves differently depending on how many version segments are given. '~> 4.0' (two segments) means >= 4.0.0 and < 5.0.0, so it allows both minor and patch upgrades within the 4.x line but blocks 5.0.
A teammate updated the version constraint for the azurerm provider in required_providers from "~> 3.0" to "~> 4.0" and pushed the change. When you pull the change and run 'terraform plan', Terraform reports that the installed provider version does not satisfy the new constraints and refuses to proceed, even though your .terraform.lock.hcl still lists the old 3.x version. What is the correct command to resolve this?
'terraform init -upgrade' tells Terraform to consider newer provider versions that satisfy the updated constraints, download the new provider, and update the .terraform.lock.hcl file accordingly.
You must deploy identical S3 buckets into both us-east-1 and eu-west-1 using a single AWS provider configuration block per region. You've defined a second aws provider block with alias = "euwest" pointing at eu-west-1. How do you tell the resource for the European bucket to use that specific provider configuration?
To route a resource to a non-default (aliased) provider configuration, you set the meta-argument 'provider = <PROVIDER TYPE>.<ALIAS>' inside the resource block, e.g., provider = aws.euwest.
Your configuration needs both the official HashiCorp AWS provider and the community-maintained GitHub provider published under the 'integrations' namespace on the Terraform Registry. Which required_providers block correctly declares both?
The GitHub provider on the public registry is published under the 'integrations' namespace (source = "integrations/github"), not 'hashicorp'. This option correctly maps each local name to its true namespace/type using the required object syntax {source, version} inside the required_providers block.
A resource managed by Terraform was manually deleted from the cloud console outside of Terraform's workflow. Your configuration for that resource is unchanged. What will 'terraform plan' show the next time it is run?
During plan, Terraform refreshes its view of real infrastructure. If the state file says the resource should exist but the provider reports it's gone, Terraform reconciles this by proposing to create it again to match the desired configuration — this is the core function of state as the source of truth for existing/expected resources.
Which statement correctly describes the relationship between the required_providers block and a provider configuration block in Terraform?
required_providers (nested in the terraform block) declares which providers are needed by source address and version constraint, letting Terraform know what to download during init. Separately, one or more provider blocks configure how Terraform should actually talk to that provider's API (region, credentials, endpoints, aliases).
Ready for the real thing?
The full course: two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed explanations.
undefined $34.99 with code FREETEST33 — valid through Sep 23.
Get my $34.99 deal →