HashiCorp Certified: Terraform Authoring and Operations Professional (AWS provider) (AWS provider) (AWS provider) — Questions 226–278

terraform state mv relocates a resource entry between state files or addresses, updating the state to match refactored configuration without destroying or recreating infrastructure. This satisfies the module-refactoring scenario by preserving existing resources while their configuration addresses change.

The count meta-argument combined with a ternary expression evaluates the boolean to either 1 or 0, creating or omitting the resource instances accordingly. This directly satisfies the stem's requirement for conditional resource creation from a boolean input.

The terraform_remote_state data source reads another workspace's stored state outputs at plan time, exposing them as data attributes. This is the documented best practise for cross-workspace output sharing, avoiding hardcoded values or manual copying between configurations.

When a workspace is connected to a VCS repository, HCP Terraform automatically queues a speculative plan for every pull request that modifies the working directory. This plan runs without applying changes, giving reviewers a preview of the infrastructure impact. Configuring the workspace with VCS integration is exactly what enables this automatic validation.

terraform init -upgrade re-resolves provider version constraints and downloads the newest permitted versions, bypassing the cached binary. This satisfies the stem's requirement to force a fresh download when the provider binary is missing from the local registry cache.

Input variables declared in the child module accept values supplied by the calling module's arguments, making data injection dynamic per invocation. This satisfies the requirement because the same module can receive different values on each call.

Workspaces let one configuration directory drive multiple, isolated deployments, each holding its own state, variables and run history. Separate workspaces for development, staging and production therefore reuse the same configuration files while keeping environments fully isolated, satisfying the stated constraint.

Terraform resolves providers through installation sources beyond the public registry, including local filesystem mirrors and private registries. Configuring such a source lets the developer install and use the provider normally, so absence from the public registry is not a blocker.

Because the child module declares no provider block of its own, it automatically inherits the root module's default (unaliased) provider configuration, including region us-west-2. The required_providers entry only constrains source and version, it does not create or isolate a provider instance. This inheritance is the standard behavior for unaliased providers passed implicitly down the module tree.

terraform state mv rewrites the resource address inside the state file without touching the real S3 bucket, so the renamed configuration block now matches an existing state entry. A subsequent plan should report no changes, proving the bucket is preserved. This is the standard technique for refactoring addresses while avoiding an unnecessary destroy and recreate of production data.

Nested dynamic blocks let you conditionally generate inner arguments, and wrapping the source in a conditional that returns an empty list when the attribute is null means zero inner blocks are produced for entries lacking cidr_blocks. The required scalar arguments remain in the outer content, so every rule is valid.

In HCP Terraform, state locks are typically held by active runs. The developer should inspect the workspace's run history to see if a run is currently executing. If so, waiting for it to finish or canceling it will release the lock. This is the safe and recommended way to resolve the lock without risking state corruption.

Running `terraform init -upgrade` re-resolves provider version constraints and rewrites `.terraform.lock.hcl` with the newest versions permitted by your configuration, along with fresh checksums. This satisfies the stem's requirement to reflect upgraded provider selections, whereas a plain `terraform init` installs only the versions already recorded in the lock file.

Soft-mandatory policies pause the run when they fail, allowing a user with the 'manage policy overrides' permission to override the failure. This enables the run to continue to apply after the override, which is the expected behavior for a soft-mandatory policy.

The conditional operator evaluates the workspace name at plan time and selects the hard-coded type only in the dr workspace, falling back to the variable everywhere else. Both branches produce strings, so the result type is consistent and the single resource block behaves correctly across all workspaces.

For registry modules, Terraform uses the separate version argument to select a specific version. Setting version = "1.2.0" pins the module to that exact release, so even if newer versions are published, the consumer continues to use 1.2.0. This is the documented and supported way to achieve strict version pinning for registry-hosted modules.

Speculative plans run on pull requests without applying or writing state, so reviewers see the planned effect in each consuming workspace before merge. Attaching the repository to each workspace is what triggers those plan-only runs, giving the pre-merge visibility the scenario requires while keeping state untouched.

