Terraform Associate Understand Infrastructure as Code (IaC) Concepts: 45 practice questions

12 of the 45 Understand Infrastructure as Code (IaC) Concepts 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. Declarative: Which approach does Terraform use?

1. Declarative ✓

   Correct. Terraform uses a declarative approach — you describe the desired end state in .tf files, and Terraform determines the API calls needed to achieve that state.
2. Imperative

   Incorrect. Imperative (procedural) IaC specifies step-by-step commands to execute — like shell scripts or Ansible playbooks. Terraform is declarative, not imperative.
3. Event-driven

   Incorrect. Event-driven refers to architecture patterns where actions are triggered by events — it is not an IaC provisioning model.
4. Reactive

   Incorrect. Reactive is not a standard IaC paradigm. Terraform's model is declarative.

Terraform is declarative — you define the desired end state, and Terraform plans and executes whatever changes are needed to achieve it.

2. Infrastructure configurations can be version-controlled: Which of the following is a key advantage of using In

1. IaC guarantees zero infrastructure costs because it automatically negotiates provider pricing down on every apply run

   Incorrect. IaC optimizes provisioning efficiency but has no ability to negotiate provider pricing — you still pay the cloud vendor's published rates for whatever you provision.
2. Infrastructure configurations can be version-controlled, reviewed, and reproduced consistently across environments ✓

   Correct. IaC stores infrastructure definitions in code files that can be tracked in version control (Git), peer-reviewed, and applied repeatedly to produce identical environments.
3. IaC removes all dependency on cloud provider APIs by provisioning hardware through a direct physical connection

   Incorrect. IaC tools like Terraform provision resources by calling provider APIs — they abstract those API calls but never bypass them with direct hardware access.
4. IaC applies every infrastructure change instantly to production without offering a preview or planning step first

   Incorrect. Terraform specifically includes a planning phase (terraform plan) that previews changes before they are applied — IaC does not skip planning.

IaC enables version control, peer review, consistent reproduction across environments, and automated auditing of infrastructure changes.

3. Terraform: Which tool BEST supplements Ansible for this purpose?

1. Chef

   Incorrect. Chef is a configuration management tool similar to Ansible/Puppet — not a cloud infrastructure provisioning tool with multi-cloud state management.
2. AWS CloudFormation

   Incorrect. CloudFormation is AWS-only — it cannot provision Azure or GCP resources. The requirement for multi-cloud support eliminates CloudFormation.
3. Terraform ✓

   Correct. Terraform is provider-agnostic (supports 3,000+ providers), declarative, and stateful — complementing Ansible's configuration management strength with infrastructure provisioning.
4. Puppet

   Incorrect. Puppet focuses on configuration management (like Ansible) — it does not provide strong multi-cloud infrastructure provisioning with state tracking.

Terraform's provider-agnostic architecture, declarative HCL, and state management make it the leading choice for multi-cloud infrastructure provisioning.

4. Terraform detects the drift and shows a plan to revert: The next time `terraform plan` is run, what happens?

1. Terraform deletes the manually modified security group outright because it detects that the resource was changed outside of Terraform

   Incorrect. Terraform does not automatically delete drifted resources — it shows them in the plan output as resources to update back to the desired state.
2. Terraform detects the drift and shows a plan to revert the security group back to the configuration defined in the .tf files ✓

   Correct. Terraform compares the desired state (.tf files) against the real infrastructure (refreshed from API). Manual console changes appear as drift — Terraform plans to revert them.
3. Terraform ignores the manual changes made outside of Terraform and reports that no configuration differences were found at all

   Incorrect. Terraform refreshes state during plan and detects any difference between the desired config and real infrastructure — manual changes are surfaced as drift.
4. Terraform automatically rewrites the affected .tf files so that they match the manual change made in the AWS Console

   Incorrect. Terraform never modifies .tf files. The code is the source of truth — drifted infrastructure is reconciled back to the code, not the other way around.

Terraform detects configuration drift during plan by comparing the .tf desired state against refreshed real infrastructure — planning to revert unauthorized changes.

5. Provisioning cloud infrastructure such as virtual machines: Which of the following is the MOST appropriate use

1. Installing and configuring application software on servers that already exist and run

   Incorrect. Software installation and in-place configuration (Day 2 operations) is better handled by configuration management tools like Ansible, Chef, or Puppet — not Terraform.
2. Debugging application source code and fixing the software bugs found inside a codebase

   Incorrect. Terraform manages infrastructure, not application code. Debugging source is a developer task unrelated to IaC provisioning tooling.
3. Provisioning cloud infrastructure such as virtual machines, networks, and databases ✓

   Correct. Terraform excels at infrastructure provisioning (Day 0/Day 1 operations) — creating and managing cloud resources like VMs, VPCs, and managed databases.
