Hard Difficulty Questions

type = map(any)

Why it fails: map(any) enforces uniform value types across all entries and cannot declare which named attributes must exist, so required keys go unvalidated. It is tempting for arbitrary key-value metadata, and would be correct where keys are dynamic and no fixed attribute schema is needed.

type = list(object)

Why it fails: list(object) validates each element's attributes but accepts an ordered sequence, so it cannot enforce that a single object contains every required attribute. It is tempting for repeating structured records, and would be correct where the module receives multiple similar objects rather than one fixed-shape value.

type = tuple([...])

Why it fails: A tuple fixes positional element types, so it cannot express named attributes with required presence; object({...}) with optional() and validation does that. Tuples suit ordered, heterogeneous lists where each index has a distinct type, such as returning multiple values from a module.

Configure a run trigger from a cost monitoring workspace to the finance workspaces to automatically reject runs that exceed the threshold.

Why it fails: Run triggers only start runs in dependent workspaces after a source workspace completes; they cannot inspect cost estimation or reject runs based on cost. They do not provide any enforcement of spending limits, so they are unsuitable for this compliance rule.

Enable the 'Cost Estimation' setting on each finance workspace and manually review the cost estimate before applying.

Why it fails: Enabling cost estimation only displays the estimate; it does not automatically fail a run when a threshold is exceeded. Manual review is not an automated enforcement and cannot guarantee compliance, so it does not meet the rule's requirement for automatic failure.

Set a workspace variable named COST_THRESHOLD to 500 and rely on Terraform's AWS provider to enforce it during plan.

Why it fails: The AWS provider does not read arbitrary workspace variables to enforce cost limits. Terraform itself has no built-in cost threshold enforcement. This approach would have no effect on the run and would not satisfy the compliance requirement.

terraform login

Why it fails: terraform login only authenticates the CLI to HCP Terraform and stores an API token; it does not reconfigure the backend or migrate existing local state. It is tempting because authentication is a prerequisite step, and it would be correct when first connecting the CLI to a Terraform Cloud or HCP Terraform organisation.

terraform push

Why it fails: terraform push is a legacy Terraform Enterprise command for uploading configurations to a remote environment; it does not migrate local state into HCP Terraform. It is tempting because the name suggests sending state to a remote service, and it was correct for older Terraform Enterprise workflows.

terraform migrate

Why it fails: Terraform has no migrate subcommand; initialising HCP Terraform migration is done with terraform init, which detects the cloud block and offers to copy local state to the remote backend. The name sounds plausible because migration is the task, but terraform init is the actual entry point.

Use a local variable that reads from the provider config.

Why it fails: Locals cannot read from provider configs for resource naming.

Define the bucket name in the root module and override the child resource.

Why it fails: You cannot override individual attributes of a child module resource directly from the root.

Use the 'module_name' variable provided by Terraform.

Why it fails: This variable does not exist.

The resource is destroyed as well.

Why it fails: Deleting the referenced resource does not cascade destruction; replace_triggered_by only forces replacement when the referenced attribute changes, and a deleted reference simply yields no trigger. It is tempting because dependency chains can propagate destruction, but that behaviour belongs to explicit depends_on or reference-based graph edges, not to this lifecycle argument.

The resource is kept as is.

Why it fails: A deleted referenced resource produces no attribute value to compare, so no replacement is triggered; the resource is not simply left untouched as a rule. It is tempting because replace_triggered_by never destroys anything by itself, but the accurate outcome is that the trigger evaluates against a null or absent value and no action occurs.

The trigger is ignored.

Why it fails: Terraform treats it as a dependency failure.

terraform plan -refresh-only

Why it fails: terraform plan -refresh-only reconciles state with real infrastructure; it never contacts the registry to re-download a missing provider binary. It is tempting because it does reach out to the provider's APIs, but that is for reading resource attributes, not fetching plugin binaries. terraform init is what installs providers.

terraform providers install

Why it fails: terraform providers install is not a valid subcommand; terraform providers only has a schema subcommand for printing provider schemas. It is tempting because the name sounds like the obvious install action, but provider installation happens during terraform init, which downloads binaries into the plugin cache directory.

terraform refresh

Why it fails: terraform refresh updates state to match real infrastructure by reading existing resources; it does not download provider plugins. It is tempting because it sounds like it re-syncs everything, but refresh only queries APIs using an already-installed provider. terraform init is the command that installs missing provider binaries.

Shared modules

Why it fails: Shared modules distribute reusable configuration across workspaces, but they carry no credentials or account mapping, so they cannot target separate cloud accounts. They are the right answer when standardising identical resource definitions across many teams, not when one organisation must reach multiple accounts.

Provider aliases

