HashiCorp Terraform Authoring and Operations Advanced Practice Exam

What the HashiCorp Terraform Authoring and Operations Advanced exam covers

• Manage Resource Lifecycle152 questions
• Develop and Troubleshoot Dynamic Configuration182 questions
• Develop Collaborative Terraform Workflows117 questions
• Create, Maintain, and Use Terraform Modules118 questions
• Configure and Use Terraform Providers118 questions
• Collaborate on Infrastructure as Code Using HCP Terraform111 questions

Free HashiCorp Terraform Authoring and Operations Advanced practice test questions

A sample of 10 questions with answers and explanations. A free account includes a fixed set of 20 practice questions for this exam, retryable anytime. Paid access unlocks the full 798-question bank.

1. Question 1Develop and Troubleshoot Dynamic Configuration

   A variable block is defined as: ```hcl variable "environment" { type = string validation { condition = contains(["dev", "staging", "prod"], var.environment) error_message = "environment must be dev, staging, or prod." } } ``` A caller sets environment = "test". What happens?

   • ATerraform substitutes the closest valid value automatically
   • BTerraform halts before any resource is planned and shows the error_messageCorrect
   • CTerraform applies using the variable's default value instead
   • DTerraform proceeds and only logs a warning to the console
   ✓ Correct answer: B

   contains(["dev","staging","prod"], "test") evaluates to false, so this validation block's condition fails for the caller's input. Terraform evaluates variable validations during the earliest configuration-processing stage, before it walks the dependency graph and builds a plan for any resource, so the run aborts right there and prints the exact error_message text, "environment must be dev, staging, or prod." This differs from a plain type constraint, which only rejects wrong types, such as a number where a string is expected; a validation block lets you enforce an arbitrary business rule, like membership in an allowed-value set, with a message you control. No resource is touched and no state changes occur.

   Why the other options are wrong

   • AValidation can only accept or reject a supplied value based on its condition; it has no mechanism to substitute or auto-correct it to a nearby valid one.
   • CThere is no fallback to the variable's default once an explicit value has been supplied and that value fails its validation condition.
   • DA false validation condition is treated as a blocking error that halts the run, not merely something logged as a warning while the run continues.
2. Question 2Develop and Troubleshoot Dynamic Configuration

   Given var.numbers = [-2, 5, -8, 3], what does the following for expression evaluate to? [for n in var.numbers : n if n > 0]

   • A[5, 3]Correct
   • B[-2, 5, -8, 3]
   • C[-2, -8]
   • D2
   ✓ Correct answer: A

   A for expression with a trailing if n > 0 filters the source list before applying the result expression, keeping only elements where the condition holds true. Of [-2, 5, -8, 3], only 5 and 3 satisfy n > 0, so the result is [5, 3], preserving their original relative order from the source list - -2 and -8 are dropped entirely rather than transformed. This is the opposite of a filter that would keep only negative values, and the expression's output is the filtered list of qualifying numbers themselves, not a count of how many elements passed the condition.

   Why the other options are wrong

   • BThis ignores the if filter entirely and returns every original element, both positive and negative, unchanged.
   • CThis result keeps exactly the elements that fail the n > 0 condition, the negative numbers, which is the opposite of what the filter retains.
   • DThe expression returns the filtered list of qualifying numbers themselves; it does not return a numeric count of how many elements passed.
3. Question 3Develop and Troubleshoot Dynamic Configuration

   A team wants to pass a short-lived cloud credential into a provider block without it ever appearing in the Terraform state file. Which current Terraform feature is designed specifically for this?

   • AAn ephemeral resource or ephemeral valueCorrect
   • BA standard data source combined with sensitive = true on its output
   • CA count = 0 conditional resource block
   • DA moved block referencing the provider configuration
   ✓ Correct answer: A

   An ephemeral resource or ephemeral value is the feature purpose-built for passing a short-lived cloud credential into a provider block, or another ephemeral-aware context, without it ever being written into the Terraform state file. Terraform evaluates the ephemeral value during the run, uses it where an ephemeral-aware argument accepts it, and discards it when the run ends; because the value is never persisted, it cannot leak through the state backend or a later terraform show.

   Why the other options are wrong

   • Bsensitive = true only affects CLI display; it does not prevent a data source's result from being persisted to state.
   • Ccount = 0 simply results in zero instances of a resource; it does not address how a credential is persisted or handled.
   • Dmoved blocks remap resource addresses during refactoring and have no relationship to credential handling or state persistence.