4. Monitoring live application performance metrics and generating operational alerts

   Incorrect. Application performance monitoring is handled by tools like Datadog, Prometheus, or CloudWatch — not Terraform, which focuses on infrastructure provisioning.

Terraform is designed for infrastructure provisioning — creating and managing cloud resources like VMs, networks, and databases (Day 0/1 operations).

6. Mutable infrastructure and Immutable infrastructure: What are these two patterns called?

1. Blue-green deployment and Canary deployment, which shift live traffic to a new release

   Incorrect. Blue-green and Canary are application deployment strategies about traffic shifting, not the mutable versus immutable infrastructure distinction the question describes.
2. Declarative infrastructure and Imperative infrastructure, describing how the end state is expressed

   Incorrect. Declarative versus imperative describes HOW infrastructure is defined, not whether running servers are patched in place or replaced.
3. Stateful infrastructure and Stateless infrastructure, based on whether data persists across requests

   Incorrect. Stateful versus stateless refers to whether an application retains data between requests, not to whether servers are patched or replaced.
4. Mutable infrastructure (patching in-place) and Immutable infrastructure (destroy and replace) ✓

   Correct. Mutable infrastructure modifies existing resources; immutable infrastructure replaces resources entirely, reducing configuration drift and ensuring consistency.

Mutable infrastructure patches existing servers in-place; immutable infrastructure replaces servers entirely with new builds, eliminating configuration drift.

7. Push — Terraform runs from a control machine and directly: Which model does Terraform use?

1. Push — Terraform runs from a control machine and directly calls provider APIs to apply changes ✓

   Correct. Terraform uses the push model: you run terraform apply from a control machine (local workstation or CI runner), and Terraform directly calls cloud provider APIs to create or modify resources. No agent is required on target systems.
2. Pull — Terraform agents on each resource poll HashiCorp's servers for desired state

   Incorrect. Terraform has no agent component. Tools like Puppet or Chef use pull models where agents on managed nodes check in with a server. Terraform is agentless and push-based.
3. Push — Terraform installs an agent on each provisioned VM to complete configuration

   Incorrect. Terraform is push-based but does NOT install agents. Terraform calls cloud APIs to provision resources; any further OS-level configuration would require a separate tool like Ansible or user-data scripts.
4. Pull — Terraform Cloud continuously polls provider APIs and applies drift corrections automatically

   Incorrect. Terraform Cloud can detect drift via health assessments but does NOT automatically apply corrections without a human-triggered or VCS-triggered run. Terraform remains a push model.

Terraform is a push-based tool: it runs from a control plane and calls provider APIs directly, with no agents on target resources.

8. Terraform is agentless: Which characteristic of Terraform supports this goal compared to agent-based tools?

1. Terraform encrypts its agent channel with mutual TLS, keeping the privileged VM daemon from being exploited

   Incorrect. Terraform has no agent and no agent channel to encrypt. mTLS agent-server encryption describes tools like Puppet; because Terraform is agentless there is no VM daemon to protect.
2. Terraform is agentless — it calls cloud provider APIs without requiring any software installed on provisioned VMs ✓

   Correct. Terraform manages infrastructure by calling cloud provider APIs from the machine where it runs. No daemon or agent runs on provisioned VMs, which minimizes the attack surface compared to agent-based tools.
3. Terraform installs a lightweight read-only agent that can inspect the OS but is denied all write and privileged access

   Incorrect. Terraform installs no agent at all, not even a read-only one. It runs entirely from the host executing the terraform binary and communicates only through provider APIs.
4. Terraform relies on a Vault agent daemon on every VM to fetch credentials, but it runs without elevated rights

   Incorrect. Vault Agent is a separate product for secret injection and is not required by Terraform. Terraform needs no agent on VMs; any Vault use is optional and independent of its agentless design.

Terraform is agentless — infrastructure is managed through provider API calls, so no persistent daemon or agent needs to run on provisioned VMs.

9. Unit testing using terraform validate and terraform test: Which testing approach best fits this goal?

1. End-to-end testing that provisions the entire application stack in a production-like account to verify real behavior across integrated components

   Incorrect. End-to-end testing provisions the full stack in a production-like environment. It is the slowest and most expensive testing tier and is inappropriate for fast PR-gate feedback without provisioning.
2. Integration testing that deploys the module to a staging cloud account and checks that outputs and dependencies resolve correctly

   Incorrect. Integration testing provisions real cloud resources in a staging environment. While valuable, it does not satisfy the 'without provisioning real cloud resources' requirement and is much slower than unit tests.
