Select Two (Multi-Select) Questions

Defining a resource

Why it fails: The for expression produces a value — a list, map, or set — from an existing collection; it cannot declare infrastructure. Resource blocks are defined with resource syntax, while for expressions appear inside arguments, outputs, and locals to transform collections.

Managing provider blocks

Why it fails: Provider blocks are static configuration blocks; no for expression can generate them, and provider requirements are declared in required_providers. The for expression instead transforms collections into lists or maps, for example building a map of subnet IDs from a variable.

Creating dynamic blocks

Why it fails: Dynamic blocks are generated with the dynamic block and for_each argument, not the for expression, which returns a value rather than nesting configuration. The for expression is used to build lists and maps inside arguments, such as transforming a variable into a local value.

Code linting.

Why it fails: Code linting is not a run pipeline stage; it belongs to CI checks before a run is queued. It is tempting because quality gates feel pipeline-like, but HCP Terraform's stages are plan, policy check and apply.

Automatic refactoring.

Why it fails: Automatic refactoring is not a run pipeline stage; HCP Terraform does not rewrite configuration during a run. It is tempting because tooling can suggest improvements, but the pipeline stages are plan, policy check and apply.

State migration.

Why it fails: State migration is not a run pipeline stage; it is a separate operation performed when moving state between workspaces or backends. It is tempting because state handling is central to Terraform, but the pipeline stages are plan, policy check and apply.

It is only compatible with the AWS provider.

Why it fails: ignore_changes is a core Terraform meta-argument, provider-agnostic and usable with any provider, so AWS-only compatibility is false. Its real constraints involve attributes populated by remote APIs or references, which is why it is often reached for when managing resources created outside Terraform.

It requires all attributes to be ignored.

Why it fails: ignore_changes accepts a selective list of attribute names, and even the wildcard form is optional, so requiring all attributes is false. Selective ignoring is exactly its purpose, typically applied to attributes mutated by autoscaling or external tooling while the remainder stay managed.

It only works with primitive types.

Why it fails: ignore_changes accepts any attribute type, including lists, maps and nested blocks, so primitive-only support is false. The genuine limitations concern computed attributes and referenced values, which is why practitioners sometimes believe type restrictions exist when nested blocks behave unexpectedly during planning.

Local execution only

Why it fails: HCP Terraform's benefit is remote execution, which runs plans and applies consistently on managed runners rather than an engineer's workstation. Local execution only is what plain Terraform CLI already does, so it adds nothing for teams. Remote runs would be chosen when you need shared state locking and audit trails.

No need for version control

Why it fails: HCP Terraform integrates with VCS providers to trigger runs from commits, so version control remains essential rather than eliminated. Dropping version control removes the change history and review workflow that the platform is built around. It would suit a solo throwaway experiment, not collaborative team infrastructure.

Lower costs

Why it fails: HCP Terraform pricing scales with resources under management, so it does not inherently lower costs versus self-managed runners. It is tempting because consolidating state and runs may reduce operational overhead, and it would be correct if the question asked about reducing infrastructure management effort rather than cost.

Increasing performance of the Terraform CLI.

Why it fails: Provider instances change which account, region or role a resource targets; they do not affect CLI execution speed, which depends on parallelism and graph size. It is tempting because splitting work across accounts can look like load distribution, but performance is not a reason to declare aliased providers.

Installing multiple versions of the same provider.

Why it fails: Provider instances are separate configurations of one provider, not separate binaries; version selection happens through required_providers constraints and the lock file. It is tempting because version pinning is a genuine Terraform concern, but multiple instances exist to target distinct accounts, regions or roles.

Bypassing the need for a state file.

Why it fails: State files remain mandatory for every Terraform configuration; provider instances only alter which credentials or endpoints a resource uses. It is tempting because aliased providers feel like parallel contexts, but they still write into the same state, and bypassing state is not a supported outcome.

Defining the provider inside the module's 'main.tf'.

Why it fails: Declaring the provider inside the child module creates its own configuration rather than receiving the parent's, so aliases, credentials and region from the caller are ignored. It tempts because modules do contain provider blocks, but that pattern suits standalone reusable modules, not inherited configuration.

Passing the provider as a string input variable.

Why it fails: Provider configurations are passed as blocks or via the providers map, not as string variables; a string cannot carry provider schema, aliases or credentials. It tempts because variables do parameterise modules, but they pass values, not provider objects.

Using a global variable for provider credentials.