4. Question 4Collaborate on Infrastructure as Code Using HCP Terraform

   A sensitive workspace variable is referenced in configuration as var.db_password. Can a user with workspace access run terraform console locally against remote state and print its plaintext value?

   • AYes, because terraform console always and completely bypasses sensitivity marking for every single variable without exception
   • BNo; a variable marked sensitive is treated as sensitive throughout Terraform, so console output redacts it, though the value is still used for provider operationsCorrect
   • CYes, but only for members of the organization's built-in Owners team, no one else
   • DNo, because sensitive variables can never be referenced anywhere at all inside a Terraform configuration file, under any circumstance whatsoever
   ✓ Correct answer: B

   A variable marked sensitive keeps that sensitivity classification everywhere Terraform evaluates it, including in a local terraform console session run against the workspace's remote state, so any expression that would print var.db_password has its output redacted rather than shown in plaintext. The value is still fully functional under the hood; it is genuinely passed to the provider to perform real authentication, sensitivity marking only affects what gets displayed in output, not whether the value is usable.

   Why the other options are wrong

   • ASensitivity marking is enforced consistently across Terraform's tooling; terraform console has no special bypass that reveals a sensitive value's plaintext.
   • CRedaction behavior in console output does not depend on the viewer's organization role; Owners see the same masked output as anyone else.
   • DSensitive variables can absolutely be referenced inside a Terraform configuration file, referencing them as inputs to resources and providers is their entire intended purpose.
5. Question 5Manage Resource Lifecycle

   Between `terraform plan -out=tfplan` and `terraform apply tfplan`, another operator applies an unrelated change that alters the state's serial number. What happens when the saved plan is applied?

   • AIt detects the state has changed since the plan was created and refuses to apply the stale plan.Correct
   • BTerraform applies the stale plan anyway, silently overwriting the other operator's changes.
   • CTerraform merges both sets of changes automatically before applying.
   • DTerraform ignores the state entirely when applying from a saved plan file.
   ✓ Correct answer: A

   A saved plan file records the specific state serial it was computed against, so when another operator's unrelated apply bumps that serial in between, Terraform detects the state has moved on and refuses to execute the now-stale plan, reporting an error instead of proceeding. This protects against exactly the concurrent-operator scenario in the stem.

   Why the other options are wrong

   • BTerraform explicitly checks the state's freshness before applying a saved plan and errors out rather than silently clobbering the other operator's newer changes.
   • CThere is no automatic merge logic for conflicting changes; a state mismatch simply blocks the apply until a fresh plan is generated.
   • DA saved plan file still records exactly which state serial it was computed against, so state is very much still consulted at apply time.
6. Question 6Manage Resource LifecycleSelect all that apply

   Which two statements correctly describe Terraform resource addressing? (Choose TWO)

   • Afor_each resource instances are addressed with a quoted string key inside square bracketsCorrect
   • Bcount resource instances are addressed with a zero-based integer index inside square bracketsCorrect
   • CConverting a resource from count to for_each automatically preserves the same instance addresses
   • DA resource inside a module call can be addressed while omitting the leading module.<name> segment
   • ESplat expressions like aws_instance.web[*].id can be used directly as a terraform state mv target address
   ✓ Correct answer: A, B

   for_each instances are addressed by their exact map key as a quoted string inside square brackets (e.g. ["primary"]), while count instances are addressed by a zero-based integer index inside square brackets (e.g. [0]); these are the two distinct multi-instance addressing schemes Terraform uses, and they are not interchangeable. Because the address shapes differ entirely, changing a resource from one scheme to the other requires an explicit moved block or terraform state mv to remap every instance.

   Why the other options are wrong

   • Ccount and for_each use fundamentally different addressing schemes, so converting between them changes every instance's address and requires an explicit remap, not automatic preservation.
   • DThe module.<name> prefix is a required part of any address for a resource declared inside a module call; it cannot be omitted.
   • Estate mv requires a single concrete resource instance address as its target; a splat expression referring to every instance at once is not valid there.
7. Question 7Create, Maintain, and Use Terraform Modules

   How does the public Terraform Registry determine which module versions are available for a given published module?

   • AIt reads semantic-versioned Git tags (for example v1.0.0, v1.1.0) from the linked source repositoryCorrect
   • BIt reads a manually maintained versions.json file the author must upload separately to the registry
   • CIt increments a version counter automatically every time terraform init is run against the module
   • DIt derives a version number from the total commit count on the default branch
   ✓ Correct answer: A

   The public Terraform Registry integrates directly with a module's linked VCS repository and discovers a new listed version whenever a properly formatted semantic version tag, such as v1.0.0 or v1.1.0, is pushed to that repository; there is no separate manual step, upload, or counter involved in populating the version list the registry shows consumers. Running terraform init against a module has no effect whatsoever on the registry's published version listing - init only downloads whichever already-published version a module block's version constraint selects, it never writes back to or updates the registry itself.

   Why the other options are wrong

   • BThere is no separate versions.json file authors upload; Git tags in the linked repository are the sole source of truth.
   • CRunning terraform init against a module has no effect on the registry's published version listing; init only consumes already-published versions.
   • DCommit count on the default branch plays no role in deriving version numbers; only explicit semver tags do.
