Scenario practice questions

During a deployment, a user runs `terraform apply` but the command fails because the state lock cannot be acquired. They suspect the lock was released after the previous `apply` but is still held. What command can they use to force unlock the state?

Trap 1: `terraform init -force-copy`

The `terraform init` command initializes a working directory, configuring backends and providers. The `-force-copy` flag is specifically used in conjunction with `terraform init -migrate-state` to compel a copy of the state file during a backend migration, even if a move would typically occur. This flag has no function related to releasing or managing state locks, which are handled by distinct commands.

Trap 2: `terraform state unlock`

While `terraform state` is a valid subcommand for various state management operations, `unlock` is not a recognized action directly under it. Terraform's CLI structure requires specific commands for managing state locks, and `terraform state unlock` is syntactically incorrect. Attempting to execute this command would result in an error, indicating an unknown or unsupported subcommand for state manipulation.

Trap 3: `terraform break-lock`

The command `terraform break-lock` is not a valid or recognized command within the Terraform CLI. Terraform's command-line interface follows a predefined structure of commands and subcommands for managing infrastructure. Using an undefined command like `break-lock` will simply result in an 'Unknown command' error, as it does not correspond to any functionality for state lock management or other Terraform operations.

A
`terraform init -force-copy`
Why wrong: The `terraform init` command initializes a working directory, configuring backends and providers. The `-force-copy` flag is specifically used in conjunction with `terraform init -migrate-state` to compel a copy of the state file during a backend migration, even if a move would typically occur. This flag has no function related to releasing or managing state locks, which are handled by distinct commands.
B
`terraform force-unlock <lock_id>`
This command is the correct and designated mechanism for manually releasing a stuck or orphaned Terraform state lock. When a Terraform operation is interrupted, the state lock might persist, preventing subsequent operations. By providing the unique `<lock_id>`, this command allows an administrator to force the release of the specific lock, enabling further infrastructure changes to proceed safely. This is an essential recovery tool for maintaining operational continuity.
C
`terraform state unlock`
Why wrong: While `terraform state` is a valid subcommand for various state management operations, `unlock` is not a recognized action directly under it. Terraform's CLI structure requires specific commands for managing state locks, and `terraform state unlock` is syntactically incorrect. Attempting to execute this command would result in an error, indicating an unknown or unsupported subcommand for state manipulation.
D
`terraform break-lock`
Why wrong: The command `terraform break-lock` is not a valid or recognized command within the Terraform CLI. Terraform's command-line interface follows a predefined structure of commands and subcommands for managing infrastructure. Using an undefined command like `break-lock` will simply result in an 'Unknown command' error, as it does not correspond to any functionality for state lock management or other Terraform operations.

Question 2mediummultiple choice

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?

Trap 1: Terraform is a configuration management tool for installing…

Terraform's primary function is infrastructure provisioning, meaning it creates and manages the underlying resources like virtual machines, networks, and databases. Configuration management tools, such as Ansible or Chef, operate *after* provisioning, focusing on installing software, configuring operating systems, and managing services *within* those existing servers. Therefore, Terraform is not a configuration management tool but rather an orchestrator for infrastructure creation.

Trap 2: Terraform is a cloud-specific orchestration tool that only works…

This statement is incorrect because Terraform is designed as a multi-cloud and multi-provider infrastructure-as-code tool. Its extensive provider ecosystem allows it to manage resources across various public cloud platforms like AWS, Azure, and Google Cloud Platform, as well as on-premises infrastructure, SaaS offerings, and even custom APIs. Limiting Terraform to only AWS or a single cloud contradicts its core design principle of provider agnosticism and broad applicability.

Trap 3: Terraform is a monitoring and logging tool for cloud resources.

Terraform's role is to define, provision, and manage the lifecycle of infrastructure resources, not to monitor their operational status or collect logs. Specialized monitoring and logging solutions, such as AWS CloudWatch, Azure Monitor, Splunk, or Prometheus, are responsible for gathering metrics, events, and logs from the provisioned infrastructure. While Terraform can provision these monitoring *services*, it does not perform the monitoring or logging functions itself.

A
Terraform is a configuration management tool for installing software on existing servers.
Why wrong: Terraform's primary function is infrastructure provisioning, meaning it creates and manages the underlying resources like virtual machines, networks, and databases. Configuration management tools, such as Ansible or Chef, operate *after* provisioning, focusing on installing software, configuring operating systems, and managing services *within* those existing servers. Therefore, Terraform is not a configuration management tool but rather an orchestrator for infrastructure creation.
B
Terraform is a cloud-specific orchestration tool that only works with AWS.
Why wrong: This statement is incorrect because Terraform is designed as a multi-cloud and multi-provider infrastructure-as-code tool. Its extensive provider ecosystem allows it to manage resources across various public cloud platforms like AWS, Azure, and Google Cloud Platform, as well as on-premises infrastructure, SaaS offerings, and even custom APIs. Limiting Terraform to only AWS or a single cloud contradicts its core design principle of provider agnosticism and broad applicability.
C
Terraform is a monitoring and logging tool for cloud resources.
Why wrong: Terraform's role is to define, provision, and manage the lifecycle of infrastructure resources, not to monitor their operational status or collect logs. Specialized monitoring and logging solutions, such as AWS CloudWatch, Azure Monitor, Splunk, or Prometheus, are responsible for gathering metrics, events, and logs from the provisioned infrastructure. While Terraform can provision these monitoring *services*, it does not perform the monitoring or logging functions itself.
D
Terraform is an infrastructure-as-code tool for provisioning and managing any infrastructure across multiple providers.
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.

