HashiCorp Certified: Terraform Authoring and Operations Professional (AWS provider) (AWS provider) (AWS provider) — Questions 76–150

Semantic Versioning communicates breaking, feature and patch changes predictably, letting consumers pin safe ranges. Applying SemVer to every release satisfies the stem's best-practice requirement for a private registry, where consumers depend on clear version signals.

HCP Terraform places runs in a per-workspace queue and permits only one run to hold the workspace lock at a time. The second run waits until the first finishes, is discarded, or is canceled. This serialization prevents concurrent state mutation and is the platform's built-in coordination mechanism for teams applying to a shared workspace.

This is the definition of tainting.

Projects provide a grouping layer above workspaces, letting teams organise related workspaces and apply team access permissions across the whole collection. This satisfies the scenario by centralising access control instead of managing permissions workspace by workspace.

Terraform records each resource's real-world identity and attribute values in terraform.tfstate, the sole artefact binding configuration addresses to actual infrastructure. Without it, Terraform cannot detect drift or determine which objects to update or destroy, so it is the mapping file the question asks for.

The pessimistic constraint operator ~> 3.0 permits versions from 3.0 upward but below 4.0, since it locks the major version while allowing minor and patch increments. This satisfies the stated range of at least 3.0 and less than 4.0.

replace_triggered_by with the S3 object's etag attribute will trigger replacement of the Lambda function whenever the ETag changes. This directly ties the function's lifecycle to the code version, ensuring updates when the code changes. It is the precise solution for the scenario.

Run triggers are configured on the destination workspace. By adding a run trigger in Workspace B that references Workspace A, you ensure that a successful apply in Workspace A automatically queues a run in Workspace B. This is the correct way to set up a dependency between workspaces.

By default, plan refreshes state against AWS and compares to configuration. The manually changed instance class will appear as an in-place update to restore the declared value. Simply not applying leaves the drift in place for later review, which matches the requirement to detect but not revert automatically.

Manual apply causes HCP Terraform to pause after a successful plan until someone confirms the apply, and the run approval permission restricts who may confirm. Together they ensure a designated reviewer must approve before production changes proceed, which is precisely the gated workflow the team requires.

This is correct because dynamic blocks can be nested, and conditionally including a nested block is best achieved by setting the inner dynamic block's for_each to a one-element list or an empty list based on the condition. This pattern is idiomatic HCL for optional nested blocks and preserves the correct structure.

The CLI-driven workflow lets users run Terraform commands on their local machine, but state is stored remotely in HCP Terraform. This provides the benefits of remote state management, such as locking and versioning, while allowing developers to use their local tooling and environment.

The providers lock command regenerates the dependency lock file and, with repeated -platform flags, records hashes for each specified platform. Including linux_amd64 and darwin_arm64 makes the lock file cover both the CI runner and the Apple Silicon developer workstation, so both environments verify the same provider versions and hashes during init.

terraform init initialises the working directory by downloading and installing modules declared in module blocks, along with providers and backend configuration. This satisfies the scenario's need to make module source code available locally before plan or apply can reference it.

With create_before_destroy, Terraform provisions the replacement aws_instance first, but because the ENI is managed by the instance, a new ENI is created for the new instance. The old instance and its ENI are destroyed afterward, so the private IP is not preserved. The ENI's private IP is tied to the ENI itself, and a new ENI gets a new IP. To preserve the IP, the ENI must be a separate resource with its own lifecycle.

The `concat()` function joins two or more lists into a single combined list, directly satisfying the requirement to manipulate lists. Unlike `join()`, which merges list elements into a string, `concat()` preserves list structure and element order, making it the appropriate choice for combining list values without altering their underlying data type.

Policy check results expose Sentinel or OPA enforcement failures that block a run before apply, satisfying the need to identify policy-driven plan failures. HCP Terraform surfaces these under the run's policy evaluations, distinct from configuration or provider errors, so checking them pinpoints whether governance rules, not code, caused the failure.

The count meta-argument accepts a whole number and creates that many instances of the resource. Setting count = var.instance_count directly satisfies the requirement of creating exactly the desired number of aws_instance resources, and each instance is addressable by index. This is the idiomatic Terraform way to provision a fixed quantity of identical resources.

Project-level permissions in HCP Terraform scope a team's access to only the workspaces within that project, so each team manages its own workspaces without seeing others. Organisation-level access would grant visibility across all projects, violating the isolation requirement. This satisfies the constraint of per-team workspace management with enforced separation.