Why it fails: Global variables cannot carry provider configurations; Terraform has no global variable construct, and credentials supplied this way bypass provider aliasing and the providers map entirely. It tempts because centralising credentials sounds tidy, but that role belongs to the provider block or environment variables.

Add a `provider "aws"` block with a `version` argument set to the desired minor version.

Why it fails: The `version` argument inside a `provider` block is not a valid way to constrain provider versions in modern Terraform; version constraints belong in the `required_providers` block. Using it here would either be ignored or produce a configuration error, so it does not contribute to pinning the provider version.

Set the `TF_CLI_CONFIG_FILE` environment variable to point at a file that contains the provider version constraint.

Why it fails: The CLI configuration file governs provider installation methods, mirrors, and plugin cache settings, not version constraints for a specific configuration. Version constraints must be declared in the configuration's `required_providers` block, so this action does not pin the AWS provider version as required.

Run `terraform providers lock -platform=linux_amd64` to generate checksums for all platforms.

Why it fails: `terraform providers lock` generates or updates the lock file with checksums, but specifying a single platform limits coverage to that platform. It also does not by itself pin the version; that comes from the version constraint. While useful in some workflows, it does not satisfy the two required actions in this scenario.

It is used to store the state file.

Why it fails: State is stored in a backend such as an Azure Storage container, S3 bucket or Terraform Cloud, not in the lock file. The lock file pins provider versions and hashes to make installs reproducible. Confusing the two is tempting because both are generated artefacts kept alongside configuration in version control.

It can only be edited manually.

Why it fails: Terraform writes and updates the lock file automatically during init and provider upgrades, so manual editing is not the only route; the CLI maintains it. Manual editing is tempting because the file is human-readable HCL, but it records provider version selections and hashes, not hand-authored configuration.

It stores secret credentials.

Why it fails: The lock file records provider source addresses, version constraints and cryptographic hashes only; credentials belong in environment variables, credential files or a secrets manager. Storing secrets is tempting because the file is committed to version control, yet it deliberately contains no sensitive values for that reason.

To increase the speed of the provider download

Why it fails: Provider download speed is determined by network bandwidth and registry proximity, not by which agent executes the run. Agents are chosen to reach private networks or isolated environments. Faster downloads are tempting because agents cache plugins, but caching affects subsequent runs, not the download rate itself.

To remove the need for a VCS

Why it fails: Agents still require a VCS source.

split_map()

Why it fails: split_map() is not a Terraform function; no such built-in exists, so it cannot transform data. It is tempting because split() and map-like functions do exist, and split() would be correct when dividing a delimited string into a list.

loop()

Why it fails: Terraform has no loop() function; iteration is achieved with for expressions, dynamic blocks or count/for_each meta-arguments. It tempts because general-purpose languages expose loop constructs, and repetition is genuinely needed when generating multiple similar resources, but Terraform's HCL handles that through those declarative mechanisms instead.

They run after the apply phase

Why it fails: OPA and Sentinel evaluate during plan, before any resources are created, so they cannot run after apply. It is tempting because post-apply verification does exist in some tooling, and that would be the right layer for checking real deployed state rather than proposed configuration.

They can only be used with AWS

Why it fails: OPA and Sentinel are provider-agnostic policy engines that evaluate Terraform plan JSON, so they work across AWS, Azure and others. It is tempting because HashiCorp ships Sentinel with Terraform Cloud and many examples target AWS, which would be the correct framing only for AWS-specific policy sets.

They replace the need for IAM

Why it fails: OPA and Sentinel evaluate infrastructure-as-code and admission decisions; they do not authenticate principals or grant API permissions, so IAM remains required. It is tempting because policy-as-code centralises guardrails, and would be right if the question asked about enforcing configuration standards across deployments.

Git branch name.

Why it fails: Registry source strings comprise namespace, provider name, and target hostname; a Git branch name belongs to Git-based module sources, not Registry addressing. It is tempting because branch pinning is common in version control. A branch name would be correct when sourcing a module directly from a Git repository.

Operating system.

Why it fails: Operating system is not encoded in a Registry source string; that string is namespace, provider name, and hostname, with version constraints supplied separately. It is tempting because providers do support multiple platforms. Specifying an OS would be relevant when selecting a provider binary build, not when writing the source address.

A list of all possible provider configurations.

Why it fails: Listing every possible provider configuration is unbounded and unhelpful; a module should document required providers and version constraints instead. Enumerating all configurations would be correct only for a reference catalogue of provider options, not for describing a reusable module's interface.

