Free Terraform Authoring & Operations Advanced practice test: 30 questions with answers

A saved plan file records the exact changes that were reviewed, so applying it runs those changes without a new plan. Option A describes an apply with no saved plan, option C describes an import, and option D describes plan output rather than an apply.

terraform destroy is a shortcut for terraform apply -destroy, which removes all managed resources after confirmation. The plan variant only previews the removal, refresh-only changes state without destroying anything, and state rm forgets resources without deleting them.

terraform state rm only edits the state file, so the real bucket keeps running while Terraform no longer tracks it. Deleting, renaming, or exporting the bucket would require an apply or a separate action, and none of those happen during a state removal.

terraform init installs providers and modules and sets up the configured backend, and it is safe to run again. It does not create or refresh infrastructure, which happens during plan and apply.

The -refresh-only mode reads real infrastructure and writes the result to state, with no configuration-driven changes to resources. The replace option would recreate the group, state rm forgets it, and importing a resource that Terraform already manages fails.

try evaluates its arguments in order and returns the first one that succeeds, which makes it useful for fallback values. The can function is the one that returns a boolean for validity, while the other options describe behaviour that try does not have.

Values passed with -var or -var-file on the command line have the highest precedence, above tfvars files, and environment variables have the lowest. The file, environment, and error options each misstate that order or wrongly treat the duplicate definitions as a failure.

The sensitive flag only redacts the value in plan and apply output and does not encrypt state, so the state must still be protected. Sensitive outputs can still be passed to other modules, and the value still reaches the provider when it is needed.

A data block reads existing objects during planning without creating or managing them. A resource block with the same type would try to manage a VPC, and module or output blocks cannot look up objects that belong to another state.

A validation block in a variable evaluates a condition on the input and fails with the custom error message when the condition is false. The type argument checks only the data type, sensitive hides values, and provider blocks do not support precondition blocks.

The dependency lock file records the provider versions and checksums chosen during init, so committing it keeps installs reproducible. Ignoring it, deleting it before each run, or keeping it only in a backend would remove that consistency, and the file holds no secrets from state.

The pessimistic operator lets only the last listed number increase, so ~> 5.2.0 allows 5.2.x and nothing from 5.3.0 upward. The other options allow major-version jumps, a single exact version, or unlimited minor upgrades, which the operator prevents.

terraform_remote_state reads the outputs of another configuration's state from its backend, so Team B can use exported values without duplicating code or resources. A resource block would create a second VPC, a module block would copy code, and a moved block only relocates addresses within one state.

The -input=false flag stops Terraform from prompting for missing values, and applying a saved plan runs the exact reviewed changes without an interactive confirmation. Upgrading providers, deleting the backend, or using console does not address the prompt, and deleting the backend would break state storage.

State locking prevents concurrent operations from corrupting state, and force-unlock is a recovery command that is risky while another run is active. Auto-approve does not disable locking, and the lock file records provider checksums rather than lock records.

Git module sources use the ref query parameter to select a tag or commit, and the double slash selects a subdirectory of the repository. The version argument works only for registry modules, a local path cannot carry a Git ref, and tag is not a recognised source parameter.

Module outputs are accessed through the module address, and module inputs are supplied as arguments in the module block. Child modules do not inherit parent variables or resources, so any value they need must be passed in explicitly.

A moved block tells Terraform that an existing object now has a new address, so the plan shows a move instead of a destroy and create. The other options either destroy the instance or leave Terraform creating a second one.

The providers argument in a module block maps the module's provider names to configurations defined by the caller, which keeps provider blocks in the root. Declaring providers inside reusable modules or hardcoding credentials makes the module harder to reuse and is discouraged.

The pessimistic operator in a module's version argument allows 5.x releases at or above 5.0 and blocks 6.0. An exact pin, an open-ended constraint, or a constraint placed in required_providers does not give that behaviour, since required_providers applies to providers.

The provider meta-argument picks which provider configuration a resource uses, and aliases are declared in provider blocks rather than resource blocks. A terraform block does not select providers per resource, and depends_on controls ordering rather than provider choice.

required_providers inside the terraform block declares each provider's source and version constraint, and init enforces it. Resource blocks have no version argument, the lock file records selected versions rather than constraints, and no such environment variable exists.

Providers are separate plugin programs that Terraform starts and talks to over RPC, which is why init has to download them. The other options wrongly place API calls in core, bundle the provider into the binary, or merge separate state files.

TF_LOG controls log verbosity for Terraform core and provider plugins, and TF_LOG_PATH writes that output to a file. Provider blocks have no debug argument, and validate does not call provider APIs, so it cannot print their responses.

Dynamic or externally managed credentials keep secrets out of code and out of version control, which is the recommended approach. Committing keys to provider blocks or to a committed tfvars file exposes them to everyone with repository access.

Speculative plans run from pull requests in VCS-connected workspaces and show proposed changes, but they are never applied, even if auto-apply is enabled. The other options describe applying, locking, or creating workspaces, which speculative plans do not do.

The Plan workspace permission lets a user queue plan runs and see their results while blocking apply. Write adds applying runs, Read is limited to viewing, and Admin covers workspace settings and deletion.

Hard-mandatory policies stop the run before apply when they fail, and no one can override them, while soft-mandatory policies can be overridden by authorized users. Policy checks run between plan and apply, so the option that places them after apply is wrong.

Variable sets let an organization define values such as provider credentials once and apply them to several workspaces. Copying values per workspace, creating extra organizations, or sharing a state file do not provide that central management.

Local execution runs plans and applies on the team's own machines while the workspace still stores and locks state in HCP Terraform. Remote execution moves the runs into HCP Terraform, speculative plans are a plan-only trigger, and the last option describes state copying that HCP Terraform does not do after each apply.