HashiCorp Terraform Authoring and Operations Professional Practice Exam

What the HashiCorp Terraform Authoring and Operations Professional exam covers

• Manage Resource Lifecycle143 questions
• Develop and Troubleshoot Dynamic Configuration167 questions
• Develop Collaborative Terraform Workflows114 questions
• Create, Maintain, and Use Terraform Modules114 questions
• Configure and Use Terraform Providers114 questions
• Collaborate on Infrastructure as Code Using HCP Terraform107 questions

Free HashiCorp Terraform Authoring and Operations Professional sample questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 759.

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

   A failed validation condition is a hard error, not a warning. Terraform evaluates variable validations before building the plan, so the run stops immediately and prints the configured error_message rather than continuing with an invalid value.

   Why the other options are wrong

   • AValidation only accepts or rejects a value; it never substitutes or corrects it.
   • CThere is no fallback to a default once an explicit value is supplied and fails validation.
   • DA false condition is an error that halts the run, not merely a logged warning.
2. Question 2Develop and Troubleshoot Dynamic Configuration

   A local value builds a multi-line string using a heredoc: locals { script = <<-EOT echo hello echo world EOT } What is the effect of the hyphen before EOT in <<-EOT?

   • AIt allows the closing marker to be indented and strips that leading whitespace from each lineCorrect
   • BIt escapes the entire heredoc so no interpolation occurs inside it
   • CIt converts the heredoc contents into a list of lines
   • DIt trims trailing newlines from the final rendered string
   ✓ Correct answer: A

   The <<- variant of heredoc syntax lets the closing delimiter be indented to match the surrounding code's indentation for readability, and Terraform removes that common leading whitespace from every line in the heredoc's content when computing the final string value.

   Why the other options are wrong

   • BInterpolation still works normally inside a <<- heredoc; the hyphen only affects whitespace handling of indentation.
   • CA heredoc always produces a single string value, never a list, regardless of the hyphen variant used.
   • DThe hyphen controls leading indentation stripping per line, not trimming of trailing newlines at the end.
3. Question 3Develop and Troubleshoot Dynamic Configuration

   A variable db_config is type object({ host = string, password = string }) and the whole variable is marked sensitive = true. What is the granularity of that sensitivity marking?

   • AThe entire object value is sensitive as a whole; Terraform has no per-attribute sensitivity markingCorrect
   • BOnly the password attribute is treated as sensitive, while host still displays normally
   • CSensitivity supposedly applies only to the variable's name in logs, not the actual value
   • Dsensitive = true on an object-typed variable is supposedly invalid, unsupported syntax
   ✓ Correct answer: A

   Marking a variable sensitive applies to its entire value as a unit; there is no built-in mechanism to mark just one nested attribute of an object as sensitive while leaving sibling attributes unmarked at the variable-block level.

   Why the other options are wrong

   • BBoth host and password are treated as sensitive together, since sensitivity applies to the whole object.
   • CThe actual value is redacted from display, not just the variable's name.
   • Dsensitive = true is valid on variables of any type, including object.
4. Question 4Collaborate on Infrastructure as Code Using HCP Terraform

   A workspace variable named subnet_ids needs to hold a Terraform list value like ["subnet-a", "subnet-b"] rather than a plain string. What must be done when creating that variable in the UI?

   • ANothing extra is needed at all; every workspace variable is automatically parsed as HCL by default
   • BThe HCL toggle must be enabled for that variable so its value is parsed as a Terraform expression instead of a literal stringCorrect
   • CThe variable must instead be manually added twice over as two separate variables, once separately for each individual list element value
   • DThe variable's category must instead be set to env, since only env category supports list values
   ✓ Correct answer: B

   By default, a variable's value is treated as a plain string; enabling the HCL option tells HCP Terraform to parse it as a Terraform expression so it can hold a list, map, or other structured value.

   Why the other options are wrong

   • ABy default, values are treated as plain strings unless HCL parsing is explicitly enabled.
   • CA single variable can hold an entire list value without duplicating the variable.
   • DThe env category exports variables as raw shell strings, it does not support structured HCL values.
5. Question 5Manage Resource Lifecycle

   In an HCP Terraform VCS-driven workspace, what is a "speculative plan" triggered by a pull request?

   • AA plan run that shows proposed changes for review but cannot be applied, since it is not associated with a mergeable run.Correct
   • BA plan that is automatically applied to real infrastructure the moment the pull request is opened.
   • CA plan that only refreshes state and never evaluates any configuration changes at all.
   • DA locally-run plan that never reaches HCP Terraform's UI or workspace run history.
   ✓ Correct answer: A

   Speculative plans give reviewers visibility into what a proposed configuration change would do before it merges, running remotely and posting results to the pull request, without producing a run that can be applied.

   Why the other options are wrong

   • BSpeculative plans are explicitly not applyable; auto-apply behavior is a separate, distinct workspace setting for merged runs.
   • CA speculative plan still evaluates full configuration changes, not just a refresh-only comparison.
   • DSpeculative plans run remotely in HCP Terraform and their output is shown directly in the pull request and UI.