Why it fails: Provider aliases let a single configuration address several regions or accounts within one workspace, but they do not give organisation-level management across separate cloud accounts. They are correct when one root module must deploy into two regions or two accounts simultaneously.

Remote execution

Why it fails: Remote execution runs Terraform operations on HCP Terraform's runners instead of locally, which changes where plans and applies happen, not which cloud accounts the organisation can manage. It is the right choice when you need consistent, networked agent execution rather than multi-account governance.

keys()

Why it fails: keys() returns only the attribute names of a map, discarding the associated values, so it cannot build the object set the dynamic block requires. It is tempting when iterating map structures, but converting a flat list into objects needs a function that constructs each object, such as a for expression.

distinct()

Why it fails: distinct() removes duplicate values from a list, returning a list of unique primitives, so it cannot restructure flat strings into the object shape a dynamic block's for_each requires. It is tempting because it does manipulate collections, and would be correct when deduplicating a list of simple values before iteration.

compact()

Why it fails: compact() only strips null and empty-string elements from a list, leaving the flat structure intact, so the dynamic block still receives strings rather than objects. It is tempting because it tidies lists, and would be correct when removing blank entries from a list of strings before passing them elsewhere.

No, only registry providers are supported.

Why it fails: Terraform supports filesystem mirrors, network mirrors and local plugin directories, so registry-only sourcing is false. The claim tempts because the public registry is the default discovery path, yet a provider absent from it can still be installed when a mirror or explicit installation method is configured.

Yes, by setting the env var TF_IN_AUTOMATION.

Why it fails: TF_IN_AUTOMATION only adjusts CLI output to suppress interactive prompts and hints; it has no bearing on provider installation sources. It is genuinely useful in CI pipelines for cleaner logs, but sourcing a non-registry provider requires a filesystem mirror or explicit provider installation configuration instead.

Yes, by recompiling Terraform binary.

Why it fails: Recompiling the Terraform binary does not add provider sources; providers are separate plugins resolved at init time. Rebuilding suits embedding custom builds or patching core behaviour, but installing an unlisted provider needs a filesystem or network mirror configured through the provider installation settings.

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.

Add lifecycle { prevent_destroy = true } to the renamed resource, then apply so Terraform refuses to delete the original bucket.

Why it fails: prevent_destroy would cause the apply to fail rather than migrate the resource, because Terraform still sees a destroy of the old address and a create of the new one. The bucket is not preserved through a state operation; the plan simply errors out. The engineer would be left with a broken apply and no address migration.

Use terraform apply -replace=aws_s3_bucket.audit_logs so Terraform rebuilds the bucket under the new name without data loss.

Why it fails: -replace forces destruction and recreation of the addressed resource, which for an S3 bucket means deleting the bucket and its objects, causing data loss. It is the opposite of what is needed when the goal is to preserve the existing bucket. The address change itself would still not be reconciled by this flag.

Run terraform import aws_s3_bucket.audit_logs with the bucket name, then delete the old resource block from configuration.

Why it fails: Importing the bucket under the new address would create a duplicate state entry that points at the same real object as the old address. Terraform would then see two resources managing one bucket, and removing the old block would plan a destroy of the shared object. This approach risks deleting production logs and is not a safe refactor.

Declare the variable as a list of maps and rely on Terraform to supply empty defaults for any map keys that are absent.

Why it fails: Terraform does not invent default values for absent map keys; accessing a missing key produces an error or a null depending on context, and a null passed to cidr_blocks is not the same as omitting the argument. This approach therefore does not reliably generate the intended rules.

Use content with from_port = rule.value.from_port and reference cidr_blocks = rule.value.cidr_blocks inside the same content block.

Why it fails: Referencing an attribute that is absent from a given element raises an error during evaluation because Terraform cannot resolve the missing key on an object that does not define it. Supplying a null default does not help inside a plain content block, so the odd entry would fail the plan rather than generating a valid rule.

Set the iterator argument to a custom label and reference the custom label inside content for all attributes, including cidr_blocks.

Why it fails: Renaming the iterator only changes how you reference the current element; it does not make a missing attribute resolvable. The entry without cidr_blocks would still trigger an unsupported attribute error, so this approach does not address the conditional requirement.

The run continues automatically but logs a warning, and the apply proceeds without any intervention.

Why it fails: Soft-mandatory policies do not allow the run to continue automatically; they pause and require an explicit override. Advisory policies log warnings and continue, but soft-mandatory policies block until overridden. This option confuses the two enforcement levels.

The run fails immediately and cannot be overridden; the developer must modify the configuration and push a new commit.

Why it fails: Soft-mandatory policies allow authorized users to override the failure and proceed with the run. They do not fail immediately without the option to override. This option describes hard-mandatory behavior, not soft-mandatory, so it is incorrect for this scenario.