For registry modules, the version argument is specified separately from the source string. Using an exact version constraint like "2.3.0" pins the module to that specific release, ensuring reproducible deployments. This is the documented syntax for private and public Terraform registry modules and is the recommended way to avoid unexpected changes.

Variable sets allow you to define variables once and apply them to multiple workspaces or entire projects. Assigning a variable set to a project ensures all current and future workspaces in that project inherit the variables, reducing duplication and manual effort. This is the most efficient method for consistent AWS region and tagging variables.

Provider version constraints belong in the required_providers block inside the terraform block, which each module declares independently. Placing it there satisfies the stem's requirement, since module-level constraints are honoured during init alongside the root configuration.

A resource selects a non-default provider configuration through the provider meta-argument, written as the provider type followed by the alias, aws.prod. Without it, the resource would use the default configuration and be created in the development account. This is the standard mechanism for directing individual resources to aliased provider instances within the same module.

Provider configurations are inherited by child modules, and the `providers` meta-argument on a `module` block lets the root map each child's default AWS provider to a specific aliased root provider configuration. This changes the region per module instance without editing the child module's resources, which is exactly the intended mechanism for multi-region reuse of a shared module.

Terraform's module downloader shells out to Git, so it inherits whatever credential helper or SSH key 'git clone' already uses. Supplying those same credentials satisfies the private-repository access constraint without configuring a separate Terraform-native authentication mechanism.

The `.terraform` directory caches modules fetched from registries into `.terraform/modules`, so remote module source code is available locally without re-downloading during each run. This satisfies the stem's requirement that downloaded module source code resides there, distinct from provider plugins stored under `.terraform/providers`.

for_each accepts a map or set and creates one module instance per element, keyed by that element. This satisfies the scenario's need to instantiate multiple module copies from a map or set rather than a fixed count.

Child module outputs are stored in the state file under the module's path. To make them visible at the root level via `terraform output`, the root module must declare its own output that references the child module's output. This is the standard way to expose child module values to the user or to other parts of the configuration.

Terraform intersects all provider version constraints from the root module and every child module. The child requires `~> 5.0` and the root requires `~> 4.0`, which have no overlap. During `terraform init`, Terraform fails with an error indicating that no available version meets the combined constraints, and the user must align the constraints before proceeding.

Scoping the hard-mandatory policy set to exclude the migration project ensures that only the migration project is exempt, while all other workspaces are strictly enforced. The advisory policy set for the migration project logs violations without blocking, providing visibility. This achieves the required exception while maintaining governance elsewhere.

Omitting the version constraint lets Terraform select the newest provider release available in the registry, satisfying the stem's scenario where no version is pinned. Terraform resolves this during initialisation, installing the latest matching version and recording it in the dependency lock file.

Terraform collects version constraints from every module's required_providers block and selects the newest provider version that satisfies all of them. The child module's unconstrained declaration imposes no restriction, so the root module's ~> 4.0 constraint determines the upper and lower bounds for selection.

ignore_changes = [tags] tells Terraform to exclude the tags attribute from diff comparison, so out-of-band tag changes are not reverted. Other attributes such as policy and versioning remain managed, satisfying the requirement to keep controlling those settings while tolerating external tag edits.

Separate provider instances each carry their own authentication configuration, so distinct credential sets can be applied per instance. Resources referencing the appropriate alias then authenticate with the intended credentials, satisfying the need to isolate access across resources.

Checking the registry website displays the module's published documentation, including inputs, outputs and usage examples, directly satisfying the requirement to view docs for a registry-published module. It avoids needing local installation or source access, since the registry page is the authoritative, versioned reference for that module.

Variable Sets allow you to define variables once and apply them to multiple workspaces. Organization-level variable sets can be applied to all current and future workspaces, ensuring consistent AWS credentials. This centralizes management and avoids manual per-workspace configuration, directly meeting the requirement.

By default, a dynamic block uses the label of the block as the iterator name. Since the dynamic block is named rule, the iterator object is rule, and rule.value accesses the current element from the collection being iterated. This is the correct way to reference the current rule inside the content block.