Question 3hardmultiple choice

A developer runs terraform plan and sees a large number of resources will be destroyed. They suspect the state file is corrupted. They have a recent backup of the state file. Which command can help recover the previous state from the backup?

Trap 1: No command can recover; they must re-import all resources.

This statement is incorrect because Terraform provides mechanisms to recover from state issues, particularly when a backup of the state file is available. While re-importing resources using `terraform import` is a valid strategy for bringing existing infrastructure under Terraform management, it is a time-consuming and often complex process. It is not the primary or necessary recovery method if a functional state file backup exists, as `terraform state push` offers a direct restoration path.

Trap 2: terraform state rm

The `terraform state rm` command is used to remove one or more resources from the Terraform state file, effectively telling Terraform to "forget" about those specific resources. This operation does not delete the actual cloud resources, but it removes their mapping from the state, making them unmanaged by Terraform. Therefore, using `terraform state rm` would exacerbate a state corruption problem by further reducing the known state, rather than restoring it.

Trap 3: terraform state pull

The `terraform state pull` command is designed to download the *current* state file from the configured remote backend to a local file. Its primary purpose is to inspect the active state or to create a local copy for debugging or archival. If the remote state is already corrupted or missing, pulling it down would only retrieve the problematic state or an empty file, offering no mechanism to restore from a separate, valid backup.

A
terraform state push
When a Terraform state file becomes corrupted or is accidentally deleted, and a valid backup of the state file exists locally, `terraform state push` is the command used to upload this backup to the configured remote backend. This action overwrites the current (potentially invalid or missing) state in the backend with the provided backup, effectively restoring the infrastructure's known state. This allows subsequent `terraform plan` and `apply` operations to correctly reflect the deployed resources.
B
No command can recover; they must re-import all resources.
Why wrong: This statement is incorrect because Terraform provides mechanisms to recover from state issues, particularly when a backup of the state file is available. While re-importing resources using `terraform import` is a valid strategy for bringing existing infrastructure under Terraform management, it is a time-consuming and often complex process. It is not the primary or necessary recovery method if a functional state file backup exists, as `terraform state push` offers a direct restoration path.
C
terraform state rm
Why wrong: The `terraform state rm` command is used to remove one or more resources from the Terraform state file, effectively telling Terraform to "forget" about those specific resources. This operation does not delete the actual cloud resources, but it removes their mapping from the state, making them unmanaged by Terraform. Therefore, using `terraform state rm` would exacerbate a state corruption problem by further reducing the known state, rather than restoring it.
D
terraform state pull
Why wrong: The `terraform state pull` command is designed to download the *current* state file from the configured remote backend to a local file. Its primary purpose is to inspect the active state or to create a local copy for debugging or archival. If the remote state is already corrupted or missing, pulling it down would only retrieve the problematic state or an empty file, offering no mechanism to restore from a separate, valid backup.

Question 4mediummultiple choice

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?

Trap 1: Immutable infrastructure

Immutable infrastructure is a paradigm where servers and other infrastructure components are never modified after deployment; instead, any change requires replacing the existing resource with a new, updated version. This approach emphasizes consistency and predictability by avoiding in-place updates that can lead to configuration drift. The scenario describes a direct manual modification to an existing resource, which is the antithesis of immutable infrastructure principles, as it involves changing a deployed component rather than replacing it.

Trap 2: Resource tagging

Resource tagging involves applying metadata labels to cloud resources for organizational, cost allocation, security, or automation purposes. Tags are key-value pairs that help categorize and manage resources, such as identifying ownership, environment, or project. While important for cloud governance, tagging is entirely unrelated to the core problem of detecting and reverting an unauthorized manual change to a resource's operational configuration, which is a matter of state management and desired state enforcement.

Trap 3: Imperative provisioning

Imperative provisioning specifies *how* to achieve a desired state through a sequence of explicit commands or steps, such as a shell script or a series of API calls. This contrasts sharply with Terraform's declarative approach, where you describe *what* the desired end state should be, and Terraform figures out the necessary steps. The scenario focuses on detecting and correcting a deviation from a *declared* desired state, not on the method by which the resource was initially provisioned or how subsequent changes are applied step-by-step.

