HashiCorp Certified: Terraform Authoring and Operations Professional (AWS provider) (AWS provider) (AWS provider) — Questions 151–225

HCP Terraform agents run inside your own infrastructure, so they can reach endpoints on private networks that the hosted execution environment cannot route to. This directly satisfies the stem's private-network access constraint, which the public runners cannot fulfil.

A Private Module Registry stores modules within your own organisation, giving centralised publishing, semantic versioning and access control. This satisfies the need for central management and version control of reusable modules, unlike the public registry where you cannot govern or curate shared code.

The providers lock command with multiple -platform flags records package checksums for each specified platform in .terraform.lock.hcl. Including both linux_amd64 and darwin_arm64 ensures every environment finds a matching entry, so init succeeds on CI and developer machines while preserving checksum verification and version pinning.

A map(object({...})) constraint requires every value in the map to be an object whose attributes match the declared schema, so region must be a string and count a number. Terraform converts compatible values and raises a type error for mismatches during validation, which is exactly the plan-time rejection the scenario requires.

Lifecycle meta-arguments govern an individual resource's creation and destruction behaviour, so they nest inside the resource block as a lifecycle block. This satisfies the constraint that settings such as create_before_destroy apply only to that resource.

Specifying an exact version constraint, such as version = "1.2.0", ensures that Terraform only uses that version. This prevents automatic upgrades from introducing breaking changes. The version argument is the standard mechanism for version pinning in Terraform modules, and it applies to modules from the Terraform Registry or other sources that support versioning.

Write permission allows team members to read and write to the workspace, including queuing runs and applying changes, but does not permit modifying workspace settings or deleting the workspace. This exactly matches the requirement: developers can apply changes but cannot alter settings or delete.

Variable sets allow you to define variables once and apply them to multiple workspaces, projects, or the entire organization. Applying a variable set to a project automatically makes those variables available to all workspaces within that project, satisfying the need for shared configuration.

Read permissions grant visibility into workspaces and runs without any write or approval capability, so members can inspect run status and logs while being blocked from approving plans. This satisfies both constraints in the stem: view runs, deny approvals. Approval rights require the Write permission set, which Read deliberately excludes.

This expression uses a `for` expression with the syntax `{ for s in var.list : s => s }`. It iterates over each element `s` in `var.list` and creates a map entry with key `s` and value `s`. This is the correct syntax for a map comprehension where both key and value are derived from the same element.

Policy sets are applied at the organization or workspace level, and a hard-mandatory policy evaluates the plan and blocks the run when it fails. Sentinel or OPA policies can inspect planned resource attributes such as `associate_public_ip_address` and return a descriptive failure message. This satisfies both pre-apply blocking and developer-visible failure reasons.

Organization-level read grants visibility into workspaces, runs, and policy evaluations across all projects without conferring the ability to modify settings or trigger runs. It scales automatically to new projects and workspaces, giving the compliance officer exactly the read-only cross-project view required.

The count meta-argument can be used on any resource to conditionally create instances. Setting count = var.enable_logging ? 1 : 0 creates one instance when enable_logging is true and zero when false. This is a standard and supported pattern inside modules. The resource is then referenced using index syntax, such as aws_cloudwatch_log_group.example[0], when needed.

terraform state rm detaches resources from state without calling any AWS API, so the role and its attachment remain intact in the account. Removing the attachment entry first avoids a dangling reference to a resource that no longer exists in state. After both entries are gone and the configuration is deleted, future plans ignore them entirely, which is exactly what a shared-resource handoff requires.

Module outputs are accessed directly as attributes on the module object. The syntax is module.<MODULE_NAME>.<OUTPUT_NAME>. This allows the root configuration to use the output value in other resources or outputs. It is the standard way to reference module outputs in Terraform.

The States tab within a workspace lists every historical state version, showing serial numbers, timestamps and who created each one. This is the dedicated interface for reviewing past state, satisfying the requirement to view historical state versions rather than only the current state.

This is correct because a validation block in a variable definition can enforce constraints on the variable's value. Using alltrue over a for expression that checks each map value against the allowed list ensures every entry is valid, and Terraform will produce a custom error message when the condition fails, stopping the plan early.

