Knowledge + Practice

CCNA Understand Terraform's purpose Questions

56 questions · Understand Terraform's purpose · All types, answers revealed

Practice these questions Domain overview All questions

1

MCQeasy

A company wants to manage both on-premises and cloud infrastructure with a single tool. Which feature of Terraform makes this possible?

A.Provider plugins

B.State files

C.Provisioners

D.Workspaces

AnswerA

Provider plugins let Terraform interact with distinct APIs through a common workflow. Separate providers for on-premises platforms and cloud services translate Terraform configuration into each environment's native calls, so one tool and language manage both infrastructures, satisfying the single-tool requirement.

Why this answer

Terraform uses provider plugins as the abstraction layer that allows it to interact with different infrastructure platforms. Each provider plugin (e.g., AWS, Azure, vSphere) implements the necessary API calls to manage resources on that platform. By using multiple provider plugins in the same configuration, Terraform can manage both on-premises infrastructure (e.g., VMware vSphere) and cloud infrastructure (e.g., AWS EC2) with a single tool.

Exam trap

The trap here is that candidates often confuse provider plugins with state files or workspaces, thinking that state files enable multi-cloud management, when in fact provider plugins are the core mechanism that allows Terraform to interface with any infrastructure API.

How to eliminate wrong answers

Option B is wrong because state files store the mapping between Terraform resources and real-world infrastructure, but they do not enable multi-platform management; they are a data store, not an integration mechanism. Option C is wrong because provisioners are used to execute scripts or configuration management tools on local or remote machines after resource creation, not to manage different infrastructure platforms. Option D is wrong because workspaces allow you to manage multiple distinct sets of infrastructure (e.g., dev, staging, prod) within the same configuration, but they do not provide the ability to interact with different infrastructure providers.

Practice this question →

2

Multi-Selectmedium

Which of the following accurately describe core purposes and benefits of using Terraform in a cloud infrastructure environment? Choose all that apply. (There are four correct answers.)

Select 4 answers

.Enables infrastructure as code by allowing users to define resources in declarative configuration files.

.Automates the provisioning and lifecycle management of infrastructure across multiple cloud providers.

.Provides a built-in drift detection mechanism that automatically reverts unauthorized manual changes to infrastructure.

.Supports state management to track the current state of infrastructure and plan changes incrementally.

.Generates real-time billing and cost optimization recommendations for deployed resources.

.Facilitates collaboration through remote state backends and version-controlled configuration files.

Why this answer

Terraform's core purpose is to enable Infrastructure as Code (IaC) by allowing users to define cloud resources in declarative HCL (HashiCorp Configuration Language) files. It automates provisioning and lifecycle management across multiple providers (AWS, Azure, GCP, etc.) using a single workflow. State management is fundamental: Terraform maintains a state file to track real-world resources, enabling incremental planning and safe updates.

Collaboration is facilitated by storing state remotely (e.g., in S3, Terraform Cloud) and using version control for configuration files, ensuring team consistency and auditability.

Exam trap

HashiCorp often tests the misconception that Terraform automatically reverts drift or provides cost optimization, when in fact drift detection is read-only and cost management is outside Terraform's scope.

Practice this question →

3

MCQeasy

What is the primary purpose of Terraform's state file?

A.Provide a GUI

B.Execute scripts

C.Map configurations to real-world resources

D.Store secrets

AnswerC

The Terraform state file is the definitive source of truth that precisely maps the logical resource definitions within your Terraform configuration to their corresponding physical instances in the real world. This crucial mapping includes unique identifiers, attributes, and dependencies of each managed resource. By maintaining this comprehensive record, Terraform can accurately understand the current state of your infrastructure, enabling it to intelligently plan and apply changes to achieve the desired configuration.

Why this answer

Terraform's state file is the authoritative record that maps resources declared in configuration to the actual real-world objects (e.g., AWS instance IDs, Azure resource IDs). Without it, Terraform cannot know what it has already created, what to update, or what to destroy.

Exam trap

TF-004 often tests the misconception that the state file stores secrets or executes code — candidates must remember its core purpose is the mapping between configuration and real infrastructure, not secret management or script execution.

How to eliminate wrong answers

Option A is wrong because Terraform is a CLI-driven IaC tool; the state file has nothing to do with providing a GUI. Option B is wrong because the state file does not execute scripts — it is a JSON data store describing resource metadata and attributes. Option D is wrong because while state can incidentally contain sensitive values (which is why remote backends with encryption are recommended), storing secrets is not its purpose and it should never be treated as a secrets manager.

Practice this question →

4

Drag & Dropmedium

Drag and drop the steps to destroy infrastructure managed by Terraform in the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Destroy plan previews removal; destroy command with confirmation tears down infrastructure.

Practice this question →

5

Multi-Selecthard

Which THREE are considered Terraform's best practices?

Select 3 answers

A.Use variables to parameterize configurations

B.Use latest version of all modules

C.Store state securely

D.Use remote state locking

E.Use provisioners for all software installs

AnswersA, C, D

Using variables to parameterize configurations is a fundamental best practice, enabling dynamic values to be passed into modules and resources. This approach promotes reusability by allowing the same core configuration to be deployed across different environments (e.g., development, staging, production) with varying inputs, significantly reducing code duplication and enhancing maintainability. Variables make configurations flexible and adaptable to changing requirements without modifying the underlying HCL code.

Why this answer

A is correct because using variables to parameterize configurations is a core Terraform best practice that enables reusability, flexibility, and separation of concerns. By defining input variables in `variables.tf` and passing values via `terraform.tfvars` or environment variables, you avoid hardcoding values like instance types or region names, making configurations portable across environments (dev, staging, prod). This aligns with Terraform's principle of writing infrastructure as code that is modular and maintainable.

Exam trap

A common pitfall in Terraform is assuming that always using the latest module version is a best practice. In reality, for reproducibility and stability, you should pin module versions to specific, tested releases.

Practice this question →

6

MCQmedium

An organization uses Terraform Cloud for remote state management. A user runs `terraform apply` locally but receives an error that the state is locked. What is the most likely cause?

A.The Terraform configuration has a syntax error.

B.The user does not have access to the remote state backend.

C.Another user or process is currently running a Terraform operation that modifies the same state.

D.The remote backend is temporarily unavailable.

AnswerC

Terraform state locking is a crucial mechanism designed to prevent concurrent write operations from corrupting the remote state file. When an operation like `terraform apply` or `terraform destroy` begins, Terraform attempts to acquire an exclusive lock on the state. If another user or automated process is already performing a state-modifying operation, that lock will be held, causing subsequent operations to fail with a 'state locked' error, thereby ensuring data integrity.

Why this answer

Terraform Cloud uses a state locking mechanism to prevent concurrent modifications that could corrupt the state file. When a user runs `terraform apply` locally, the command first attempts to acquire a lock on the remote state. If another user or process (e.g., a Terraform Cloud run, a CI/CD pipeline, or another local apply) is already holding that lock, the new operation will fail with a 'state is locked' error.

This is a fundamental safety feature to ensure state consistency.

Exam trap

The trap here is that candidates often confuse a 'state locked' error with a 'backend unavailable' error (Option D) or an 'access denied' error (Option B), but The TF-003 exam specifically tests the understanding that a lock error is a concurrency control mechanism, not a connectivity or permission issue.

How to eliminate wrong answers

Option A is wrong because a syntax error in the Terraform configuration would cause a validation failure during `terraform plan` or `terraform apply`, not a state lock error; the lock error is a backend-level issue, not a configuration-level one. Option B is wrong because if the user lacked access to the remote state backend, the error would typically be an authentication or authorization failure (e.g., 'AccessDenied' or '403 Forbidden'), not a state lock message; the lock error implies the user can reach the backend but the state is already locked. Option D is wrong because if the remote backend were temporarily unavailable, the error would be a network or timeout error (e.g., 'RequestError' or 'unable to reach the backend'), not a specific 'state is locked' message; the lock error indicates the backend is reachable and actively reporting a lock.

Practice this question →

7

Multi-Selectmedium

A team is evaluating Terraform for managing their multi-cloud infrastructure. Which TWO statements accurately describe Terraform's purpose and capabilities? (Choose two.)

Select 2 answers

A.Terraform requires all configuration files to be placed in a single directory named 'terraform'.

B.Terraform can provision, update, and destroy infrastructure resources across multiple providers.

C.Terraform's configuration language (HCL) is designed to be human-readable and machine-friendly.

D.Terraform uses an imperative language to specify the exact steps to create resources.

E.Terraform is primarily a configuration management tool for installing software on servers.

AnswersB, C

Terraform's declarative engine plans and applies changes through provider plugins, so a single configuration can create, modify, and delete resources spanning AWS, Azure, and GCP. This directly satisfies the stem's multi-cloud requirement, since each provider's API is abstracted behind the same lifecycle operations.

Why this answer

Option B is correct because Terraform's core purpose is infrastructure as code: the terraform plan/apply/destroy workflow lets it provision, modify, and tear down resources through provider plugins for many clouds (AWS, Azure, GCP, etc.) from one configuration. Option C is correct because Terraform's HashiCorp Configuration Language (HCL) is a declarative, human-readable syntax that is also structured enough for machines to parse and process. Option A is wrong because Terraform does not mandate a directory named 'terraform'; configuration files can live in any working directory and are conventionally named with a .tf extension.

Option D is wrong because Terraform is declarative, not imperative: you describe the desired end state and Terraform computes the steps, rather than specifying exact procedural steps. Option E is wrong because Terraform is a provisioning/IaC tool, not a configuration management tool like Ansible, Chef, or Puppet that installs and configures software on servers.

Exam trap

HashiCorp often tests the distinction between declarative (Terraform) and imperative (e.g., Ansible playbooks) approaches, and candidates may confuse Terraform's purpose with configuration management tools like Chef or Puppet.

Practice this question →

8

MCQeasy

What does Terraform's declarative model mean for infrastructure changes?

A.You manually approve each step

B.You describe the desired end state

C.You must specify the order of creation

D.You write scripts to create resources

AnswerB

Terraform's declarative model fundamentally means you define the desired final configuration of your infrastructure using HashiCorp Configuration Language (HCL). Instead of providing a sequence of commands to execute, you simply describe 'what' your infrastructure should look like, including resources, their properties, and relationships. Terraform then intelligently calculates the 'how' — the precise actions needed to achieve that specified end state from the current infrastructure.

Why this answer

Terraform's declarative model means you describe the desired end state of your infrastructure in configuration files, and Terraform determines the actions needed to reach that state. You do not specify the sequence of API calls or the order of resource creation; Terraform builds a dependency graph and executes operations in the correct order automatically. This contrasts with imperative scripting, where you must define each step explicitly.

Exam trap

TF-004 often tests the confusion between declarative (describe end state) and imperative (specify steps/order) — candidates may pick 'specify order of creation' thinking Terraform needs explicit sequencing, when it actually infers it.

How to eliminate wrong answers