A
Configuration drift and correction
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.
B
Immutable infrastructure
Why wrong: Immutable infrastructure is a paradigm where servers and other infrastructure components are never modified after deployment; instead, any change requires replacing the existing resource with a new, updated version. This approach emphasizes consistency and predictability by avoiding in-place updates that can lead to configuration drift. The scenario describes a direct manual modification to an existing resource, which is the antithesis of immutable infrastructure principles, as it involves changing a deployed component rather than replacing it.
C
Resource tagging
Why wrong: Resource tagging involves applying metadata labels to cloud resources for organizational, cost allocation, security, or automation purposes. Tags are key-value pairs that help categorize and manage resources, such as identifying ownership, environment, or project. While important for cloud governance, tagging is entirely unrelated to the core problem of detecting and reverting an unauthorized manual change to a resource's operational configuration, which is a matter of state management and desired state enforcement.
D
Imperative provisioning
Why wrong: Imperative provisioning specifies *how* to achieve a desired state through a sequence of explicit commands or steps, such as a shell script or a series of API calls. This contrasts sharply with Terraform's declarative approach, where you describe *what* the desired end state should be, and Terraform figures out the necessary steps. The scenario focuses on detecting and correcting a deviation from a *declared* desired state, not on the method by which the resource was initially provisioned or how subsequent changes are applied step-by-step.

Question 5easymultiple choice

A DevOps engineer is managing a multi-cloud infrastructure using Terraform. The team relies on a module sourced from the Terraform Registry to deploy a standard web application. This module defines an input variable called 'instance_count' with a default value of 2. For the production environment, the engineer wants to deploy 3 instances. They create a root module configuration that references the module. In the root module's main.tf, they write a block that sets instance_count = 3. However, when they run terraform plan, the output indicates that the module will still use instance_count = 2. The engineer double-checks the configuration: the root module's main.tf is syntactically correct, the module source points to the correct registry module and version, and they have run terraform init and terraform validate without errors. What is the most likely reason the variable override is not taking effect?

Trap 1: The module version specified does not support variable overrides;…

Terraform's module system inherently allows calling modules to pass values to any input variable declared within a child module, regardless of the module's version. Module versions primarily manage feature sets, bug fixes, and breaking changes in the module's internal logic, not the fundamental mechanism of variable input. Therefore, the ability to override variables is a core design principle of Terraform modules and is not dependent on a specific module version or disabled by any version.

Trap 2: The variable 'instance_count' is not declared as an input variable…

If 'instance_count' were not declared as an input variable within the child module's `variables.tf` (or any `.tf` file in the module), Terraform would produce an error during the `terraform plan` or `terraform validate` phase, indicating an undeclared variable. The problem statement implies that the plan runs without such an error, suggesting the variable is indeed declared, possibly with a default value, which is a common practice for optional or default-configured inputs.

Trap 3: The engineer forgot to run terraform init after modifying the root…

`terraform init` is primarily responsible for initializing the working directory, which includes downloading provider plugins, configuring the backend, and downloading remote modules. Modifying a local variable or a module argument within the root module's configuration does not alter these foundational components. Since the engineer is attempting to override an existing module variable, `terraform init` would not be necessary to apply this specific configuration change, especially if `init` and `validate` have already run successfully.

A
The module version specified does not support variable overrides; the engineer must use a different module.
Why wrong: Terraform's module system inherently allows calling modules to pass values to any input variable declared within a child module, regardless of the module's version. Module versions primarily manage feature sets, bug fixes, and breaking changes in the module's internal logic, not the fundamental mechanism of variable input. Therefore, the ability to override variables is a core design principle of Terraform modules and is not dependent on a specific module version or disabled by any version.
B
The variable 'instance_count' is not declared as an input variable in the child module's variables.tf.
Why wrong: If 'instance_count' were not declared as an input variable within the child module's `variables.tf` (or any `.tf` file in the module), Terraform would produce an error during the `terraform plan` or `terraform validate` phase, indicating an undeclared variable. The problem statement implies that the plan runs without such an error, suggesting the variable is indeed declared, possibly with a default value, which is a common practice for optional or default-configured inputs.
C
The engineer forgot to run terraform init after modifying the root module's configuration.
Why wrong: `terraform init` is primarily responsible for initializing the working directory, which includes downloading provider plugins, configuring the backend, and downloading remote modules. Modifying a local variable or a module argument within the root module's configuration does not alter these foundational components. Since the engineer is attempting to override an existing module variable, `terraform init` would not be necessary to apply this specific configuration change, especially if `init` and `validate` have already run successfully.
D
The root module defines instance_count as a local value rather than passing it as an argument to the module block.
To pass a value to an input variable of a child module, it must be explicitly defined as an argument directly within the `module` block declaration in the calling configuration. A local value, defined using the `locals` block in the root module, is an internal construct for simplifying expressions within that *same* root module. It does not automatically get passed down or override variables within a child module; it must be referenced and then passed as a module argument.

Question 6hardmulti select

Which three of the following are true regarding Terraform state?

Trap 1: State can be manually edited with a text editor without risk.

Manually editing the Terraform state file with a text editor is extremely risky and strongly discouraged. The state file contains sensitive resource IDs, internal checksums, and a specific JSON structure that can be easily corrupted by manual changes. Such corruption can lead to inconsistencies between the state and real-world infrastructure, causing Terraform to misidentify resources, destroy unintended components, or fail during subsequent operations. Instead, use `terraform state` commands for safe state manipulation.