`replace_triggered_by` forces Terraform to destroy and recreate the resource whenever a referenced attribute or resource changes, satisfying the requirement that the resource is always recreated when the associated data source value changes. It accepts resource references directly, unlike `lifecycle` triggers, which only react to arbitrary values.

The random_id resource generates a unique identifier that can be used as a suffix. By combining it with the account ID and region, you can create a globally unique bucket name that follows the convention. This is a common pattern for ensuring uniqueness in AWS resource names.

This declaration defines a variable with a type and a default value. If the caller does not provide a value, Terraform uses the default. If the caller provides a value, it overrides the default. This meets the requirement to allow customization while enforcing a default when no value is given.

Soft-mandatory policies block a run when the policy fails, but users with permission to manage policies can override the failure and allow the run to proceed. This matches the requirement to block non-compliant S3 buckets while allowing administrators to override in emergencies. It provides both enforcement and flexibility.

The `.terraform.lock.hcl` file is created automatically by `terraform init` to record the exact provider versions selected and their cryptographic checksums. This satisfies the stem's requirement for a generated file that locks versions and verifies integrity, ensuring consistent provider installations across runs and preventing tampering.

The `required_providers` block within a `terraform` block accepts a `version` argument, letting you pin or constrain a provider's version directly in configuration. This satisfies the stem's requirement for a valid specification method, as Terraform reads these constraints during initialisation to select a compatible provider release.

When a soft-mandatory policy fails and a user with override permissions chooses to override, the run proceeds, and the override action is logged in the audit trail. This ensures accountability while allowing flexibility. The policy remains in effect for future runs.

terraform console evaluates expressions interactively against current state and variables, so you can inspect the intermediate result of a complex for expression without applying. This isolates whether the comprehension itself is malformed, satisfying the need to debug its output directly.

Because the state file records the last-known real-world attributes, any out-of-band modification makes the stored values diverge from actual infrastructure. Terraform therefore reports a non-empty diff during plan even when the configuration itself is untouched, satisfying the drift-detection consequence.

The Run UI records run metadata, and the initiating user is displayed so teams can trace who triggered the plan or apply. This satisfies the stem's requirement for information shown in the HCP Terraform Run UI, alongside status and timing details.

`terraform providers` lists every provider required by the current configuration and its child modules, showing the source address and version constraints each module declares. This directly exposes version conflicts or missing provider requirements during debugging, satisfying the need to inspect provider dependencies across the configuration.

Hard-mandatory policies enforce strict compliance; if the policy fails, the run is halted and cannot continue to apply. There is no override option. In this scenario, the missing tag causes the policy to fail, so the run fails immediately. The user must fix the configuration and start a new run to proceed.

A validation block in the variable definition enforces the rule where the variable is declared, so every caller is checked automatically. Using a condition with contains() against the allowed set produces a clear error before any resources are planned, centralizing enforcement in the module.

Auto-apply removes the manual confirmation gate, so a successful plan in a non-production workspace is applied without human approval. This directly satisfies the automation requirement, whereas manual apply would still require someone to approve each run.

When a resource omits the provider meta-argument, Terraform binds it to the default provider configuration — the one declared without an alias in the required_providers block. Aliased configurations are only selected through an explicit provider argument, so the unaliased instance is the implicit default.

Outputs are used to expose values from a module to the parent configuration. By defining an output that references the EC2 instance's private_ip attribute, the caller can access this value. This is the correct way to share resource attributes from a child module.

for_each requires a map or set of unique keys; a list of strings can contain duplicates, producing unstable addresses and plan errors. Converting the list to a set guarantees unique keys, keeping resource instance addresses stable across runs.

A lifecycle block is nested within the resource block it modifies, applying only to that specific resource. This positional placement is what makes it a valid statement about lifecycle blocks, distinct from provider or terraform-level configuration.

flatten() collapses nested lists into a single-level list, so a list of lists of objects becomes one flat list of objects. This satisfies the stem's requirement to iterate the result with for_each, which rejects nested collections.

Setting `prevent_destroy = true` in the resource's `lifecycle` block makes Terraform reject any plan that would destroy the database, including removal of its resource block. This directly satisfies the stem's requirement that Terraform refuse destruction after an accidental configuration deletion, failing the apply with an error rather than deleting the instance.

