Terraform-Associate-004 Questions and Answers

Terraform creates the .terraform.lock.hcl file after the first terraform init command. This lock file ensures that the dependencies for your project are consistent across different runs by locking the versions of the providers and modules used.

Rationale for Correct Answer: terraform output shows the root module’s outputs (the outputs defined in the current working directory’s root module). Outputs from child modules are not directly listed unless the root module re-exports them via its own output blocks (e.g., output "child_public_ip" { value = module.child.public_ip }).

Analysis of Incorrect Options (Distractors):

A (True): Incorrect because child module outputs are accessible via module..

, but terraform output displays only outputs defined in the root module.

Key Concept: Module outputs scope: child outputs must be exposed through root outputs to be shown by terraform output.

Rationale for Correct Answer: To expose values from a child module to a parent module, you define an output in the child module (e.g., output "public_ip" { value = aws_instance.example.public_ip }). The parent module can then reference it via module..public_ip.

Analysis of Incorrect Options (Distractors):

B: A data source in the parent could look up an instance, but that’s unnecessary and brittle compared to using module outputs (and may require extra identifiers).

C: Import is for bringing existing resources into state; it doesn’t expose attributes between modules.

D: Locals are only scoped within the module; they are not accessible from the parent.

Key Concept: Module composition: outputs are the contract for passing data from child to parent.

Rationale for Correct Answer (D):

The Terraform Registry provides documentation for published modules, including:

Required inputs (variables you must supply).

Optional inputs with defaults (so you know what you can override).

Outputs (what values the module returns for use elsewhere).

Therefore, the correct answer is all of the above.

Analysis of Incorrect Options:

A. Required inputs only: Incomplete.

B. Outputs only: Incomplete.

C. Optional inputs only: Incomplete.

D. All of the above: Correct because the Registry provides all relevant documentation.

Key Concept:

Terraform Registry modules include inputs, outputs, and usage details, enabling reusability and modular design.

Any user with permission to apply a plan can apply it, not only the user that generated it. This allows for collaboration and delegation of tasks among team members.

You can develop a custom provider to manage its resources using Terraform, as Terraform is an extensible tool that allows you to write your own plugins in Go language. You can also publish your custom provider to the Terraform Registry or use it privately.

Rationale for Correct Answer: terraform state rm

removes a resource from Terraform state without destroying the real infrastructure. After removal, Terraform “forgets” it and will no longer manage it (unless it’s re-imported). That matches the requirement: keep the resource, stop managing it.

Analysis of Incorrect Options (Distractors):

A: Removing the resource block causes Terraform to plan to destroy the resource (because it’s in state but no longer in config), which is the opposite of “keep it.”

B: Changing count can cause Terraform to destroy instances that no longer have an address (depending on indexing), and it doesn’t explicitly “stop managing” a specific existing instance safely.

D: moved blocks are for renaming/refactoring addresses while keeping management; they do not stop managing a resource.

Key Concept: Detaching resources from Terraform management using state subcommands (terraform state rm).

A module cannot always refer to all variables declared in its parent module, as it needs to explicitly declare input variables and assign values to them from the parent module’s arguments. A module cannot access the parent module’s variables directly, unless they are passed as input arguments.

Rationale for Correct Answer: terraform plan -refresh-only refreshes (reconciles) the state with the real infrastructure only for the purpose of the plan output. It does not persist (write) those updates to the state file. To actually update the stored state, you must run terraform apply -refresh-only (or a normal terraform apply). This matches the Terraform CLI objective: plan previews changes; apply makes changes (including writing state).

Analysis of Incorrect Options (Distractors):

A (True): Incorrect because terraform plan does not write state; it only calculates and displays what would change.

Key Concept: The plan vs apply workflow and when Terraform writes state.

The terraform import command is not part of any other Terraform workflow. It must be explicitly invoked by the user with the appropriate arguments, such as the resource address and the ID of the existing infrastructure to import. References = [Importing Infrastructure]

From the Terraform Output Docs – Sensitive:

"Marking an output as sensitive prevents Terraform from showing its value in the CLI output,but it will still bestored in the state file."

Thus, it protects display, not storage.

This is how the Terraform Cloud integration differs from other state backends such as S3, Consul, etc., as it allows you to perform remote operations on Terraform Cloud’s servers instead of your local machine. The other options are either incorrect or irrelevant.