Modules encapsulate resource definitions behind typed input variables, so every team instantiates the same reviewed code rather than hand-writing resources. This directly satisfies the stem's standardisation constraint: configuration drift between teams is eliminated because changes propagate from one versioned source, and inputs are validated at plan time.

Terraform resolves a single provider version across all modules during init. If constraints are mutually exclusive, no version satisfies every module, so initialisation aborts before any plan or apply runs, satisfying the conflict scenario described in the stem.

The configuration_aliases argument inside required_providers declares that the module expects an additional provider configuration with the alias aws.west. This informs Terraform that the module's resources may use aws.west, and the caller must pass a matching provider instance using the providers meta-argument.

Cost Estimation parses the plan against cloud provider pricing to project monthly spend before apply, satisfying the requirement to monitor costs within an HCP Terraform workspace. It surfaces projected deltas per resource, unlike run notifications or state inspection, which report activity rather than monetary impact.

count indexes instances numerically, so resources are identified by position rather than meaningful string keys. This satisfies the stem's pitfall about identification: you cannot reference an instance by a stable name, making lookups and references brittle compared with for_each.

Terraform Cloud's private module registry enforces Semantic Versioning, requiring the MAJOR.MINOR.PATCH format for every published module version. This satisfies the stem's versioning constraint directly: the registry rejects tags that deviate from SemVer, so teams must increment versions accordingly when releasing module updates.

A `dynamic` block allows generating nested blocks dynamically based on a collection. By using `dynamic "ingress"` with `for_each = var.ingress_rules`, the module can create one ingress block per rule. This keeps the module flexible and avoids hardcoding rules, enabling callers to pass any number of rules without changing module code.

This approach preserves backward compatibility because existing callers do not need to set the new variable; the default empty list means no additional groups are attached. Using `concat()` to combine the internally managed security group with consumer-supplied IDs correctly composes the final list. It is the idiomatic way to extend module behavior without forcing a breaking change on existing consumers.

ignore_changes = [tags] instructs Terraform to disregard differences in the tags attribute between configuration and real infrastructure. Manually altered tags in the AWS Console are therefore not detected as drift, so the next plan performs no action on the tags.

terraform state mv rewrites resource addresses inside the shared state file, so every collaborator's subsequent plan and apply reads the altered mapping. Teammates must pull the updated state before running, otherwise their plans reference stale addresses and may propose destructive changes.

Setting the apply method to manual ensures that a successful plan does not automatically apply; a user must explicitly approve it. Assigning a team with write permissions allows those users to review the plan output and approve or discard the run. This combination enforces the required review and approval before any infrastructure changes, aligning with collaborative workflows in HCP Terraform.

This for expression correctly iterates over the map, applies a condition to filter only enabled entries, and constructs a new map with keys prefixed by 'prod-'. The syntax is valid: it uses the map form with key and value, includes an if clause for filtering, and the key expression generates the new key.

The pessimistic constraint `~> 2.1.0` allows only versions greater than or equal to 2.1.0 and less than 2.2.0. Terraform's module installer selects the highest available version within that allowed range, so 2.2.0 is never chosen. Consuming teams remain on the newest 2.1.x release until they update their version constraint.

Hard-mandatory policies in HashiCorp Sentinel halt a run immediately and cannot be overridden by any user, satisfying the stem's "without possibility of override" constraint. Soft-mandatory permits privileged override, while advisory only logs warnings. Hard-mandatory is therefore the only policy type enforcing an absolute, non-bypassable block.

Dynamic blocks generate repeated nested configuration blocks from a collection, such as multiple ingress rules inside an aws_security_group. This directly satisfies the requirement for nested repeatable blocks, which count and for_each cannot produce inside a resource argument.

This explicitly sets the iterator name to rule and references rule.value inside the content block. This is the correct and unambiguous way to access the current element when the default iterator name might conflict or when you want clarity. It correctly iterates over the list of objects and uses the iterator's value attribute.

A filesystem mirror lets Terraform install a provider from a local directory instead of the public Terraform Registry, satisfying the constraint that the provider is unpublished. The .terraformrc provider_installation block redirects installation to that mirror, so no registry lookup occurs.

Provider aliases create distinct configurations within one provider block, each pinned to a different region. Referencing the alias via the provider meta-argument on a resource directs that resource to the aliased instance, satisfying the requirement to manage two regions from a single configuration.

