Courseiva

CCNA Iac Concepts Questions

45 questions · Iac Concepts topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
Multi-Selecthard

Which two statements accurately describe the difference between declarative and imperative IaC approaches? (Choose two.)

Select 2 answers
A.Imperative is only used for scripting, not IaC
B.Declarative tools are always faster than imperative tools
C.Declarative focuses on the desired outcome, while imperative specifies step-by-step commands
D.Imperative can lead to configuration drift because steps may cause unintended states
E.Declarative eliminates the need for idempotency
AnswersC, D

This is the fundamental difference.

Why this answer

Declarative IaC, as used in Terraform with HCL, allows you to define the desired end state of infrastructure (e.g., 'I want an AWS EC2 instance with AMI ami-0c55b159cbfafe1f0 and instance type t2.micro'), and the tool automatically determines the necessary steps to achieve that state. In contrast, imperative IaC, such as using AWS CLI commands or Ansible playbooks with explicit 'command' modules, requires you to specify each step (e.g., 'run aws ec2 run-instances, then wait, then tag'). This fundamental difference in approach is a core concept in the TF-003 exam.

Exam trap

HashiCorp often tests the misconception that declarative IaC eliminates the need for idempotency, but in reality, declarative tools enforce idempotency through state management and plan generation, making it a key feature rather than an omission.

Practice this question →
2
Matchingmedium

Match each Terraform command to its primary function.

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

Concepts
Matches

Initialize a working directory with provider plugins

Create an execution plan

Execute the actions proposed in a plan

Destroy previously-created infrastructure

Check configuration for syntax and internal consistency

Why these pairings

The correct matches are: init initializes the workspace, plan creates an execution plan, apply executes changes, destroy tears down resources. Common mistakes include confusing init with apply or plan with destroy.

Practice this question →
3
Multi-Selecteasy

Which two are benefits of using Infrastructure as Code? (Choose two.)

Select 2 answers
A.Guaranteed cost optimization
B.Removes need for cloud providers
C.Reproducible environments
D.Automated documentation
E.Elimination of all manual errors
AnswersC, D

Infrastructure as Code (IaC) ensures highly reproducible environments by defining infrastructure configurations in declarative code, which can be version-controlled and applied consistently across different stages. This means that development, testing, and production environments can be provisioned with identical resource specifications, reducing "it works on my machine" issues and ensuring predictable behavior. The ability to recreate an entire infrastructure stack from a known state is a core benefit, facilitating disaster recovery and consistent deployments.

Why this answer

Reproducible environments (C) are a key benefit because IaC allows you to consistently provision identical infrastructure from the same configuration, eliminating environment drift. Automated documentation (D) is another benefit because IaC code serves as a living, version-controlled description of your infrastructure. A is false: IaC does not guarantee cost optimization; costs depend on resource usage, not just code.

B is false: IaC does not remove the need for cloud providers; it relies on them. E is false: while IaC reduces manual errors, it does not eliminate all of them (e.g., logic errors in code).

Practice this question →
4
MCQhard

An organization manages multiple environments (dev, staging, prod) using Terraform. They want to minimize code duplication while allowing environment-specific variable values. Which approach best achieves this goal?

A.Use a separate Git branch for each environment, each with its own Terraform configuration.
B.Write a single Terraform configuration that uses count and conditional expressions to create resources based on environment variable.
C.Use Terraform workspaces with a single configuration and define all variable values in one .tfvars file.
D.Organize the repository with a shared modules directory and separate subdirectories for each environment that call the same modules with environment-specific .tfvars files.
AnswerD

Organizing the repository with a shared modules directory and separate subdirectories for each environment is a best practice that maximizes code reuse and maintains clear separation of concerns. Common infrastructure patterns are encapsulated in reusable modules, while each environment's subdirectory instantiates these modules using its own dedicated `.tfvars` files. This structure ensures consistency, simplifies environment-specific parameter management, and enhances overall maintainability and scalability.

Why this answer

It leverages Terraform's module system to define reusable infrastructure components in a shared directory, while each environment (dev, staging, prod) has its own subdirectory with a root configuration that calls those modules and passes environment-specific `.tfvars` files. This minimizes code duplication by keeping the module logic in one place, and allows per-environment variable values without mixing concerns. It follows the recommended pattern for multi-environment management in Terraform, avoiding the pitfalls of branches, workspaces, or conditional logic that can lead to complexity or state corruption.

Exam trap

HashiCorp often tests the misconception that Terraform workspaces are the correct way to manage multiple long-lived environments, but workspaces are actually designed for short-lived or temporary infrastructure, not for permanent dev/staging/prod separation, because they share the same backend configuration and can lead to accidental state corruption if not carefully isolated.

How to eliminate wrong answers

Option A is wrong because using separate Git branches for each environment leads to configuration drift, merge conflicts, and makes it difficult to promote changes consistently across environments; Terraform state is not designed to be managed across branches. Option B is wrong because using `count` and conditional expressions within a single configuration to create resources based on an environment variable results in a monolithic state file, making it hard to apply changes to one environment without affecting others, and it violates the principle of separating environments for safety and isolation. Option C is wrong because Terraform workspaces share the same configuration and backend, but defining all variable values in one `.tfvars` file forces all workspaces to use the same variable file, which defeats the purpose of environment-specific values; workspaces are better suited for temporary or testing scenarios, not for managing distinct environments like dev, staging, and prod with different variable sets.

Practice this question →
5
MCQmedium

A team uses Terraform to manage multiple AWS EC2 instances with a 'count' meta-argument. They need to reference the ID of the third instance in another resource's configuration. Which expression should they use?

A.aws_instance.example[1].id
B.aws_instance.example[2].id
C.element(aws_instance.example.*.id, 3)
D.aws_instance.example[3].id
AnswerB

This expression correctly references the ID of the third EC2 instance in a collection named `aws_instance.example`. Terraform consistently uses zero-based indexing for lists and resource collections created with `count`. Consequently, an index of `2` precisely targets the third element in the sequence, making `aws_instance.example[2].id` the correct way to retrieve its unique identifier.

Why this answer

In Terraform, the 'count' meta-argument creates a list of resources indexed starting from 0. To reference the third instance, you use index 2 (0, 1, 2). Option B correctly uses `aws_instance.example[2].id` to access the ID of the third EC2 instance.

Exam trap

The trap here is that candidates often forget Terraform uses zero-based indexing and mistakenly pick option D (index 3) or option A (index 1), confusing the ordinal position with the index number.

How to eliminate wrong answers

Option A is wrong because `aws_instance.example[1].id` references the second instance (index 1), not the third. Option C is wrong because `element(aws_instance.example.*.id, 3)` uses the splat expression with `element()` and index 3, which would attempt to access the fourth element (index 3), not the third; also, the splat expression returns a list, but the correct index for the third instance is 2. Option D is wrong because `aws_instance.example[3].id` uses index 3, which references the fourth instance, not the third.

Practice this question →
6
MCQmedium

A company is managing multiple cloud environments (dev, test, prod) using Terraform. They want to ensure consistent configurations across environments while allowing environment-specific values. Which IaC practice best supports this?

A.Using data sources only
B.Hardcoding values
C.Duplicating configuration files
D.Using variables and workspaces
AnswerD

Using variables allows the Terraform configuration to be parameterized, enabling different values (e.g., resource sizes, region names, environment tags) to be supplied dynamically for distinct environments without altering the core .tf files. Concurrently, Terraform workspaces provide isolated state files for each environment (e.g., dev, test), allowing a single, consistent configuration to manage multiple independent deployments. This powerful combination ensures flexibility, prevents state file conflicts, and maintains consistency across all environments from a unified codebase.

Why this answer

Using variables and workspaces allows you to define a single set of Terraform configurations while dynamically injecting environment-specific values via variable definitions (e.g., terraform.tfvars or -var-file) and isolating state per environment using workspaces (terraform workspace). This avoids duplication and ensures consistent resource definitions across dev, test, and prod, with only the variable values differing.

Exam trap

Candidates often think data sources can replace variables for environment separation, but data sources only read existing infrastructure and cannot define or override configuration values. Workspaces and variables are required to manage environment-specific settings without duplicating code.

How to eliminate wrong answers