8. Question 8Configure and Use Terraform ProvidersSelect all that apply

   Which TWO statements about provider `alias` configurations are correct? (Choose TWO)

   • AAn aliased configuration that no resource, data source, or module ever references is still valid; Terraform does not require every alias to be usedCorrect
   • BA resource selects an aliased configuration through the provider meta-argument, written as the provider local name followed by its aliasCorrect
   • CA child module automatically inherits its parent's aliased configurations, so it can reference aws.west without being handed a providers map
   • DThe provider meta-argument accepts an expression, so a resource can choose its aliased configuration from an input variable
   • EDeclaring configuration_aliases in required_providers lets a module build the aliased configuration itself when its caller omits one
   ✓ Correct answer: A, B

   Terraform never enforces that a declared alias must actually be referenced by some resource, data source, or module - an unused aliased configuration is perfectly valid, it simply sits unused. The standard way any resource or data source opts into a non-default configuration is the provider meta-argument written as local_name.alias, for example provider = aws.west.

   Why the other options are wrong

   • COnly default provider configurations are inherited implicitly; additional configurations with alias set are never inherited automatically by child modules, so aws.west has to be handed over explicitly through the module block's providers map.
   • DThe provider meta-argument must be a static <local_name>.<alias> reference rather than an expression: Terraform resolves which provider configuration a resource uses while building the dependency graph, before variables can be evaluated, so an input variable cannot select an alias.
   • Econfiguration_aliases only declares that the module expects to receive an additional configuration; it creates nothing. The calling module must still pass a matching entry in its providers map, and omitting it produces an error rather than a self-built aliased configuration.
9. Question 9Configure and Use Terraform Providers

   What is the difference between the errors "Unsupported argument" and "Missing required argument" when they reference a resource's configuration?

   • AThey are the same error with different wording
   • BUnsupported means an unknown argument; Missing means a required one was left outCorrect
   • CUnsupported argument only occurs in modules; Missing required argument only occurs in the root
   • DBoth only occur during terraform destroy
   ✓ Correct answer: B

   "Unsupported argument" fires when the HCL sets an argument that the provider's current schema simply does not define - often because a version upgrade renamed or removed it - while "Missing required argument" fires when a mandatory field the schema demands was never provided at all; they describe opposite, distinct situations (present-but-unknown versus absent-but-required). They are not the same error with different wording. Neither error is scoped exclusively to modules or the root configuration - both can occur in either. And both are schema validation errors surfaced at plan or validate time, not specifically tied to destroy.

   Why the other options are wrong

   • AThese describe opposite situations, present-but-unknown versus absent-but-required, so they are meaningfully distinct error classes.
   • CBoth errors can occur in either root module or child module configuration; neither is scoped exclusively to one.
   • DBoth are schema validation errors surfaced at plan or validate time, not specifically tied to terraform destroy.
10. Question 10Develop Collaborative Terraform Workflows

    A pipeline's committed terraform.tfvars file currently contains a cloud provider access key in plain text. What is the primary automation risk this creates?

    • ANone; tfvars files are never read by CI systems
    • BAnyone with read access to the repository or its history can retrieve itCorrect
    • CTerraform refuses to plan because tfvars files cannot hold string values
    • DThe credential is automatically encrypted by Terraform at parse time
    ✓ Correct answer: B

    Version control systems retain every prior revision of a file, so even removing the credential from terraform.tfvars in a later commit does not erase it from repository history, meaning anyone who has been granted read access, whether a current teammate, a contractor whose access outlived their engagement, or an attacker who compromised any account with clone rights, can still retrieve the plaintext key by inspecting that history.

    Why the other options are wrong

    • Aterraform.tfvars files are routinely and directly read by CI pipelines during ordinary plan and apply operations; this is not something CI systems skip.
    • CString values, including something formatted like an access key, are a completely normal and fully supported tfvars data type with no such restriction.
    • DTerraform performs no automatic encryption on values found in a tfvars file; every value there is read and handled as plain text exactly as written.

Who this HashiCorp Terraform Authoring and Operations Advanced practice exam is for

This practice set is for anyone preparing for the HashiCorp Terraform Authoring and Operations Advanced exam at the advanced level - from first-time candidates building a foundation to experienced HashiCorp practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this HashiCorp Terraform Authoring and Operations Advanced practice exam

1. Start with the free sample questions above to gauge your current baseline.
2. Read the full explanation on every question, including why each wrong option is wrong.
3. Track your weak domains and focus your study where you are losing the most marks.
4. Once you are scoring consistently well, take a timed, full-length mock exam.
5. Treat your readiness score as knowledge readiness, then validate it with hands-on practice in a real environment before booking the HashiCorp Terraform Authoring and Operations Advanced exam.

Related HashiCorp resources

• HashiCorp Terraform Authoring and Operations Advanced study guideKey concepts
• HashiCorp practice examsAll HashiCorp
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• How these questions are written and reviewedMethodology
• Report a problem with a questionCorrections
• HashiCorp Vault Associate (003) practice examRelated
• HashiCorp Vault Operations Advanced practice examRelated
• HashiCorp Terraform Associate (004) practice examRelated

HashiCorp Terraform Authoring and Operations Advanced practice exam FAQ