Trap 2: State must be stored in a file named terraform.tfstate.

While `terraform.tfstate` is the default filename for local state, it is not a mandatory requirement for all Terraform deployments. Users can configure a different local state filename using the `terraform init -state=path/to/my.tfstate` command or by specifying a backend configuration. Furthermore, when using remote backends like S3 or Azure Storage, the state is stored externally and may not even reside in a local file with any specific name after initialization, making the default local filename irrelevant.

A
State can be stored in a local file or remotely.
Terraform state can be stored locally in a `terraform.tfstate` file, which is suitable for individual development and testing. For collaborative environments and production deployments, remote state storage is highly recommended. Terraform backends, such as Amazon S3, Azure Storage, or HashiCorp Consul, enable durable, shared, and versioned state management, often including state locking to prevent concurrent modifications and ensure consistency across teams.
B
State can be manually edited with a text editor without risk.
Why wrong: Manually editing the Terraform state file with a text editor is extremely risky and strongly discouraged. The state file contains sensitive resource IDs, internal checksums, and a specific JSON structure that can be easily corrupted by manual changes. Such corruption can lead to inconsistencies between the state and real-world infrastructure, causing Terraform to misidentify resources, destroy unintended components, or fail during subsequent operations. Instead, use `terraform state` commands for safe state manipulation.
C
State is required for Terraform to function.
Terraform state is absolutely fundamental for the tool's operation, serving as the authoritative record of the infrastructure it manages. It maps real-world cloud resources to the configuration defined in your `.tf` files, storing their unique identifiers and attributes. Without state, Terraform would be unable to track which resources it created, compare the current configuration against the deployed infrastructure, or determine the necessary changes during `terraform plan` and `terraform apply` operations.
D
State must be stored in a file named terraform.tfstate.
Why wrong: While `terraform.tfstate` is the default filename for local state, it is not a mandatory requirement for all Terraform deployments. Users can configure a different local state filename using the `terraform init -state=path/to/my.tfstate` command or by specifying a backend configuration. Furthermore, when using remote backends like S3 or Azure Storage, the state is stored externally and may not even reside in a local file with any specific name after initialization, making the default local filename irrelevant.
E
State contains resource metadata and dependencies.
The Terraform state file meticulously records comprehensive metadata about each managed resource, including its unique identifier, current attributes, and the provider responsible for its management. This metadata is crucial for Terraform to interact with the correct API endpoints and perform operations like updates or deletions. Additionally, the state implicitly tracks resource dependencies, allowing Terraform to correctly determine the order of creation, modification, and destruction operations to maintain infrastructure integrity.

Question 7mediummulti select

Which TWO scenarios require the use of the depends_on argument?

Trap 1: When a resource uses the output of another resource in its…

When a resource uses the output of another resource in its arguments, Terraform's dependency graph automatically infers the correct creation order. For instance, if an aws_instance resource references the id attribute of an aws_vpc resource, Terraform understands that the VPC must be created and its ID available before the instance can be provisioned within it. This implicit dependency mechanism is fundamental to how Terraform manages resource relationships and ensures proper sequencing without manual intervention.

Trap 2: When a resource uses the output of a data source in its arguments.

When a resource uses the output of a data source in its arguments, Terraform automatically establishes an implicit dependency. Data sources are designed to fetch information about existing infrastructure or external services *before* resources are created or updated. Therefore, if a resource configuration references an attribute from a data source, Terraform ensures the data source is successfully read and its outputs are available before attempting to configure the dependent resource, guaranteeing the necessary information is present.

Trap 3: When a resource uses a module output as an input.

Referencing an output from a child module as an input to a resource in a parent or sibling module creates an implicit dependency that Terraform automatically resolves. Modules encapsulate configurations, and their outputs are only available after the module's resources have been successfully provisioned. Terraform ensures that the child module is applied and its outputs computed before any resource in the calling module attempts to use those outputs, maintaining the correct execution order across module boundaries.