The raw state file of the module's resources.

Why it fails: State files hold resource attributes and may contain secrets, and they change per environment; committing them to module documentation is unsafe and stale. Documented modules need inputs, outputs and usage examples. State belongs in secured remote backends, not documentation.

It disables the use of lifecycle meta-arguments.

Why it fails: Lifecycle meta-arguments remain fully usable regardless of drift; they govern create, update and destroy behaviour in configuration and are evaluated independently of state accuracy. They are the correct tool when you need create_before_destroy, prevent_destroy or ignore_changes on a resource.

It automatically updates the configuration file.

Why it fails: Terraform never rewrites your .tf files; drift is detected by refresh or plan and reported as a diff, leaving configuration untouched until you edit it. Configuration files are only changed by you or by commands such as terraform import, which adds existing resources to state.

They allow changing the provider version dynamically.

Why it fails: Lifecycle blocks govern create, update and destroy behaviour of a resource, such as create_before_destroy and prevent_destroy; they cannot alter provider versions. It tempts because version constraints and lifecycle both appear in configuration, but provider versions are pinned in required_providers or the provider block.

They are inherited from the provider block.

Why it fails: Lifecycle blocks are declared inside a resource and apply only to that resource; they are not inherited from provider configuration, which supplies credentials, region and version constraints. Confusion arises because provider-level defaults do propagate to resources, but lifecycle meta-arguments are resource-scoped and never inherited.

Run 'terraform refresh' to clear the taint.

Why it fails: Refresh only reconciles state with real infrastructure; the taint marker persists because it is metadata recorded in state, not a drift condition. It is tempting since refresh does rewrite state, and it is the right command when you need to detect out-of-band changes before planning.

Use 'terraform state rm' to fix the taint.

Why it fails: State rm only removes the resource from state, leaving the real infrastructure orphaned and untracked; it does not clear the taint flag. It is tempting because both commands manipulate state entries, and state rm is genuinely correct when you intend to stop managing a resource entirely.

Use 'terraform plan -force-apply'.

Why it fails: No such flag exists; terraform plan only previews changes and cannot apply or clear taint. It is tempting because plan output does show tainted resources marked for replacement, so operators assume a flag can force the action, but taint removal requires terraform untaint or a successful apply.

Terraform provider configurations.

Why it fails: Variable sets hold Terraform and environment variables, including sensitive values and HCP Terraform-specific variables, but not provider configurations; those belong in the Terraform configuration itself. It tempts because provider blocks accept variables, yet the set stores values, not provider setup.

Sentinel policy sets.

Why it fails: Sentinel policy sets are attached to workspaces or projects through the policy sets feature, not embedded in a variable set; variable sets carry Terraform and environment variables. It tempts because both are workspace-scoped configuration, but they are separate mechanisms.

The provider source code

Why it fails: Provider source code is unrelated to a failed plan; the plan fails on configuration, variables, credentials or state, not on provider internals. It is tempting because provider bugs can cause errors, which is correct when diagnosing a reproducible provider defect, but routine troubleshooting checks the run log, configuration and state instead.

Organization billing page

Why it fails: Billing pages show subscription charges and payment history, not run logs, plan output or configuration errors. It is tempting because failed runs caused by unpaid invoices or expired trials do surface there, making it the right place when runs are blocked by account-level billing suspension rather than plan failure.

Increasing the execution speed of API calls.

Why it fails: Modules organise and reuse configuration; they do not alter how quickly the AWS provider sends API calls, since execution speed depends on provider concurrency and resource graph parallelism. It is tempting because modules reduce duplicated code, but that is authoring efficiency, not runtime API throughput.

Automatically preventing all resource drift.

Why it fails: Terraform modules package and reuse configuration; they do not detect or reconcile drift, which requires terraform plan or refresh against state. It is tempting because modules standardise resources, but drift prevention comes from state comparison, not module encapsulation.

terraform fmt

Why it fails: terraform fmt only rewrites configuration files into canonical style; it reads no state and contacts no provider, so it reveals nothing about provider failures. It is tempting because formatting is a routine hygiene command, correct when preparing code for commit rather than diagnosing authentication or API errors.

terraform taint

Why it fails: terraform taint marks a resource for destruction and recreation on the next apply; it does not inspect provider behaviour or log provider API calls. It is tempting because taint is used to force replacement when a resource misbehaves, which is correct for suspected resource drift rather than provider faults.