This is the meta-argument that you must include in any non-default provider configurations, as it allows you to give a friendly name to the configuration and reference it in other parts of your code. The other options are either invalid or irrelevant for this purpose.

Rationale for Correct Answer: terraform graph outputs a Graphviz DOT representation of Terraform’s dependency graph, which you can pipe into Graphviz tools (e.g., dot) to visualize resource/module dependencies.

Analysis of Incorrect Options (Distractors):

B: terraform show displays state or a plan file in human-readable form (or JSON with -json), not DOT.

C: terraform refresh (deprecated as a standalone command in newer workflows) refreshes state, not graph output.

D: terraform output prints root module outputs, not dependency graphs.

Key Concept: Visualizing Terraform’s dependency graph using terraform graph.

Rationale for Correct Answer (D):

terraform state list shows all resources currently managed by Terraform. terraform state show provides detailed attributes, including the VM ID. This lets you match the Terraform-managed instance with the actual infrastructure.

Analysis of Incorrect Options:

A: Importing is not needed since one VM is already in state.

B: terraform apply doesn’t show which VM ID is managed, it only refreshes attributes.

C: Removing state entries is destructive and may lead to losing state data unnecessarily.

Key Concept:

The state file is Terraform’s source of truth for which resources it manages.

This is the best time to run terraform validate, as it will check your code for syntax errors, typos, and missing arguments before you attempt to create a plan. The other options are either incorrect or unnecessary.

Rationale for Correct Answer: A moved block tells Terraform that an object’s address in state has changed (renamed/refactored) and it should move the state from the old address to the new address. This preserves the existing real resource and prevents unnecessary destroy/recreate.

Analysis of Incorrect Options (Distractors):

A: Works but is unnecessarily risky/extra work; moved is the intended refactoring mechanism for renames.

B: Incorrect—refresh-only updates state to match real infrastructure, but it does not remap an object from one address to another.

C: Incorrect—Terraform will treat the new name as a new resource address and the old one as removed unless you explicitly move/rename state.

Key Concept: Refactoring addresses safely using moved blocks (state address migration).

Setting the TF_LOG environment variable to DEBUG causes debug messages to be logged into stdout, along with other log levels such as TRACE, INFO, WARN, and ERROR. This can be useful for troubleshooting or debugging purposes.

This is the best way to delete the newly-created VM with Terraform, as it will only affect the resource that was created by your configuration and state file. The other options are either incorrect or inefficient.