A
When a resource uses the output of another resource in its arguments.
Why wrong: When a resource uses the output of another resource in its arguments, Terraform's dependency graph automatically infers the correct creation order. For instance, if an aws_instance resource references the id attribute of an aws_vpc resource, Terraform understands that the VPC must be created and its ID available before the instance can be provisioned within it. This implicit dependency mechanism is fundamental to how Terraform manages resource relationships and ensures proper sequencing without manual intervention.
B
When a provisioner creates resources that other resources depend on.
Provisioners execute arbitrary scripts or commands on a resource, often interacting with external systems or creating entities that Terraform itself does not manage directly. Because Terraform cannot introspect or track the side effects of these external operations, any subsequent Terraform-managed resource that relies on an outcome of a provisioner's execution will not have an automatically inferred dependency. In such cases, an explicit depends_on argument is essential to force the correct ordering, ensuring the provisioner completes its task before dependent resources are evaluated.
C
When Terraform cannot automatically infer an implicit dependency.
Terraform's primary method for determining resource creation and update order is by analyzing attribute references within the configuration. However, there are specific scenarios where a logical dependency exists between resources, but no direct attribute reference links them. For example, if resource A needs resource B to be fully operational before it can start, but A doesn't consume any output from B, Terraform cannot infer this. The depends_on argument provides a manual override to explicitly declare such a dependency, ensuring B is applied before A.
D
When a resource uses the output of a data source in its arguments.
Why wrong: When a resource uses the output of a data source in its arguments, Terraform automatically establishes an implicit dependency. Data sources are designed to fetch information about existing infrastructure or external services *before* resources are created or updated. Therefore, if a resource configuration references an attribute from a data source, Terraform ensures the data source is successfully read and its outputs are available before attempting to configure the dependent resource, guaranteeing the necessary information is present.
E
When a resource uses a module output as an input.
Why wrong: Referencing an output from a child module as an input to a resource in a parent or sibling module creates an implicit dependency that Terraform automatically resolves. Modules encapsulate configurations, and their outputs are only available after the module's resources have been successfully provisioned. Terraform ensures that the child module is applied and its outputs computed before any resource in the calling module attempts to use those outputs, maintaining the correct execution order across module boundaries.

Question 8easymultiple choice

A team uses an S3 backend for Terraform state. During a `terraform apply`, another team member accidentally runs a plan that also modifies the same state. Which feature prevents state corruption in this scenario?

Trap 1: The `-lock=false` flag

The `-lock=false` flag explicitly disables Terraform's state locking mechanism. This action is counterproductive for protecting state during concurrent operations, as it removes the safeguard designed to prevent multiple users or automated processes from simultaneously modifying the remote state file. Disabling locking significantly increases the risk of state file corruption, lost updates, and inconsistent infrastructure deployments in collaborative environments.

Trap 2: Terraform Cloud remote operations

Terraform Cloud remote operations refer to the execution environment where Terraform commands are run within the Terraform Cloud platform. While Terraform Cloud inherently provides robust state locking as part of its managed remote execution capabilities, 'remote operations' itself is a broad platform feature, not the specific underlying mechanism (like DynamoDB) that performs the state locking. The platform leverages locking, but it is not the direct feature for preventing concurrent state modifications.

Trap 3: State versioning in S3

State versioning in S3 automatically retains previous versions of the state file whenever it is updated or deleted, providing a crucial mechanism for disaster recovery and auditing. While versioning allows for rollbacks to earlier states and protects against accidental data loss, it does not prevent concurrent write operations from occurring. It addresses data integrity from a historical perspective, not from the perspective of preventing simultaneous modifications that could lead to state corruption.

A
The `-lock=false` flag
Why wrong: The `-lock=false` flag explicitly disables Terraform's state locking mechanism. This action is counterproductive for protecting state during concurrent operations, as it removes the safeguard designed to prevent multiple users or automated processes from simultaneously modifying the remote state file. Disabling locking significantly increases the risk of state file corruption, lost updates, and inconsistent infrastructure deployments in collaborative environments.
B
Terraform Cloud remote operations
Why wrong: Terraform Cloud remote operations refer to the execution environment where Terraform commands are run within the Terraform Cloud platform. While Terraform Cloud inherently provides robust state locking as part of its managed remote execution capabilities, 'remote operations' itself is a broad platform feature, not the specific underlying mechanism (like DynamoDB) that performs the state locking. The platform leverages locking, but it is not the direct feature for preventing concurrent state modifications.
C
State locking via DynamoDB
State locking via DynamoDB is the correct and recommended mechanism for protecting Terraform state when using an S3 backend. Terraform utilizes a DynamoDB table to acquire and release a distributed lock before and after state modifications, ensuring that only one `terraform apply` or `terraform destroy` operation can proceed at a time. This prevents race conditions, safeguards state consistency, and avoids corruption in shared development or production environments.
D
State versioning in S3
Why wrong: State versioning in S3 automatically retains previous versions of the state file whenever it is updated or deleted, providing a crucial mechanism for disaster recovery and auditing. While versioning allows for rollbacks to earlier states and protects against accidental data loss, it does not prevent concurrent write operations from occurring. It addresses data integrity from a historical perspective, not from the perspective of preventing simultaneous modifications that could lead to state corruption.

Question 9mediummultiple choice

A company uses Terraform with multiple workspaces (dev, staging, prod) and a remote backend in an S3 bucket with a DynamoDB lock table. The backend configuration is defined in the main.tf with partial configuration. Developers are required to provide the backend configuration via command-line flags during 'terraform init'. One developer accidentally ran 'terraform init' without the required flags on a Monday morning. The init succeeded and created a local state file in the project directory. Over the next few days, other team members made changes to the workspace and pushed updates to the remote state. The developer who ran local init then runs 'terraform plan' and sees a plan that would recreate all resources. They realize their mistake. How can this situation be prevented in the future?

Trap 1: Enable state locking on the local backend to prevent conflicts.

Enabling state locking on a local backend is ineffective for preventing conflicts across multiple users or CI/CD pipelines. Local state locking only applies to a single machine's execution, offering no protection against concurrent operations from other environments or users accessing different local state files. It does not facilitate shared state management or prevent state divergence when multiple parties are independently managing infrastructure, making it unsuitable for collaborative or multi-environment setups.