Multiple provider blocks for the same provider need a unique alias so resources and modules can reference the intended region explicitly, for example aws.west versus aws.east. Without distinct aliases Terraform cannot tell the instances apart.

Using the `ref` parameter pins the module source to a specific Git tag, branch or commit, so deployments always fetch that immutable revision rather than the repository's moving default branch. This directly satisfies the strict versioning constraint, preventing upstream breaking changes from silently affecting your infrastructure during deployment.

A validation block inside the variable declaration evaluates a condition against the supplied value and returns an error message when it fails. This rejects malformed input at plan time, satisfying the requirement to guard against incorrect data types before resources are created.

Creating the replacement before destroying the original means both exist simultaneously, so fixed names, unique DNS labels or static identifiers clash. The provider rejects the duplicate, causing the plan or apply to fail until the name is parameterised or the old resource is destroyed first.

Creating a separate workspace that tracks the feature branch allows the developer to run plan and apply in isolation, using the same configuration but with its own state and variables. This prevents interference with the main workspace's state and infrastructure. It aligns with HCP Terraform's recommended pattern for branch-based development and testing, enabling safe experimentation before merging to main.

Terraform caches downloaded provider plugins in the .terraform/providers/ directory within the working directory, so subsequent runs reuse them without re-downloading. This satisfies the default storage location constraint, as init installs providers there unless a plugin cache directory is configured.

lookup() retrieves a value from a map for a given key and returns null when the key is absent, rather than erroring. This makes it the safe accessor for potentially missing map keys in Terraform configurations.

The AWS provider's `assume_role` block accepts `role_arn`, `session_name`, and related arguments, and any of them can reference input variables. Feeding the role ARN from a variable lets the same configuration target staging or production based on the variable value supplied by the pipeline, without embedding credentials or duplicating provider blocks.

Granting Read plus Queue Plan satisfies the least-privilege requirement: Read exposes plan logs and workspace state, while Queue Plan permits triggering runs. Neither permission includes the variables:write capability, so the user cannot modify workspace variables. This precisely matches the stem's constraint of triggering runs and viewing logs without variable edit rights.

Cost estimation runs asynchronously after plan, so a policy evaluating cost data during the plan phase may execute before estimation finishes. The policy then reads an empty or incomplete result and fails, despite cost estimation being enabled.

Outputs expose values across module boundaries; declaring an output block in the child module and referencing it as module.<name>.<output> in the root module is the standard mechanism. This satisfies the requirement to pass a complex object upward without duplicating logic.

Terraform requires both conditional results to share a compatible type. When the true and false expressions return different types, evaluation fails with a type mismatch error rather than coercing one value, satisfying the stem's scenario.

The -var flag passes an input variable value at the command line for that single terraform apply invocation, taking precedence over the workspace's stored value. The workspace configuration file remains untouched, satisfying the requirement to override without permanent change.

Enabling 'Manual Apply' overrides the auto-apply setting and requires a user to manually confirm the apply after a successful plan. Even if auto-apply is enabled, manual apply forces an approval step. This directly prevents the change from being applied immediately without human intervention.

Variable sets can be scoped to projects, and all workspaces within that project automatically inherit the variables. This eliminates the need to configure each workspace individually. It is the intended feature for sharing variables across multiple workspaces, and it supports environment variables, including sensitive ones.

Setting sensitive = true on a variable prevents its value from being displayed in Terraform plan and apply output. This is important for variables like passwords or API keys. It helps prevent accidental exposure of secrets in logs or console output. This practice is recommended for any variable that carries sensitive data, ensuring that the module adheres to security best practices.

The for expression lowercases every action, distinct() removes duplicates including those that differed only by case, and sort() imposes a stable lexicographic order. The combination yields a deterministic, case-normalized, duplicate-free list regardless of input order, which is exactly what the policy document needs for reproducible JSON output across callers.

Soft-mandatory sits between advisory and hard-mandatory on the enforcement scale: failure blocks the run but permits a privileged user to override, resuming it. Hard-mandatory cannot be overridden, and advisory only logs, so pausing for override matches the stem.

A private module registry in Terraform Cloud or Enterprise publishes modules to a single organisation-wide namespace, so every team consumes the same versioned source. This satisfies the requirement to share one module across the entire organisation rather than per-workspace or public consumption.