6. Question 6Manage Resource Lifecycle

   A security group rule was added manually in the cloud console. The team wants state to reflect this new reality without reverting the manual change on the next apply, and without yet editing the .tf configuration. What should they run?

   • Aterraform apply -refresh-only, then accept the updateCorrect
   • Bterraform apply
   • Cterraform destroy -target on the security group
   • Dterraform taint aws_security_group.app
   ✓ Correct answer: A

   This targeted workflow updates the recorded state to match reality, leaving both the manual change and the rest of the infrastructure untouched, without yet requiring any configuration edits.

   Why the other options are wrong

   • Ba default apply would refresh, then plan and execute changes to reconcile back toward the unchanged configuration, likely reverting the manual rule.
   • Cdestroying the resource is the opposite of preserving the manually added rule.
   • Dtainting only forces recreation on the next apply; it does not reconcile drifted attribute values into state.
7. Question 7Create, Maintain, and Use Terraform Modules

   A child module declares output "vpc_id" { value = aws_vpc.this.id }. How does the calling (root) configuration reference this value elsewhere?

   • Amodule.network.vpc_idCorrect
   • Boutput.network.vpc_id
   • Cvar.network.vpc_id
   • Dnetwork.outputs.vpc_id
   ✓ Correct answer: A

   The expression module.network.vpc_id reaches into the module block named "network" and reads its declared output vpc_id. This is the standard, and only, way a parent configuration accesses a value exposed by a child module.

   Why the other options are wrong

   • Boutput.<name> is how you might loosely describe an output conceptually, but it is not valid reference syntax; module.<name>.<output> is.
   • Cvar.<name> refers to the calling module's own input variables, not a called module's outputs.
   • DThere is no <name>.outputs.<output> syntax in Terraform's expression language.
8. Question 8Configure and Use Terraform Providers

   A `required_providers` entry uses the source address `hashicorp/aws`, omitting the leading hostname segment. Which registry does Terraform resolve this address against?

   • Aapp.terraform.io
   • Bregistry.terraform.ioCorrect
   • Creleases.hashicorp.com
   • Dgithub.com/hashicorp
   ✓ Correct answer: B

   A fully-qualified provider source address is hostname/namespace/type. When the hostname is omitted, Terraform assumes the public registry at registry.terraform.io. This is why most required_providers entries only show a two-part address like hashicorp/aws.

   Why the other options are wrong

   • Aapp.terraform.io is the HCP Terraform web application, not the provider registry endpoint used for source resolution.
   • Creleases.hashicorp.com serves Terraform CLI binaries and some product downloads, not provider packages.
   • Dgithub.com/hashicorp hosts provider source code but is never consulted directly by init's provider installer.
9. Question 9Configure and Use Terraform Providers

   What is the key security tradeoff between static, long-lived provider credentials and dynamic (OIDC-based) short-lived credentials?

   • AThere is no difference in risk between the two
   • BStatic credentials stay valid if leaked; dynamic ones expire fastCorrect
   • CDynamic credentials are always slower to provision infrastructure
   • DStatic credentials cannot be used with any provider
   ✓ Correct answer: B

   A leaked static key stays usable until someone notices and rotates it, whereas a dynamic, run-scoped credential naturally expires and is limited to what that single run needed, which meaningfully reduces the impact of a leak.

   Why the other options are wrong

   • AThe exposure duration and scope genuinely differ between the two approaches, which is the whole reason dynamic credentials exist.
   • CProvisioning speed is unaffected by which credential mechanism is used, only how the credential was obtained.
   • DStatic credentials remain fully supported by virtually every provider; the concern is about security posture, not compatibility.
10. Question 10Develop Collaborative Terraform Workflows

    To read outputs from another configuration's state using the terraform_remote_state data source, what must the consuming configuration have?

    • AOnly the workspace name of the source configuration
    • BRead and write credentials for the exact backend and state location the source configuration usesCorrect
    • CA shared required_providers block identical to the source configuration's
    • DA local copy of the source configuration's .terraform.lock.hcl file
    ✓ Correct answer: B

    Because the data source fetches the raw state object (for example, from the same S3 bucket/key or HCP Terraform workspace) rather than calling an API scoped to just outputs, the consumer needs credentials and permission to read from that exact backend location.

    Why the other options are wrong

    • AA workspace name alone is not sufficient; the consumer needs the actual backend connection details and access.
    • Crequired_providers concerns provider plugin versions and has no bearing on remote state access.
    • DThe lock file tracks provider versions for the source configuration's own init; it is irrelevant to reading its state remotely.

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

This practice set is for anyone preparing for the HashiCorp Terraform Authoring and Operations Professional 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 Professional 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. Use your readiness score to decide when you are ready to book the real HashiCorp Terraform Authoring and Operations Professional exam.

Related HashiCorp resources

• HashiCorp Terraform Authoring and Operations Professional study guideKey concepts
• HashiCorp practice examsAll HashiCorp
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• HashiCorp Terraform Associate (004) practice examRelated
• HashiCorp Vault Operations Professional practice examRelated
• HashiCorp Vault Associate (003) practice examRelated

HashiCorp Terraform Authoring and Operations Professional practice exam FAQ