Trap 2: Add a 'terraform plan -check' step that warns if state is not…

The 'terraform plan' command does not include a '-check' flag or any built-in mechanism to explicitly warn if the state is not remote. Its primary function is to show the execution plan based on the *currently configured* backend, whether local or remote. While 'terraform init' is responsible for configuring the backend, 'terraform plan' itself does not validate the backend type, making this proposed step non-existent and ineffective for the stated goal of detecting non-remote state.

Trap 3: Use 'terraform workspace' commands to switch to the correct…

Using 'terraform workspace' commands primarily manages distinct named states *within* a single, already configured backend. Switching workspaces does not inherently configure or reconfigure the backend itself; it merely selects which specific state snapshot within that backend will be used for subsequent operations. Therefore, this action alone does not guarantee that a remote backend is being utilized or prevent the use of a local backend if 'terraform init' hasn't been properly configured for remote access.

A
Enable state locking on the local backend to prevent conflicts.
Why wrong: Enabling state locking on a local backend is ineffective for preventing conflicts across multiple users or CI/CD pipelines. Local state locking only applies to a single machine's execution, offering no protection against concurrent operations from other environments or users accessing different local state files. It does not facilitate shared state management or prevent state divergence when multiple parties are independently managing infrastructure, making it unsuitable for collaborative or multi-environment setups.
B
Implement a CI/CD pipeline that runs 'terraform init' with the correct backend config and enforces that only pipeline-initiated runs are allowed.
Implementing a CI/CD pipeline is the most robust solution for managing Terraform state across multiple workspaces and teams. The pipeline can be configured to explicitly run 'terraform init' with the correct remote backend configuration, ensuring all operations consistently use the designated shared state. Enforcing pipeline-initiated runs prevents individual developers from accidentally using local state or incorrect backend configurations, thereby centralizing state management, preventing divergence, and ensuring operational consistency.
C
Add a 'terraform plan -check' step that warns if state is not remote.
Why wrong: The 'terraform plan' command does not include a '-check' flag or any built-in mechanism to explicitly warn if the state is not remote. Its primary function is to show the execution plan based on the *currently configured* backend, whether local or remote. While 'terraform init' is responsible for configuring the backend, 'terraform plan' itself does not validate the backend type, making this proposed step non-existent and ineffective for the stated goal of detecting non-remote state.
D
Use 'terraform workspace' commands to switch to the correct workspace before running init.
Why wrong: Using 'terraform workspace' commands primarily manages distinct named states *within* a single, already configured backend. Switching workspaces does not inherently configure or reconfigure the backend itself; it merely selects which specific state snapshot within that backend will be used for subsequent operations. Therefore, this action alone does not guarantee that a remote backend is being utilized or prevent the use of a local backend if 'terraform init' hasn't been properly configured for remote access.

Question 10hardmultiple choice

Your team is developing a custom module for creating EC2 instances with attached EBS volumes. The module variables are: instance_type (default "t2.micro"), ami (required), volume_size (default 8), volume_type (default "gp2"). Another team uses this module to create a web server. In their root module, they call the module without any explicit instance_type override, but they do set other variables. After applying, the web server is created with instance_type "t2.nano" instead of the expected "t2.micro". They confirm that the module still has the default "t2.micro". What is the most likely explanation?

Trap 1: The module's instance_type variable uses a default that is…

This contradicts the given fact that the module's default is "t2.micro".

Trap 2: The instance_type variable is not defined in the module's…

If the variable is not defined, Terraform would return an error, not silently use a different value.

Trap 3: The module's variable default was changed to "t2.nano" in a new…

The scenario states the module's default is still "t2.micro".

A
The module's instance_type variable uses a default that is "t2.nano" but the root module overrode it with a variable from its own context.
Why wrong: This contradicts the given fact that the module's default is "t2.micro".
B
The instance_type variable is not defined in the module's variables.tf, so it uses a default from the AWS provider.
Why wrong: If the variable is not defined, Terraform would return an error, not silently use a different value.
C
The root module has a variable called instance_type set to "t2.nano" that is being passed to the module.
If the root module defines or inherits an instance_type variable with value "t2.nano", and the module block passes it (e.g., instance_type = var.instance_type), that overrides the module's default.
D
The module's variable default was changed to "t2.nano" in a new version.
Why wrong: The scenario states the module's default is still "t2.micro".

Question 11mediummultiple choice

An organization wants to use Terraform to manage resources across multiple accounts and regions, with different team members responsible for different environments. Which Terraform feature helps separate state and configuration for each environment?

Trap 1: Providers

Define cloud provider connections, not state separation.

Trap 2: Modules

Organize code but do not isolate state.

Trap 3: Backends

Store state but don't inherently separate environments.

A
Providers
Why wrong: Define cloud provider connections, not state separation.
B
Modules
Why wrong: Organize code but do not isolate state.
C
Workspaces
Create separate state files for each environment.
D
Backends
Why wrong: Store state but don't inherently separate environments.

