TF-Associate-004 - Core Terraform workflow (19% of the exam) - Section 3c
Validate a Terraform configuration.
terraform validate checks syntax and internal consistency (types, required arguments, references) without contacting a provider or reading state. Candidates should distinguish validate, which needs no credentials, from plan, which does.
terraform validatesyntax and consistency checkno provider access requiredvalidate versus plan
Practice question for this objective
lock_openFree sampleCore Terraform workfloweasy
A practitioner has cloned a repository onto a fresh laptop with no cloud credentials configured and no network access to the AWS APIs. Before wiring up any authentication, they want to confirm that the HCL is syntactically correct and internally consistent. Which command can they run successfully in this environment?
$ terraform init
$ # no AWS credentials set, no provider API reachable
Aterraform validate, because it checks syntax and internal consistency without contacting a provider or reading remote state.check_circle Correct
Bterraform plan, because planning is the only command that reports configuration errors before an apply.
Cterraform apply with the -refresh=false flag, because skipping refresh removes the need for credentials.
Dterraform providers, because it validates that every declared provider can reach its API endpoint.
terraform validate checks syntax and internal consistency locally, so it runs without provider credentials or network access. validate works entirely against the parsed configuration in the working directory, checking argument types, required arguments and references. It never authenticates to a provider or reads state, which is why it succeeds with no credentials.
Why A is correct: Correct: validate operates purely on the configuration in the directory, so it needs no credentials and no network access to the provider.
Why B is wrong: Tempting because plan does surface some errors, but plan refreshes real resources and so needs provider access and credentials, which are unavailable here.
Why C is wrong: Tempting because -refresh=false avoids a refresh, but apply still authenticates to the provider to create or read resources, so it fails without credentials.
Why D is wrong: Tempting because the name suggests provider checks, but this command only prints the provider requirements tree and does not validate configuration consistency.
Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.
It reports success, because validate only parses HCL grammar and does not resolve references between resources.
errorWhy it is wrong: Tempting because validate is often described as a syntax check, but it also verifies references, so an undeclared resource is caught rather than passed.
Because validate quietly falls back to cached credentials from a previous plan, while plan always requests fresh credentials from the user.
errorWhy it is wrong: This is tempting because caching sounds like a plausible optimisation, but validate does not use credentials at all, cached or otherwise, so there is nothing to fall back on.
That the configuration matches the real infrastructure by querying each provider and refreshing the current state before reporting.
errorWhy it is wrong: This is tempting because checking against reality sounds thorough, but refreshing and querying providers is the job of plan and refresh, not validate, which never contacts a provider or reads state.