for_each keys each instance by its map or set key rather than a positional index, so Terraform tracks instances by stable identifiers in state. Adding or removing entries therefore leaves unrelated instances untouched, satisfying the stem's requirement regarding state behaviour.

HCP Terraform evaluates each changed file against the trigger patterns. If at least one changed file is not excluded, a run is queued. The change to `terraform.tfvars` is outside the excluded subdirectory, so the run is triggered even though another file in the commit is excluded.

Specifying source and a version constraint in required_providers pins the provider to the intended registry namespace and version range. This removes ambiguity in provider lookup and enforces the standardized version across root modules, directly satisfying both the source-explicitness and version-enforcement goals the platform team defined.

HCP Terraform's run page presents the cost estimate broken down per resource, with monthly and hourly deltas, alongside the plan itself. Opening that page satisfies the requirement to inspect detailed estimate line items rather than a single aggregate figure, which the CLI alone cannot display.

Documenting each output states what the value represents and how consumers should use it, which is essential when the module is called elsewhere. Without it, callers must read the source to interpret returned values, defeating the stem's requirement for a well-documented module.

This for expression uses the grouping ellipsis (...) after the value expression. The ellipsis groups all values that share the same key into a list. So the resulting map will have keys from obj.name and values as lists of objects. This is the correct way to handle duplicate keys by grouping.

Explicit types enable Terraform to validate inputs and provide better error messages, while defaults make optional variables easier to use. This improves the module's usability and reduces the chance of misconfiguration. It also documents the expected input shape, which is essential for a module shared across teams with varying requirements.

The Plugin SDK exposes schema definition constructs that providers use to declare resource and data source attributes, including their types, optionality and validation. This schema drives Terraform's configuration parsing and state handling, making schema definition a core SDK capability.

The count meta-argument creates a fixed number of resource instances derived from a whole number, so scaling is tied strictly to the count of items in a configuration. This satisfies the stem's dependency on item quantity, unlike for_each, which iterates over map or set keys.

Advisory enforcement only logs policy failures and does not block or pause runs. If the policy set is advisory, the run will proceed even if the policy fails. To block runs, the policy set must be hard-mandatory or soft-mandatory (with override).

When -plugin-dir is specified, Terraform searches only the given directories for provider plugins and does not attempt to install providers from a registry or from other configured sources. This is intended for offline or air-gapped environments where providers are pre-placed in a local directory.

During plan, Terraform refreshes each resource by reading its current state from AWS. Because the security group was deleted outside Terraform, the refresh marks the resource as missing and the plan proposes to create it again. Running apply then recreates the security group according to the existing configuration, restoring the desired state.

An advisory result in Sentinel produces a warning in the run logs while allowing the run to proceed, satisfying the requirement that execution continues despite the policy outcome. Unlike soft-mandatory, which blocks and prompts for override, advisory never halts the operation, so the plan or apply completes normally with the warning recorded.

The Schema block declares each resource's attributes, their types, and whether they are required, optional, or computed. This lets Terraform validate configuration and map values to the provider's API calls, satisfying the need to describe resource structure before CRUD operations run.

Tagged releases create immutable version identifiers that consumers reference through version constraints. This lets teams adopt changes deliberately and roll back by adjusting constraints. Without tags, the registry cannot resolve versions, and consumers would be forced onto whatever the default branch contains, making controlled upgrades impossible.

Provider selection is opt-in per resource. Without the provider meta-argument naming the alias, the resource uses the module's default aws configuration and would be created in eu-central-1. Writing provider = aws.dr explicitly binds the route53 record to the DR configuration, which is the only supported way to target an aliased provider from within the same module.

Module inputs are set by passing arguments inside the `module` block, using the variable name as the argument name. This directly overrides the default value for that instance of the module. The consumer does not need to edit the module source or use environment variables, making this the correct and standard approach.

With for_each over a map or set, Terraform exposes each.key and each.value; each.value yields the current element's value, letting the resource configuration reference per-iteration data. This satisfies the need to access the current iteration's value directly within the resource block.

ignore_changes with the tags attribute instructs Terraform to disregard drift in that attribute after creation, so external script modifications no longer appear as diffs. This satisfies the requirement to leave post-creation tag changes untouched during planning and apply.