Question 12mediummultiple choice

During 'terraform apply', a user receives an error: 'Error: Error creating resource: Resource already exists'. The resource does not appear in the Terraform state. What is the most likely cause?

Trap 1: The state file was migrated from a different backend and the…

State file migration primarily involves moving the metadata about managed resources from one backend location to another, not duplicating the resources themselves within the state or in the cloud provider. If a resource were truly duplicated within the state, Terraform would likely report a conflict during planning or an inability to manage the resource, rather than receiving a 'resource already exists' error from the cloud provider during a creation attempt. This error specifically indicates Terraform is trying to create something that already exists in the target environment.

Trap 2: The resource was removed from the configuration but not from state.

If a resource is present in the Terraform state file but subsequently removed from the configuration files, Terraform's plan will identify this resource as no longer desired. During the `terraform apply` operation, Terraform would then attempt to *destroy* this resource from the cloud provider environment to align with the updated configuration. This scenario would lead to a deletion action, not a failure to create due to the resource already existing.

Trap 3: The user forgot to run terraform refresh before apply.

`terraform refresh` updates the state file to reflect the current attributes of resources *already managed* by Terraform, detecting any drift from the last known state. It does not, however, discover or import resources that were created manually outside of Terraform and are therefore not present in the state file. Consequently, omitting `terraform refresh` would not prevent Terraform from attempting to create a resource it believes is missing, leading to the 'resource already exists' error if a manual creation occurred.

A
The state file was migrated from a different backend and the resource is duplicated.
Why wrong: State file migration primarily involves moving the metadata about managed resources from one backend location to another, not duplicating the resources themselves within the state or in the cloud provider. If a resource were truly duplicated within the state, Terraform would likely report a conflict during planning or an inability to manage the resource, rather than receiving a 'resource already exists' error from the cloud provider during a creation attempt. This error specifically indicates Terraform is trying to create something that already exists in the target environment.
B
The resource was removed from the configuration but not from state.
Why wrong: If a resource is present in the Terraform state file but subsequently removed from the configuration files, Terraform's plan will identify this resource as no longer desired. During the `terraform apply` operation, Terraform would then attempt to *destroy* this resource from the cloud provider environment to align with the updated configuration. This scenario would lead to a deletion action, not a failure to create due to the resource already existing.
C
The user forgot to run terraform refresh before apply.
Why wrong: `terraform refresh` updates the state file to reflect the current attributes of resources *already managed* by Terraform, detecting any drift from the last known state. It does not, however, discover or import resources that were created manually outside of Terraform and are therefore not present in the state file. Consequently, omitting `terraform refresh` would not prevent Terraform from attempting to create a resource it believes is missing, leading to the 'resource already exists' error if a manual creation occurred.
D
The resource was manually created outside of Terraform before the apply.
When Terraform executes `terraform apply`, it compares the desired state defined in the configuration with the known state recorded in its state file. If a resource is defined in the configuration but is entirely absent from the state file, Terraform assumes this resource needs to be provisioned. If an identical resource, perhaps with the same unique name or identifier, was previously created directly within the cloud provider environment, the cloud API will reject Terraform's creation request, resulting in an 'already exists' error.

Question 13hardmultiple choice

When running terraform plan, the output indicates that a resource will be replaced (destroy then create) due to a change in the 'name' attribute. However, the engineer only changed a tag. What is the most likely cause?

Trap 1: The tag change triggered a ForceNew attribute.

While some resource attributes are marked `ForceNew`, meaning any change necessitates resource replacement, tags are typically designed for in-place updates. Most cloud providers allow tags to be modified on existing resources without requiring their destruction and recreation. Therefore, a simple tag modification alone is highly unlikely to trigger a `ForceNew` behavior for the entire resource, which would cause replacement.

Trap 2: The resource has create_before_destroy enabled.

The `create_before_destroy` lifecycle setting dictates the *order* in which a replacement operation occurs, ensuring the new resource is provisioned successfully before the old one is terminated. It does not, however, *cause* a resource replacement. Replacement is triggered when a `ForceNew` attribute is modified, and `create_before_destroy` merely optimizes the transition for high availability, rather than initiating the replacement itself.

Trap 3: The underlying API does not support in-place updates.

While some cloud provider APIs indeed lack support for in-place updates for specific resource types or attributes, it is highly uncommon for an entire resource to be completely immutable for *all* its attributes. If the underlying API truly did not support *any* in-place updates, then *any* modification to *any* attribute, including simple tags, would invariably trigger a resource replacement. This scenario is generally rare, as most APIs allow at least some metadata or configuration changes without full resource recreation.