Option A is wrong because data sources are used to fetch or compute information from providers or existing infrastructure, not to manage environment-specific configuration values or state isolation. Option B is wrong because hardcoding values directly in configuration files eliminates reusability and forces manual changes per environment, violating IaC principles of consistency and automation. Option C is wrong because duplicating configuration files for each environment leads to configuration drift, increased maintenance overhead, and violates the DRY (Don't Repeat Yourself) principle central to Terraform best practices.

Practice this question →
7
MCQmedium

Refer to the exhibit. A team is using this S3 backend configuration. During a deployment, they receive an error that the state file is locked. What is the most likely cause?

A.The S3 bucket does not exist
B.The region is incorrect
C.The DynamoDB table is not provisioned or the IAM role lacks permissions
D.The key path is incorrect
AnswerC

Terraform's S3 backend leverages an Amazon DynamoDB table for robust state locking to prevent concurrent state modifications. If the specified DynamoDB table does not exist, or if the IAM role used by Terraform lacks the necessary `dynamodb:PutItem`, `dynamodb:GetItem`, and `dynamodb:DeleteItem` permissions, Terraform will be unable to acquire or release the state lock. This directly manifests as a "Failed to get lock" or "Error acquiring the state lock" message, as the mechanism designed to prevent race conditions is non-functional.

Why this answer

The error message 'state file is locked' directly indicates that Terraform is attempting to acquire a lock on the state using DynamoDB, but the lock table either does not exist or the IAM role used by Terraform lacks the required permissions (dynamodb:PutItem, dynamodb:GetItem, dynamodb:DeleteItem, dynamodb:DescribeTable). Without a properly provisioned DynamoDB table or sufficient IAM permissions, the locking mechanism fails, producing this specific error.

Exam trap

HashiCorp often tests the distinction between S3 access errors and DynamoDB lock errors, so candidates mistakenly attribute the lock error to S3 bucket issues (like missing bucket or wrong region) rather than recognizing it as a DynamoDB-specific failure.

How to eliminate wrong answers

Option A is wrong because if the S3 bucket did not exist, Terraform would return an error such as 'bucket does not exist' or 'NoSuchBucket', not a state lock error. Option B is wrong because an incorrect region would cause an 'InvalidAccessKeyId' or 'region not found' error when trying to access S3, not a lock-related error. Option D is wrong because an incorrect key path would result in a 'NoSuchKey' error when trying to read the state file, not a lock contention issue.

Practice this question →
8
MCQhard

After applying the configuration above, the user changes the AMI to a new value and runs 'terraform apply'. Assuming the new AMI triggers a recreate, what happens during the apply?

A.The existing instance is deleted before the new one is created.
B.Both instances run simultaneously only if the instance type allows it.
C.The new instance is created first, then the old one is deleted.
D.The plan fails because AMI change with create_before_destroy is not allowed.
AnswerA

This statement is correct. When an immutable attribute, such as the Amazon Machine Image (AMI) for an EC2 instance, is modified in the Terraform configuration, Terraform's default behavior is to destroy the existing resource before creating its replacement. This 'destroy-then-create' sequence is the standard approach for resource recreation unless explicitly overridden by `lifecycle` settings. This ensures resource consistency but typically results in a period of downtime for the affected service.

Why this answer

Terraform's default lifecycle for resource replacement is to destroy the existing resource first, then create the new one. This is the standard behavior unless `create_before_destroy` is explicitly set to `true`. The AMI change triggers a recreate, and by default, the old instance is deleted before the new one is provisioned.

Exam trap

A common trap is assuming that Terraform defaults to create-before-destroy to minimize downtime. In reality, the default is destroy-before-create; you must explicitly set `create_before_destroy = true` to change this behavior.

How to eliminate wrong answers

Option A is wrong because Terraform does not delete the existing instance before creating the new one when a recreate is triggered; it creates the new instance first to avoid downtime, unless 'create_before_destroy' is explicitly set to false or the resource type defaults to destroy-before-create. Option B is wrong because both instances running simultaneously is not dependent on the instance type; it is a result of Terraform's default 'create_before_destroy' behavior for resources that support replacement, and the instance type does not control this lifecycle ordering. Option D is wrong because an AMI change with 'create_before_destroy' is fully allowed and is a common scenario; Terraform supports this lifecycle configuration and will plan the creation of the new instance before destroying the old one.

Practice this question →
9
MCQeasy

Which statement best describes 'immutable infrastructure' in the context of IaC?

A.Configuration is changed via patches and updates
B.Servers are never modified after deployment; new ones are created for updates
C.Resources are shared across environments
D.Infrastructure is version-controlled
AnswerB

This statement accurately defines immutable infrastructure, a paradigm where once a server or resource is deployed, it is never modified. Any required changes, such as software updates, configuration adjustments, or security patches, necessitate the creation and deployment of an entirely new server instance with the desired modifications. The old instance is then decommissioned, ensuring consistency and preventing configuration drift across the infrastructure.

Why this answer

Immutable infrastructure means that servers are never modified after deployment; instead, new servers are created for any updates or changes. Option B correctly states this. Option A describes mutable infrastructure where configuration is changed via patches.

Option C is about resource sharing, not immutable infrastructure. Option D is about version control, which is a separate IaC practice.

Practice this question →
10
MCQhard

Refer to the exhibit. After applying this configuration, a team member manually changes the instance type to 't2.small' via the AWS console. The next `terraform plan` shows a change to revert to 't2.micro'. What does this demonstrate?

A.Terraform's drift detection only
B.Immutable infrastructure pattern
C.Terraform's desired state reconciliation
D.A misconfiguration in the Terraform code
AnswerC

Terraform operates on the principle of desired state configuration, where the HCL code defines the intended end-state of the infrastructure. When a manual modification introduces drift, Terraform's `plan` command identifies this deviation by comparing the actual infrastructure with the declared configuration. It then generates a plan to reconcile these differences, proposing actions to bring the actual state back into alignment with the desired state defined in the configuration.

Why this answer

Terraform operates on a desired state model: the configuration file defines the target state (t2.micro), and `terraform plan` detects that the actual state (t2.small) has diverged from it. The plan proposes to revert the instance type to t2.micro, demonstrating Terraform's reconciliation of the actual infrastructure back to the declared desired state. This is not merely drift detection (which only reports differences) but active enforcement of the desired configuration.

Exam trap

The Terraform exam often tests the distinction between drift detection (passive observation) and desired state reconciliation (active correction). The trap here is that candidates confuse the two, thinking Terraform only reports drift when it actually plans to enforce the declared state.

How to eliminate wrong answers

Option A is wrong because drift detection only identifies differences between actual and desired state without automatically planning to revert changes; Terraform's plan to revert shows reconciliation, not just detection. Option B is wrong because immutable infrastructure pattern involves replacing resources entirely (e.g., creating a new instance) rather than modifying an existing one, whereas here Terraform plans an in-place change to the instance type. Option D is wrong because the configuration is correct; the manual change via the console is an out-of-band modification that Terraform is designed to correct, not a misconfiguration in the code.

Practice this question →
11
MCQmedium

A development team is using a declarative IaC tool. They make a change to the configuration file to add a new security group rule. When they apply the configuration, the tool automatically modifies the existing security group to add the rule. What is this behavior called?

A.Desired state reconciliation
B.Provisioning
C.Imperative execution
D.Resource drift
AnswerA

Declarative IaC tools continuously perform desired state reconciliation by comparing the current actual infrastructure state with the configuration defined as the desired state. This process automatically identifies any discrepancies and applies the necessary changes, such as creating, updating, or deleting resources, to bring the infrastructure into full alignment. This ensures that the deployed environment consistently matches the specified blueprint, automating infrastructure management and preventing configuration drift.

Why this answer

This behavior is called desired state reconciliation because declarative IaC tools like Terraform or AWS CloudFormation compare the current state of infrastructure against the desired state defined in the configuration file. When a new security group rule is added to the configuration, the tool automatically computes the necessary changes to reconcile the actual state with the desired state, creating, updating, or deleting resources as needed. This is a core principle of declarative IaC, where the user specifies the 'what' and the tool handles the 'how'.

Exam trap

The trap here is that candidates confuse the automatic correction of drift with the initial provisioning process, or they mistakenly think that any automated change is 'imperative execution' rather than recognizing the declarative reconciliation loop.

How to eliminate wrong answers

Option B is wrong because provisioning refers to the initial creation and setup of infrastructure resources, not the ongoing process of modifying existing resources to match a desired configuration. Option C is wrong because imperative execution involves explicitly scripting each step (e.g., using AWS CLI commands to add a rule), whereas the question describes a declarative tool that automatically determines the actions. Option D is wrong because resource drift is a condition where the actual state of infrastructure diverges from the desired state over time, not the automatic correction of that divergence through reconciliation.

Practice this question →
12
MCQhard

An organization is evaluating IaC tools and wants to minimize configuration drift. Which characteristic of a declarative IaC approach is most effective in preventing drift?

A.Periodic state comparison and correction
B.Manual approval gates
C.Tagging resources
D.Using modules
AnswerA

Periodic state comparison and correction is the core mechanism by which declarative Infrastructure as Code tools like Terraform prevent configuration drift. Terraform maintains a desired state in its configuration files and a record of the actual infrastructure state in its state file. During a `terraform plan` operation, it compares these two states, identifying any discrepancies, and then `terraform apply` can be used to reconcile the actual infrastructure with the desired configuration, effectively correcting any drift.

Why this answer

A declarative IaC approach defines the desired end state of infrastructure, and tools like Terraform use periodic state comparison (e.g., `terraform plan` and `terraform apply`) to detect and correct any configuration drift. This automated reconciliation ensures the actual infrastructure matches the declared configuration, directly preventing drift without manual intervention.

Exam trap

HashiCorp often tests the misconception that drift prevention is achieved through code organization (modules) or operational controls (approvals), rather than the core declarative mechanism of automated state comparison and correction.

How to eliminate wrong answers

Option B is wrong because manual approval gates (e.g., in CI/CD pipelines) enforce process control but do not automatically detect or correct drift in the deployed infrastructure. Option C is wrong because tagging resources is a metadata labeling practice that aids in resource identification and cost allocation, not a mechanism for drift detection or correction. Option D is wrong because using modules promotes code reuse and consistency but does not inherently perform state comparison or auto-remediation against drift.

Practice this question →
13
Multi-Selecteasy

Which two commands are part of the standard Terraform workflow for provisioning infrastructure?

Select 2 answers
A.terraform init
B.terraform fmt
C.terraform apply
D.terraform import
E.terraform taint
AnswersA, C

The `terraform init` command is an indispensable first step in the standard Terraform workflow, executed whenever a new or existing configuration is started or updated. It performs crucial setup tasks, including downloading and installing the necessary provider plugins, initializing the configured backend for state management, and preparing any modules referenced in the configuration. Without successfully running `init`, Terraform cannot properly interact with the configuration files or the remote infrastructure providers.

Why this answer

`terraform init` is correct because it initializes a working directory containing Terraform configuration files, downloading the required providers and modules. `terraform apply` is correct because it executes the actions proposed in a Terraform plan to provision or change infrastructure resources. These two commands form the core of the standard workflow: initialize, plan, and apply.

Exam trap

HashiCorp often tests the distinction between provisioning commands and lifecycle or maintenance commands, so candidates may incorrectly select `terraform taint` or `terraform import` because they associate them with changing infrastructure, even though they do not directly provision new resources.

Practice this question →
14
MCQhard

A Terraform configuration includes a variable for a database password marked as sensitive. When a user runs 'terraform apply', the password appears as (sensitive) in the plan output. However, they want to pass this password to a provisioner as an environment variable. What should they do?

A.Use the variable directly; sensitive only affects CLI output.
B.Use the nonsensitive() function around the variable when assigning.
C.Store the password in a local value with sensitive = false.
D.Remove the sensitive flag from the variable.
AnswerB

The `nonsensitive()` function explicitly marks a sensitive value as non-sensitive for a specific expression or assignment, allowing it to be used in contexts where a sensitive value would otherwise be redacted or cause an error. Crucially, while `nonsensitive()` permits its use in a particular operation or argument, the original variable's value *remains marked sensitive within the Terraform state file*. This ensures the value is only exposed when explicitly intended for processing, maintaining its sensitive status for storage and subsequent operations.

Why this answer

The `nonsensitive()` function explicitly marks a sensitive value as safe to use in contexts where Terraform would otherwise block its usage, such as passing it to a provisioner's environment variable. Even though the variable is marked as sensitive, Terraform still prevents it from being used in certain contexts unless you explicitly override that protection with `nonsensitive()`. This ensures the password is available to the provisioner while still hiding it from CLI output.

Exam trap

The trap here is that candidates assume the sensitive flag only affects CLI output, leading them to choose Option A, but Terraform enforces sensitivity in all contexts unless `nonsensitive()` is used.

How to eliminate wrong answers

Option A is wrong because the sensitive flag does more than affect CLI output; it also prevents the value from being used in places like provisioner environment variables, where Terraform would raise an error. Option C is wrong because local values cannot override the sensitive flag; marking a local value with `sensitive = false` does not bypass the original variable's sensitive constraint. Option D is wrong because removing the sensitive flag would expose the password in all outputs and logs, which defeats the purpose of keeping it secure.

Practice this question →
15
Multi-Selectmedium

Which TWO statements about Infrastructure as Code (IaC) are correct?

Select 2 answers
A.IaC is only applicable to cloud-based infrastructure.
B.IaC eliminates configuration drift entirely.
C.IaC enables automated provisioning and management of infrastructure.
D.IaC allows the same configuration to be applied multiple times with the same result.
E.IaC tools require manual execution of scripts.
AnswersC, D

This statement is correct because a primary advantage of Infrastructure as Code is its ability to automate the entire lifecycle of infrastructure resources, from initial provisioning to ongoing management and eventual deprovisioning. By defining infrastructure in machine-readable files, IaC tools can interpret these definitions and automatically interact with underlying APIs to create, update, and destroy resources without manual intervention. This automation drastically reduces human error and accelerates deployment cycles.

Why this answer

Infrastructure as Code (IaC) automates the provisioning and management of infrastructure through machine-readable definition files, enabling consistent and repeatable deployments without manual intervention. Tools like Terraform use a declarative approach to define resources, and the IaC engine handles creation, modification, and deletion based on the desired state. Option D is correct because IaC configurations are idempotent—applying the same configuration multiple times yields the same result.

This is achieved through state management and drift detection, ensuring that infrastructure remains in the specified state regardless of how many times the configuration is applied.

Exam trap

HashiCorp often tests the misconception that IaC eliminates drift entirely, when in reality it only detects and corrects drift through reconciliation, and candidates may also incorrectly assume IaC is cloud-only, missing its applicability to on-premises and hybrid environments.

Practice this question →
16
MCQmedium

A company has a Terraform module that creates an AWS VPC with subnets. They want to reuse this module across multiple AWS accounts. What is the best practice for referencing the module from different root configurations?

A.Store the module in a shared S3 bucket and reference it with the module source.
B.Use a module registry and specify a version constraint.
C.Use a data source to fetch the module's output from another state.
D.Copy the module code into each root configuration's directory.
AnswerB

A module registry, such as the public Terraform Registry or a private registry in Terraform Cloud/Enterprise, provides a centralized, discoverable, and version-controlled repository for sharing modules. Specifying a version constraint (e.g., `~> 1.0.0`) ensures that consumers utilize a compatible module version, enabling controlled updates and preventing unintended breaking changes. This approach significantly promotes reusability, consistency, and efficient collaboration across an organization's Terraform configurations.

Why this answer

Using a module registry with a version constraint is the best practice for reusing Terraform modules across multiple AWS accounts. It provides a centralized, version-controlled source that can be referenced by any root configuration via a simple source address (e.g., `registry.terraform.io/org/module/aws`), ensuring consistency and enabling safe upgrades through semantic versioning. This approach avoids duplicating code and leverages Terraform's built-in dependency resolution and caching mechanisms.

Exam trap

Candidates may think that using a remote source like S3 or Git is just as good as the HashiCorp Terraform Registry. However, the registry provides built-in version resolution, centralized management, and is the recommended best practice for sharing modules across multiple root configurations and accounts.

How to eliminate wrong answers

Option A is wrong because storing a module in an S3 bucket and referencing it with `source = "s3::https://bucket/path"` works for sharing, but it lacks built-in versioning and dependency resolution; you must manually manage versions via object keys or separate buckets, making it less robust than a registry. Option C is wrong because using a `data` source to fetch a module's output from another state file (e.g., `terraform_remote_state`) reads outputs from an existing deployment, not the module code itself, so it cannot be used to reuse the module definition across root configurations. Option D is wrong because copying the module code into each root configuration's directory violates DRY principles, creates maintenance overhead, and makes it difficult to propagate updates or enforce consistent versions across accounts.

Practice this question →
17
MCQmedium

A team uses Terraform to manage AWS resources. After a manual change to an S3 bucket policy through the AWS console, Terraform's next plan shows that it will revert the policy to the configuration. This is an example of which concept?

A.Configuration drift and correction
B.Immutable infrastructure
C.Resource tagging
D.Imperative provisioning
AnswerA

When a team manually alters an AWS resource managed by Terraform, it creates "configuration drift" where the actual infrastructure deviates from the defined desired state in the Terraform configuration. Terraform detects this discrepancy during a `terraform plan` operation by comparing the current state file with the live infrastructure and the configuration files. The proposed plan to revert the manual change back to the configuration's desired state exemplifies the "correction" mechanism, ensuring infrastructure consistency.

Why this answer

This scenario describes configuration drift, where a manual change to an S3 bucket policy via the AWS console creates a difference between the actual state of the resource and the desired state defined in Terraform code. Terraform's next plan detects this drift and will revert the policy to match the configuration, demonstrating its correction mechanism. This is a core principle of declarative IaC tools like Terraform, which enforce the desired state and automatically remediate any out-of-band changes.

Exam trap

Terraform certification exams often test the distinction between configuration drift correction and immutable infrastructure. Candidates may mistakenly think any automated change implies immutability, but drift correction modifies existing resources rather than replacing them.

How to eliminate wrong answers

Option B is wrong because immutable infrastructure refers to replacing resources entirely rather than modifying them in place, whereas Terraform here is reverting a policy change on an existing S3 bucket, not replacing the bucket. Option C is wrong because resource tagging is a metadata practice for organizing and labeling resources, not a mechanism for detecting or correcting state mismatches. Option D is wrong because imperative provisioning involves step-by-step commands to achieve a desired state, while Terraform uses a declarative approach where the configuration defines the end state and the tool handles the steps to reach it.

Practice this question →
18
MCQhard

An organization uses Terraform Cloud with VCS-driven runs. They have two workspaces: network and application. They want a new run in the application workspace to automatically trigger whenever the network workspace completes a successful plan. What should they configure?

A.Run triggers in the application workspace pointing to the network workspace.
B.A webhook from Terraform Cloud to an external CI system.
C.Use 'terraform apply' with '-target' to simulate dependency.
D.Run triggers in the network workspace pointing to the application workspace.
AnswerA

Run triggers are configured in the *downstream* workspace to monitor an *upstream* workspace. Therefore, for the application workspace to depend on the network workspace, the application workspace (downstream) must have a run trigger configured to watch the network workspace (upstream). When the network workspace successfully completes a `terraform apply`, it will automatically queue a run in the application workspace, ensuring proper dependency ordering and resource availability in a VCS-driven Terraform Cloud environment.

Why this answer

Run triggers in Terraform Cloud allow one workspace to automatically queue a run in another workspace after a successful plan. By configuring a run trigger in the application workspace that points to the network workspace, any successful plan in the network workspace will automatically initiate a new run in the application workspace, satisfying the requirement without external tools or manual steps.

Exam trap

The trap here is that candidates often confuse the direction of run triggers, thinking they should be configured on the upstream workspace (network) pointing to the downstream (application), when in fact they must be set on the downstream workspace (application) pointing to the upstream (network).

How to eliminate wrong answers

Option B is wrong because a webhook to an external CI system introduces unnecessary complexity and external dependencies; Terraform Cloud’s native run triggers provide the same functionality directly. Option C is wrong because 'terraform apply -target' is used to apply only specific resources within a single workspace, not to trigger cross-workspace runs, and it does not automate dependency-based triggering. Option D is wrong because run triggers are configured in the downstream workspace (the one that needs to be triggered), not in the upstream workspace; pointing from network to application would not cause the application workspace to run when network completes.

Practice this question →
19
MCQeasy

A team wants to ensure that their infrastructure configuration repeatedly results in the same environment regardless of the initial state. Which IaC concept is most directly associated with this goal?

A.Version control
B.Idempotency
C.Orchestration
D.Provisioning
AnswerB

Idempotency is a fundamental principle in infrastructure as code (IaC) that ensures applying a configuration or operation multiple times produces the identical result as applying it once. This means if a resource already exists in the desired state, an idempotent operation will make no changes, preventing unintended modifications or errors during repeated deployments. It is essential for reliable automation and recovery.

Why this answer

Idempotency ensures that applying the same configuration multiple times always results in the same desired state, regardless of the starting state. In Terraform, this is achieved by the provider's ability to detect drift and reconcile the real-world infrastructure with the declared configuration in the .tf files. Without idempotency, repeated runs could create duplicate resources or fail to correct unintended changes.

Exam trap

HashiCorp often tests idempotency by contrasting it with version control, where candidates mistakenly think that simply tracking changes in Git ensures repeatable environments, ignoring that idempotency is about the execution behavior, not the history.

How to eliminate wrong answers

Option A is wrong because version control tracks changes to configuration files over time but does not guarantee that applying those files repeatedly yields the same environment; it only provides history and rollback. Option C is wrong because orchestration coordinates the order and execution of multiple automated tasks (e.g., provisioning, configuration) but does not inherently ensure that each individual operation is idempotent. Option D is wrong because provisioning is the act of creating resources (e.g., via Terraform apply) but does not by itself guarantee that subsequent runs will leave the environment unchanged if the initial state differs.

Practice this question →
20
Multi-Selecteasy

Which TWO statements correctly describe Infrastructure as Code principles?

Select 2 answers
A.IaC enables version control of infrastructure configurations.
B.IaC requires manual approval for every infrastructure change.
C.IaC is only applicable to public cloud environments.
D.IaC eliminates the need for configuration management tools.
E.IaC promotes repeatable and consistent deployments.
AnswersA, E

IaC configurations are defined in code, which can be stored in version control systems like Git. This capability allows teams to track every change made to the infrastructure, review modifications before application, and easily revert to previous stable states if issues arise. Version control also facilitates collaborative development, ensuring a clear audit trail and improved operational transparency for infrastructure management.

Why this answer

A and E are correct. A is correct because IaC enables version control of infrastructure configurations using tools like Git, allowing tracking and rollback. E is correct because IaC automates provisioning and configuration, ensuring repeatable and consistent deployments.

B is incorrect because IaC often automates changes without requiring manual approval for every change, though approval workflows can be integrated. C is incorrect because IaC applies to on-premises, hybrid, and multi-cloud environments, not just public cloud. D is incorrect because IaC does not eliminate configuration management tools; they complement each other (e.g., Terraform for provisioning, Ansible for configuration).

Practice this question →
21
MCQeasy

A company uses Terraform to deploy virtual machines. They want to ensure that the same exact operating system and software versions are used every time. Which practice supports this?

A.Manually installing software
B.Using a golden image and referencing it in the configuration
C.Using inline userdata scripts
D.Running configuration management after provisioning
AnswerB

A golden image, pre-configured with all necessary operating system patches, required software, and security hardening, ensures that every virtual machine provisioned from it is identical and compliant from the moment it launches. By referencing this image ID within the Terraform configuration, the deployment becomes highly repeatable, consistent, and significantly faster, as no post-provisioning installation steps are required. This method aligns perfectly with immutable infrastructure principles, drastically reducing configuration drift and simplifying management and troubleshooting.

Why this answer

Using a golden image—a pre-configured virtual machine template containing the exact operating system and software versions—ensures consistency across deployments. Terraform can reference this image via the `source_image` or `image_id` argument in a resource like `azurerm_virtual_machine` or `aws_instance`, guaranteeing that every provisioned VM starts from the same immutable baseline.

Exam trap

HashiCorp often tests the misconception that userdata scripts or configuration management tools can guarantee identical software versions, but the trap is that these methods depend on external sources (repositories, scripts) that can change over time, whereas a golden image captures a fixed, immutable state at build time.

How to eliminate wrong answers

Option A is wrong because manually installing software introduces human error and configuration drift, defeating the goal of repeatable, identical deployments. Option C is wrong because inline userdata scripts (e.g., cloud-init) run at first boot and can install software, but they are prone to failures from network issues, repository changes, or script updates, and do not guarantee the same exact versions every time. Option D is wrong because running configuration management (e.g., Ansible, Chef) after provisioning applies changes to a running system, which can still result in version inconsistencies if the base image or package repositories differ.

Practice this question →
22
Multi-Selecthard

Which three characteristics are associated with immutable infrastructure as practiced by Terraform?

Select 3 answers
A.New versions are deployed by creating new instances
B.Configuration drift is accepted
C.Rollbacks are performed by redeploying a previous version
D.Resources are replaced rather than modified in place
E.In-place updates are preferred
AnswersA, C, D

In immutable infrastructure, deploying a new version involves provisioning entirely new instances from a fresh, updated image or configuration. These new instances replace the old ones, which are then decommissioned, ensuring that every deployment starts from a known, consistent state rather than modifying existing running systems.

Why this answer

Immutable infrastructure in Terraform involves deploying new versions by creating entirely new instances rather than modifying existing ones. This aligns with Terraform's resource lifecycle, where changes to certain attributes trigger destruction and recreation, ensuring a consistent and reproducible state.

Exam trap

The trap here is that candidates confuse immutable infrastructure with mutable patterns, mistakenly thinking that in-place updates or accepting drift are acceptable, when Terraform's immutable model strictly replaces resources to enforce consistency.

Practice this question →
23
Drag & Dropmedium

Drag and drop the steps to initialize a Terraform working directory in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Initialization begins after writing configs; terraform init downloads providers/modules, creates .terraform directory, and validate checks syntax.

Practice this question →
24
MCQeasy

A Terraform user wants to visualize the execution order of resources before applying changes. Which command provides a dependency graph view?

A.terraform graph
B.terraform show
C.terraform plan
D.terraform output
AnswerA

The `terraform graph` command is specifically designed to generate a visual representation of the dependency graph for a Terraform configuration. It processes the configuration files and outputs a graph in the DOT format, which can then be rendered into an image using external tools like Graphviz. This visual output clearly illustrates the relationships and execution order between resources, modules, and providers, making it the ideal tool for visualizing the infrastructure's provisioning flow.

Why this answer

The `terraform graph` command generates a visual representation of the dependency graph for Terraform resources, showing the execution order based on implicit and explicit dependencies. This allows users to see which resources will be created, updated, or destroyed in sequence before applying changes. It outputs DOT format, which can be rendered with tools like Graphviz.

Exam trap

HashiCorp often tests the distinction between commands that show execution plans (`terraform plan`) versus those that visualize the underlying dependency graph (`terraform graph`), leading candidates to mistakenly choose `terraform plan` for graph visualization.

How to eliminate wrong answers

Option B is wrong because `terraform show` displays the current state or a saved plan file, not a dependency graph of execution order. Option C is wrong because `terraform plan` shows the execution plan as a textual diff of changes, not a visual dependency graph. Option D is wrong because `terraform output` retrieves output values from the state, not any graph or execution order visualization.

Practice this question →
25
MCQeasy

A team is evaluating Terraform and Ansible for infrastructure provisioning. They note that Terraform describes the desired end state, while Ansible defines steps to reach that state. This difference is best described as:

A.Declarative vs imperative
B.Client-server vs agentless
C.Immutable vs mutable
D.Push vs pull
AnswerA

Terraform's configuration files are fundamentally declarative, meaning they specify the desired end state of infrastructure resources without detailing the exact procedural steps to achieve it. In contrast, Ansible typically employs an imperative approach, where playbooks define a precise sequence of commands and tasks that must be executed in a specific order to transition the infrastructure to a particular configuration. This distinction in how desired outcomes are expressed is a primary differentiator when evaluating these infrastructure as code tools.

Why this answer

The difference between declarative and imperative paradigms is key: Terraform is declarative (you specify the desired end state, and Terraform figures out how to achieve it), while Ansible is imperative (you specify each step to reach the state). Option B (client-server vs agentless) refers to architecture, option C (immutable vs mutable) refers to update strategies, and option D (push vs pull) refers to deployment methods. Therefore, option A is correct.

Practice this question →
26
MCQmedium

Refer to the exhibit. What will happen when you run terraform plan?

A.The plan will prompt for the name interactively.
B.The plan will succeed and create the IAM user with a generated name.
C.The plan will fail with an error about missing required argument.
D.The plan will create the user with the path only.
AnswerC

Terraform performs rigorous configuration validation during the `plan` phase, checking the provided arguments against the resource's schema defined by its respective provider. For the `aws_iam_user` resource, the `name` attribute is unequivocally marked as required. Therefore, omitting this critical argument will trigger a validation error, causing the `terraform plan` command to fail before any changes can be proposed or applied.

Why this answer

The configuration is missing the required 'name' argument for an IAM user resource. Terraform will fail during the planning phase with an error indicating that the required argument is missing. Option C correctly identifies this error.

Option A is incorrect because Terraform does not prompt for missing required arguments interactively; it fails with an error. Option B is incorrect because the plan cannot succeed without the required 'name' argument. Option D is incorrect because the resource cannot be created without the name; the path alone is insufficient.

Practice this question →
27
MCQhard

A team of five engineers uses Terraform with a remote backend in AWS S3 with DynamoDB state locking. One engineer runs 'terraform apply' but it hangs at 'Acquiring state lock'. What is the most likely cause?

A.Another engineer has an active lock from a previous run that was not released.
B.The S3 bucket policy denies the request.
C.A recent 'terraform init' was run without the proper backend configuration.
D.The DynamoDB table is in a different AWS region.
AnswerA

When Terraform attempts to acquire a state lock, it checks for an existing lock held by another operation on the remote backend. If a lock is found, Terraform will wait for a configurable timeout period, continuously retrying to acquire the lock. This mechanism prevents concurrent state modifications, ensuring state consistency in collaborative environments. An unreleased lock from a previous, possibly failed, run will cause subsequent operations to indefinitely wait or timeout until the lock is manually released or expires.

Why this answer

The most likely cause is that another engineer has an active lock from a previous run that was not released. Terraform uses DynamoDB state locking to prevent concurrent modifications to the state file. When `terraform apply` hangs at 'Acquiring state lock', it indicates that the lock item in the DynamoDB table is still present, meaning a prior operation either crashed, was interrupted, or the lock was not explicitly released via `force-unlock`.

Exam trap

HashiCorp often tests the distinction between a hang (lock contention) and a hard failure (access denied, region mismatch, or backend misconfiguration), so the trap here is that candidates may confuse a permission or configuration error with a lock acquisition timeout.

How to eliminate wrong answers

Option B is wrong because if the S3 bucket policy denied the request, Terraform would fail with an access denied error, not hang indefinitely at the lock acquisition phase. Option C is wrong because a recent `terraform init` without proper backend configuration would cause a backend initialization error or state mismatch, not a hang at the lock step. Option D is wrong because the DynamoDB table being in a different AWS region would cause a connectivity or access error, not a hang; Terraform would fail quickly with a timeout or region mismatch error.

Practice this question →
28
MCQmedium

During development, a Terraform user wants to check that their configuration is syntactically valid and internally consistent before running 'terraform plan'. Which command should they use?

A.terraform init
B.terraform refresh
C.terraform validate
D.terraform fmt
AnswerC

The `terraform validate` command performs a static analysis of the Terraform configuration files in the current directory, checking for syntax errors, argument type mismatches, and internal consistency. It ensures that the configuration is syntactically correct and semantically valid according to Terraform's language rules, without requiring any backend or provider initialization. This command is crucial for catching configuration issues early, before attempting to interact with any remote infrastructure or state.

Why this answer

The `terraform validate` command checks that a Terraform configuration is syntactically valid and internally consistent, such as verifying that resource names are unique and that references to other resources or data sources are correctly formed. It runs without requiring any cloud provider credentials or state, making it ideal for early-stage validation before `terraform plan`.

Exam trap

HashiCorp often tests the distinction between validation and formatting, so the trap here is that candidates confuse `terraform fmt` (which only fixes code style) with `terraform validate` (which checks for actual errors in the configuration).

How to eliminate wrong answers

Option A is wrong because `terraform init` initializes the working directory by downloading provider plugins and modules, but it does not validate the configuration's syntax or internal consistency. Option B is wrong because `terraform refresh` updates the state file with real-world infrastructure, which requires existing state and credentials, and it does not perform configuration validation. Option D is wrong because `terraform fmt` rewrites configuration files to a canonical format and style, but it does not check for syntactic or semantic validity.

Practice this question →
29
MCQeasy

An organization wants to ensure that running the same Terraform configuration multiple times produces the same result without unintended changes. Which IaC concept is most critical for this goal?

A.Dynamic provider credentials
B.Modularity
C.Version control
D.Idempotency
AnswerD

Idempotency guarantees repeated runs produce the same outcome.

Why this answer

Idempotency ensures that applying the same Terraform configuration multiple times results in the same desired state, with no unintended changes on subsequent runs. Terraform achieves this by comparing the current state (stored in a state file) with the desired configuration and only making changes necessary to reconcile differences. This is the core principle behind Terraform's 'plan and apply' workflow, which guarantees repeatable infrastructure provisioning.

Exam trap

HashiCorp often tests the distinction between 'version control' and 'idempotency' by presenting version control as a plausible answer, since it is a fundamental IaC practice, but the question specifically asks about producing the same result across multiple runs, which is the definition of idempotency.

How to eliminate wrong answers

Option A is wrong because dynamic provider credentials (e.g., using AWS STS AssumeRole) relate to authentication and access control, not to ensuring repeatable, unchanged results across multiple runs. Option B is wrong because modularity improves code organization and reusability but does not inherently guarantee that repeated executions produce the same outcome; a non-idempotent module can still cause drift. Option C is wrong because version control tracks changes to configuration files over time but does not enforce that applying the same configuration multiple times yields identical infrastructure state; it is a best practice for collaboration, not a mechanism for idempotent execution.

Practice this question →
30
MCQmedium

A startup is adopting Terraform to manage their cloud infrastructure. They want to ensure that changes to infrastructure are reviewed and approved before being applied. Which practice aligns with Infrastructure as Code principles to achieve this?

A.Implement a Git-based workflow with pull requests and automated plan reviews.
B.Use Terraform workspaces to separate environments and manually apply changes.
C.Store Terraform state files in a version control system to track changes.
D.Encourage developers to run terraform apply directly on production.
AnswerA

A Git-based workflow provides robust version control for Terraform configurations, enabling a complete audit trail of all infrastructure changes. Pull requests facilitate essential peer review and approval gates, ensuring code quality and adherence to organizational standards. Automated plan reviews, typically integrated into a CI/CD pipeline, validate syntax, enforce policies, and predict infrastructure changes, significantly reducing the risk of errors before deployment.

Why this answer

It aligns with Infrastructure as Code (IaC) principles by using a Git-based workflow where changes are proposed via pull requests, reviewed by peers, and validated through automated Terraform plan runs before merging. This ensures that all infrastructure modifications are version-controlled, auditable, and require explicit approval, preventing unauthorized or erroneous changes from being applied directly.

Exam trap

A common misconception is that storing Terraform state files in version control is a best practice, but it is actually a security anti-pattern because state files often contain sensitive data and Terraform requires state locking for safe concurrent operations.

How to eliminate wrong answers

Option B is wrong because Terraform workspaces are designed to manage multiple environment configurations within the same backend, but manually applying changes bypasses the review and approval process, violating IaC's principle of automated, auditable change management. Option C is wrong because storing Terraform state files in a version control system is a security risk (state files often contain sensitive data like plaintext passwords or access keys) and can lead to state corruption or conflicts; state should be stored in a remote backend with locking, not in VCS. Option D is wrong because encouraging developers to run terraform apply directly on production undermines the entire purpose of IaC, which is to enforce review, approval, and repeatability; it introduces risk of unapproved, unreviewed changes and violates the principle of treating infrastructure as code.

Practice this question →
31
MCQeasy

A junior administrator wants to practice Terraform by deploying a single web server in AWS. They write a configuration file and run terraform init and terraform apply. The deployment succeeds but they notice the web server is not accessible from the internet. What is the most likely reason?

A.The instance type chosen does not support public IP addresses.
B.The terraform init command failed and the apply did not actually create resources.
C.The subnet is configured as private and does not have a route to the internet.
D.The security group does not allow inbound HTTP/HTTPS traffic from 0.0.0.0/0.
AnswerD

The security group does not allow inbound HTTP/HTTPS traffic from 0.0.0.0/0. This is the most probable cause. Security groups function as stateful virtual firewalls that control inbound and outbound traffic for instances. For a web server to be accessible over HTTP (port 80) or HTTPS (port 443) from any IP address on the internet (represented by 0.0.0.0/0), explicit inbound rules must be configured within the associated security group. Without these specific rules, all connection attempts on those ports will be silently dropped, making the web server appear inaccessible even if it is running and has a public IP address.

Why this answer

Even if the web server is deployed in a public subnet with a public IP address, the security group acts as a virtual firewall at the instance level. By default, AWS security groups block all inbound traffic. Without an explicit rule allowing inbound HTTP (port 80) or HTTPS (port 443) traffic from 0.0.0.0/0, the web server will not respond to internet requests, making it inaccessible from the internet.

Exam trap

HashiCorp often tests the misconception that a public subnet or public IP alone guarantees internet accessibility, when in fact the security group's inbound rules are the primary gatekeeper for traffic reaching the instance.

How to eliminate wrong answers

Option A is wrong because all AWS instance types support the assignment of public IP addresses; the ability to assign a public IP is controlled by the subnet's auto-assign public IP setting or the instance's network interface configuration, not the instance type. Option B is wrong because if terraform init had failed, terraform apply would not proceed to create resources; the question states the deployment succeeded, meaning both commands completed without error. Option C is wrong because a private subnet would prevent internet access entirely, but the question does not specify the subnet type; the most common and direct reason for a web server being inaccessible after a successful deployment is the lack of an inbound security group rule for HTTP/HTTPS traffic.

Practice this question →
32
MCQmedium

A team is adopting Terraform to manage infrastructure. One requirement is that all configuration changes must be reviewed and approved before being applied. The team wants to ensure that the Terraform state file reflects the actual deployed infrastructure at all times. Which practice should they implement to meet these requirements?

A.Store state locally and use a manual approval process outside of Terraform.
B.Store state remotely and use a version control system with pull requests to review changes before applying.
C.Store state locally and use a shared network drive for team access.
D.Have each team member run terraform apply from their local machine after informal discussion.
AnswerB

Remote state enables team collaboration and VCS with PRs enforces review.

Why this answer

Storing state remotely (e.g., in S3, Azure Storage, or Terraform Cloud) enables state locking and versioning, which is essential for team collaboration. Using a version control system with pull requests ensures that all configuration changes are reviewed and approved before being applied, meeting the requirement for change control. This combination also ensures the state file accurately reflects deployed infrastructure by preventing concurrent modifications and providing an audit trail.

Exam trap

HashiCorp often tests the misconception that local state with manual processes is sufficient for team collaboration, but the trap here is that without remote state and version-controlled review, you cannot guarantee state consistency or enforce an approval gate, leading to drift and conflicts.

How to eliminate wrong answers

Option A is wrong because storing state locally prevents team collaboration and state locking, and a manual approval process outside of Terraform does not integrate with Terraform's workflow, risking state drift and concurrent apply conflicts. Option C is wrong because a shared network drive lacks state locking and versioning, leading to corruption or overwrites when multiple team members run terraform apply simultaneously. Option D is wrong because having each team member run terraform apply from their local machine after informal discussion bypasses any formal review or approval process, and local state files will diverge, causing inconsistency and potential infrastructure drift.

Practice this question →
33
MCQmedium

You are a DevOps engineer at a growing startup. The infrastructure currently consists of a single AWS EC2 instance running a web application, manually configured. The company plans to scale to multiple instances and environments (development, staging, production). They want to adopt Infrastructure as Code using Terraform. The team has limited experience with Terraform and wants to start small, then gradually adopt more advanced features. The current manual infrastructure must be imported into Terraform. The team also wants to ensure that code changes are reviewed via pull requests before being applied. Which of the following is the best course of action to meet these requirements?

A.Install Terraform on the existing instance, run terraform init and apply directly to manage it, and store state locally. Have team members share the state file via a shared folder.
B.Write Terraform configuration from scratch to match the existing instance, but do not import; instead, destroy the old instance and recreate it with Terraform.
C.Create separate Git branches for each environment (dev, staging, prod) and have each team member work independently on their branch, merging occasionally.
D.Create a Git repository with a main branch. Write a minimal Terraform configuration that describes the existing EC2 instance. Use terraform import to bring the instance under Terraform management. Store the state file remotely in S3 with DynamoDB locking. Set up a CI pipeline that runs terraform plan on pull requests and requires approval before merging.
AnswerD

Creating a Git repository with a main branch provides version control and a single source of truth for infrastructure code. Using `terraform import` allows existing resources to be brought under management non-disruptively, while remote state in S3 with DynamoDB locking ensures collaborative safety and prevents concurrent state modifications. A CI pipeline with `terraform plan` on PRs and approval enforces code review and validates changes before deployment, establishing robust operational practices.

Why this answer

It follows the best practices for adopting Infrastructure as Code with Terraform in a team setting. It starts by writing a minimal configuration that matches the existing EC2 instance, uses `terraform import` to bring it under management without downtime, stores state remotely in S3 with DynamoDB locking for collaboration and consistency, and sets up a CI pipeline to run `terraform plan` on pull requests with approval gates, ensuring code review before changes are applied.

Exam trap

HashiCorp often tests the misconception that you must destroy and recreate infrastructure to adopt IaC, or that local state sharing is acceptable for teams, when in fact `terraform import` and remote state with locking are the correct approaches for zero-downtime adoption and collaboration.

How to eliminate wrong answers

Option A is wrong because storing state locally in a shared folder leads to state file corruption, conflicts, and no locking mechanism, which violates the requirement for safe team collaboration and code review via pull requests. Option B is wrong because destroying the existing instance to recreate it with Terraform causes unnecessary downtime and risk, whereas `terraform import` can bring the instance under management without disruption. Option C is wrong because having separate Git branches for each environment without a unified main branch and CI pipeline leads to configuration drift, lack of code review, and no controlled promotion of changes across environments.

Practice this question →
34
Matchingmedium

Match each Terraform cloud/enterprise feature to its purpose.

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

Concepts
Matches

Organize state and runs for different environments

Integrate third-party policy or compliance checks

Policy as code framework for governance

Store state securely in Terraform Cloud

Trigger runs automatically from version control

Why these pairings

Workspaces isolate state and variables per environment, Sentinel enforces policies, and Run Tasks integrate third-party tools. Common confusions include mixing the roles of Workspaces and Remote State, or Sentinel with Workspaces.

Practice this question →
35
Drag & Dropmedium

Drag and drop the steps to upgrade Terraform providers in a configuration in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The correct sequence for upgrading Terraform providers is: first check current provider versions to establish a baseline, then update version constraints in the configuration to target the desired versions, then run terraform init to download and install those versions, and finally run terraform plan to verify that the upgrade does not introduce unexpected changes. This order ensures a controlled and validated upgrade process.

Practice this question →
36
Multi-Selecteasy

A team is defining their Infrastructure as Code strategy. Which two of the following are key benefits of using IaC compared to manual configuration?

Select 2 answers
A.Faster deployment and provisioning.
B.Reduced need for monitoring.
C.Elimination of all security vulnerabilities.
D.Automatic recovery from any infrastructure failure.
E.Consistent and repeatable infrastructure setups.
AnswersA, E

Infrastructure as Code (IaC) tools like Terraform automate the entire infrastructure lifecycle, from initial provisioning to updates and deprovisioning. This automation significantly reduces the time required to deploy complex environments compared to manual, click-intensive processes, enabling rapid iteration and scaling of resources.

Why this answer

IaC automates the provisioning and configuration of infrastructure through code, eliminating the need for manual, error-prone steps. This enables rapid deployment of resources, often reducing setup times from hours to minutes by leveraging tools like Terraform to apply declarative configurations in parallel across multiple providers.

Exam trap

In HashiCorp Terraform exams, this question tests the misconception that IaC eliminates all operational overhead, such as monitoring or failure recovery, when in reality IaC focuses on provisioning and configuration consistency, not on runtime resilience or security guarantees.

Practice this question →
37
MCQeasy

A company manages multiple AWS accounts using Terraform. They have a central repository where all Terraform configurations are stored. Recently, a developer accidentally ran terraform destroy on a production workspace and deleted critical resources. The team wants to implement safeguards to prevent such incidents while still allowing developers to test changes in non-production environments. They currently use Terraform Cloud for remote state management and runs. Which course of action should the team take to minimize risk?

A.Store the production Terraform state file locally and restrict access to it.
B.Use Terraform's built-in lifecycle prevent_destroy on all production resources.
C.Implement run tasks in Terraform Cloud that require approval for any destroy operation on workspaces tagged as 'production'.
D.Remove all developers' access to the Terraform Cloud API and only allow operations via pull requests.
AnswerC

Implementing run tasks in Terraform Cloud that require approval for any destroy operation on workspaces tagged as 'production' is an effective and scalable solution. Terraform Cloud run tasks allow for custom policy enforcement and integration with external systems, enabling a mandatory manual approval step specifically for destructive actions on critical resources. This provides a robust governance mechanism, ensuring that production infrastructure changes are reviewed and authorized before execution, thereby preventing accidental destruction.

Why this answer

Terraform Cloud run tasks can enforce approval workflows for destroy operations on production workspaces, providing a safeguard against accidental deletions while still allowing developers to test in non-production environments. Option A is wrong because storing state locally is insecure and eliminates the benefits of remote state management. Option B is wrong because `prevent_destroy` blocks all destroy operations, including intentional ones, and is not a flexible safeguard.

Option D is wrong because removing API access entirely is too restrictive and hinders legitimate operations; instead, proper permissions and approval workflows should be used.

Practice this question →
38
MCQhard

A team manages a multi-tier application consisting of web servers, application servers, and databases deployed across AWS and Azure. Historically, they have provisioned infrastructure manually using cloud consoles and ad-hoc scripts. To improve consistency and reduce errors, they decide to adopt Terraform for Infrastructure as Code. After initial rollout, they encounter problems: some team members still make direct changes via the cloud console to quickly fix issues, causing configuration drift between the Terraform state and actual resources. They also need to manage three distinct environments (development, staging, production) with different configurations (e.g., instance sizes, database settings). The team consists of five people with a limited budget for additional tools. Which course of action best addresses these challenges while adhering to IaC principles?

A.Store Terraform state in a shared S3 bucket with DynamoDB locking, and have each team member apply their own changes locally after review.
B.Use Terraform workspaces to manage environments and enforce that all changes go through version-controlled Terraform configs, disabling direct console changes via IAM policies.
C.Assign each environment to a different Terraform provider alias and use manual planning to ensure correctness.
D.Implement a CI/CD pipeline that runs terraform plan and apply automatically on merges to the main branch, and use Terraform Cloud's Sentinel policies to prevent drift.
AnswerD

Implementing a CI/CD pipeline ensures that all infrastructure changes are applied through an automated, version-controlled process, eliminating local applies and unreviewed modifications that commonly cause drift. This pipeline can run `terraform plan` for review and `terraform apply` automatically upon merge to the main branch, enforcing a single source of truth. Furthermore, integrating Terraform Cloud's Sentinel policies provides policy-as-code enforcement, actively preventing deployments that would introduce drift or violate organizational compliance rules by blocking non-compliant plans before application.

Why this answer

Best addresses both challenges. Implementing a CI/CD pipeline that runs terraform plan and apply automatically on merges to the main branch ensures all infrastructure changes are made through version-controlled Terraform configurations, preventing configuration drift from manual console changes. Using Terraform Cloud's Sentinel policies adds an additional layer of governance to enforce compliance and prevent unauthorized changes.

This approach also naturally supports environment management because different branches or configurations can represent the three environments (development, staging, production), and the pipeline can target different remote backends or workspaces. Option A (shared S3 with DynamoDB locking) improves state management and collaboration but does not prevent drift from direct console changes. Option B (workspaces and IAM policies) can help with environment separation and restrict console changes, but local applies still risk drift and the IAM approach may be overly restrictive.

Option C (provider aliases) is not designed for environment management and manual planning does not prevent drift.

Practice this question →
39
MCQeasy

Which of the following is a primary benefit of using Infrastructure as Code?

A.Faster provisioning through automation
B.Removes dependency on cloud providers
C.Guarantees zero downtime during updates
D.Eliminates the need for cloud credentials
AnswerA

Terraform, as an Infrastructure as Code (IaC) tool, automates the entire infrastructure lifecycle, from initial provisioning to subsequent updates and deletion. By defining infrastructure in declarative configuration files, repetitive manual tasks are eliminated, significantly reducing the time required to deploy complex environments. This automation ensures consistency and dramatically accelerates the delivery of infrastructure resources compared to traditional manual processes, making provisioning much faster.

Why this answer

Faster provisioning through automation (A) is a core benefit because IaC enables quick and repeatable deployments via code, reducing manual effort and time. Option B is false: IaC does not remove dependency on cloud providers; you still rely on them for infrastructure services. Option C is false: IaC helps manage updates but does not guarantee zero downtime.

Option D is false: credentials are still required to authenticate with cloud providers.

Practice this question →
40
MCQhard

In Terraform, the `terraform plan` command compares the current state with the configuration. This is an example of which IaC principle?

A.Version control integration
B.Continuous delivery
C.Modular architecture
D.Desired state enforcement
AnswerD

The `terraform plan` command is central to desired state enforcement in Terraform. It meticulously compares the infrastructure's current state, as recorded in the state file and potentially observed live, against the desired configuration defined in the Terraform files. The resulting plan details all the actions (creations, updates, destructions) required to reconcile any discrepancies, thereby showing precisely what is needed to achieve the desired infrastructure state.

Why this answer

The `terraform plan` command compares the current state (what is deployed) with the configuration (what is declared) and computes the changes needed to align the real-world infrastructure with the declared configuration. This is the essence of desired state enforcement: the tool continuously reconciles the actual state toward the user-defined desired state, rather than executing imperative steps. Option D is correct because Terraform's core loop—plan, apply, refresh—is built around this declarative, state-driven model.

Exam trap

HashiCorp often tests the distinction between declarative (desired state enforcement) and imperative (step-by-step) approaches, and the trap here is that candidates confuse the `plan` command's output with a simple diff report rather than recognizing it as the core mechanism of Terraform's declarative state reconciliation model.

How to eliminate wrong answers

Option A is wrong because version control integration refers to storing Terraform configurations in Git or similar systems, not to the behavior of `terraform plan`. Option B is wrong because continuous delivery is a software engineering practice for automating deployments through pipelines, not a principle demonstrated by a single command that compares state. Option C is wrong because modular architecture is about organizing configurations into reusable modules (e.g., using `module` blocks), which is unrelated to the state-comparison mechanism of `terraform plan`.

Practice this question →
41
MCQmedium

Based on the exhibit, what can be inferred about the Terraform state and configuration?

A.The aws_instance.db resource is in state but not in configuration, so it will be destroyed.
B.The configuration for aws_instance.db has been added back to the .tf files.
C.The aws_instance.db resource was manually deleted from the AWS console.
D.The aws_instance.web resource is being imported into Terraform management.
AnswerA

Terraform plans to destroy resources that are in state but removed from configuration.

Why this answer

The `terraform plan` output shows that `aws_instance.db` exists in the state file but is absent from the current configuration. Terraform interprets this as a resource that should be removed to align the real-world infrastructure with the configuration, so it will be destroyed. This is a core behavior of Terraform's desired-state management: any resource in state but not in configuration is marked for deletion.

Exam trap

HashiCorp often tests the distinction between resources missing from configuration (destroy) versus resources missing from the real world (re-create), and the trap here is confusing manual deletion with configuration removal.

How to eliminate wrong answers

Option B is wrong because if the configuration for `aws_instance.db` had been added back, the plan would show an update or no change, not a destroy. Option C is wrong because manual deletion from the AWS console would cause Terraform to detect the resource as missing and plan to re-create it, not destroy it. Option D is wrong because importing a resource would produce a plan that shows the resource being added to state without a destroy action, and the exhibit shows a destroy, not an import.

Practice this question →
42
Multi-Selectmedium

Which three practices help maintain consistency and reduce configuration drift in IaC? (Choose three.)

Select 3 answers
A.Storing state files remotely and locking them
B.Implementing CI/CD pipelines with automated testing
C.Regularly running terraform plan and apply
D.Using manual changes to fix minor issues
E.Allowing multiple team members to run apply simultaneously
AnswersA, B, C

Storing Terraform state files remotely, typically in a backend like S3, Azure Blob Storage, or HashiCorp Consul, centralizes the authoritative record of managed infrastructure. This remote storage, combined with state locking mechanisms provided by the backend, prevents multiple users or automated processes from concurrently modifying the state file. This ensures that only one operation can write to the state at a time, preventing race conditions, state corruption, and configuration drift caused by uncoordinated changes.

Why this answer

Storing state files remotely (e.g., in an S3 bucket with DynamoDB locking) prevents concurrent modifications and ensures that the state file reflects the true infrastructure state. This practice eliminates the risk of conflicting changes and configuration drift caused by local or stale state files.

Exam trap

A common trap in Terraform exams is assuming that manual changes or concurrent applies are acceptable shortcuts. The exam emphasizes that any deviation from the IaC pipeline—even minor fixes—introduces drift and undermines reproducibility.

Practice this question →
43
MCQhard

A company uses Terraform to manage infrastructure on AWS. They have a configuration that creates an S3 bucket and a DynamoDB table for state locking. The team notices that sometimes when two members run terraform apply simultaneously, they get a state locking error. However, they want to allow concurrent operations on different workspaces. What is the best approach?

A.Remove the DynamoDB table and use local state files to avoid locking issues.
B.Configure all team members to use the same workspace so that only one person can apply at a time.
C.Keep the current setup because the error is harmless and users can retry.
D.Use separate state files per workspace and ensure each workspace has its own lock entry in DynamoDB; the current setup already supports this.
AnswerD

Terraform workspaces inherently create separate state files within the configured remote backend, such as an S3 bucket. Each of these distinct state files is then protected by its own unique lock entry in the DynamoDB table, preventing concurrent modifications to that specific workspace's state. This design allows multiple team members to concurrently apply changes to different workspaces without conflict, leveraging the robust locking mechanisms provided by the remote backend.

Why this answer

Terraform natively supports per-workspace state files, and when using a remote backend like S3 with DynamoDB for state locking, each workspace's state file is stored at a distinct path in S3. The DynamoDB lock entry is tied to the specific state file path via the LockID, so concurrent operations on different workspaces acquire separate locks and do not conflict. This setup allows multiple team members to run terraform apply simultaneously as long as they are working in different workspaces.

Exam trap

HashiCorp often tests the misconception that DynamoDB locking is global across all workspaces, when in fact the lock is scoped to the specific state file path, which includes the workspace name.

How to eliminate wrong answers

Option A is wrong because removing the DynamoDB table and using local state files eliminates state locking entirely, which can lead to state corruption if multiple users apply changes concurrently, even on different workspaces. Option B is wrong because configuring all team members to use the same workspace defeats the purpose of allowing concurrent operations and forces serialization of all applies, reducing team productivity. Option C is wrong because the state locking error is not harmless; it indicates a real conflict that can cause corruption or inconsistent state if ignored, and simply retrying does not address the underlying need for concurrent workspace-level isolation.

Practice this question →
44
MCQeasy

You are a platform engineer at a growing startup. The company currently manages infrastructure manually by SSH-ing into servers to install packages and update configurations. As the team grows, this approach has led to frequent configuration drift, inconsistent environments, and manual errors. Deploying a new environment takes several days and requires detailed runbooks. The CTO has asked you to propose a solution that improves consistency, reduces deployment time, and enables version control of infrastructure. You are evaluating Infrastructure as Code (IaC) tools like Terraform. Which course of action best addresses the CTO's requirements?

A.Improve SSH key management and use configuration management tools like Ansible to apply changes.
B.Migrate all applications to containers and use Kubernetes for orchestration.
C.Adopt Terraform to define all infrastructure as code, store configurations in a Git repository, and use a CI/CD pipeline to apply changes automatically.
D.Create more detailed runbooks and require peer review for all manual changes.
AnswerC

Adopting Terraform for Infrastructure as Code (IaC) allows declarative definition of all infrastructure resources, ensuring consistency and repeatability across environments. Storing these configurations in a Git repository provides robust version control, auditability, and collaborative development, while a CI/CD pipeline automates the application of changes. This integrated approach eliminates manual errors, enforces the desired state, and significantly accelerates infrastructure provisioning and updates.

Why this answer

Terraform directly addresses the CTO's requirements by enabling infrastructure as code (IaC), which ensures consistent, repeatable deployments through declarative configuration files stored in Git for version control. Using a CI/CD pipeline to automatically apply changes eliminates manual SSH errors, reduces deployment time from days to minutes, and prevents configuration drift by enforcing a single source of truth for infrastructure state.

Exam trap

HashiCorp often tests the distinction between configuration management tools (like Ansible) and infrastructure provisioning tools (like Terraform), trapping candidates who confuse managing software on existing servers with defining and versioning the infrastructure itself.

How to eliminate wrong answers

Option A is wrong because improving SSH key management and using Ansible for configuration management still relies on imperative, agent-based execution against existing servers, which does not provide the declarative, version-controlled infrastructure provisioning that Terraform offers; it also does not inherently prevent configuration drift across environments. Option B is wrong because migrating to containers and Kubernetes addresses application deployment and orchestration, not the underlying infrastructure provisioning (e.g., VMs, networks, storage), and introduces unnecessary complexity for a startup that has not yet solved basic infrastructure consistency. Option D is wrong because creating more detailed runbooks and requiring peer review only reduces manual errors marginally but does not automate provisioning, eliminate configuration drift, or enable version control of infrastructure; it perpetuates the slow, error-prone manual process.

Practice this question →
45
MCQeasy

A team uses the backend configuration above. What is the primary benefit of storing state remotely in S3?

A.Automatic encryption of state files
B.Reducing the number of API calls to AWS
C.Enabling state sharing and locking across the team
D.Faster Terraform execution times
AnswerC

The paramount benefit of a remote backend is enabling seamless collaboration among multiple team members by centralizing the Terraform state file in a shared, persistent location. This ensures everyone operates against the same authoritative infrastructure definition. Furthermore, remote backends provide crucial state locking mechanisms, which prevent concurrent `terraform apply` operations from simultaneously modifying and potentially corrupting the state file, thereby maintaining state integrity and consistency.

Why this answer

Storing Terraform state remotely in S3 is the standard practice for team collaboration because it allows multiple team members to access and modify the same state file, preventing conflicts. Combined with DynamoDB for state locking, it ensures that only one person runs `terraform apply` at a time, avoiding race conditions and state corruption. This is the primary benefit over local state storage, which is single-user by design.

Exam trap

HashiCorp often tests the misconception that remote state is about performance (faster execution) or security (automatic encryption), when the actual core purpose is enabling safe, concurrent team collaboration through state sharing and locking.

How to eliminate wrong answers

Option A is wrong because S3 does not automatically encrypt state files by default; server-side encryption (SSE-S3 or SSE-KMS) must be explicitly configured in the backend block or bucket policy. Option B is wrong because storing state remotely in S3 does not reduce API calls to AWS; in fact, it may increase them due to state retrieval and locking operations. Option D is wrong because remote state storage typically increases execution time due to network latency for downloading/uploading the state file, not faster execution.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Iac Concepts questions.

Start 20-question session