The run is paused, and an organization owner must approve an override before the apply can proceed.

Why it fails: Soft-mandatory policies do not require an organization owner to approve overrides. The developer with appropriate permissions can override the policy failure themselves. This option incorrectly implies a higher level of approval is needed, which is not the case for soft-mandatory policies.

Terraform uses 'null' for the value.

Why it fails: Terraform does not substitute null for an omitted required variable; it raises an error during plan, because a variable with no default and no supplied value has no value to assign. Null is a deliberate value you can pass explicitly. This option tempts those who confuse an unset variable with an explicit null assignment.

Terraform uses the variable value from the previous state.

Why it fails: Terraform raises an error and halts the plan when a required variable lacks a value; it never silently reuses prior state. The option tempts candidates who assume state persists variable values, but state stores resource attributes, not input variable defaults.

Terraform automatically sets the value to an empty string.

Why it fails: Terraform never coerces a missing required variable to an empty string; validation fails at plan time because the variable has no default and no value was supplied. Empty-string defaults arise only when you declare default = "" yourself. This tempts anyone assuming string variables silently default to blank.

Run the 'terraform show' command on the state file.

Why it fails: 'terraform show' renders the state or plan file's resource attributes and values; it performs no pricing lookup, so no cost figures appear. It tempts because it does display plan detail, but cost estimation requires Infracost, which maps resource attributes to provider pricing data.

Check the cloud provider's billing dashboard.

Why it fails: The billing dashboard reports charges already incurred on deployed resources, not the projected cost of an unapplied plan. It tempts because it is the authoritative source for real spend, but pre-deployment estimation requires Infracost to price the plan's resources before provisioning.

Use the Sentinel CLI tool.

Why it fails: Sentinel is a policy-as-code framework that evaluates plan data against governance rules and returns pass or fail; it holds no pricing catalogue, so it cannot produce cost figures. It tempts because it inspects plan contents, but Infracost is the tool that translates resources into monetary estimates.

The cost estimation provider is not configured for AWS.

Why it fails: Cost estimation supports AWS, Azure and GCP without a per-provider configuration switch, so no such setting exists to misconfigure. A provider-specific cost configuration would matter only if estimation were disabled for that cloud, which is not how the feature works.

The workspace does not have Sentinel enabled.

Why it fails: Sentinel enforcement is configured at the organisation or project level and applies to the workspace's runs; a failing policy proves Sentinel is active. Enabling Sentinel per workspace is unnecessary when the policy is already evaluating plans and returning failures.

The API key for AWS is invalid.

Why it fails: An invalid AWS API key would break the plan or apply itself, producing authentication errors before cost estimation runs, not a policy failure on an estimate. Rotating credentials is the fix when runs cannot authenticate to AWS at all.

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.

It disables the prevent_destroy rule.

Why it fails: ignore_changes and prevent_destroy are independent lifecycle meta-arguments; setting ignore_changes = all does not alter or disable prevent_destroy, which still blocks any destroy plan. It is tempting because both sit in the same lifecycle block, but the correct behaviour is that prevent_destroy remains enforced regardless of ignore_changes.

It ignores the resource existence entirely.

Why it fails: ignore_changes = all suppresses Terraform's diff detection for every attribute of an existing resource, so updates to those attributes are not planned; it never affects whether the resource is created, read or destroyed. It is tempting because 'ignore' suggests skipping the resource, but that behaviour belongs to lifecycle prevent_destroy or removed blocks.

It causes a syntax error.

Why it fails: ignore_changes = all is valid HCL and accepted by Terraform; it simply tells the provider to disregard all attribute differences during planning. It is tempting because 'all' looks like a wildcard that might be rejected, but Terraform documents it as a supported meta-argument, so no syntax error occurs.

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.

Terraform replaces the instance with one built from the new AMI.

Why it fails: Because ignore_changes includes ami, Terraform treats the ami argument as if it were not configured and will not generate a replacement plan when the value differs. The instance continues running the old AMI, so no replacement occurs despite the configuration change.

Terraform updates the instance in place to the new AMI without replacement.

Why it fails: Changing the AMI of an existing EC2 instance is not an in-place operation; the AMI is a force-new attribute and normally requires replacement. In this scenario ignore_changes suppresses the difference entirely, so Terraform does not plan any change, in-place or otherwise.

Terraform fails the plan with an error because the AMI differs from state.

Why it fails: ignore_changes does not cause an error; it silently suppresses the difference. Terraform only errors on a plan if there is a configuration problem or a lifecycle conflict such as prevent_destroy blocking a destroy. A differing AMI under ignore_changes is simply omitted from the plan.