A
The tag change triggered a ForceNew attribute.
Why wrong: While some resource attributes are marked `ForceNew`, meaning any change necessitates resource replacement, tags are typically designed for in-place updates. Most cloud providers allow tags to be modified on existing resources without requiring their destruction and recreation. Therefore, a simple tag modification alone is highly unlikely to trigger a `ForceNew` behavior for the entire resource, which would cause replacement.
B
The resource has create_before_destroy enabled.
Why wrong: The `create_before_destroy` lifecycle setting dictates the *order* in which a replacement operation occurs, ensuring the new resource is provisioned successfully before the old one is terminated. It does not, however, *cause* a resource replacement. Replacement is triggered when a `ForceNew` attribute is modified, and `create_before_destroy` merely optimizes the transition for high availability, rather than initiating the replacement itself.
C
The 'name' attribute is computed and any change to the resource forces replacement.
Many resource types have core identifying attributes, such as 'name', that are immutable after initial creation. If the provider marks the 'name' attribute as `ForceNew`, any attempt to modify its value in the configuration will necessitate the destruction of the existing resource and the creation of a new one. Even if 'name' is `computed`, meaning its value is determined by the provider, if the provider's internal logic dictates that the resource's identity (often tied to its name) cannot be altered in-place, then any change impacting that identity will trigger replacement.
D
The underlying API does not support in-place updates.
Why wrong: While some cloud provider APIs indeed lack support for in-place updates for specific resource types or attributes, it is highly uncommon for an entire resource to be completely immutable for *all* its attributes. If the underlying API truly did not support *any* in-place updates, then *any* modification to *any* attribute, including simple tags, would invariably trigger a resource replacement. This scenario is generally rare, as most APIs allow at least some metadata or configuration changes without full resource recreation.

Question 14mediummulti select

Which TWO scenarios could cause 'terraform plan' to show 'No changes' even though the configuration file was recently modified? (Choose two.)

Trap 1: The resource was manually updated in the cloud provider console.

terraform plan inherently includes a refresh phase, where it queries the cloud provider to determine the actual current state of managed resources. If a resource was manually updated in the cloud provider console, this change would be detected as "drift" during the refresh. Terraform would then propose actions to bring the actual state back into alignment with the configuration, meaning the plan would show changes, not no changes, unless the refresh operation itself was explicitly suppressed.

Trap 2: A new resource block was added.

Adding a new resource block to the Terraform configuration explicitly declares a desired resource that does not yet exist in the Terraform state file or the cloud provider. When terraform plan is executed, it will identify this new declaration and propose a create action for that resource. Therefore, the plan output would clearly indicate the addition of a new resource, showing a change, rather than displaying no changes.

Trap 3: The provider version was changed in the required_providers block.

Changing the provider version in the required_providers block can potentially introduce new resource attributes, modify existing ones, or alter resource behavior due to API changes in the provider. After running terraform init -upgrade, a subsequent terraform plan would compare the existing state against the configuration interpreted by the new provider version. This comparison could lead to proposed updates, replacements, or even no-op changes if the new provider version has no impact on the configured resources, but it would not inherently result in "no changes" if the configuration itself was unchanged and the provider version change had an effect. It's highly unlikely to consistently show "no changes" if the change is significant enough to warrant a version bump.

A
The user ran 'terraform plan' from a different directory that does not contain the modified configuration.
terraform plan operates strictly within the current working directory, scanning for .tf configuration files to build its desired state. If a user executes terraform plan from a directory that does not contain the relevant configuration files, or an outdated set, Terraform will not detect any changes made to files in other directories. Consequently, the plan output will reflect no changes, as it's comparing the current state to an unchanged or non-existent desired state from its perspective.
B
A lifecycle block with ignore_changes was applied to the modified attribute.
When a lifecycle block with ignore_changes is configured for a specific attribute within a resource, Terraform is explicitly instructed to disregard any differences detected for that attribute between the current state and the desired configuration. If the modification made to the configuration affects an attribute listed in ignore_changes, Terraform will not register it as a pending change during terraform plan. This prevents Terraform from attempting to update or re-create the resource based on that particular attribute's divergence.
C
The resource was manually updated in the cloud provider console.
Why wrong: terraform plan inherently includes a refresh phase, where it queries the cloud provider to determine the actual current state of managed resources. If a resource was manually updated in the cloud provider console, this change would be detected as "drift" during the refresh. Terraform would then propose actions to bring the actual state back into alignment with the configuration, meaning the plan would show changes, not no changes, unless the refresh operation itself was explicitly suppressed.
D
A new resource block was added.
Why wrong: Adding a new resource block to the Terraform configuration explicitly declares a desired resource that does not yet exist in the Terraform state file or the cloud provider. When terraform plan is executed, it will identify this new declaration and propose a create action for that resource. Therefore, the plan output would clearly indicate the addition of a new resource, showing a change, rather than displaying no changes.
E
The provider version was changed in the required_providers block.
Why wrong: Changing the provider version in the required_providers block can potentially introduce new resource attributes, modify existing ones, or alter resource behavior due to API changes in the provider. After running terraform init -upgrade, a subsequent terraform plan would compare the existing state against the configuration interpreted by the new provider version. This comparison could lead to proposed updates, replacements, or even no-op changes if the new provider version has no impact on the configured resources, but it would not inherently result in "no changes" if the configuration itself was unchanged and the provider version change had an effect. It's highly unlikely to consistently show "no changes" if the change is significant enough to warrant a version bump.