Selecting an aliased provider in the wrong place
The wrong answers put the choice of an aliased aws configuration somewhere other than the provider meta-argument. They set region on the resource, add an alias argument to it, reach for depends_on, or wrap the reference in quotes. Region and alias belong in the provider block that defines the extra configuration. A resource opts in with provider = aws.sydney, a bare reference of provider type, a dot and the alias.
See it in a sample questionPassing an aliased provider into a module
The wrong answers pass an aliased provider into a module through something other than the providers map: an alias argument or the singular provider meta-argument on the module block, an export argument on the provider block, or a duplicate provider block inside the child. Default providers are inherited implicitly, but aliased configurations are not. A module block takes a providers map, such as providers = { google = google.europe }, which links the name the child uses to a specific configuration in the caller.
See it in a sample questionMisreading the pessimistic version constraint
The wrong answers treat ~> as an exact pin, as a plain minimum with no ceiling, or as a reason to take the newest release overall. The operator holds the left-hand segments fixed and lets the rightmost segment rise. With ~> 3.4 that permits 3.4.0 up to but not including 4.0.0, and Terraform selects the highest release inside that range, not the lowest.
See it in a sample questionGiving the dependency lock file another job
The wrong answers give the dependency lock file jobs that belong elsewhere: tracking real infrastructure, which is the state file; storing plugin binaries, which sit in the plugin cache; or holding version ranges, which required_providers declares. A related slip treats it as the state lock and reaches for terraform force-unlock. The lock file records the exact provider versions and hashes selected. terraform providers lock -platform appends checksums for another operating system without changing those versions, whereas init -upgrade can change them.
See it in a sample questionNaming the wrong baseline for a plan
The wrong answers compare the configuration against version control history, an apply log, a full scan of the account, the provider schema or cached plugins. None of these records what Terraform applied. A plan diffs the desired configuration against the resource attributes held in state from the last apply, and proposes create, update or destroy actions to close the gap.
See it in a sample question