Soft-mandatory enforcement blocks the apply if the policy fails, but allows users with the appropriate permissions to override the failure and proceed, typically after providing a reason. This matches the requirement to block non-compliant changes while permitting authorized overrides with justification.

The `dynamodb_table` parameter enables state locking by writing a lock item to a DynamoDB table before any apply begins, so a second concurrent `terraform apply` fails rather than corrupting the shared state file. This directly satisfies the stem's requirement that simultaneous operations across regions cannot overwrite each other's state.

Terraform modules have no implicit variable inheritance, so the intermediate module must declare the variable in its own variables block and explicitly forward it via an argument in its module call to the leaf. This explicit pass-through satisfies the root-to-leaf requirement.

OPA evaluates Terraform plan JSON, where every proposed change appears under input.resource_changes. Each entry carries the resource type, address and planned values, so the policy can inspect the EC2 instance's tags block and deny the run when 'CostCenter' is absent.

count addresses instances by numeric index, so removing an item shifts subsequent indices and forces recreation of those resources. for_each keys instances by map or set value, so removing one item only affects that instance, avoiding unrelated recreation.

An object type constraint declares named attributes with their individual types, so Terraform validates that every required attribute is present and correctly typed. This enforces the specific attributes the stem demands, unlike map or any, which permit arbitrary keys.

Sentinel policies can access cost estimation results through the tfrun import, specifically the cost_estimate data. A hard-mandatory policy can evaluate the monthly cost delta and fail the run if it exceeds the threshold, providing the required enforcement for the finance project.

Each HCP Terraform workspace stores its own state file, holding the recorded resource attributes and serial for the infrastructure it manages. State is a core component of the workspace object, distinct from configuration, which lives in the linked VCS repository.

`terraform providers` lists every provider required by the configuration alongside its source address and version constraints, reading the dependency lock file and module manifests. This directly satisfies the stem's requirement to verify proper initialisation, since missing or uninitialised providers appear as unresolved entries rather than confirmed installations.

Terraform tracks resources by address in state. Renaming the block changes its address, so the plan shows the old address destroyed and the new one created, unless a moved block or state mv is used.

In HCP Terraform, the 'Automatic run triggering' setting, when enabled, causes a run to be queued whenever a change is pushed to the tracked branch in the VCS repository. This is exactly what is needed to trigger runs on pushes to the main branch. It is a standard feature for VCS-driven workflows.

Sentinel is HCP Terraform's policy-as-code engine, evaluating plans against rules before apply. A policy can require specific tag keys on every workspace resource, blocking non-compliant runs, which directly enforces the mandated tag set across all workspaces.

`terraform init` detects the existing local backend configuration and prompts to migrate state to HCP Terraform's remote backend, copying `terraform.tfstate` to the workspace. This satisfies the migration constraint directly, since no separate import or push command exists for backend transitions.

Policy Check is a distinct pipeline stage where Sentinel policies evaluate the plan before apply, enforcing governance. It runs after Plan and before Apply, so it satisfies the requirement for a standard HCP Terraform run stage.

Removing the prevent_destroy argument eliminates the protection at its source, so the subsequent apply can destroy and recreate the resource. Terraform still manages the lifecycle, satisfying the stem's requirement to retain management while bypassing the guard.

Adding a lifecycle block with prevent_destroy set to true causes Terraform to reject any plan that would destroy the RDS instance, failing the apply before the destructive action occurs. This protects the database from accidental replacement caused by configuration drift or an unintended change to a force-new attribute, which is exactly the outage scenario described.

The provider block, such as provider "aws" {}, declares and configures the provider plugin, accepting arguments like region and profile. This directly satisfies the requirement to set provider-level settings, since these values are passed to every resource managed by that provider.

Sentinel policies using the tfplan/v2 import inspect the structured plan representation before any infrastructure changes occur. When a policy has hard-mandatory enforcement, a failing rule halts the run and the apply cannot proceed, which is precisely how you block a bucket without a lifecycle_rule. This is the intended mechanism for preventive governance in HCP Terraform.

The condition applies alltrue() over a for expression that evaluates the range check for every element, so any out-of-range port makes the condition false and produces the custom error message during plan. Because validation lives in the variable block, callers receive the failure immediately, and list(number) enforces the element type before the range logic runs.