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 Workflows118 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. Sign up free to practice all 799.

1. Question 1Develop and Troubleshoot Dynamic Configuration

   A variable block is defined as: 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? (Ephemeral resources and write-only arguments arrived after Terraform 1.6, the version this exam targets, so treat this as supplemental knowledge.)

   • 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

   A is correct: 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, which a standard data source cannot guarantee even when its output is marked sensitive = true, since sensitive only changes CLI display and the data source's result is still persisted to state regardless. A count = 0 conditional simply prevents a resource from being created at all and has nothing to do with credential handling, and a moved block is used to remap resource addresses during refactors, an entirely separate concern from credential persistence.

   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. This redaction is enforced consistently for every user regardless of organization role, and sensitive variables are absolutely allowed to be referenced inside configuration, that is their entire purpose for existing.

   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. It rules out silently overwriting the other operator's work (contrast B), rules out automatic merge logic, since Terraform simply blocks until a fresh plan is generated (contrast C), and confirms state is very much still consulted, not ignored, when applying a saved plan (contrast D).

   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. Converting a resource from count to for_each therefore does not automatically preserve the same instance addresses, since the address shapes differ entirely and require an explicit moved block or state mv to remap. A resource inside a module call always needs its leading module.<name> segment as part of the address, and state mv requires one concrete instance address, not a splat expression covering all instances.

   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

   A private module registry source is written as source = "app.terraform.io/example-corp/vpc/aws". What does the app.terraform.io segment represent?

   • AThe hostname of the registry serving the module, distinguishing this private or HCP Terraform registry lookup from the public oneCorrect
   • BThe name of the HCP Terraform organization that owns and publishes this particular module to its members
   • CAn alias for the aws provider that is expected to match a corresponding required_providers configuration_aliases entry
   • DA required literal string with no functional meaning at all to Terraform, included in the address purely for human readability
   ✓ Correct answer: A

   A is correct because when a module source string includes four segments instead of three, the leading segment (here app.terraform.io) is interpreted as the hostname of the registry Terraform should query, which is precisely what distinguishes this private (or HCP Terraform) registry lookup from the public registry's default three-segment NAMESPACE/NAME/PROVIDER form; example-corp/vpc/aws remains the namespace/name/provider portion following it. Contrast with B: the organization name that actually owns and publishes the module is the next segment, example-corp, not the hostname segment itself - conflating the two would misidentify which part of the address selects the registry versus the publishing organization.

   Why the other options are wrong

   • BThe organization name is the next segment, example-corp here, not the leading hostname segment that identifies the registry itself.
   • CProvider aliasing via configuration_aliases is unrelated to the registry source address; this segment identifies a registry host, not a provider alias.
   • DThis hostname segment is functionally significant to Terraform; it changes which registry endpoint gets queried, it is not merely decorative text.
8. Question 8Configure and Use Terraform Providers

   Given: ``` terraform { required_providers { awsgov = { source = "hashicorp/aws" version = "~> 5.0" } } } provider "awsgov" { region = "us-gov-west-1" } ``` What does using the local name awsgov (instead of aws) let you do in resource blocks?

   • ANothing changes; local names have no effect on configuration
   • BReference it via provider = awsgov; the plugin is still hashicorp/awsCorrect
   • CForce Terraform to download a different provider plugin entirely
   • DAutomatically alias every resource that mentions aws
   ✓ Correct answer: B

   The key used in required_providers, here awsgov, is only the local name - the identifier resources, data sources, and provider blocks use throughout that configuration to refer to this provider. It has no effect on which plugin actually gets installed; that is entirely determined by the source address (hashicorp/aws), so awsgov still resolves to and behaves exactly like the standard AWS provider, just referenced under a custom, more descriptive name useful here for signaling GovCloud usage. Resources reference it via provider = awsgov rather than provider = aws, and renaming it has no automatic effect on any other resource that still says aws elsewhere.

   Why the other options are wrong

   • AThe local name is precisely what every resource, data, and provider block in the configuration must reference, so changing it very much changes how the configuration is written.
   • CWhich plugin is downloaded is controlled by the source field, not by whatever local name is chosen for it.
   • DRenaming the local name has no automatic effect on unrelated resource or provider blocks elsewhere that still use the literal name aws.
9. Question 9Configure and Use Terraform Providers

   A colleague adds a new entry to required_providers for a provider that was never used before, pushes the change, but forgets to run terraform init or commit an updated lock file. What happens when a teammate pulls the change and runs terraform plan?

   • ANothing; Terraform assumes reasonable defaults for the missing provider
   • BTerraform reports it needs a provider not yet installed, and prompts initCorrect
   • Cterraform plan silently skips resources from the new provider
   • DThe plan succeeds but apply fails instead
   ✓ Correct answer: B

   B is correct: because the newly required provider was never installed locally by the teammate who pulled the change, and the lock file has no entry recording it, terraform plan cannot proceed and instead reports that the provider is required but not installed, directing the user to run terraform init first - well before reaching apply. There are no reasonable defaults Terraform can assume for an uninstalled provider (A); it must be explicitly resolved via init. Terraform does not silently omit resources tied to a provider it cannot find (C) - it errors out. And the failure surfaces at plan time already, so it never reaches a passing plan followed by a failing apply (D).

   Why the other options are wrong

   • AThere are no reasonable defaults Terraform can assume for an uninstalled provider; it must be explicitly resolved via init.
   • CTerraform does not silently omit resources tied to a provider it cannot find; it errors out instead.
   • DThe failure surfaces already at plan time, so it never reaches a passing plan followed by a failing apply.
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. terraform.tfvars files are routinely and directly read by CI pipelines during ordinary plan and apply operations, so the claim that CI never reads them is false, string values are an entirely normal, fully supported tfvars data type with no restriction against holding a key, and Terraform performs no automatic encryption of any value found in a tfvars file, reading everything there as plain text exactly as written.

    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