A secure string is not a valid option to keep secrets out of Terraform configuration files. A secure string is a feature of AWS Systems Manager Parameter Store that allows you to store sensitive data encrypted with a KMS key. However, Terraform does not support secure strings natively and requires a custom data source to retrieve them. The other options are valid ways to keep secrets out of Terraform configuration files. A Terraform provider can expose secrets as data sources that can be referenced in the configuration. Environment variables can be used to set values for input variables that contain secrets. A -var flag can be used to pass values for input variables that contain secrets from the command line or a file. References = [AWS Systems Manager Parameter Store], [Terraform AWS Provider Issue #55], [Terraform Providers], [Terraform Input Variables]

Rationale for Correct Answer:When multiple provider configurations are defined using an alias, Terraform requires the provider meta-argument inside the resource block to explicitly reference the aliased provider.In this case, the provider is defined as aws with alias = "west", so resources targeting us-west-2 must specify:

provider = aws.west

This tells Terraform exactly which provider configuration to use.

Analysis of Incorrect Options (Distractors):

B. alias = aws.west: Incorrect — alias is only used inside the provider block, not in resources.

C. provider = west: Incorrect — Terraform requires the full provider name (aws.west), not just the alias.

D. alias = west: Incorrect — resources do not support an alias meta-argument.

Key Concept:Using aliased provider configurations and the provider meta-argument to deploy resources across multiple regions or accounts.

Rationale for Correct Answer:terraform init initializes backends, downloads providers, and retrieves modules — but it does not generate or create configuration files.

Analysis of Incorrect Options (Distractors):

A: Correct action performed by terraform init.

C: Providers are downloaded during initialization.

D: Module source code is fetched during initialization.

Key Concept:terraform init prepares the working directory but does not create configuration.

The reason why the apply fails after adding a new provider to the configuration and immediately running terraform apply in the CD using the local backend is because Terraform needs to install the necessary plugins first. Terraform providers are plugins that Terraform uses to interact with various cloud services and other APIs. Each provider has a source address that determines where to downloadit from. When Terraform encounters a new provider in the configuration, it needs to run terraform init first to install the provider plugins in a local directory. Without the plugins, Terraform cannot communicate with the provider and perform the desired actions. References = [Provider Requirements], [Provider Installation]

A Terraformbackenddetermineswhere and how Terraform state is stored.

Bothterraform applyandterraform destroyinteract with state, so Terraform needs access to the backend for state storage and updates.

D (Neither are correct)is incorrect becauseTerraform state is required for both apply and destroy operations.

Official Terraform Documentation Reference:

Terraform Backends

Rationale for Correct Answers:

C. terraform.tfvars securely managed: Acceptable if distributed securely outside version control.

D. HCP Terraform/Terraform Cloud sensitive variables: Official best practice for team-based workflows.

E. Vault: HashiCorp Vault is designed for secret management and integrates well with Terraform.

Analysis of Incorrect Options:

A: Storing plaintext secrets on shared drives is insecure.

B: Checking secrets into version control is a major security risk.

Key Concept:

Sensitive values should be managed securely in Vault, HCP Terraform, or securely shared .tfvars files — never in plaintext or version control.

Rationale for Correct Answer: Terraform uses a declarative approach: you define the desired end state of infrastructure in configuration files that can be version-controlled and repeatedly applied. Terraform then computes an execution plan to reach that state. This is a key distinction from ad-hoc API calls or hand-written scripts that typically manage infrastructure in a more imperative and less state-aware way.

Analysis of Incorrect Options (Distractors):

B: Incorrect because Terraform is not “merely a wrapper.” It provides a workflow (state, diff/plan, dependency graph, drift detection) that fundamentally changes how infrastructure is managed.

C: Incorrect because Terraform does not replace provider APIs; providers still use the underlying cloud/service APIs.

D: Incorrect because Terraform is primarily declarative, not imperative scripting to force a specific order (ordering is derived from dependencies).

Key Concept: Declarative desired-state configuration, plan/apply workflow, and version-controlled IaC.

This is the backend that the Terraform CLI uses by default, unless you specify a different backend in your configuration. The local backend stores the state file in a local file named terraform.tfstate, which can be used to track and manage the state of your infrastructure.

The terraform plan command does not update the state file. Instead, it reads the current state and the configuration files to determine what changes would be made to bring the real-world infrastructure into the desired state defined in the configuration. The plan operation is a read-only operation and does not modify the state or the infrastructure. It is the terraform apply command that actually applies changes and updates the state file.References = Terraform's official guidelines and documentation clarify the purpose of the terraform plan command, highlighting its role in preparing and showing an execution plan without making any changes to the actual state or infrastructure .

terraform validateonlychecks the configuration’s syntax and internal consistency—itdoes notinteract with provider APIs or check if the infrastructure settings are correct.

It ensures that the Terraform code is syntactically correct and follows proper HCL structure.

However, it doesnotverify if resources are valid according to the provider API or if the credentials are correct.

To verify actual infrastructure settings, use terraform plan, which interacts with the provider APIs.

Official Terraform Documentation Reference:

terraform validate - HashiCorp Documentation

None of the above methods prevent credentials from being stored in the state file. Terraform stores the provider configuration in the state file, which may include sensitive information such as credentials. This is a potential security risk and should be avoided if possible. To prevent credentials from being stored in the state file, you can use one of the following methods:

Use environment variables to pass credentials to the provider. This way, the credentials are not part of the provider configuration and are not stored in the state file. However, this method may not work for some providers that require credentials to be set in the provider block.

Use dynamic credentials to authenticate with your cloud provider. This way, Terraform Cloud or Enterprise will request temporary credentials from your cloud provider for each run and use them to provision your resources. The credentials are not stored in the state file and are revoked after the run is completed. This method is supported for AWS, Google Cloud Platform, Azure, and Vault. References = : [Sensitive Values in State] : Authenticate providers with dynamic credentials

Rationale for Correct Answer: Data sources are referenced with: data....For a vSphere datacenter data source, the correct reference to its id is:data.vsphere_datacenter..id.✅ Given the options, only A follows the correct data-source addressing pattern and includes the .id attribute.

Analysis of Incorrect Options (Distractors):

B: Incorrect—missing the data. prefix, so it looks like a managed resource reference.

C: Incorrect—missing the attribute (.id).

D: Incorrect—missing the data source type and name.

Key Concept: Correct HCL reference syntax for data sources.

This is where Terraform saves resource state when using a remote backend or Terraform Cloud integration, as it allows you to store and manage your state file in a remote location, such as a cloud storage service or Terraform Cloud’s servers. This enables collaboration, security, and scalability for your Terraform infrastructure.

The terraform import command allows Terraform to takeexistinginfrastructure andbring it under Terraform’s management.

A (terraform get)is incorrect because it is used to fetch modules.

B (terraform refresh)is incorrect because it only updates Terraform's state to match the infrastructure but does not import resources.

D (terraform init)is incorrect because it only initializes the Terraform working directory.

Official Terraform Documentation Reference:

terraform import - HashiCorp Documentation

Inrefresh-only mode(terraform apply -refresh-only), Terraformupdates the state fileto match the actual infrastructurewithout modifying resources.

A (Terraform configuration)–Not modifiedin refresh-only mode.

B (Terraform plan)–Plan is generated but not modified.

D (Cloud infrastructure)–Not modifiedin refresh-only mode.

Official Terraform Documentation Reference:

Refresh-Only Mode

Rationale for Correct Answer: A private registry in HCP Terraform is designed to publish and share modules within an organization (with org access controls), rather than publicly. That supports internal reuse while keeping module content and usage confined to authorized users in the org.

Analysis of Incorrect Options (Distractors):

B (False): Incorrect—confidential/internal distribution is a primary purpose of private registries.

Key Concept: Public vs private module registries and organizational access control.

You can configure a backend in your Terraform code before initializing it. Initializing a backend will store the state file remotely and enable features like locking and workspaces. References = [Terraform Backends]

This is the command that always causes a state file to be updated with changes that might have been made outside of Terraform, as it will only refresh the state file with the current status of the real resources, without making any changes to them or creating a plan.

The module source path that does not specify a remote module is source = "module/consul". This specifies a local module, which is a module that is stored in a subdirectory of the current working directory. The other options are all examples of remote modules, which are modules that are stored outside of the current working directory and can be accessed by various protocols, such as Git, HTTP, or the Terraform Registry. Remote modules are useful for sharing and reusing code across different configurations and environments. References = [Module Sources], [Local Paths], [Terraform Registry], [Generic Git Repository], [GitHub]

The error messageindicates an authentication issue (403 - Access Denied), which requiresdebugging Terraform logs.

Setting TF_LOG=DEBUG enablesdetailed logs, providing insights into API requests, state loading, and authentication errors.

Terraformdoes not log errors in /var/log/terraform.log or syslog, making optionsC and D incorrect.

A (terraform login)is only relevant forTerraform Cloud, but this error appears to be related toprovider authentication.

Official Terraform Documentation Reference:

Debugging Terraform

You should run terraform fmt to rewrite all Terraform configurations within the current working directory to conform to Terraform-style conventions. This command applies a subset of the Terraform language style conventions, along with other minor adjustments for readability. It is recommended to use this command to ensure consistency of style across different Terraform codebases. The command is optional, opinionated, and has no customization options, but it can help you and your team understand the code more quickly and easily. References = : Command: fmt : Using Terraform fmt Command to Format Your Terraform Code

This is how Terraform chooses which version of the provider to use, when you add a new resource to an existing Terraform configuration, but do not update the version constraint in the configuration. The lock file records the exact version of each provider that was installed in your working directory, and ensures that Terraform will always use the same provider versions until you run terraform init -upgrade to update them.

Terraform providers are not part of the Terraform core binary. Providers are distributed separately from Terraform itself and have their own release cadence and version numbers. Providers are plugins that Terraform uses to interact with various APIs, such as cloud providers, SaaS providers, and other services. You can find and install providers from the Terraform Registry, which hosts providers for most major infrastructure platforms. You can also load providers from a local mirror or cache, or develop your own custom providers. To use a provider in your Terraform configuration, you need to declare it in the provider requirements block and optionally configure its settings in the provider block. References = : Providers - Configuration Language | Terraform : Terraform Registry - Providers Overview | Terraform

Rationale for Correct Answer (D):

The terraform.lock.hcl file is automatically created and maintained by Terraform. It records the specific versions and checksums of providers used in a configuration, ensuring consistent runs across environments and machines.

Analysis of Incorrect Options:

A. There is no such file: Incorrect — the lock file exists and is crucial for dependency management.

B. Storing references to workspaces: Incorrect — workspaces are tracked in the state file, not the lock file.

C. Preventing Terraform runs: Incorrect — the lock file does not block runs; it enforces consistent provider versions.

Key Concept:

The terraform.lock.hcl file enforces provider version consistency, which is critical for reproducible and reliable Terraform deployments.

Rationale for Correct Answer: With immutable infrastructure, you don’t modify running servers/resources in place; you replace them with new versions built from a known image/artifact. This reduces configuration drift and “snowflake” issues, making deployments and rollbacks more predictable—often resulting in less operational complexity compared with troubleshooting in-place changes.

Analysis of Incorrect Options (Distractors):

A: Incorrect—immutable infrastructure specifically avoids in-place upgrades.

B: Not the best answer—upgrades can be fast in some setups, but “quicker” is not guaranteed; replacing infrastructure may take time depending on provisioning and rollout strategy.

C: Incorrect—immutability doesn’t inherently mean upgrades are “automatic”; automation is a separate practice/tooling choice.

Key Concept: Immutable vs mutable infrastructure; replace instead of modify to reduce drift and simplify operations.

Rationale for Correct Answer:

B: Providers can manage on-premises services (e.g., vSphere, Kubernetes, GitHub, DNS, databases), not just public cloud.

C: Providers provision and manage public cloud resources (AWS, Azure, Google Cloud, etc.).

D: Providers are the plugin layer that interacts with APIs (cloud/service APIs) to create, read, update, and delete resources.

Analysis of Incorrect Options (Distractors):

A: This describes how Terraform configuration and state are organized (root module/workspace/state), not a provider function.

E: Policy enforcement is handled by separate policy-as-code systems (e.g., Sentinel/OPA integrations) rather than being a core provider responsibility.

Key Concept: Providers as plugins that implement resource/data source types and perform API interactions for many platforms.

You should use the force-unlock command when automatic unlocking failed. Terraform will lock your state for all operations that could write state, such as plan, apply, or destroy. This prevents others from acquiring the lock and potentially corrupting your state. State locking happens automatically on all operations that could write state and you won’t see any message that it is happening. If state locking fails, Terraform will not continue. You can disable state locking for most commands with the -lock flag but it is not recommended. If acquiring the lock is taking longer than expected, Terraform will output a status message. If Terraform doesn’t output a message, state locking is still occurring if your backend supports it. Terraform has a force-unlock command to manually unlock the state if unlocking failed. Be very careful with this command. If you unlock the state when someone else is holding the lock it could cause multiple writers. Force unlock should only be used to unlock your own lock in the situation where automatic unlocking failed. To protect you, the force-unlock command requires a unique lock ID. Terraform will output this lock ID if unlocking fails. This lock ID acts as a nonce, ensuring that locks and unlocks target the correct lock. The other situations are not valid reasons to use the force-unlock command. You should not use the force-unlock command if you have a high priority change, if apply failed due to a state lock, or if you see a status message that you cannot acquire the lock. These situations indicate that someone else is holding the lock and you should wait for them to finish theiroperation or contact them to resolve the issue. Using the force-unlock command in these cases could result in data loss or inconsistency. References = [State Locking], [Command: force-unlock]

Running terraform fmt without any flags in a directory with Terraform configuration files will not check the formatting of those files without changing their contents, but will actually rewrite them to a canonical format and style. If you want to check the formatting without making changes, you need to use the -check flag.

You do not need to use different Terraform commands depending on the cloud provider you use. Terraform commands are consistent across different providers, as they operate on the Terraform configuration files and state files, not on the provider APIs directly.

Sentinel is a policy-as-code framework that integrates with Terraform Cloud to enforce security, compliance, and governance rules. You can enforce rules such as approved AMIs and ensure security best practices. Policies are written in the Sentinel language, not HCL.

Rationale for Correct Answer: Locals are evaluated as expressions, and one local can reference another using local.. This supports building up derived values cleanly:

locals {

env = "prod"

app_name = "api-${local.env}"

}

Analysis of Incorrect Options (Distractors):

B (False): Incorrect—Terraform explicitly supports local-to-local references.

Key Concept: Local values (locals) and expression references.

Rationale for Correct Answer:Terraform detects drift by refreshing state during terraform apply. Since the VM no longer exists but is still declared in configuration, Terraform will plan and recreate the missing resource.

Analysis of Incorrect Options (Distractors):

B. Error: Terraform treats this as drift, not an error.

C. Remove from state: Terraform does not remove resources automatically unless instructed.

D. No changes: Incorrect because drift is detected and corrected.

Key Concept:Terraform enforces the desired state defined in configuration, correcting drift automatically.

Rationale for Correct Answer (C):

Version constraints must be specified with = and quotes, e.g.:

version = ">= 3.1"

This ensures compatibility with Terraform’s syntax.

Analysis of Incorrect Options:

A, B: Incorrect syntax, missing quotes or wrong operator format.

C: Correct Terraform syntax.

Key Concept:

Correct syntax in provider version constraints ensures reproducibility.

Destroy Command Options: Theterraform destroycommand is the correct method to destroy resources, and it requires either manual approval or the -auto-approve flag.

Unsupported Triggering Method: The--destroy flagis not a recognized option for plan or apply commands, making B the correct answer as it isnota valid way to initiate resource destruction.

For more on destroying resources, refer to theterraform destroy command documentationin the Terraform CLI reference.

The terraform import command is used to import existing infrastructure into your Terraform state. This command takes the existing resource and associates it with a resource defined in your Terraform configuration, updating the state file accordingly. It does not generate configuration for the resource, only the state.

This will enable additional logging messages to find out from which paths Terraform is loading providers referenced in your Terraform configuration files, as it will set the log level to TRACE, which is the most verbose and detailed level.

Rationale for Correct Answer: To save an execution plan to a file, Terraform uses the -out flag: terraform plan -out=tfplan. That produces a plan file that can later be applied with terraform apply tfplan.

Analysis of Incorrect Options (Distractors):

A: This is an apply command with a variable file flag; it does not create a plan file.

B: -target expects a resource address (like aws_instance.example), not a plan filename.

C: -generate-config-out is used with configuration generation workflows (e.g., from import), not for saving a plan.

Key Concept: Creating and saving plan files with terraform plan -out=....

In Terraform, a data block is used to fetch or compute information from external sources for use elsewhere in the Terraform configuration. Unlike resource blocks that manage infrastructure, data blocks gather information without directly managing any resources. This can include querying for data from cloud providers, external APIs, or other Terraform states.References = This definition and usage of data blocks are covered in Terraform's official documentation, highlighting their role in fetching external information to inform Terraform configurations.

Rationale for Correct Answer (B):

IaC best practice is to manage infrastructure through version-controlled code. Changes should be reviewed and approved (via PRs), ensuring collaboration, traceability, and automation.

Analysis of Incorrect Options:

A, D, E: Making direct/manual changes bypasses IaC practices and causes drift.

C: Running code without PR review skips collaboration and approval.

Key Concept:

Infrastructure as Code emphasizes version control + peer review + automation.

Terraform providers are not always installed from the Internet. There are other ways to install provider plugins, such as from a local mirror or cache, from a local filesystem directory, or from a network filesystem. These methods can be useful for offline or air-gapped environments, or for customizing the installation process. You can configure the provider installation methods using the provider_installation block in the CLI configuration file.

It lets you version, reuse, and share infrastructure configuration as code files, which can be stored in a source control system and integrated with your CI/CD pipeline.

It reduces risk of operator error by automating repetitive tasks and ensuring consistency across environments. IaC does not necessarily provision resources at a lower cost, secure your credentials, or prevent manual modifications to your resources - these depend on other factors such as your cloud provider, your security practices, and your access policies.

This is not true, as modules can be either public or private, depending on your needs and preferences. You can use the Terraform Registry to publish and consume public modules, or use Terraform Cloud or Terraform Enterprise to host and manage private modules.

Not all standard backend types support state locking and remote operations like plan, apply, and destroy. For example, the local backend does not support remote operations and state locking. State locking is a feature that ensures that no two users can make changes to the state file at the same time, which is crucial for preventing race conditions. Remote operations allow running Terraform commands on a remote server, which is supported by some backends like remote or consul, but not all.

This command will upgrade the plugins to the latest acceptable version within the version constraints specified in the configuration. The other commands do not have an -upgrade option.

Rationale for Correct Answer: Terraform logging is controlled via environment variables. TF_LOG sets the verbosity (e.g., DEBUG), and TF_LOG_PATH directs Terraform to write those logs to a specified file path. This is part of Terraform CLI troubleshooting and operational usage.

Analysis of Incorrect Options (Distractors):

B (Update the Terraform CLI configuration file): The CLI config can control some behaviors (credentials helpers, plugin cache, etc.), but log-to-file is specifically handled by TF_LOG_PATH.

C (Add a path argument to the terraform block): The terraform block configures required versions, required providers, and backends—not CLI logging output.

D (Run the terraform output command): terraform output displays output values from state; it has nothing to do with logging.

Key Concept: Terraform debugging and logging via environment variables (TF_LOG, TF_LOG_PATH).

You can install third party plugins using terraform init, as long as you specify the plugin directory in your configuration or as a command-line argument. You can also use the terraform providers mirror command to create a local mirror of providers from any source.

According to theofficial Terraform documentationhere:

????Terraform Docs – Declaring an Output Value

In Terraform 0.12 and later, you can directly use expressions in outputs without interpolation syntax:

output "instance_ip_addr" {

value = aws_instance.server.private_ip

}

This aligns perfectly withOption A:

output "instance_ip_addr" {

value = aws_instance.main.private_ip

}

Why not the others?

❌Option B: Incorrect syntax. "${main.private_ip}" is referencing main as if it were a global variable or resource, but it isn’t defined. Plus, the output name is oddly written as aws_instance.instance_ip_addr, which is not a valid identifier format.

❌Option C: Although valid in older versions (<= 0.11), interpolation with "${}" isdeprecatedin Terraform 0.12+. The docs clearly advise using direct expressions instead.

❌Option D: Terraform hasno return statement; this is syntactically invalid in Terraform’s HCL.

The command that makes your code more human readable is terraform fmt. This command is used to rewrite Terraform configuration files to a canonical format and style, following the Terraform language style conventions and other minor adjustments for readability. The command is optional, opinionated, and has no customization options, but it is recommended to ensure consistency of style across different Terraform codebases. Consistency can help your team understand the code more quickly and easily, making the use of terraform fmt very important. You can run this command on your configuration files before committing them to source control or as part of your CI/CD pipeline. References = : Command: fmt : Using Terraform fmt Command to Format Your Terraform Code

The terraform apply command changes both the cloud infrastructure and the state file after you approve the execution plan. The command creates, updates, or destroys the infrastructure resources to match theconfiguration. It also updates the state file to reflect the new state of the infrastructure. The .terraform directory, the execution plan, and the Terraform code are not changed by the terraform apply command. References = Command: apply and Purpose of Terraform State

You can configure Terraform to log to a file using the TF_LOG environment variable. This variable can be set to one of the log levels: TRACE, DEBUG, INFO, WARN or ERROR. You can also use the TF_LOG_PATH environment variable to specify a custom log file location. References = : Debugging Terraform

Rationale for Correct Answer: Data sources are referenced using the address format:data...Here, the type is aws_ami, the name is web, and the attribute is id, so the correct reference is data.aws_ami.web.id.

Analysis of Incorrect Options (Distractors):

A (aws_ami.web.id): Incorrect because it omits the required data. prefix. This looks like a managed resource reference, not a data source.

B (web.id): Incorrect because Terraform references must include the full address (type and name); web alone is ambiguous.

D (data.web.id): Incorrect because it omits the data source type (aws_ami).

Key Concept: Terraform addressing and attribute references for data sources.

The terraform validate command is used to check that your Terraform configuration files are syntactically valid and internally consistent. It is a useful command for ensuring your Terraform code is error-free before applying any changes to your infrastructure.

Rationale for Correct Answer (C):

Credentials should not be hardcoded in Terraform files. Best practice is to configure them via environment variables or secret managers.

Analysis of Incorrect Options:

A: Shared servers introduce risk and drift.

B: Storing secrets in config/version control is insecure.

D: Incorrect since option C is valid.

Key Concept:

Separation of credentials from code is a Terraform security best practice.

From the Terraform Provider Requirements:

">= 3.0" means any versiongreater than or equal to 3.0— including 4.x and beyond.

A (wrong): Would need >= 3.0, < 4.0

C/D (wrong): > excludes 3.0 — not what’s written.

The Terraform binary version and provider versions do not have to match each other in a single configuration. Terraform allows you to specify provider version constraints in the configuration’s terraform block, which can be different from the Terraform binary version1. Terraform will use the newest version of the provider that meets the configuration’s version constraints2. You can also use the dependency lock file to ensure Terraform is using the correct provider version3. References =

•1: Providers - Configuration Language | Terraform | HashiCorp Developer

•2: Multiple provider versions with Terraform - Stack Overflow

•3: Lock and upgrade provider versions | Terraform - HashiCorp Developer

To see all the resources that Terraform will delete, you can use either of these two commands:

terraform destroy will show the plan of destruction and ask for your confirmation before proceeding. You can cancel the command if you do not want to destroy the resources.

terraform plan -destroy will show the plan of destruction without asking for confirmation. You can use this command to review the changes before running terraform destroy. References = : Destroy Infrastructure : Plan Command: Options

You need to write Terraform configuration files for the existing infrastructure that you want to import into Terraform, otherwise Terraform will not know how to manage it. The configuration files should match the type and name of the resources that you want to import.

Rationale for Correct Answer: terraform init initializes the working directory: it sets up the backend, downloads providers, and installs modules. It does not validate that required input variables have values—that check occurs when running commands that evaluate the configuration (typically plan/apply), and terraform validate checks configuration structure, not whether you supplied runtime variable values.

Analysis of Incorrect Options (Distractors):

A: Yes—init installs required providers.

C: Yes—init initializes and configures the backend.

D: Yes—init retrieves and installs modules referenced by module blocks.

Key Concept: What terraform init does vs what happens at plan/apply time.

In Terraform, the correct way to reference a resource attribute is:

pgsql

CopyEdit

resource_type.resource_name.attribute

For example, if the resource block is:

hcl

CopyEdit

resource "kubernetes_namespace" "example" {

metadata {

name = "my-namespace"

}

}

To reference the name attribute, use:

pgsql

CopyEdit

kubernetes_namespace.example.name

Explanation of incorrect answers:

A (resource.kubernetes_namespace.example.name)– Incorrect. Terraform does not use the resource. prefix when referencing resources.

C (data.kubernetes.namespace.name)– Incorrect. This syntax is used fordata sources, not resources.

D (kubernetes_namespace.test.name)– Incorrect. The resource name is "example", not "test".

Official Terraform Documentation Reference:

Terraform Resource References

terraform apply can runwithout explicitly running terraform plan first.

Running terraform plan before apply isrecommendedbutnot mandatory.

If no plan file is provided, terraform applyautomatically creates and executes a planbefore applying changes.

Official Terraform Documentation Reference:

terraform apply - HashiCorp Documentation

This command will initialize the new backend and prompt you to migrate the existing state file to the new location3. The other commands are not relevant for this task.

This is the type of block that is used to construct a collection of nested configuration blocks, by using a for_each argument to iterate over a collection value and generate a nested block for each element. For example, you can use a dynamic block to create multiple ingress rules for a security group resource.

To import the contents of a local file as a string in Terraform, you can use the built-in file function. By specifying file("id_rsa.pub"), Terraform reads the contents of the id_rsa.pub file and uses it as a string within your Terraform configuration. This function is particularly useful for scenarios where you need to include file data directly into your configuration, such as including an SSH public key for provisioning cloud instances.References = This information is a standard part of Terraform's functionality with built-in functions, as outlined in Terraform's official documentation and commonly used in various Terraform configurations.

C (✅Correct)– InHCP Terraform, you can use the terraform_remote_state data source to referenceanother workspace's state. This feature isnot available in Terraform CLI.

A (❌Incorrect)– terraform plan (dry runs)is available in both Terraform CLI and HCP Terraform.

B (❌Incorrect)– Secure variable storageexists in HCP Terraform, but CLI users can store variables securely using environment variables or .tfvars files.

D (❌Incorrect)– BothTerraform CLI and HCP Terraform support multiple cloud providers.

Official Terraform Documentation Reference:

terraform_remote_state - HashiCorp Documentation

Child modulesdo not automatically inheritvariables from the parent module.

To pass values from theparent moduleto thechild module, you mustexplicitly define input variablesin the child module and pass them in the parent module.

Example:

hcl

CopyEdit

module "example" {

source = "./child_module"

var1 = "value"

}

Official Terraform Documentation Reference:

Passing Variables to Modules