Option A is wrong because manual approval of each step describes a gated workflow (like Terraform's plan/apply approval), not the declarative model itself — declarative means you state the end state, not that you approve each action. Option C is wrong because specifying the order of creation is the imperative approach; Terraform infers order from dependencies in the declarative configuration. Option D is wrong because writing scripts to create resources is imperative/procedural, the opposite of Terraform's declarative paradigm.

Practice this question →

9

MCQeasy

A company wants to adopt infrastructure as code (IaC) to manage their expanding cloud environment. Which problem does Terraform directly address?

A.Ensuring applications are highly available across regions

B.Automating software installation and patching on servers

C.Eliminating manual configuration drift across environments

D.Providing real-time monitoring and alerting for infrastructure

AnswerC

Terraform excels at eliminating manual configuration drift by enforcing a desired state model for infrastructure. It defines infrastructure declaratively in code, and during an `apply` operation, Terraform compares the current actual state of the infrastructure with this desired configuration. Any discrepancies, whether accidental manual changes or unapplied updates, are identified and can be automatically reconciled, ensuring environments remain consistent and aligned with their codified definition.

Why this answer

Terraform directly addresses the problem of manual configuration drift by enabling infrastructure as code (IaC), where the entire infrastructure state is defined in declarative configuration files. It uses a desired-state model: Terraform compares the current state of resources against the configuration and automatically reconciles any differences, ensuring environments remain consistent and drift is eliminated without manual intervention.

Exam trap

Candidates often confuse Terraform's purpose of infrastructure provisioning with configuration management tools like Ansible or Chef. Option B might be chosen because it deals with software installation, but Terraform is not a configuration management tool; it focuses on managing infrastructure resources declaratively.

How to eliminate wrong answers

Option A is wrong because Terraform is a provisioning tool, not a high-availability solution; ensuring applications are highly available across regions requires architectural patterns (e.g., multi-region deployment, load balancing, failover) and is outside Terraform's scope. Option B is wrong because automating software installation and patching on servers is the domain of configuration management tools like Ansible, Chef, or Puppet, not Terraform, which focuses on infrastructure provisioning and lifecycle management. Option D is wrong because real-time monitoring and alerting for infrastructure is handled by observability platforms such as Prometheus, CloudWatch, or Datadog, not by Terraform, which has no built-in monitoring or alerting capabilities.

Practice this question →

10

MCQhard

A team member runs terraform apply with the configuration shown in the exhibit. The apply succeeds, but the output of the local-exec provisioner shows an empty string for the public IP address. What is the most likely cause?

A.There is a dependency cycle between the aws_instance and null_resource causing Terraform to skip the provisioner.

B.The local-exec provisioner only runs during terraform destroy, not during apply.

C.The aws_instance resource does not have a public IP assigned because it is launched in a default VPC without auto-assign public IP, and no Elastic IP is attached.

D.The provisioner cannot access the aws_instance resource's attributes because it is defined in a separate resource block.

AnswerC

By default, EC2 instances launched into a default VPC do not automatically receive a public IP address unless the specific subnet's 'Auto-assign public IPv4 address' setting is enabled, or an Elastic IP (EIP) is explicitly associated with the instance. If neither of these conditions is met, the `aws_instance.public_ip` attribute will remain empty. This absence prevents the provisioner from establishing a connection using a public IP, leading to connection failures.

Why this answer

The `local-exec` provisioner runs on the machine executing Terraform, not on the AWS instance itself. If the instance is launched in a default VPC without `auto-assign public IP` enabled and no Elastic IP is attached, the `self.public_ip` attribute will be an empty string. The provisioner then outputs that empty string, as it simply reads the attribute value from the resource state.

Exam trap

HashiCorp often tests the misconception that `local-exec` runs on the remote instance or that `self.public_ip` is always populated, when in reality it depends on the network configuration and the provisioner's execution context.

How to eliminate wrong answers

Option A is wrong because a dependency cycle would cause Terraform to error out during planning, not silently skip the provisioner; the apply succeeded, so no cycle exists. Option B is wrong because `local-exec` provisioners run during `terraform apply` by default, not only during destroy; `destroy-time` provisioners require explicit `when = destroy`. Option D is wrong because provisioners can access attributes of any resource in the configuration, including `aws_instance`, as long as the resource is referenced (e.g., via `self` or a direct reference); the `null_resource` has a `depends_on` ensuring the instance exists.

Practice this question →

11

MCQmedium

During a terraform apply, the state file becomes corrupted. What is the recommended recovery method?

A.Restore from backup

B.Re-run apply

C.Delete the state and re-import all resources

D.Use terraform state pull

AnswerA

When a Terraform state file becomes corrupted, the most reliable and recommended recovery strategy is to restore it from a recent, uncorrupted backup. Remote state backends, such as AWS S3 or Azure Blob Storage, automatically version and store previous states, making restoration straightforward. This approach ensures the state accurately reflects the infrastructure, preventing drift and potential resource destruction or recreation during subsequent `terraform apply` operations. It minimizes data loss and operational disruption, maintaining infrastructure integrity.

Why this answer

The recommended recovery method for a corrupted Terraform state file is to restore it from a known good backup. Terraform does not have built-in corruption repair mechanisms, so maintaining regular backups of the state file (e.g., using remote backends with versioning like S3 versioning or Terraform Cloud) is the standard operational practice. Restoring from backup ensures the state accurately reflects the real-world infrastructure without manual intervention.

Exam trap

The misconception tested in this question is that Terraform has a built-in repair command like `terraform state pull` or that re-running `terraform apply` can recover from corruption. In reality, the only reliable recovery method is restoring from a known good backup of the state file.

How to eliminate wrong answers

Option B is wrong because re-running `terraform apply` without a valid state file will fail or attempt to create duplicate resources, as Terraform cannot reconcile the existing infrastructure without a correct state. Option C is wrong because deleting the state and re-importing all resources is error-prone, time-consuming, and may lead to configuration drift or missed dependencies; it is not a recommended recovery method. Option D is wrong because `terraform state pull` retrieves the current state from a configured backend but does not fix corruption; if the state is already corrupted, pulling it only retrieves the corrupted data.

Practice this question →

12

MCQeasy

A developer runs `terraform plan` and sees that Terraform will create a new S3 bucket and modify a security group. Which Terraform feature allows the developer to review these changes before applying them?

A.The `terraform apply` command

B.The `terraform validate` command

C.The `terraform plan` command

D.The `terraform state` command

AnswerC

The `terraform plan` command generates an execution plan, detailing the actions Terraform will take to achieve the desired state defined in the configuration files. This command compares the current infrastructure state (from the state file) with the desired state (from the configuration) and displays a comprehensive preview of resources to be added, changed, or destroyed, without making any actual modifications to the infrastructure.

Why this answer

The `terraform plan` command creates an execution plan that shows what actions Terraform will take to achieve the desired state defined in the configuration. It compares the current state with the configuration and outputs a diff-like summary of resources to be created, modified, or destroyed, allowing the developer to review changes before applying them with `terraform apply`.

Exam trap

HashiCorp often tests the distinction between `terraform plan` as a read-only preview and `terraform apply` as the execution command, trapping candidates who confuse 'review' with 'apply' or think `terraform validate` performs a dry-run.

How to eliminate wrong answers

Option A is wrong because `terraform apply` executes the changes and does not provide a review-only preview; it applies the plan and prompts for confirmation unless auto-approved. Option B is wrong because `terraform validate` checks the syntax and internal consistency of the configuration files, not the planned changes against the real infrastructure state. Option D is wrong because `terraform state` is used to inspect or manipulate the Terraform state file (e.g., `terraform state list`, `terraform state show`), not to preview upcoming changes.

Practice this question →

13

MCQhard

A company is adopting Terraform to manage its multi-cloud infrastructure on AWS and Azure. The infrastructure team has written several Terraform configurations stored in a Git repository. Each configuration is applied by different team members using their local machines. Recently, the team has been experiencing state file conflicts and inconsistencies, leading to infrastructure drift. The team currently stores the state file locally. They want to ensure that only one person can apply changes at a time and that the state file is always up-to-date. They also want to be able to collaborate effectively without overwriting each other's changes. Which approach should they implement?

A.Use Terraform Cloud to manage state and provide remote operations with locking.

B.Have only one team member run terraform apply from a dedicated machine.

C.Store the state file in a shared Git repository and use git pull/push to sync changes.

D.Use a remote backend such as Amazon S3 with DynamoDB for state locking.

AnswerA

Use Terraform Cloud to manage state and provide remote operations with locking is correct because Terraform Cloud offers managed remote state with built-in locking and remote operations, ensuring exclusive apply access, centralized state, and collaborative features.

Why this answer

Terraform Cloud provides a managed remote state backend with built-in state locking and remote operations. This ensures that only one person can apply changes at a time (via the locking mechanism), the state file is always up-to-date (stored centrally), and team members can collaborate without overwriting each other's changes. It directly addresses the team's need for exclusive apply access and consistent state.

Exam trap

HashiCorp often tests the distinction between remote state storage with locking (e.g., S3 with DynamoDB) and remote operations (e.g., Terraform Cloud). The trap is that candidates may see a 'remote backend' and assume it solves all collaboration issues, but Terraform Cloud provides additional benefits like remote execution and VCS integration that foster better collaboration. However, it's important to note that S3 with DynamoDB does provide state locking, which prevents concurrent applies.

How to eliminate wrong answers

Option B is wrong because it introduces a single point of failure and a bottleneck, and does not solve the underlying state locking issue—other team members could still run terraform plan or modify local state, leading to drift. Option C is wrong because storing the state file in a shared Git repository is not safe; Git does not provide state locking, and concurrent git pull/push operations can cause merge conflicts, corruption, or stale state. Option D is wrong because while Amazon S3 with DynamoDB provides state locking and remote storage, it does not offer remote operations (the apply still runs locally), so the team would still need to coordinate who runs apply, and the state file could become stale if multiple users run apply simultaneously without proper locking integration.

Practice this question →

14

Multi-Selectmedium

Which TWO of the following are key advantages of using Terraform over manual infrastructure management? (Select TWO.)

Select 2 answers

A.Guaranteed zero downtime during updates

B.Consistent and repeatable deployments

C.Version-controlled infrastructure code

D.Automatic discovery of existing resources

E.Self-healing infrastructure

AnswersB, C

Terraform's core strength lies in its declarative configuration language (HCL), which describes the *desired state* of infrastructure rather than a sequence of imperative steps. When `terraform apply` is executed, Terraform calculates the necessary actions to transition the current infrastructure to the desired state, ensuring that subsequent deployments of the same configuration will consistently yield identical infrastructure, significantly reducing human error and configuration drift. This predictability is crucial for reliable operations across environments.

Why this answer

Option B is correct because Terraform's declarative configuration and state file let you apply the same plan repeatedly, producing consistent and repeatable deployments across environments instead of relying on error-prone manual steps. Option C is correct because Terraform configurations are plain code (HCL) that can be stored in Git and versioned, enabling peer review, change history, and rollback of infrastructure definitions. Options A, D, and E are not inherent Terraform advantages: zero downtime depends on the resource/provider and update strategy, Terraform does not automatically discover and import existing resources without explicit import commands, and self-healing is typically provided by orchestrators or auto-scaling services rather than by Terraform itself.

Exam trap

A common misconception is that Terraform automatically discovers existing resources or provides self-healing capabilities. In reality, Terraform is a provisioning tool that requires explicit state management and manual execution (terraform apply) to reconcile infrastructure. It does not automatically detect resources outside its state file nor heal infrastructure without user intervention.

Practice this question →

15

Multi-Selecteasy

Which TWO statements best describe Terraform's purpose? (Choose two.)

Select 2 answers

A.It is a configuration management tool.

B.It is designed for single-cloud environments.

C.It uses a declarative language.

D.It requires a master node to manage agents.

E.It is an infrastructure provisioning tool.

AnswersC, E

Terraform utilizes HashiCorp Configuration Language (HCL), a declarative language, to define the desired end state of infrastructure. Users specify *what* resources should exist and their attributes, rather than *how* to achieve that state through a series of procedural steps. Terraform then intelligently determines the necessary actions to transition the current infrastructure to the declared desired state, ensuring idempotence and consistency across deployments.

Why this answer

Terraform uses a declarative language (HCL) where you define the desired end state of your infrastructure, and Terraform determines the necessary steps to achieve that state. This is a core differentiator from imperative tools, as it focuses on 'what' rather than 'how'.

Exam trap

Candidates often confuse infrastructure provisioning (Terraform) with configuration management (Puppet, Ansible, Chef). Terraform provisions the underlying infrastructure, while configuration management tools configure the software and settings on that infrastructure. This distinction is critical.

Practice this question →

16

MCQmedium

A team is reviewing the Terraform configuration shown in the exhibit. Which statement best describes the relationship between the two resources?

A.The S3 bucket cannot be created until the EC2 instance is running.

B.The S3 bucket depends on the EC2 instance because it is defined after it.

C.The two resources have no dependencies and can be created in any order.

D.The EC2 instance depends on the S3 bucket because the instance uses the bucket name.

AnswerC

Terraform establishes dependencies either implicitly, when one resource's attribute is referenced by another, or explicitly, using the `depends_on` meta-argument. Given the absence of any such references or explicit declarations linking the EC2 instance and S3 bucket resources, Terraform correctly identifies them as entirely independent. This independence allows the Terraform graph to execute their creation in parallel or in any sequential order, as no ordering constraints exist.

Why this answer

Terraform resources are independent by default unless an explicit or implicit dependency is declared. In the exhibit, the S3 bucket and EC2 instance are defined without any `depends_on` argument or attribute reference (e.g., `aws_s3_bucket.example.arn` used in the EC2 instance configuration). Therefore, Terraform can create them in parallel or any order, as there is no directed acyclic graph (DAG) edge enforcing a creation sequence.

Exam trap

HashiCorp often tests the misconception that Terraform creates resources in the order they appear in the configuration file, but the actual dependency mechanism is based on explicit references and `depends_on`, not lexical order.

How to eliminate wrong answers

Option A is wrong because there is no `depends_on` or attribute reference from the S3 bucket to the EC2 instance, so Terraform does not require the EC2 instance to be running before creating the bucket. Option B is wrong because Terraform does not use definition order to determine dependencies; it builds a dependency graph based on explicit references and `depends_on` blocks, not the order in the configuration file. Option D is wrong because the EC2 instance does not reference the S3 bucket's name or any attribute (e.g., `aws_s3_bucket.example.bucket`), so no implicit dependency exists; the instance can be created independently of the bucket.

Practice this question →

17

MCQmedium

A team has been managing their AWS infrastructure using a collection of Bash scripts that create resources in a specific order. They frequently encounter issues where resources are created out of order or not properly cleaned up. They want to adopt a more reliable approach that ensures consistent provisioning and teardown. Which action best aligns with Terraform's purpose?

A.Continue using the Bash scripts but add more error handling.

B.Use Terraform but only store state locally on the lead engineer's machine.

C.Convert the scripts into Terraform configuration files and use remote state.

D.Rewrite the scripts as Ansible playbooks for provisioning.

AnswerC

Converting to Terraform configuration files leverages a declarative approach, allowing the team to define the desired end state of their AWS infrastructure, rather than the steps to get there. Terraform automatically builds a dependency graph, ensuring resources are provisioned in the correct order and handling updates efficiently. Utilizing remote state, such as in an S3 bucket with DynamoDB locking, enables secure team collaboration, prevents concurrent modifications, and maintains a consistent, shared record of the infrastructure's actual state.

Why this answer

Terraform's core purpose is to provide declarative, idempotent infrastructure as code with a state file that tracks resource dependencies and enables consistent provisioning and teardown. Converting the Bash scripts to Terraform configuration files directly addresses the ordering and cleanup issues because Terraform builds a dependency graph and applies changes in the correct order. Using remote state (e.g., S3 backend with DynamoDB locking) ensures the state is shared, consistent, and protected from loss, which is essential for team collaboration and reliable teardown.

Exam trap

TF-004 often tests the misconception that any automation tool (like Ansible) or improved scripting can replace Terraform's declarative state management, when the key differentiator is Terraform's state file and dependency graph.

How to eliminate wrong answers

Option A is wrong because adding error handling to imperative Bash scripts does not solve the fundamental problem of managing resource dependencies and state; scripts remain order-dependent and lack idempotency. Option B is wrong because storing state locally on one engineer's machine creates a single point of failure, prevents team collaboration, and risks state loss or corruption, which undermines Terraform's reliability. Option D is wrong because Ansible is primarily a configuration management and orchestration tool that operates imperatively for provisioning; while it can create cloud resources, it does not provide Terraform's declarative state management and dependency graph, so it would not fully address the ordering and cleanup issues.

Practice this question →

18

MCQhard

Which Terraform feature allows managing multiple separate sets of infrastructure from the same configuration?

A.Workspaces

B.Count

C.Providers

D.For_each

AnswerA

Workspaces in Terraform allow for managing multiple distinct instances of the same configuration. Each workspace maintains its own independent state file, enabling the deployment of identical infrastructure setups (e.g., `dev`, `staging`, `prod`) without modifying the core HCL code. This isolation prevents resource conflicts and ensures environment-specific configurations are applied correctly through variable overrides, making them ideal for environment separation.

Why this answer

Workspaces allow you to manage multiple distinct sets of infrastructure resources from the same Terraform configuration by maintaining separate state files. Each workspace isolates its own state data, enabling you to deploy, modify, or destroy infrastructure for different environments (e.g., dev, staging, prod) without interfering with each other. This is the native Terraform feature designed specifically for managing multiple separate instances of infrastructure from a single configuration.

Exam trap

A common pitfall is confusing meta-arguments like 'count' and 'for_each', which create multiple resource instances within a single state, with workspaces, which provide full state isolation for managing entirely separate environments (e.g., dev, staging, prod) from the same configuration.

How to eliminate wrong answers

Option B (count) is wrong because it is a meta-argument used to create multiple copies of a resource within a single configuration, not to manage separate sets of infrastructure; it operates within a single workspace and state file. Option C (Providers) is wrong because providers are plugins that interact with specific cloud APIs (e.g., AWS, Azure) and do not provide any mechanism for isolating or managing separate infrastructure instances; they define the resource types available, not workspace separation. Option D (for_each) is wrong because it is a meta-argument that creates multiple resource instances from a map or set of strings, similar to count, and does not offer state isolation or separate management of infrastructure sets; it works within a single workspace.

Practice this question →

19

MCQmedium

A company wants to ensure that Terraform configurations are consistent across teams. What practice should they adopt?

A.Write all code in a single file

B.Use modules from a registry

C.Use provisioners extensively

D.Avoid using variables

AnswerB

Using modules from a registry is the most effective method to ensure consistent Terraform configurations across an organization. Modules encapsulate a set of related infrastructure resources, allowing them to be defined once with standardized inputs and outputs, then reused across multiple projects or environments. This promotes consistency by enforcing predefined patterns, reducing configuration drift, and enabling centralized management and versioning of infrastructure components, directly addressing the need for reliable and repeatable deployments.

Why this answer

Using modules from a registry (Option B) is the correct practice because modules encapsulate reusable, version-controlled infrastructure configurations that enforce consistency across teams. By referencing a shared registry, teams can standardize on approved module versions, reducing drift and ensuring compliance with organizational policies. This approach aligns with Terraform's best practices for code reuse and collaboration.

Exam trap

A common mistake is assuming a single file ensures consistency, but modules from a registry provide version-controlled, shareable configurations that standardize infrastructure across teams.

How to eliminate wrong answers

Option A is wrong because writing all code in a single file violates the principle of separation of concerns, leading to monolithic, unmaintainable configurations that are difficult to version and review across teams. Option C is wrong because provisioners should be used sparingly as a last resort; extensive use introduces procedural logic that undermines Terraform's declarative model, making configurations brittle and non-idempotent. Option D is wrong because avoiding variables eliminates the ability to parameterize configurations, forcing hardcoded values that prevent reuse and consistency across different environments or teams.

Practice this question →

20

MCQhard

An organization is evaluating Terraform for managing interconnected resources that must be created in a specific order. Why is Terraform's dependency graph handling a key aspect of its purpose?

A.It reduces the amount of code needed

B.It allows all resources to be created in parallel for speed

C.It ensures resources are provisioned in the correct order based on dependencies

D.It enables modularity and code reuse

AnswerC

The dependency graph is fundamental to Terraform's operational integrity, as it precisely maps out the relationships between all declared resources. By analyzing these explicit (e.g., `depends_on`) and implicit (e.g., attribute references) dependencies, Terraform constructs an execution plan that guarantees resources are provisioned, updated, or destroyed in the correct, logical sequence. This prevents provisioning failures, ensures state consistency, and maintains the desired infrastructure configuration.

Why this answer

Terraform builds a dependency graph from the resource configurations, analyzing explicit references (e.g., `aws_instance.web.vpc_id`) and implicit dependencies. This graph ensures that resources are created, updated, or destroyed in the correct order, preventing provisioning failures that would occur if, for example, a subnet were created before its parent VPC. This deterministic ordering is fundamental to Terraform's ability to manage complex, interconnected infrastructure reliably.

Exam trap

A common trap is the misconception that Terraform creates all resources in parallel for speed. While Terraform does parallelize independent resources, it strictly serializes dependent ones based on the dependency graph, so full parallelism is never the goal—correct ordering is.

How to eliminate wrong answers

Option A is wrong because Terraform's dependency graph does not reduce the amount of code; it manages execution order, while code reduction is achieved through features like modules, variables, and count/for_each. Option B is wrong because Terraform does not allow all resources to be created in parallel; it uses the dependency graph to identify resources with no dependencies and creates those in parallel, but dependent resources must wait, so full parallelism is impossible and would cause errors. Option D is wrong because modularity and code reuse are enabled by Terraform's module system and input/output variables, not by the dependency graph, which is solely concerned with ordering and parallelism.

Practice this question →

21

MCQeasy

A developer is new to infrastructure as code and wants to deploy a simple web server on AWS using a tool that allows them to define the infrastructure in a reusable and version-controlled manner. They are considering using the AWS Management Console, AWS CLI, or Terraform. Which course of action aligns best with Terraform's purpose?

A.Use Terraform to define the web server in a .tf file and run terraform apply.

B.Use the AWS Management Console to manually create the web server.

C.Write a shell script using the AWS CLI to provision resources.

D.Use Terraform but only with local state and no version control.

AnswerA

Terraform's declarative configuration, defined in a .tf file, specifies the desired end state of the web server infrastructure. Running terraform apply then intelligently provisions or modifies resources to match this state, ensuring idempotency and providing a consistent, version-controlled blueprint for the environment. This approach automates infrastructure provisioning and updates reliably.

Why this answer

Terraform's core purpose is to allow infrastructure to be defined declaratively in configuration files (typically .tf files) that can be version-controlled, shared, and reused. Writing the web server definition in a .tf file and running `terraform apply` follows this declarative, code-based workflow, enabling repeatable and auditable deployments. This aligns with infrastructure as code (IaC) principles, unlike manual or imperative approaches.

Exam trap

TF-004 often tests the misconception that any automated tool (like AWS CLI scripts) qualifies as infrastructure as code, or that Terraform can be used without version control and still meet IaC goals.

How to eliminate wrong answers

Option B is wrong because using the AWS Management Console is a manual, click-based process that is not version-controlled, repeatable, or reusable, and thus does not align with Terraform's purpose. Option C is wrong because writing a shell script with AWS CLI commands is an imperative approach that lacks Terraform's declarative state management, idempotency, and plan/apply lifecycle. Option D is wrong because using Terraform with only local state and no version control undermines the reusability, collaboration, and versioning benefits that are central to Terraform's design.

Practice this question →

22

MCQhard

A DevOps team accidentally deleted their Terraform state file. The actual infrastructure (EC2 instances, security groups, etc.) is still running and unchanged. They have the Terraform configuration files that were used to create the infrastructure. They want to re-establish management of the existing infrastructure without recreating it. Which course of action aligns with Terraform's purpose?

A.Delete all existing infrastructure and run terraform apply to recreate it.

B.Manually edit the configuration to match the existing resources exactly, then run terraform apply.

C.Run terraform plan to generate a new state file automatically.

D.Use terraform import for each resource to bring them into the state file.

AnswerD

Using terraform import for each resource is the correct and most robust method to recover from a lost state file without disrupting existing infrastructure. This command allows you to link an existing cloud resource, identified by its provider-specific ID, to a corresponding resource block defined in your Terraform configuration. By systematically importing each managed resource, Terraform rebuilds its state file, establishing a new authoritative record of the infrastructure it controls.

Why this answer

terraform import is the supported mechanism to bring existing resources under Terraform management by writing their real-world attributes into the state file, without destroying or recreating them. Since the configuration files already exist and match the infrastructure, importing each resource re-establishes the mapping between config and state. After import, terraform plan should show no changes if the config matches reality.

Exam trap

The trap is believing terraform plan or apply can reconstruct state from live infrastructure — candidates pick plan or manual config editing, not realizing only terraform import writes existing resources into state.

How to eliminate wrong answers

Option A is wrong because deleting and recreating infrastructure causes downtime and data loss, and contradicts the goal of preserving existing resources. Option B is wrong because manually editing configuration does not create state; Terraform still has no record of the resources and would attempt to create duplicates. Option C is wrong because terraform plan only compares config to state — it cannot generate state from existing infrastructure; with no state, plan would propose creating everything.

Practice this question →

23

MCQmedium

Refer to the exhibit. A user attempts to run terraform apply with this configuration. What error will occur?

A.Conflicting access control settings

B.Missing required provider configuration

C.Duplicate resource name "mybucket"

D.Invalid bucket name pattern

AnswerC

Terraform requires that all resources within a given module have a unique combination of resource type and local name. In the provided configuration, there are two separate `aws_s3_bucket` resources both declared with the local name `mybucket`. This duplication creates an ambiguous reference and violates Terraform's naming conventions, leading to a validation error during the plan or apply phase because Terraform cannot uniquely identify or manage these distinct resources.

Why this answer

Terraform requires every resource block to have a unique address within the same module. If two `aws_s3_bucket` resources both use the same logical name `mybucket`, Terraform will reject the configuration with a `Duplicate resource name` error during the `plan` or `apply` phase. This is a fundamental rule of Terraform's configuration language, enforced at parse time before any provider interaction occurs.

Exam trap

A common pitfall is confusing Terraform's core language validation (which catches duplicate resource names) with provider-level validation (which catches invalid bucket names or missing configurations). This question tests the distinction between a local naming error and a provider or API error.

How to eliminate wrong answers

Option A is wrong because access control settings (like bucket policies or ACLs) are configured within the resource arguments, not at the resource naming level, and Terraform does not raise a 'conflicting access control' error from duplicate resource names. Option B is wrong because a missing provider configuration would cause a different error, such as 'No provider configuration found' or 'Provider not configured', not a duplicate name error. Option D is wrong because bucket name pattern validation (e.g., DNS-compliant naming) is performed by the AWS provider or API, not by Terraform's core parser, and would produce an error like 'Invalid bucket name' rather than a duplicate resource error.

Practice this question →

24

MCQhard

An organization has multiple teams using Terraform to manage shared infrastructure. They want to enforce policies such as requiring specific tags on all resources and preventing the use of certain instance types. Which Terraform feature should they implement to meet these requirements?

A.Terraform workspaces

B.Custom Terraform providers

C.Remote backends with state locking

D.Sentinel policy enforcement

AnswerD

Sentinel is HashiCorp's policy-as-code framework, integrated into Terraform Cloud and Enterprise, that evaluates plans against rules before apply. It directly satisfies the stem's constraints — mandatory tags and blocked instance types — by rejecting non-compliant plans, unlike OPA or manual review.

Why this answer

Sentinel is HashiCorp's policy-as-code framework that integrates with Terraform Cloud and Enterprise to enforce fine-grained, logic-based policies before resources are created or modified. It can mandate that all resources carry specific tags (e.g., `required_tags`) and block prohibited instance types (e.g., `t2.micro`) by evaluating Terraform plan output against Sentinel rules, making it the correct choice for these governance requirements.

Exam trap

Terraform certification exams often test the distinction between operational features (workspaces, backends) and governance features (policy enforcement), leading candidates to confuse state management with policy control.

How to eliminate wrong answers

Option A is wrong because Terraform workspaces are used to manage multiple distinct state files for the same configuration (e.g., dev, prod), not to enforce policies on resource tags or instance types. Option B is wrong because custom Terraform providers extend Terraform to manage new resource types or APIs, but they do not provide a mechanism to write and enforce policy rules across all resources. Option C is wrong because remote backends with state locking ensure state file consistency and prevent concurrent modifications, but they have no capability to inspect or enforce tagging or instance-type restrictions.

Practice this question →

25

MCQhard

A company has a Terraform configuration that works correctly in us-east-1 but fails in us-west-2 due to resource availability. What is the best way to handle this?

A.Hardcode region in resources

B.Use count

C.Use data sources

D.Use provisioners

AnswerC

Data sources are a powerful Terraform feature that allows configurations to query and retrieve information from external systems, such as cloud provider APIs, during the plan phase. This enables dynamic fetching of region-specific attributes like available AMI IDs, instance types, or subnet configurations, which can then be used to configure resources adaptively. By leveraging data sources, the configuration can dynamically adjust to regional differences and ensure resource compatibility without hardcoding.

Why this answer

Data sources allow Terraform to query the target region for available resources at plan time, enabling dynamic configuration that adapts to regional differences. By using a data source to filter or validate resource availability, the configuration can fail gracefully or select an alternative resource without hardcoding region-specific values.

Exam trap

A common trap on the HashiCorp Terraform exam is thinking that `count` or `for_each` can directly handle regional resource differences. In reality, those meta-arguments require a data source to dynamically determine the available resources in each region, making the data source the correct approach.

How to eliminate wrong answers

Option A is wrong because hardcoding region-specific resources reduces portability and violates Terraform's infrastructure-as-code principles, requiring manual updates for each region. Option B is wrong because `count` controls the number of resource instances but cannot dynamically select a different resource type or handle unavailability across regions. Option D is wrong because provisioners are for executing scripts on local or remote machines after resource creation, not for resolving resource availability at plan time.

Practice this question →

26

MCQhard

A company uses AWS CloudFormation for AWS resources and Azure Resource Manager for Azure resources. They want to standardize on a single tool that can manage resources across both clouds with a consistent workflow and support for infrastructure as code. They also want to ensure that their infrastructure can be version-controlled and reviewed. Which approach best fulfills Terraform's purpose?

A.Use a custom Python script that calls both cloud APIs.

B.Continue using CloudFormation for AWS and Resource Manager for Azure.

C.Use Terraform with the AWS and Azure providers to manage all resources.

D.Migrate all resources to a single cloud provider to simplify management.

AnswerC

Terraform is purpose-built for multi-cloud and multi-provider infrastructure provisioning, making it the optimal solution for standardizing management across AWS and Azure. By leveraging its robust official AWS and Azure providers, engineers can define resources using a consistent HashiCorp Configuration Language (HCL) syntax within a single codebase. This approach centralizes state management, automates dependency resolution, and provides a unified, declarative workflow for all cloud resources, significantly reducing operational complexity.

Why this answer

Terraform is a cloud-agnostic infrastructure as code tool that uses providers to interact with multiple cloud APIs. By configuring both the AWS and Azure providers, Terraform can manage resources across both clouds using a single, consistent workflow and HCL configuration. This enables version control and code review of the infrastructure definitions, fulfilling the company's requirements.

Exam trap

TF-004 often tests the misconception that a custom script or native cloud tools can provide the same multi-cloud, declarative infrastructure as code benefits as Terraform, when in fact Terraform's provider-based architecture and state management are key differentiators.

How to eliminate wrong answers

Option A is wrong because a custom Python script is not a declarative infrastructure as code tool; it would require manual coding of API calls, lacks state management, and does not provide a consistent workflow or built-in version control integration. Option B is wrong because using CloudFormation and Resource Manager separately does not standardize on a single tool; it maintains two distinct workflows and toolchains, which contradicts the goal. Option D is wrong because migrating all resources to a single cloud provider is a drastic architectural change that may not be feasible or desirable, and it does not address the need for a single tool to manage multi-cloud resources.

Practice this question →

27

MCQeasy

A team wants to manage infrastructure across multiple cloud providers using a single tool that supports infrastructure as code. Which tool is best suited for this purpose?

A.Ansible

B.Terraform

C.AWS CloudFormation

D.Chef

AnswerB

Terraform is an open-source infrastructure as code tool specifically engineered for provisioning and managing infrastructure across multiple cloud providers and on-premise solutions. It uses a declarative configuration language (HCL) to define desired infrastructure states, allowing teams to consistently create, update, and destroy resources like virtual machines, networks, and databases across AWS, Azure, GCP, and others. Its provider-based architecture enables seamless interaction with diverse APIs, making it ideal for multi-cloud strategies.

Why this answer

Terraform is the best choice because it is a cloud-agnostic Infrastructure as Code (IaC) tool that uses a declarative configuration language (HCL) to manage resources across multiple providers (e.g., AWS, Azure, GCP) through a single workflow. Unlike provider-specific tools, Terraform's provider plugin architecture allows it to abstract away API differences, enabling consistent state management and provisioning across heterogeneous environments.

Exam trap

The trap here is that candidates confuse configuration management tools (Ansible, Chef) with infrastructure provisioning tools, or assume that a cloud-specific tool like CloudFormation is sufficient for multi-cloud management, ignoring the requirement for a single, provider-agnostic tool.

How to eliminate wrong answers

Option A is wrong because Ansible is primarily a configuration management and automation tool that uses imperative playbooks (YAML) and relies on SSH/WinRM for execution; while it can provision infrastructure via modules, it lacks native multi-cloud state management and is not designed as a dedicated IaC provisioning tool. Option C is wrong because AWS CloudFormation is a proprietary IaC service that only manages resources within the AWS ecosystem, using JSON/YAML templates tied to the AWS API, and cannot manage resources from other cloud providers. Option D is wrong because Chef is a configuration management tool that uses a Ruby-based DSL (recipes/cookbooks) to enforce desired state on existing servers, not to provision infrastructure across multiple clouds, and it requires a Chef server for node management.

Practice this question →

28

Multi-Selecteasy

Which TWO statements accurately describe key purposes of Terraform?

Select 2 answers

A.Terraform enables declarative infrastructure provisioning.

B.Terraform provides built-in security scanning.

C.Terraform automates continuous delivery pipelines.

D.Terraform supports multi-cloud and multi-provider environments.

E.Terraform manages both mutable and immutable infrastructure.

AnswersA, D

Terraform's core design principle is declarative infrastructure provisioning. Users define the desired end state of their infrastructure using HashiCorp Configuration Language (HCL) or JSON, rather than specifying a sequence of steps to reach that state. Terraform then computes the necessary actions (create, update, delete) to transition the current infrastructure to the desired configuration, ensuring idempotence and consistency. This approach simplifies management and reduces human error.

Why this answer

Option A is correct because Terraform uses a declarative HashiCorp Configuration Language (HCL) model where you define the desired end state of infrastructure and Terraform computes the create/update/delete actions needed to reach it, rather than scripting imperative steps. Option D is correct because Terraform's provider plugin architecture (e.g., aws, azurerm, google, kubernetes) lets a single configuration and workflow target multiple clouds and services simultaneously, which is a core design purpose. Option B is wrong because Terraform itself has no built-in security scanning; that requires separate tools such as tfsec, Checkov, or Sentinel policies.

Option C is wrong because Terraform is an infrastructure provisioning tool, not a CI/CD pipeline engine; it is typically invoked by pipelines (Jenkins, GitHub Actions, GitLab CI) rather than replacing them. Option E is wrong because Terraform's model is fundamentally immutable/declarative resource replacement, and while it can manage mutable resources via providers, 'manages both mutable and immutable infrastructure' is not a stated key purpose in the same way as A and D.

Exam trap

TF-004 often tests the misconception that Terraform includes built-in security scanning or CI/CD pipeline automation, when those are separate concerns handled by other tools.

Practice this question →

29

Matchingmedium

Match each Terraform error code to its meaning.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Success – no errors

Error – command failed

Error – CLI argument parsing error

Error – configuration errors

Error – state lock error

Why these pairings

Terraform exit codes indicate the result of command execution. Exit code 0 means success, 1 means general error, and 2 means usage error. The other codes are not defined by Terraform.

Practice this question →

30

Multi-Selectmedium

Which TWO are benefits of Terraform's immutable infrastructure approach?

Select 2 answers

A.Easier rollbacks

B.Better performance

C.Faster provisioning

D.Lower cost

E.Reduced configuration drift

AnswersA, E

Immutable infrastructure significantly simplifies rollbacks because each deployment is based on a distinct, versioned artifact, such as a golden AMI or container image. If a new deployment introduces issues, reverting to a previous stable state involves merely deploying an older, validated version of the infrastructure artifact. This process replaces the entire problematic environment with a known-good one, eliminating complex in-place patching or state restoration.

Why this answer

Terraform's immutable infrastructure approach replaces entire resources rather than modifying them in-place. This means the previous version of the infrastructure is preserved as a state snapshot, allowing you to roll back by simply reapplying the prior configuration from your version control system. This eliminates the complexity of tracking incremental changes and ensures a clean, predictable rollback process.

Exam trap

Candidates often mistakenly assume that immutable infrastructure inherently improves performance or reduces costs, but in Terraform, the trade-offs include potentially slower provisioning due to full resource replacement and possible cost increases from maintaining multiple resource versions.

Practice this question →

31

MCQeasy

Refer to the exhibit. What does this output show?

A.Resources to be created

B.Resources in the configuration

C.Resources that are out of sync

D.Resources managed by Terraform

AnswerD

The `terraform state list` command directly queries and displays the contents of the Terraform state file, which is the authoritative record of all infrastructure resources that Terraform is currently managing. This output precisely enumerates every resource instance that has been successfully provisioned, imported, and whose metadata is stored within the state, unequivocally confirming their status as being under Terraform's active management. It serves as a definitive inventory of the infrastructure Terraform controls.

Why this answer

The output shows a list of resources that Terraform is currently tracking in its state file. This indicates which resources are under Terraform's management, not just those defined in the configuration or those that are out of sync. Option D is correct because the `terraform state list` command (or similar output) displays all resources that Terraform is actively managing, regardless of their current state relative to the configuration.

Exam trap

A common pitfall in Terraform exams is confusing resources defined in the configuration with resources actually managed in the state, leading candidates to select 'Resources in the configuration' (Option B) instead of 'Resources managed by Terraform'.

How to eliminate wrong answers

Option A is wrong because the output does not show resources to be created; it shows resources already tracked in the state, which may already exist. Option B is wrong because the output is not limited to resources defined in the configuration; it includes all resources in the state, which can differ from the configuration if resources were imported or removed. Option C is wrong because the output does not indicate synchronization status; it simply lists managed resources without comparing them to the configuration or real-world infrastructure.

Practice this question →

32

MCQhard

Refer to the exhibit. A team is troubleshooting a Terraform deployment. What information can be inferred from this state file?

A.The Terraform version is outdated and must be upgraded.

B.There is one EC2 instance of type t2.micro with a dependency on a security group.

C.The instance ID is invalid and needs to be recreated.

D.The security group dependency was not applied.

AnswerB

The Terraform state file, as presented in the exhibit, explicitly shows a single `aws_instance` resource. Within its attributes, `instance_type` is clearly set to `t2.micro`. Furthermore, the `vpc_security_group_ids` attribute contains an array with one entry, indicating an explicit dependency on a security group resource. This direct evidence from the state confirms the presence and configuration of the EC2 instance and its security group association.

Why this answer

The state file explicitly shows a resource of type `aws_instance` with `instance_type = "t2.micro"` and a `depends_on` meta-argument referencing `aws_security_group.example`. This indicates that Terraform recorded the EC2 instance as created with a t2.micro type and that it has a formal dependency on a security group resource, ensuring the security group is created before the instance during apply.

Exam trap

A common trick in Terraform exams is to assume that a `depends_on` entry in the state file means the dependency was 'not applied' or that the state file is invalid without a `terraform_version`, but in reality the presence of the dependency list confirms it was recorded and enforced.

How to eliminate wrong answers

Option A is wrong because the state file does not contain any version metadata or `terraform_version` field that would indicate an outdated version; Terraform state files include a `terraform_version` key only if the state was written by a newer version, and its absence or presence does not imply a required upgrade. Option C is wrong because the state file shows a valid `id` for the EC2 instance (e.g., `i-0abcd1234efgh5678`), and there is no indication of invalidity or need for recreation; instance IDs in state are simply recorded identifiers, not validated against the live cloud. Option D is wrong because the `depends_on` attribute in the state file explicitly records that the dependency on the security group was applied; if it were not applied, the `depends_on` block would be absent or empty.

Practice this question →

33

Multi-Selectmedium

Which TWO tasks are better suited for configuration management tools than Terraform?

Select 2 answers

A.Installing software packages

B.Managing network ACLs

C.Provisioning a VPC

D.Creating IAM roles

E.Configuring web server settings

AnswersA, E

Installing software packages on a server is a classic use case for configuration management tools such as Ansible, Chef, or Puppet. These tools excel at defining the desired state of an operating system, including which packages should be present, their versions, and ensuring they are installed idempotently. While Terraform provisions the underlying virtual machine, it does not typically manage the granular, post-provisioning software lifecycle within the guest OS.

Why this answer

Installing software packages and configuring web server settings are typical tasks for configuration management tools like Ansible or Puppet, as they operate on existing servers. Terraform, by contrast, is designed for provisioning infrastructure resources such as VPCs, IAM roles, and network ACLs. Therefore, options A and E are correct.

Practice this question →

34

Multi-Selecthard

Which THREE statements accurately describe Terraform state? (Select THREE.)

Select 3 answers

A.State is used to map real-world resources to configuration.

B.State can be shared among team members using remote backends.

C.State contains sensitive data by default.

D.State is automatically locked to prevent concurrent modifications.

E.State is stored locally by default.

AnswersA, B, E

Terraform state is a critical component that maintains a mapping between the resources defined in your configuration files (e.g., main.tf) and the actual infrastructure objects provisioned in the cloud or on-premises. It records metadata such as resource IDs, attributes, and dependencies, allowing Terraform to understand the current state of your managed infrastructure. This mapping enables Terraform to perform accurate plans and apply changes, ensuring it only modifies or creates resources as intended.

Why this answer

Option A is correct because Terraform state maintains the binding between resource instances declared in configuration and the actual remote objects, storing attributes and resource addresses so Terraform knows what exists and what to update or destroy. Option B is correct because remote backends such as S3 with DynamoDB, Terraform Cloud, or Consul allow the state file to be stored centrally and shared across team members, enabling collaboration and consistent operations. Option E is correct because, absent an explicit backend configuration, Terraform writes state to a local file named terraform.tfstate in the working directory.

Option C is not correct as a general statement because while state can contain sensitive values in plaintext, it does not inherently 'contain sensitive data by default' for every configuration. Option D is not correct because locking is not automatic in all cases; it depends on the backend, and the default local backend does not provide locking, while remote backends like S3 require explicit DynamoDB locking configuration.

Exam trap

A common misconception tested in this domain is that state locking is an automatic feature of Terraform, when in fact it requires explicit backend configuration, and that state inherently contains secrets, whereas it only holds resource attributes that may incidentally include sensitive values.

Practice this question →

35

MCQmedium

A team has been manually modifying cloud resources outside of Terraform. They now find that Terraform plans show changes that don't match their expectations. What core concept of Terraform's purpose does this situation violate?

A.Declarative configuration with desired state

B.Idempotency

C.Immutable infrastructure

D.Procedural scripting

AnswerA

Terraform operates on a declarative configuration model where the desired state of infrastructure is explicitly defined in HCL files. When resources are manually modified outside of Terraform, it introduces configuration drift, causing the actual state to diverge from the desired state defined in the configuration. This violation means Terraform's next `plan` or `apply` might propose unexpected changes or fail to reconcile the infrastructure to the intended state, undermining the reliability and predictability of infrastructure management.

Why this answer

Terraform's core purpose is to manage infrastructure through a declarative configuration that defines the desired state. When users manually modify cloud resources outside of Terraform, the actual state diverges from the desired state defined in the configuration. Terraform detects this drift and plans changes to reconcile the actual state back to the desired state, which may include unexpected modifications or deletions.

This violates the fundamental principle that Terraform should be the single source of truth for infrastructure state.

Exam trap

In the HashiCorp Terraform exam, this scenario tests understanding of Terraform's declarative nature. Candidates often confuse 'idempotency' with 'declarative configuration' because idempotency ensures consistent results, but the core issue here is that Terraform always reconciles the actual state to the desired state defined in configuration, which is the essence of declarative management.

How to eliminate wrong answers

Option B is wrong because idempotency refers to the property that applying the same configuration multiple times produces the same result, but the issue here is about state drift caused by out-of-band changes, not about repeated application behavior. Option C is wrong because immutable infrastructure is a pattern where resources are replaced rather than modified, but the core violation is about state management and drift detection, not about immutability. Option D is wrong because procedural scripting describes an imperative approach where steps are explicitly ordered, which is the opposite of Terraform's declarative model, but the question specifically highlights the mismatch between actual and desired state due to manual changes, not the scripting paradigm.

Practice this question →

36

MCQhard

An organization has a multi-cloud strategy using Terraform. They need to ensure that secrets such as API keys are not stored in plaintext in the configuration files. Which Terraform feature should they use to securely manage sensitive data?

A.Terraform variable definitions with environment variables

B.Terraform workspaces

C.Integration with a secrets management tool like Vault

D.Terraform state file encryption

E.Terraform's sensitive parameter in output blocks

AnswerC

Integrating with a dedicated secrets management tool like HashiCorp Vault is the most robust solution for securing sensitive data in a multi-cloud Terraform strategy. Vault provides centralized, secure storage for static secrets and can dynamically generate temporary credentials for various services, ensuring secrets are never hardcoded in configuration. This approach allows secrets to be retrieved at runtime, benefiting from strong encryption, auditing, and fine-grained access control policies.

Why this answer

Integrating Terraform with a dedicated secrets management tool like HashiCorp Vault allows sensitive data (e.g., API keys, passwords) to be stored securely and retrieved at runtime via data sources, rather than being hardcoded in plaintext in configuration files. This approach ensures secrets are never written to disk in plaintext, are encrypted in transit and at rest, and can be dynamically rotated without modifying Terraform code.

Exam trap

A common trap in Terraform certification is thinking that marking outputs as sensitive or using environment variables is sufficient for secure secret management, but those methods do not prevent secrets from being stored in plaintext in the state file or configuration files. Only integration with a secrets management tool like Vault ensures secrets are never exposed in plaintext.

How to eliminate wrong answers

Option A is wrong because environment variables can still leak sensitive values through logs, process listings, or shell history, and they do not provide encryption or access control for the secrets themselves. Option B is wrong because Terraform workspaces are used to manage multiple state files and environments, not to secure or encrypt sensitive data. Option D is wrong because state file encryption protects the state file at rest, but secrets may still be stored in plaintext in configuration files or in the state file before encryption; it does not prevent plaintext exposure in source code.

Option E is wrong because the `sensitive` parameter in output blocks only masks the value in CLI output and logs, but the secret is still stored in plaintext in the state file and configuration.

Practice this question →

37

MCQmedium

A DevOps engineer needs to integrate Terraform with a CI/CD pipeline. What is a common practice?

A.Run terraform plan in a pull request

B.Avoid using variables

C.Use -auto-approve always

D.Store state in a local file

AnswerA

Running `terraform plan` within a pull request (PR) is a best practice for CI/CD integration, as it provides a transparent preview of the infrastructure changes before they are applied. This allows team members to review the exact resources that will be created, updated, or destroyed, facilitating early detection of unintended modifications and ensuring adherence to infrastructure as code (IaC) principles prior to any actual state modification.

Why this answer

Running `terraform plan` in a pull request is a common practice because it allows the team to review the proposed infrastructure changes before they are applied. This integrates Terraform's safety mechanism into the CI/CD pipeline, ensuring that any destructive or unexpected modifications are caught during code review, not during deployment. It aligns with the principle of infrastructure as code (IaC) where changes are validated and approved through the same workflow as application code.

Exam trap

A common trap is to assume that `-auto-approve` is safe for automation, but it bypasses the human review step and can lead to unintended changes. The best practice is to use `terraform plan` in pull requests to review changes before applying.

How to eliminate wrong answers

Option B is wrong because avoiding variables defeats Terraform's purpose of making configurations dynamic, reusable, and environment-agnostic; variables are essential for parameterizing infrastructure across dev, staging, and production. Option C is wrong because using `-auto-approve` always bypasses the manual confirmation step, which can lead to unintended destruction of resources or misconfigurations; it should only be used in non-production pipelines with strict safeguards. Option D is wrong because storing state in a local file prevents collaboration and state locking, making it impossible for a team to safely run Terraform concurrently; remote state backends (e.g., S3 with DynamoDB locking) are required for CI/CD pipelines.

Practice this question →

38

MCQhard

A team is using Terraform to manage multiple environments (dev, staging, prod) with the same configuration but different variable values. They want to avoid duplicating configuration files. Which Terraform feature is best suited for this?

A.Terraform modules with separate directories for each environment

B.Terraform data sources to fetch environment-specific variables

C.Using multiple Terraform configuration files in a single directory

D.Terraform workspaces

AnswerD

Terraform workspaces provide a robust mechanism for managing multiple distinct infrastructure environments using a single, consistent Terraform configuration. Each workspace maintains its own isolated state file, allowing for independent deployments and modifications without affecting other environments. This approach significantly reduces configuration duplication, simplifies environment management, and ensures consistency across development, staging, and production deployments.

Why this answer

Terraform workspaces allow you to manage multiple environments (e.g., dev, staging, prod) using the same root configuration and variable definitions, but with separate state files. This avoids duplicating configuration files while enabling environment-specific variable values via `terraform.workspace` interpolation or separate `.tfvars` files per workspace. Option D is correct because workspaces are the native Terraform feature designed for this exact use case.

Exam trap

HashiCorp often tests the misconception that Terraform modules (Option A) are the primary tool for environment separation, but modules are for code reuse, not state isolation—workspaces handle state separation without duplicating configuration.

How to eliminate wrong answers

Option A is wrong because using separate directories for each environment with modules still duplicates the root configuration and state files, which is exactly what the team wants to avoid. Option B is wrong because data sources are used to fetch or compute data from providers (e.g., AWS, Azure) at plan/apply time, not to manage environment-specific variable values or state separation. Option C is wrong because placing multiple configuration files in a single directory does not inherently separate state or variable values per environment; it would still require manual management and risks state corruption.

Practice this question →

39

Multi-Selectmedium

Which TWO of the following are core components of Terraform's workflow? (Select TWO.)

Select 2 answers

A.terraform validate

B.terraform init

C.terraform install

D.terraform destroy

E.terraform plan

AnswersB, E

`terraform init` initialises the working directory, downloading the required provider plugins and modules and writing the dependency lock file. This satisfies the stem's workflow requirement, since no plan or apply can run until providers are installed and the backend is configured.

Why this answer

Terraform's core workflow consists of three main steps: init, plan, and apply. `terraform init` initializes the working directory by downloading the required providers and modules, setting up the backend, and preparing the environment for configuration. `terraform plan` creates an execution plan showing what actions Terraform will take to reach the desired state, allowing you to preview changes before applying them.

Exam trap

Candidates often mistake auxiliary commands like `terraform destroy` or `terraform validate` as part of the core workflow, but the core workflow is `init`, `plan`, and `apply`.

Practice this question →

40

MCQmedium

A team wants to use Terraform to manage their AWS infrastructure. They have existing resources created manually. What is the recommended approach to bring these resources under Terraform management?

A.Delete the existing resources and recreate them using Terraform configuration.

B.Use terraform plan to detect existing resources and automatically adopt them.

C.Write Terraform configuration that matches existing resources and run terraform apply.

D.Use terraform import to bring each resource into state.

AnswerD

The `terraform import` command is the correct and intended workflow for bringing existing infrastructure under Terraform's management. It reads the current state and attributes of a specified remote resource and then records this information within the Terraform state file, associating it with a corresponding resource block in the local configuration. This crucial step allows Terraform to recognize and manage the resource's lifecycle, enabling subsequent `plan` and `apply` operations to detect drift and make controlled modifications without recreating the resource.

Why this answer

`terraform import` is the recommended approach to bring existing manually created resources under Terraform management. It maps the real-world resource ID into your Terraform state file, allowing Terraform to track and manage it without deleting or recreating it. This preserves the existing infrastructure while enabling future updates via configuration.

Exam trap

A common misconception is that `terraform plan` can discover and adopt existing resources, but in reality, `plan` only compares state to configuration and cannot detect resources outside of state.

How to eliminate wrong answers

Option A is wrong because deleting and recreating resources causes unnecessary downtime and risk, and is not the recommended workflow for adopting existing infrastructure. Option B is wrong because `terraform plan` does not detect existing resources or automatically adopt them; it only compares the current state against the configuration and cannot discover resources not already in state. Option C is wrong because running `terraform apply` on a configuration that matches existing resources will attempt to create new resources, leading to conflicts or duplicate resources, unless the resources are already in state via import.

Practice this question →

41

MCQhard

Your organization manages a multi-cloud infrastructure using Terraform. The infrastructure includes an AWS VPC with subnets and EC2 instances, and an Azure resource group with virtual networks and VMs. The Terraform configuration is stored in a Git repository, and state is stored in an S3 bucket with DynamoDB locking. Recently, a developer updated the configuration to add a new security group rule in AWS, but after running `terraform apply`, the rule was not created. The developer verified that the configuration file contains the rule. Additionally, the developer noticed that the state file shows the security group exists but without the new rule. The developer ran `terraform plan` again, and it shows that the rule will be created. However, when applying, it fails with a 'timeout' error. The operations team suspects network connectivity issues to the S3 backend. What is the best course of action to resolve this issue?

A.Run `terraform init` again to reinitialize the backend.

B.Migrate the state backend to Terraform Cloud, and use remote operations for applies.

C.Increase the timeout value in the Terraform provider configuration.

D.Disable state locking by removing the DynamoDB table reference.

AnswerB

Migrating the state backend to Terraform Cloud and utilizing remote operations offloads the execution of `terraform apply` from the local machine to HashiCorp's managed infrastructure. This approach effectively bypasses local network instability, proxy configurations, or firewall restrictions that might be causing timeouts when accessing the state backend or provider APIs from the local environment. Terraform Cloud's robust and highly available execution environment ensures reliable communication with the state backend and target cloud providers.

Why this answer

The timeout error when applying, despite a successful plan, indicates that the issue is not with the configuration or state locking but with the network connectivity to the S3 backend during the apply operation. Migrating to Terraform Cloud with remote operations moves the execution environment to Terraform Cloud's infrastructure, which has reliable connectivity to the S3 backend, bypassing the local network issues. This resolves the timeout without altering the configuration or compromising state integrity.

Exam trap

HashiCorp often tests the distinction between provider-level timeouts (for API calls to cloud providers) and backend-level timeouts (for state storage), leading candidates to incorrectly choose increasing provider timeouts when the issue is actually with backend connectivity.

How to eliminate wrong answers

Option A is wrong because `terraform init` reinitializes the backend configuration but does not fix network connectivity issues to the S3 backend; the timeout occurs during the apply, not during initialization. Option C is wrong because increasing the timeout in the provider configuration affects API calls to AWS or Azure, not the HTTP timeout for the S3 backend connection; the timeout error is from the backend, not the provider. Option D is wrong because disabling state locking by removing the DynamoDB table reference would allow concurrent state modifications, risking state corruption and race conditions, and does not address the underlying network connectivity issue.

Practice this question →

42

MCQeasy

Refer to the exhibit. A developer runs terraform plan and sees the above output. What will happen when terraform apply is executed?

A.The existing EC2 instance is replaced due to a change in instance_type.

B.A new EC2 instance is created with instance_type t2.small, and the old one is destroyed.

C.The existing EC2 instance's instance_type is changed to t2.small in-place.

D.No changes will be made because the plan shows an update.

AnswerC

This statement is correct. The tilde (`~`) prefix in a `terraform plan` output explicitly indicates that an existing resource will be updated in-place, meaning its attributes will be modified without destroying and recreating the resource itself. For an AWS EC2 instance, changing the `instance_type` from its current value to `t2.small` is a supported in-place modification by the AWS provider, which will apply the change to the running instance.

Why this answer

Terraform's plan output shows an in-place update (indicated by the tilde `~` symbol) for the `instance_type` attribute of the existing EC2 instance. When `terraform apply` is executed, Terraform will modify the instance's type to `t2.small` without destroying and recreating the resource, as the change is supported by the AWS provider for EC2 instances.

Exam trap

Candidates often misinterpret the tilde (~) symbol in Terraform plan output as indicating a destroy-and-recreate action, but it actually signifies an in-place update. This question tests the ability to distinguish between in-place changes and resource replacement.

How to eliminate wrong answers

Option A is wrong because the plan does not show a force-new replacement (indicated by the `-/+` symbol); instead, it shows an in-place update, so the instance is not replaced. Option B is wrong because a new EC2 instance is not created; the plan shows a single resource change (update) rather than a destroy and create action. Option D is wrong because the plan explicitly shows a change to the `instance_type` attribute, so `terraform apply` will execute that modification, not skip it.

Practice this question →

43

MCQmedium

Refer to the exhibit. What is the primary purpose of the version constraint '~> 4.0'?

A.Allows any version in the 4.0 range including patch updates.

B.Allows only exact version 4.0.

C.Allows versions 4.0 through 5.0.

D.Allows any version 4.0 or higher.

AnswerA

The ~> 4.0 version constraint, known as the pessimistic constraint, precisely specifies that any version greater than or equal to 4.0.0 is acceptable, provided it remains strictly less than 5.0.0. This means it permits minor version increments (e.g., 4.1.0, 4.2.5) and patch updates (e.g., 4.0.1, 4.0.99) within the 4.x series. The primary purpose is to allow for non-breaking updates while preventing automatic upgrades to a new major version that might introduce breaking changes.

Why this answer

The version constraint '~> 4.0' uses the pessimistic version constraint operator in Terraform. It allows any version in the 4.x range, meaning versions >= 4.0 and < 5.0, including patch updates like 4.1, 4.2, etc. Therefore, option A is correct.

Option B is incorrect because '= 4.0' would pin to only exact 4.0. Option C is incorrect because it includes 5.0, which is not allowed. Option D is incorrect because it allows any version 4.0 or higher, including 5.0 and beyond, which is too broad.

Practice this question →

44

MCQmedium

A team uses a remote backend (S3) with state locking via DynamoDB. One team member runs terraform apply and it fails mid-way. Another team member immediately tries to run terraform plan. What is likely to happen?

A.The plan will run successfully because the lock is automatically released after failure.

B.The plan will run but the state file will be corrupted.

C.The plan will fail with an error indicating the state is locked.

D.The plan will run successfully and show any partial changes.

AnswerC

When a Terraform state is locked, any subsequent `terraform plan` command will fail with an explicit error message indicating that the state is currently locked. This mechanism, facilitated by DynamoDB for S3 backends, prevents concurrent operations that could lead to inconsistent infrastructure or state file corruption. The plan cannot proceed because it requires a stable, consistent view of the state, which the lock protects.

Why this answer

Terraform's remote backend with DynamoDB state locking acquires a lock at the start of `terraform apply` and does not release it until the operation completes or is explicitly unlocked. If the apply fails mid-way, the lock remains held (it is not automatically released on failure). Therefore, when another team member immediately runs `terraform plan`, the plan command will attempt to acquire the lock, fail, and return an error indicating the state is locked.

Exam trap

A common misconception is that a failed Terraform operation automatically releases the state lock, leading candidates to incorrectly choose Option A, when in fact the lock persists until explicit release or timeout.

How to eliminate wrong answers

Option A is wrong because the lock is not automatically released after failure; it remains held until the process terminates or the lock is manually removed via `terraform force-unlock`. Option B is wrong because the plan will not run at all—it will fail with a lock error—so there is no opportunity for state corruption from a concurrent plan. Option D is wrong because the plan will not run successfully; it will be blocked by the lock, and partial changes from the failed apply are not visible to a plan that cannot access the state.

Practice this question →

45

MCQeasy

A junior DevOps engineer is asked to explain the primary purpose of Terraform. Which statement best describes Terraform's purpose?

A.Terraform is a monitoring tool that tracks infrastructure changes.

B.Terraform is a scripting tool for automating manual tasks in cloud environments.

C.Terraform is a configuration management tool that installs and configures software on servers.

D.Terraform is an infrastructure provisioning tool that manages cloud and on-premises resources using declarative configuration.

AnswerD

Terraform is indeed a powerful infrastructure provisioning tool, enabling users to define and manage cloud and on-premises resources through a declarative configuration language. By describing the desired state of infrastructure in HashiCorp Configuration Language (HCL), Terraform automatically plans and applies the necessary changes to create, update, or destroy resources. This approach ensures consistent, repeatable deployments and efficient lifecycle management across diverse infrastructure providers.

Why this answer

Terraform is an infrastructure provisioning tool that uses declarative configuration (HashiCorp Configuration Language, HCL) to define and manage both cloud and on-premises resources. Its primary purpose is to provision infrastructure—such as virtual machines, networks, and storage—across multiple providers (e.g., AWS, Azure, GCP) by maintaining a desired state and applying changes via execution plans. Unlike configuration management or scripting tools, Terraform focuses on the lifecycle of infrastructure resources, not on configuring software within those resources.

Exam trap

In the HashiCorp Terraform exam, candidates often choose Option C because they confuse infrastructure provisioning (Terraform) with configuration management (e.g., Ansible, Chef, Puppet). Terraform's primary purpose is to provision infrastructure resources declaratively, not to configure software on servers.

How to eliminate wrong answers

Option A is wrong because Terraform is not a monitoring tool; it does not track infrastructure changes in real-time or provide metrics, alerts, or dashboards—those functions belong to tools like Prometheus or CloudWatch. Option B is wrong because Terraform is not a scripting tool for automating manual tasks; it uses declarative configuration, not imperative scripts, and its purpose is provisioning infrastructure, not automating ad-hoc operational tasks. Option C is wrong because Terraform is not a configuration management tool; it does not install or configure software on servers—tools like Ansible, Chef, or Puppet handle software configuration, while Terraform provisions the underlying infrastructure.

Practice this question →

46

Multi-Selecteasy

Which TWO statements accurately describe the purpose of Terraform? (Choose two.)

Select 2 answers

A.Terraform allows users to define infrastructure resources in a declarative configuration language.

B.Terraform can be used to create, modify, and destroy infrastructure resources.

C.Terraform is designed to work exclusively with AWS.

D.Terraform is a configuration management tool used for installing software on existing servers.

E.Terraform is a continuous integration and deployment tool.

AnswersA, B

Terraform utilizes HashiCorp Configuration Language (HCL) to allow users to express their desired infrastructure state in a human-readable format. This declarative approach means users describe *what* they want, such as a VPC or an EC2 instance, rather than providing imperative step-by-step instructions on *how* to create it. Terraform then intelligently determines the necessary actions to achieve this specified configuration, making infrastructure definition intuitive, versionable, and auditable.

Why this answer

Terraform uses HashiCorp Configuration Language (HCL) to define infrastructure as code in a declarative manner, meaning users specify the desired end state of resources without scripting the step-by-step process. This declarative approach allows Terraform to automatically determine the necessary actions to reach that state, making infrastructure management predictable and repeatable.

Exam trap

The trap here is that candidates often confuse Terraform's provisioning role with configuration management (Option D) or mistakenly assume it is cloud-specific (Option C), because many introductory examples focus on AWS, but Terraform's multi-provider support is a core design principle.

Practice this question →

47

MCQhard

Refer to the exhibit. What is the purpose of the data source?

A.To create a new AMI

B.To fetch an existing AMI ID

C.To define a variable

D.To output the AMI name

AnswerB

The primary purpose of this `data "aws_ami"` block is to dynamically query the AWS API and retrieve the unique identifier (ID) of an existing Amazon Machine Image that matches the specified criteria. By filtering for `ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*`, `architecture = "x86_64"`, and `virtualization_type = "hvm"`, and then selecting the latest image, the data source efficiently fetches the most current AMI ID for Ubuntu 20.04, making it available for use in other resource configurations.

Why this answer

In Terraform, a data source allows you to fetch or compute information from external sources that is not defined within the current configuration. The correct answer is B because the data source in the exhibit (e.g., `aws_ami`) is used to query and retrieve the ID of an existing AMI that matches specified filters, such as name, owner, or tag, without creating a new AMI. This enables dynamic referencing of pre-existing resources in your infrastructure.

Exam trap

A common trap in the Terraform exam is confusing data sources with resources: data sources are read-only and fetch existing information, while resources provision new infrastructure. Here, the `aws_ami` data source fetches an existing AMI ID, not creating a new one.

How to eliminate wrong answers

Option A is wrong because a data source does not create resources; it only reads existing data, whereas creating a new AMI would require a resource block like `aws_ami` with a `name` and `root_device_name`. Option C is wrong because defining a variable is done with a `variable` block, not a data source; data sources fetch runtime data, not define input variables. Option D is wrong because outputting the AMI name would require an `output` block referencing the data source's attribute, but the data source itself does not produce output; it only retrieves the AMI ID (or other attributes) for use elsewhere.

Practice this question →

48

MCQeasy

A new user is learning Terraform. They write a configuration file and run terraform apply expecting to provision resources. However, they forgot to run terraform init first. What will happen?

A.Terraform will successfully apply the configuration because validate is enough.

B.Terraform will automatically run init before applying.

C.Terraform will prompt to run init and then continue.

D.Terraform will return an error stating that the working directory is not initialized.

AnswerD

When "terraform apply" is executed in a working directory that has not been initialized, Terraform cannot proceed with the requested operation. The "apply" command fundamentally depends on the presence of downloaded provider plugins, a configured state backend, and potentially installed modules, all of which are established during the "terraform init" phase. Consequently, Terraform will halt execution and output a specific error message, clearly indicating that the working directory requires initialization before the "apply" command can be successfully executed.

Why this answer

Terraform requires the working directory to be initialized with `terraform init` before any plan or apply can be executed. The `init` command downloads the necessary provider plugins and sets up the backend state storage. Without it, Terraform has no knowledge of the providers or state configuration, so it returns an error stating that the working directory is not initialized.

Exam trap

The trap here is that candidates may assume Terraform is self-sufficient and will auto-initialize, or confuse `validate` with `init`, not realizing that provider plugins and backend state are prerequisites for any execution.

How to eliminate wrong answers

Option A is wrong because `terraform validate` only checks syntax and internal consistency of the configuration, but does not download providers or initialize the backend; without `init`, apply will fail. Option B is wrong because Terraform does not automatically run `init` before `apply`; the user must explicitly run `init` first. Option C is wrong because Terraform does not prompt to run `init` and then continue; it simply returns an error and stops.

Practice this question →

49

MCQhard

Which Terraform feature helps manage dependencies between resources?

A.data source

B.output

C.depends_on

D.provisioner

AnswerC

The `depends_on` meta-argument is Terraform's explicit mechanism for defining a direct dependency between resources that cannot be inferred automatically through attribute references. When Terraform's implicit dependency graph, built by referencing resource attributes, is insufficient to ensure a specific creation, update, or destruction order, `depends_on` forces one resource to be fully created or updated before another resource begins its lifecycle operations. This ensures proper sequencing for complex or non-obvious inter-resource relationships.

Why this answer

The depends_on meta-argument in Terraform explicitly defines dependencies between resources, ensuring that one resource is created only after another. This is useful when Terraform cannot infer the dependency from expressions.

Exam trap

TF-004 often tests the misconception that data sources or outputs manage dependencies, when only depends_on explicitly does so.

How to eliminate wrong answers

Option A is wrong because data sources fetch information but do not manage dependencies. Option B is wrong because outputs expose values but do not control creation order. Option D is wrong because provisioners execute scripts on resources but do not establish dependencies between resources.

Practice this question →

50

MCQmedium

A company wants to manage its infrastructure as code using Terraform. The team has a mix of on-premises servers and cloud resources in AWS and Azure. Which of the following best describes Terraform's purpose in this scenario?

A.Terraform is a configuration management tool for installing software on existing servers.

B.Terraform is a cloud-specific orchestration tool that only works with AWS.

C.Terraform is a monitoring and logging tool for cloud resources.

D.Terraform is an infrastructure-as-code tool for provisioning and managing any infrastructure across multiple providers.

AnswerD

This statement accurately describes Terraform's fundamental purpose. As an infrastructure-as-code tool, Terraform enables users to define infrastructure declaratively using HCL, allowing for version-controlled, repeatable, and automated provisioning and management of resources. Its robust provider framework supports a vast array of platforms, including major cloud providers, on-premises virtualization, and SaaS applications, facilitating consistent infrastructure deployment across diverse environments.

Why this answer

Terraform is explicitly designed as an infrastructure-as-code tool that uses declarative configuration files to provision and manage resources across multiple providers, including on-premises servers (via providers like vSphere or Hyper-V) and cloud platforms like AWS and Azure. Its provider model allows it to abstract away the underlying APIs, making it provider-agnostic and suitable for hybrid environments.

Exam trap

HashiCorp often tests the misconception that Terraform is a configuration management tool (like Ansible) or that it is limited to a single cloud provider, so candidates must remember that Terraform is a provisioning tool for infrastructure resources across multiple providers, not for software configuration or monitoring.

How to eliminate wrong answers

Option A is wrong because Terraform is not a configuration management tool like Ansible, Puppet, or Chef; it does not install software or manage state on existing servers—it provisions infrastructure resources. Option B is wrong because Terraform is not cloud-specific; it supports over 100 providers, including AWS, Azure, GCP, and on-premises solutions, through its plugin-based architecture. Option C is wrong because Terraform does not perform monitoring or logging; tools like CloudWatch, Azure Monitor, or Prometheus handle those tasks, while Terraform focuses on the lifecycle (create, read, update, delete) of infrastructure resources.

Practice this question →

51

MCQeasy

A junior DevOps engineer is learning about Infrastructure as Code (IaC) and asks why Terraform is preferred over manual configuration in cloud consoles. Which of the following is the primary benefit of using Terraform for infrastructure management?

A.It can only manage infrastructure on major cloud providers like AWS, Azure, and GCP.

B.It automatically rolls back any failed infrastructure changes.

C.It enables version-controlled, repeatable, and automated infrastructure provisioning.

D.It uses an imperative approach where you specify exact commands to execute.

AnswerC

Infrastructure as Code (IaC), as implemented by Terraform, fundamentally enables treating infrastructure configurations like application code. This allows for storing configurations in version control systems (e.g., Git), facilitating change tracking, collaboration, and peer review. The codified nature ensures that infrastructure deployments are repeatable, consistent, and can be fully automated through CI/CD pipelines, significantly reducing manual errors and operational overhead.

Why this answer

Terraform's core value proposition is enabling infrastructure as code (IaC), which allows teams to define infrastructure in declarative configuration files, version control them with Git, and provision consistently across environments. This repeatability and automation eliminate the drift and manual errors inherent in clicking through cloud consoles, making infrastructure management auditable, collaborative, and scalable.

Exam trap

The trap here is that candidates confuse declarative (Terraform) with imperative (e.g., Ansible or shell scripts) approaches, or assume Terraform's state management includes automatic rollback, when in fact it only provides a plan and requires explicit user action to revert changes.

How to eliminate wrong answers

Option A is wrong because Terraform is not limited to major cloud providers; it uses a plugin-based provider architecture that supports hundreds of providers, including on-premises solutions like VMware, OpenStack, and custom APIs via the Terraform Provider SDK. Option B is wrong because Terraform does not automatically roll back failed changes; it creates a state file to track resources and can detect drift, but rollbacks require manual intervention or a separate 'terraform destroy' and re-apply of a previous configuration. Option D is wrong because Terraform uses a declarative approach, not imperative; you define the desired end state in HCL (HashiCorp Configuration Language), and Terraform determines the necessary actions to reach that state, unlike imperative tools that require step-by-step commands.

Practice this question →

52

Multi-Selecteasy

A small company with no cloud automation today wants to understand what adopting Terraform would give them beyond simply storing infrastructure definitions in Git. Which two outcomes does Terraform's core workflow provide? (Choose two.)

Select 2 answers

A.Continuous runtime monitoring with alerting when application latency exceeds a threshold.

B.Automatic remediation of misconfigured operating system settings inside running virtual machines.

C.A preview of proposed changes before any are applied, so reviewers can approve or reject them.

D.Guaranteed zero-downtime deployments for every resource type without any configuration effort.

E.A recorded mapping of configuration to real resources that lets later runs detect drift and target updates.

AnswersC, E

The core workflow includes terraform plan, which compares configuration and state and shows the actions that would be taken without changing real infrastructure. This preview supports peer review and change approval, which is a concrete benefit beyond merely keeping definitions in version control, since Git alone cannot show what an apply would do.

Why this answer

Terraform's core workflow is write, plan, and apply, backed by state. The plan step gives a reviewable preview of pending changes, and state maps configuration to real resources so subsequent runs can detect drift and compute targeted updates. In-guest OS remediation, application monitoring, and universal zero-downtime guarantees fall outside the provisioning workflow and are handled by other tooling or by explicit design choices.

Exam trap

The trap here is conflating Terraform's provisioning scope with configuration management and monitoring duties that other tools own.

Practice this question →

53

MCQhard

A DevOps engineer runs terraform plan and sees that a resource will be destroyed and recreated, but they expected an in-place update. The resource is an AWS EC2 instance with a specific AMI. Which attribute change is most likely causing the destruction?

A.The AMI ID was changed.

B.The security group list was modified.

C.The tags were updated.

D.The instance type was reduced from large to micro.

AnswerA

Changing the Amazon Machine Image (AMI) ID for an EC2 instance resource in Terraform necessitates a full replacement of the instance. This is because the AMI defines the operating system and initial software configuration of the instance's root volume at launch time. Since the root volume is intrinsically tied to the AMI used for its creation, an update to the AMI ID cannot be applied in-place to an already running instance, thus forcing Terraform to destroy the old instance and create a new one.

Why this answer

Changing the AMI ID of an AWS EC2 instance is a force-new attribute in Terraform. Because the AMI defines the root block device and operating system, Terraform cannot perform an in-place update; it must destroy the existing instance and create a new one with the new AMI. This behavior is hardcoded in the Terraform AWS provider for the `aws_instance` resource.

Exam trap

A common misconception is that any attribute change requiring a stop/start (like instance type) results in destroy-and-recreate, but in Terraform, stop/start is still an in-place update unless the attribute is explicitly marked `ForceNew`.

How to eliminate wrong answers

Option B is wrong because modifying the security group list triggers a `ModifyInstanceAttribute` API call, which is an in-place update, not a destroy-and-recreate. Option C is wrong because updating tags uses the `CreateTags` API and is always an in-place operation. Option D is wrong because changing the instance type (e.g., from large to micro) triggers a `StopInstances`, `ModifyInstanceAttribute` (instance type), and `StartInstances` sequence, which is an in-place update (though it requires a stop/start cycle) and does not cause destruction.

Practice this question →

54

MCQmedium

Refer to the exhibit. What does this output indicate?

A.A resource will be modified

B.A resource will be destroyed

C.No changes

D.A resource will be created

AnswerA

The Terraform plan output explicitly states "1 to change," which directly signifies that one existing infrastructure resource, previously managed by Terraform, has detected a configuration drift or an intentional update in the Terraform configuration. This indicates that Terraform will perform an in-place modification of that resource, altering one or more of its attributes without recreating it entirely. This action ensures the resource's state aligns with the desired configuration defined in the current Terraform code.

Why this answer

The output shows a Terraform plan with a tilde (~) prefix next to a resource attribute, which indicates an in-place update. This means Terraform will modify the existing resource without destroying and recreating it, confirming that option A is correct.

Exam trap

The Terraform plan output uses a tilde (~) to indicate an in-place update, meaning the resource will be modified without destruction and recreation. This is commonly confused with the plus (+) for creation or minus (-) for destruction.

How to eliminate wrong answers

Option B is wrong because a tilde (~) indicates modification, not destruction; destruction is shown with a minus (-) sign. Option C is wrong because the presence of a tilde (~) means changes are detected, so 'No changes' is incorrect. Option D is wrong because creation is indicated by a plus (+) sign, not a tilde (~).

Practice this question →

55

MCQmedium

A platform team currently provisions servers by filing tickets that an operations group fulfills manually over several days. Leadership wants developers to describe the desired end state of that infrastructure in version-controlled files so the tooling itself figures out which resources to create, modify, or remove. Which characteristic of Terraform directly supports this goal?

A.Terraform is declarative, so you define the desired end state and it computes the actions needed to reach it.

B.Terraform stores credentials in the configuration so provisioning runs unattended.

C.Terraform applies changes through a configuration management agent installed on each managed host.

D.Terraform is procedural, so engineers write ordered scripts that call each provider API in sequence.

AnswerA

Terraform's declarative model means configuration expresses the intended end state rather than the sequence of API calls, and the core engine builds a dependency graph and diffs current state against desired state to decide what to create, update, or destroy. That is exactly what removes the manual ticket-driven step-by-step provisioning described here.

Why this answer

The team needs files that describe the intended end state of infrastructure rather than a manual sequence of provisioning steps. A declarative configuration language fits that need because Terraform compares desired state with recorded state, builds a dependency graph, and produces an execution plan of create, update, and destroy actions. Procedural scripting, embedded credentials, and host-installed agents do not deliver that outcome.

Exam trap

The trap here is assuming Terraform executes configuration top-to-bottom like a script, when ordering actually comes from the dependency graph derived from references.

Practice this question →

56

Multi-Selectmedium

Which THREE are part of Terraform's core workflow? (Choose three.)

Select 3 answers

A.Apply

B.Import

C.Plan

D.Destroy

E.Write

AnswersA, C, E

The "Apply" step, executed via `terraform apply`, is the critical phase where Terraform takes the execution plan generated during the `plan` step and provisions, updates, or deletes real infrastructure resources in the target cloud or on-premises environment. It prompts for user confirmation by default, ensuring that the proposed changes are reviewed before any actual modifications are made to the infrastructure. This action directly reconciles the desired state defined in configuration with the actual infrastructure, updating the Terraform state file upon successful completion.

Why this answer

Terraform's documented core workflow consists of three steps: Write, Plan, and Apply. Option E (Write) is correct because it is the first phase, where you author infrastructure as code in HashiCorp Configuration Language (HCL) in .tf files. Option C (Plan) is correct because it is the second phase, where `terraform plan` produces an execution plan showing the actions Terraform will take to reach the desired state.

Option A (Apply) is correct because it is the third phase, where `terraform apply` executes the planned changes to provision or modify real infrastructure. Option B (Import) is not part of the core workflow; `terraform import` is a supplementary command used to bring existing resources under Terraform management. Option D (Destroy) is not one of the three core workflow phases either; `terraform destroy` is a convenience command that applies a plan to remove all managed infrastructure, but it is not counted among Write, Plan, and Apply.

Exam trap

The exam often tests the distinction between the core workflow (write, plan, apply) and auxiliary commands like import or destroy, so the trap is that candidates may incorrectly include import or destroy as part of the core workflow because they are common Terraform operations.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Understand Terraform's purpose questions.

Start 20-question session