Terraform Associate Understand Terraform's Purpose (vs Other IaC): 40 practice questions

12 of the 40 Understand Terraform's Purpose (vs Other IaC) questions in the Certsqill Terraform Associate bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for Terraform Associate? Take the free 5-min readiness check →

1. To map Terraform configuration to real-world: What is the PRIMARY purpose of Terraform state (terraform.tfstat

1. To define the exact execution order in which Terraform creates each resource during an apply operation run

   Incorrect. Execution order is derived from the dependency graph built out of resource references, not from the state file, which only records existing infrastructure mappings.
2. To store Terraform provider credentials securely inside an encrypted section of the local working directory

   Incorrect. Credentials are supplied via environment variables, provider configuration, or secrets managers — the state file has no encrypted credential store and is not designed to hold them.
3. To cache the downloaded Terraform provider binaries so that they remain available for later offline apply runs

   Incorrect. Provider binaries are cached in the .terraform/ directory by terraform init — the state file instead tracks the mapping of configuration to real infrastructure.
4. To map Terraform configuration to real-world infrastructure so Terraform can determine what changes to make ✓

   Correct. State maps resource definitions in .tf files to actual cloud resource IDs. Without state, Terraform cannot determine what already exists and would try to create everything from scratch.

Terraform state maps .tf config to real resource IDs, enabling Terraform to compute the diff between desired and actual state during plan.

2. Terraform uses provider plugins that enable interaction: How does Terraform support this?

1. Terraform uses provider plugins that enable interaction with multiple APIs simultaneously within a single configuration ✓

   Correct. Terraform's plugin-based architecture supports multiple providers in one configuration — AWS, Azure, and GitHub providers can all be configured in the same Terraform project.
2. Terraform requires a separate federated cloud account that coordinates all provisioning across two or more providers

   Incorrect. Terraform orchestrates multi-provider provisioning locally or via Terraform Cloud — no additional federated account is required to span AWS, Azure, and GitHub.
3. Terraform can configure only a single provider per workspace, so each cloud vendor needs its own isolated workspace

   Incorrect. Multiple providers can be configured within one workspace — this multi-provider capability in a single configuration is a core Terraform strength.
4. Terraform supports only HashiCorp-owned providers, so any third-party clouds such as GitHub must each be managed outside of it

   Incorrect. The Terraform Registry hosts providers from HashiCorp, major cloud vendors (AWS, Azure, GCP), and thousands of third-party contributors including GitHub.

Terraform's provider plugin architecture allows multiple providers (AWS, Azure, GitHub) in a single configuration, enabling true multi-cloud and multi-service IaC.

3. State files may contain sensitive values like database: What is the PRIMARY security risk with this approach?

1. Multiple team members cannot commit to the same state file simultaneously without a merge conflict

   Incorrect. While concurrent state modifications matter (state locking), the PRIMARY security risk of public GitHub storage is plaintext secret exposure — a far more critical concern.
2. Public GitHub repositories cannot store any JSON file that exceeds one megabyte in size

   Incorrect. GitHub's file size limits are much larger than typical state files, and this is a storage constraint, not the security exposure the question asks about.
3. GitHub automatically deletes any terraform.tfstate file it finds for security reasons

   Incorrect. GitHub does not scan for or delete Terraform state files — the sensitive data stays exposed until it is manually removed.
4. State files may contain sensitive values like database passwords and API keys in plaintext ✓

   Correct. Terraform state stores all resource attributes in JSON, including sensitive values like database passwords, private keys, and tokens — exposing them publicly in GitHub is a critical security violation.

Terraform state files contain sensitive values (passwords, keys) in plaintext JSON — storing them publicly exposes credentials to anyone with access.

4. Terraform tracks the current state of infrastructure: How does Terraform's approach to infrastructure manageme

1. Terraform tracks the current state of infrastructure and only makes changes needed to reach the desired state, while scripts execute all commands regardless of current state ✓

   Correct. Terraform's state enables idempotent operations — it knows what exists and only makes necessary changes. Scripts re-execute all steps, potentially failing or causing unintended changes if run again.
2. Terraform runs faster because it uses precompiled binary code instead of the interpreted shell that scripts rely on, so even very large deployments finish in noticeably less time

   Incorrect. Raw speed is not the key architectural distinction — the state-based idempotency model is what fundamentally differentiates Terraform from stateless scripts.
3. Terraform can only run on Linux hosts, whereas bash scripts that call the AWS CLI are able to run on every major operating system without any modification at all

   Incorrect. Terraform runs on Linux, macOS, and Windows, so the claim that it is Linux-only is factually wrong and is not the real distinction.
4. Terraform always requires an active internet connection, while bash scripts that call the AWS CLI are specifically designed to run fully offline against local resources

   Incorrect. Both Terraform and AWS CLI scripts need internet connectivity to reach cloud APIs, so offline capability is not a meaningful difference between them.

Terraform tracks state and applies only the delta to reach desired state (idempotent). Scripts re-execute all commands regardless of current infrastructure state.

5. HCP Terraform: Which HashiCorp product solves state management, provides remote execution, and adds policy enf

1. terraform remote-exec provisioner

   Incorrect. The remote-exec provisioner runs scripts on a provisioned resource after creation — it is not a collaboration platform for team state management.
2. HCP Terraform (Terraform Cloud) ✓

   Correct. Terraform Cloud (now HCP Terraform) provides remote state with automatic locking, remote plan/apply execution, Sentinel policy enforcement, and team collaboration features.
3. Terraform Enterprise

   Incorrect. Terraform Enterprise is the self-hosted version of Terraform Cloud with the same capabilities but deployed on-premises. For most cloud teams, Terraform Cloud (SaaS) is the answer.
4. terraform workspace

   Incorrect. Terraform workspaces separate state files within a single backend — they do not provide remote execution, collaboration features, or policy enforcement.

HCP Terraform (Terraform Cloud) provides remote state with automatic locking, remote execution, Sentinel policy, and team collaboration in a SaaS platform.

6. The Terraform Registry at registry.terraform.io: Where does Terraform look by default when a `required_provide

1. GitHub's official Terraform repository

   Incorrect. Terraform Registry (registry.terraform.io) is separate from GitHub, even though provider source code may be on GitHub.
2. The HashiCorp corporate package server at packages.hashicorp.com

   Incorrect. HashiCorp's package server distributes Terraform binaries — providers are distributed via the Terraform Registry at registry.terraform.io.
3. The Terraform Registry at registry.terraform.io ✓

   Correct. By default, Terraform resolves provider addresses using registry.terraform.io as the default hostname. `hashicorp/aws` resolves to registry.terraform.io/hashicorp/aws.
4. The local filesystem's .terraform/ directory

   Incorrect. .terraform/ is where providers are cached after download — Terraform looks to the Registry first unless a local mirror or filesystem_mirror is configured.

The default provider source is registry.terraform.io — `hashicorp/aws` resolves to registry.terraform.io/hashicorp/aws automatically.

7. Deploying application code to a web server after: Which of the following tasks is OUTSIDE the typical scope of

1. Deploying application code to a web server after the server is provisioned ✓

   Correct. Deploying application code is a CI/CD concern (GitHub Actions, Jenkins, CodeDeploy) — not infrastructure provisioning. While Terraform has provisioners for this, they are a last resort and not recommended.
2. Creating a VPC that has both public and private subnets inside an AWS account

   Incorrect. Provisioning VPCs and subnets is core Terraform functionality — this is exactly the kind of network infrastructure Terraform is designed to create.
3. Configuring an S3 bucket with object versioning and lifecycle expiration rules

   Incorrect. S3 bucket configuration including versioning and lifecycle rules is fully managed through the AWS provider in Terraform.
4. Creating and managing DNS record sets inside an AWS Route 53 hosted zone

   Incorrect. Route 53 hosted zones and record sets are fully supported by the AWS Terraform provider, so DNS management is a valid Terraform use case.

Terraform provisions and configures infrastructure; application code deployment is a CI/CD concern handled by tools like GitHub Actions, not Terraform provisioners.

8. Terraform destroys the EC2 instance because it no longer: What happens when they run `terraform apply`?

1. Terraform keeps the EC2 instance running but removes it from the state file without destroying it

   Incorrect. terraform apply destroys resources whose config has been removed. `terraform state rm` is the command to remove a resource from state WITHOUT destroying it.
2. Terraform destroys the EC2 instance because it no longer exists in the desired state ✓

   Correct. When a resource is removed from configuration, Terraform's state still tracks it as existing. On apply, Terraform destroys it to reconcile real infrastructure with the desired (empty) config.
3. Terraform ignores the missing resource block and leaves the EC2 instance running

   Incorrect. Terraform does not ignore resources that disappear from config — if state has it and config doesn't, it's marked for destruction.
4. Terraform produces an error because resources cannot be removed from configuration

   Incorrect. Removing a resource block is a valid operation. Terraform handles it gracefully by planning destruction.

Removing a resource block from config marks it for destruction in the next apply — Terraform destroys it to match the desired state.

9. Terraform Open Source: Which Terraform edition is appropriate?

1. HCP Terraform (Terraform Cloud) Business tier

   Incorrect. HCP Terraform Business tier is a paid SaaS product. The startup wants free, local usage — Terraform OSS with S3 backend meets their needs without cost.
2. Terraform Enterprise

   Incorrect. Terraform Enterprise requires self-hosting servers and a commercial license — not suitable for a startup wanting free local usage.
3. Terraform Open Source (Community Edition) ✓

   Correct. Terraform OSS is free to use, runs locally, and supports all standard backends including S3 for remote state storage — no license or server required.
4. Terraform CDK

   Incorrect. Terraform CDK (CDKTF) is a framework for writing Terraform in programming languages (Python, TypeScript) — it's not a different edition of Terraform.

Terraform Open Source is free, runs locally on any OS, and supports remote backends like S3 — no license or infrastructure required.

10. Updates the Terraform state file to reflect the current: What does `terraform refresh` (or the refresh that oc

1. Downloads the newest provider plugins from the Terraform Registry and installs them into the working directory

   Incorrect. Provider plugin downloads and installation are handled by terraform init, not by the refresh performed during terraform plan.
2. Applies all pending configuration changes to the real infrastructure so it matches the desired state

   Incorrect. Applying pending changes is terraform apply — refresh only reads current infrastructure to update state and makes no changes itself.
3. Removes every resource from the state file and forces a full recreation of them on the next apply

   Incorrect. Refresh syncs state with real infrastructure — it never empties the state file or marks resources for recreation.
4. Updates the Terraform state file to reflect the current real-world infrastructure by querying provider APIs ✓

   Correct. terraform refresh queries provider APIs to get the current state of managed resources and updates the state file to match real-world infrastructure — without making any changes.

terraform refresh queries provider APIs to update the state file with real infrastructure's current attributes — no infrastructure changes are made.

11. VPC first, then subnet, then EC2 instance — Terraform: When terraform apply runs, in what order does Terraform

1. Terraform creates all three resources simultaneously in parallel, trusting the cloud APIs to resolve any ordering among the VPC, subnet, and instance

   Incorrect. Terraform does not rely on cloud APIs to order dependencies. It creates resources in dependency order; only resources with no dependencies between them run in parallel, while dependent resources wait.
2. EC2 instance first because it is the most complex resource, then the subnet, and finally the VPC that the others depend upon

   Incorrect. Terraform has no notion of resource complexity for ordering. It strictly follows the dependency graph, so resources that depend on others are created after their dependencies.
3. Terraform creates the resources strictly in the order their blocks appear in the .tf files, from the first block to the last

   Incorrect. Terraform does not use file order for execution. HCL is declarative, so block order is irrelevant; execution order is derived from the dependency graph.
4. VPC first, then subnet, then EC2 instance — Terraform builds a dependency graph from resource references and creates resources in topological order ✓

   Correct. Terraform analyzes attribute references to build a directed acyclic graph: subnet's vpc_id = aws_vpc.main.id and EC2's subnet_id = aws_subnet.main.id create edges. Terraform walks the graph in topological order: VPC then subnet then EC2.

Terraform builds a dependency graph from resource attribute references and creates resources in topological order — VPC before subnet before EC2 — not by file order or complexity.

12. Plan → Cost Estimation → Sentinel Policy Check → Apply: After a VCS commit triggers a new run, in what order d

1. Plan → Cost Estimation → Sentinel Policy Check → Apply (requires approval or auto-apply) ✓

   Correct. A Terraform Cloud run executes in this order: Plan generates the execution plan, Cost Estimation calculates projected cost changes, Sentinel Policy Check evaluates mandatory policies against the plan, and Apply provisions infrastructure gated by manual approval or auto-apply.
2. Plan → Apply → Cost Estimation → Policy Check, evaluating cost and policy only after apply

   Incorrect. Both Cost Estimation and Policy Check happen between Plan and Apply. Running them after Apply would mean they can no longer block a non-compliant or expensive apply.
3. Init → Plan → Apply → Cost Estimation, with the cost estimate produced only after provisioning

   Incorrect. Cost Estimation happens between Plan and Apply, not after Apply. Estimating costs after provisioning provides no opportunity to prevent an expensive deployment.
4. Validate → Plan → Apply → Policy Check, with the policy gate running after apply

   Incorrect. The Policy Check runs before Apply in Terraform Cloud, not after. Applying before policy evaluation would defeat the purpose of policy enforcement.

Terraform Cloud run order: Plan → Cost Estimation → Policy Check (Sentinel) → Apply — this order ensures cost and compliance gates before any provisioning occurs.

Other Terraform Associate domains

• Understand Terraform Basics — 197 questions →
• Implement and Maintain State — 77 questions →
• Interact with Terraform Modules — 50 questions →
• Use and Apply the Terraform Workflow — 49 questions →
• Understand Infrastructure as Code (IaC) Concepts — 45 questions →
• All 495 Terraform Associate questions →