3. Unit testing using terraform validate and terraform test with mock providers to catch syntax and logic errors without provisioning ✓

   Correct. Unit-level IaC testing uses terraform validate for syntax and configuration correctness and terraform test (TF 1.6+) with mock providers to evaluate module logic, all without creating real cloud resources — giving fast PR feedback.
4. Smoke testing that applies the configuration with -auto-approve, then destroys it to confirm resources provision cleanly

   Incorrect. Smoke testing still provisions real resources through an apply-then-destroy cycle. It catches deployment errors but violates the 'no real cloud resources' requirement and gives slower feedback.

Unit testing for IaC uses terraform validate and terraform test with mock providers to catch syntax and logic errors without any cloud resource provisioning.

10. Implement Sentinel policies in Terraform Cloud/Enterprise: Which approach satisfies this requirement?

1. Add a terraform validate rule that inspects each S3 bucket's public-access settings and fails the run whenever a violation appears

   Incorrect. terraform validate only checks HCL syntax and references — it cannot evaluate provider-specific attribute values or enforce business policies like blocking public S3 buckets.
2. Configure AWS Service Control Policies at the AWS organization level to deny creation of any S3 bucket configuration that enables public access

   Incorrect. AWS SCPs are an AWS-native control, not a Terraform workflow control. They enforce at the API layer after Terraform attempts the apply — not within the Terraform plan/apply pipeline the question requires.
3. Use a lifecycle precondition on every aws_s3_bucket resource to verify the public_access_block attribute before creation

   Incorrect. Lifecycle preconditions are module-level guardrails written by the module author and can be bypassed by omitting them. They are not centrally enforced the way Sentinel provides organization-wide mandatory policy.
4. Implement Sentinel policies in Terraform Cloud/Enterprise that evaluate the plan and block applies violating the public-access rule ✓

   Correct. Sentinel is HashiCorp's Policy as Code framework embedded in Terraform Cloud and Enterprise. It evaluates the terraform plan output and enforces mandatory rules — such as blocking S3 buckets with public access — before terraform apply executes.

Sentinel policies in Terraform Cloud/Enterprise evaluate the plan before apply and can enforce mandatory rules like blocking publicly accessible S3 buckets.

11. Git as the single source of truth: Which principle of GitOps does this workflow implement?

1. Git as the single source of truth — all infrastructure changes flow through version-controlled PRs and automated pipelines triggered by commits ✓

   Correct. GitOps treats the Git repository as the authoritative desired state. Every change is made via a Git commit/PR and applied by automation — no manual CLI runs outside Git — making the Git history the complete audit trail.
2. Continuous delivery — every commit is pushed straight to production by the automated pipeline with no human review step in between at all

   Incorrect. GitOps typically includes a PR review step before merging to main, which then triggers the apply. It does not imply skipping human review — the defining trait is that the mechanism is Git-driven.
3. Infrastructure immutability — each apply destroys and then recreates every managed resource from scratch instead of updating any of them in place

   Incorrect. GitOps does not mandate immutable replacement on every commit; Terraform applies only the necessary diff. Immutability is a separate concept about how individual resources are updated.
4. Blue-green deployment — the pipeline keeps two identical environments running and shifts production traffic between them on release

   Incorrect. Blue-green deployment is a release strategy for zero-downtime deployments. GitOps is about using Git as the source of truth for operational changes — a different concept.

GitOps uses Git as the single source of truth for infrastructure: all changes flow through PRs, and automated pipelines apply the merged state — no out-of-band changes.

12. Static analysis / IaC security scanning tools such as: Which category of tool is designed for this purpose?

1. Cloud provider security centers such as AWS Security Hub, which scan Terraform code pre-deploy

   Incorrect. AWS Security Hub analyzes live deployed resources, not Terraform source code. It operates post-deploy, not as a pre-apply code scanner.
2. Static analysis / IaC security scanning tools such as tfsec, Checkov, or Terrascan ✓

   Correct. Static analysis tools like tfsec, Checkov, and Terrascan scan Terraform configuration files without running them, identifying security misconfigurations against rule libraries (CIS benchmarks, provider best practices) before any apply.
3. Terraform Sentinel — it scans HCL files for security issues during the write phase

   Incorrect. Sentinel is a policy engine that evaluates Terraform plan output — it does not scan raw HCL files. It operates in the plan-to-apply phase within Terraform Cloud/Enterprise, not as a static code scanner.
4. terraform validate — it checks for security misconfigurations in HCL

   Incorrect. terraform validate checks for HCL syntax errors and invalid references — it does not evaluate security configurations, open ports, or encryption settings. It has no security ruleset.

Tools like tfsec, Checkov, and Terrascan perform static analysis on Terraform configurations, catching security misconfigurations before any infrastructure is provisioned.

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 Terraform's Purpose (vs Other IaC) — 40 questions →
• All 495 Terraform Associate questions →