ignore_changes = all tells Terraform to disregard every attribute difference between configuration and real infrastructure during planning, so no updates are proposed for that resource. This matches the stem's description of ignoring all attribute changes.

prevent_destroy is a lifecycle meta-argument that prevents Terraform from destroying the resource. When set to true, any plan that includes destruction of the resource will fail, thus protecting the S3 bucket from accidental deletion. This directly meets the requirement to ensure the bucket is never destroyed.

Using an object type allows the caller to pass a structured value containing both log_level and stage. This provides flexibility and clarity, ensuring that each environment variable gets the appropriate value. It also enables validation and documentation of the expected inputs. This is a robust way to handle multiple related settings derived from a single variable.

Declaring the AWS provider in `required_providers` with an explicit `source` and a `~>` version constraint pins the provider to the specified minor version range and confirms the public registry as the source. This is the standard way to enforce version discipline and ensure the correct provider is selected during initialization.

With ami listed in ignore_changes, Terraform ignores any difference between the configured AMI and the value recorded in state. The plan therefore shows no change for that attribute, and the running instance remains on the older AMI until the ignore_changes entry is removed and an apply is run.

A soft-mandatory policy failure pauses the run and allows a user with override permissions to bypass the policy. In this scenario, the user can override and proceed with the apply despite the missing tag. This is the designed behavior for soft-mandatory enforcement, balancing governance with flexibility for authorized users.

Terraform generates the dependency lock file during `terraform init`, recording the exact provider versions and hashes selected. This satisfies the stem's requirement for a true statement about the file's origin, since initialisation resolves and pins providers before any plan or apply runs.

Setting `replace_triggered_by` within resource B's lifecycle block forces Terraform to destroy and recreate B whenever the referenced resource A changes, satisfying the stem's requirement that B be replaced on A's update. This differs from `create_before_destroy`, which only alters replacement ordering, not the trigger itself.

Both resources use map keys as instance keys. The filtered for expression produces a new map containing only entries whose public attribute is true, so the association exists solely for public subnets and its key equals the subnet key, giving clean one-to-one correlation. Adding or removing a private entry never disturbs association addresses, and no separate index bookkeeping is required.

A locals block names intermediate expressions once, then reuses them throughout the module, cutting duplication and letting you transform variable inputs. It satisfies the goal of avoiding repeated inline expressions without expanding the module's public variable interface.

Terraform providers are written in Go, using the Terraform Plugin SDK or Plugin Framework. This satisfies the stem's requirement for the standard language: HashiCorp builds and distributes all official providers in Go, and the plugin protocol's libraries are Go-first, making it the only supported choice for custom provider development.

Marking an output sensitive makes Terraform redact its value, displaying "(sensitive value)" in plan and apply output rather than the plaintext. It satisfies the constraint of hiding secrets from CLI display, though the value still exists in state.

Consistent naming and tagging improve resource organization, cost allocation, and troubleshooting. Tagging with a module identifier helps identify which module created which resources, especially in shared AWS accounts. This practice aids in auditing and automation. It is widely recommended for reusable modules to maintain clarity and operational efficiency.

Advisory mode lets a policy report violations without failing the run, so teams can trial governance rules before enforcing them. This satisfies the requirement that policies need not block, distinguishing advisory from soft-mandatory and hard-mandatory enforcement levels.

terraform init -upgrade re-resolves module version constraints and downloads the newest release each constraint permits, refreshing the cached module. This propagates the update to every environment that runs it, satisfying the requirement that all consumers receive the new version.

Databases hold irreplaceable state, so prevent_destroy blocks the destroy plan step before Terraform can issue the deletion API call, guarding against accidental loss. Web servers are stateless and rebuildable, so the same guard would only obstruct routine replacement, making the protection disproportionate there.

After the new major version is published, each consumer must opt in by updating its `version` constraint in the `module` block. This is the deliberate adoption step that prevents accidental breakage. Without changing the constraint, consumers remain on the old major line, so this action is required to move them forward on their own schedule.

A for expression iterates the tag list and builds a map keyed by each element, which for_each requires. It satisfies the transformation constraint directly, unlike a for_each meta-argument or lookup, since it produces the map value rather than consuming one.