Hard-mandatory enforcement blocks the run entirely when a policy fails. No override is possible, and the apply is prevented. This ensures that unencrypted S3 buckets are never provisioned, aligning with strict compliance requirements. The developer must fix the configuration and trigger a new run.

for_each iterates over a map or set of strings, creating one distinct resource instance per element with a stable key. Feeding the port list as a set produces one ingress rule per port, unlike count, which lacks per-item identity.

Declaring `configuration_aliases` in the child module for the two aliases lets the caller pass the appropriate commercial or China provider configuration for each alias. Resources then target the correct alias, so the module supports both partitions and multiple regions without hardcoding a region or partition, matching the requirement exactly.

This type constraint defines a map whose values are objects with the specified attributes and types. Terraform will validate that each value in the map is an object containing an instance_type string and a min_size number. This precisely matches the requirement and provides strong type checking for the module input.

Within a `for_each` block over a map, Terraform exposes `each.key` as the map key and `each.value` as its corresponding value, satisfying the requirement to reference the current element's key. Using `each.value` would return only the value, so `each.key` is the precise object needed here.

HCP Terraform enforces per-workspace run concurrency: only one run may hold the lock at a time. The second apply therefore waits in a queue until the first completes, satisfying the simultaneous-apply constraint without corrupting state.

An HCP Terraform Agent runs inside your own network, so it is chosen when private connectivity is required — reaching internal APIs, databases or services that the hosted run environment cannot route to, and avoiding exposure of those endpoints to the public internet.

Terraform validates required input variables during the plan, so omitting one halts execution with an error before any resources are provisioned. This satisfies the stem's constraint: a required variable has no default, and the calling configuration supplies no value, so planning cannot resolve the reference.

Modifying variable sets and execution modes requires the workspace-level Settings permission, which governs configuration scoped to a single workspace rather than organisation-wide policy. This satisfies the stem's constraint by granting exactly the administrative control needed over workspace-specific variables and run behaviour, without broader access.

soft-mandatory allows a run to proceed only if a user with permission to override policies acknowledges the failure. This meets the requirement by allowing developers to continue after acknowledgment. The override action is logged, and notifications can be configured separately. It balances security with flexibility, unlike hard-mandatory which blocks entirely.

The dependency lock file records checksums per platform. If it was generated only on `linux_amd64`, it contains no hashes for `darwin_arm64`, so init on macOS fails verification. Running `terraform providers lock -platform=linux_amd64 -platform=darwin_arm64` adds the missing hashes, and committing the result lets every platform verify the same provider version.

Admin permission on a workspace grants full control, including the ability to create, edit, and delete workspace variables, including sensitive ones such as AWS access keys. Write permission allows runs and state operations but does not permit variable management, so the engineer must be elevated to Admin to modify the credentials.

Automatic speculative plans trigger a plan-only run when a pull request is opened or updated, and the results are posted as a commit status check on the pull request. This provides early feedback without applying changes, exactly matching the requirement to see plan results before merging.

The `alltrue` function returns true only when every element of the list satisfies the predicate, and the `for` expression maps each port to a boolean. This condition correctly fails if any port is out of range. The `error_message` provides a clear diagnostic, and validation runs before planning, preventing invalid input from reaching resources.

A module can only use provider configurations explicitly passed to it through the `providers` argument. Since the root only mapped the default `aws` provider, the child module has no configuration for the `aws.global` alias. The resource referencing `aws.global` therefore has no valid provider configuration, and Terraform reports an error during plan.

The providers meta-argument explicitly maps each provider configuration the child module expects to a specific configuration from the calling module, such as aws = aws.usw2. This is the documented explicit passing mechanism, satisfying the requirement for a valid way to supply provider configuration.

Removing the resource from state with `terraform state rm` detaches it from Terraform's management, so the `prevent_destroy` lifecycle guard no longer applies to it. The subsequent re-import brings it back under management, letting the replacement proceed without the guard blocking destruction.

HCP Terraform's remote backend serialises runs through state locking and retains historical run records, preventing concurrent applies from corrupting shared state. This satisfies the stem's team-collaboration advantage, which local state files cannot provide without external tooling.

Variable Sets in Terraform Cloud let you define values once and apply them across multiple workspaces, eliminating per-workspace duplication. This directly satisfies the scenario's requirement for centralised management, since shared credentials, provider tokens, or environment values need updating in only one place rather than being replicated and maintained individually.