Scenario practice questions

You need to share a module across your entire organization. Which registry type should you use?

Trap 1: The public Terraform Registry.

The public Terraform Registry publishes modules openly to all users, exposing internal code and offering no organisation-scoped access control. A private registry is required for organisation-wide sharing. Public modules suit consuming community or vendor modules.

Trap 2: A shared network drive.

A network drive stores files but provides no Terraform registry protocol, versioning or module source addressing, so terraform init cannot resolve modules from it. Registries serve that purpose. Shared drives suit ad-hoc file exchange, not module distribution.

Trap 3: An S3 bucket with public read access.

A public S3 bucket serves objects over HTTP; Terraform cannot resolve it as a registry module source, so versioning and module addressing break. It is tempting because S3 is the standard remote backend for state and can host module archives, which would suit private distribution only if fronted by a proper registry or module source URL.

A
The public Terraform Registry.
Why it fails: The public Terraform Registry publishes modules openly to all users, exposing internal code and offering no organisation-scoped access control. A private registry is required for organisation-wide sharing. Public modules suit consuming community or vendor modules.
B
A shared network drive.
Why it fails: A network drive stores files but provides no Terraform registry protocol, versioning or module source addressing, so terraform init cannot resolve modules from it. Registries serve that purpose. Shared drives suit ad-hoc file exchange, not module distribution.
C
An S3 bucket with public read access.
Why it fails: A public S3 bucket serves objects over HTTP; Terraform cannot resolve it as a registry module source, so versioning and module addressing break. It is tempting because S3 is the standard remote backend for state and can host module archives, which would suit private distribution only if fronted by a proper registry or module source URL.
D
A private module registry in Terraform Cloud or Enterprise.
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.

Question 2mediummultiple choice

You need to ensure that a resource is always recreated if an associated data source value changes. Which meta-argument supports this?

Trap 1: create_before_destroy

create_before_destroy controls the ordering of replacement, creating the new resource before destroying the old one; it does not cause recreation when a data source value changes. It is tempting because it relates to resource lifecycle, and it would be correct when a replacement must avoid downtime.

Trap 2: lifecycle_hooks

lifecycle_hooks is not a valid Terraform meta-argument; the lifecycle block supports create_before_destroy, prevent_destroy, ignore_changes and replace_triggered_by, but no hooks argument. It is tempting because lifecycle customisation sounds relevant, and it would be correct if Terraform offered pre- or post-lifecycle hooks, which it does not.

Trap 3: prevent_destroy

prevent_destroy blocks destruction of a resource, causing an error rather than recreation when a data source value changes. It is tempting because it is a lifecycle meta-argument, and it would be correct when a resource must be protected from accidental deletion, such as a production database.

A
create_before_destroy
Why it fails: create_before_destroy controls the ordering of replacement, creating the new resource before destroying the old one; it does not cause recreation when a data source value changes. It is tempting because it relates to resource lifecycle, and it would be correct when a replacement must avoid downtime.
B
replace_triggered_by
`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.
C
lifecycle_hooks
Why it fails: lifecycle_hooks is not a valid Terraform meta-argument; the lifecycle block supports create_before_destroy, prevent_destroy, ignore_changes and replace_triggered_by, but no hooks argument. It is tempting because lifecycle customisation sounds relevant, and it would be correct if Terraform offered pre- or post-lifecycle hooks, which it does not.
D
prevent_destroy
Why it fails: prevent_destroy blocks destruction of a resource, causing an error rather than recreation when a data source value changes. It is tempting because it is a lifecycle meta-argument, and it would be correct when a resource must be protected from accidental deletion, such as a production database.

Question 3hardmultiple choice

Your organization has a Sentinel policy with enforcement level 'soft-mandatory' that checks for required tags on AWS resources. During a run, the policy fails because an EC2 instance is missing the 'Environment' tag. The workspace allows users with write access to override policies. What is the immediate outcome of the run?

Trap 1: The policy failure is logged as an advisory and the run continues…

Advisory policies only log a warning and do not block or pause the run; they allow the run to continue automatically. Soft-mandatory policies, however, block the run until an override is granted or the issue is resolved. The scenario describes a soft-mandatory policy, so automatic continuation is incorrect.

Trap 2: The run fails immediately and cannot be overridden, requiring the…

Immediate failure without override is characteristic of a hard-mandatory policy, not soft-mandatory. Soft-mandatory allows authorized users to override the failure. The scenario specifies soft-mandatory, so the run does not fail permanently; it pauses for potential override. This distinction is crucial for understanding enforcement levels.

Trap 3: The run is canceled and the workspace is locked until the policy is…

Soft-mandatory policy failures do not cancel the run or lock the workspace. They pause the run and present an override option to authorized users. Cancellation and locking are not standard behaviors for policy failures; they might occur due to other errors but not specifically for soft-mandatory policy violations.

A
The policy failure is logged as an advisory and the run continues automatically without any intervention.
Why it fails: Advisory policies only log a warning and do not block or pause the run; they allow the run to continue automatically. Soft-mandatory policies, however, block the run until an override is granted or the issue is resolved. The scenario describes a soft-mandatory policy, so automatic continuation is incorrect.
B
The run is paused and a user with appropriate permissions can choose to override the policy and continue the apply.
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.
C
The run fails immediately and cannot be overridden, requiring the configuration to be fixed and a new run to be queued.
Why it fails: Immediate failure without override is characteristic of a hard-mandatory policy, not soft-mandatory. Soft-mandatory allows authorized users to override the failure. The scenario specifies soft-mandatory, so the run does not fail permanently; it pauses for potential override. This distinction is crucial for understanding enforcement levels.
D
The run is canceled and the workspace is locked until the policy is updated to pass.
Why it fails: Soft-mandatory policy failures do not cancel the run or lock the workspace. They pause the run and present an override option to authorized users. Cancellation and locking are not standard behaviors for policy failures; they might occur due to other errors but not specifically for soft-mandatory policy violations.

Question 4hardmultiple choice

Your organization uses HCP Terraform with Sentinel policies. A policy is configured with an enforcement level of 'hard-mandatory' and checks that all AWS S3 buckets have server-side encryption enabled. A developer runs a plan that includes an unencrypted bucket. What happens when the policy fails?

Trap 1: The run proceeds to apply, but the policy failure is recorded in…

Recording failures in the audit log happens for all policy evaluations, but hard-mandatory does not allow the run to proceed to apply. This option incorrectly implies that the apply can continue despite a hard-mandatory failure, which would defeat the purpose of strict enforcement.

Trap 2: The run is paused, and an organization owner must manually override…

Hard-mandatory policies cannot be overridden by any user, including organization owners. The run is not paused for manual approval; it is immediately halted. This option incorrectly suggests that an override is possible, which contradicts the strict enforcement of hard-mandatory.

Trap 3: The run continues, but the policy failure is logged as an advisory…

Advisory enforcement allows the run to continue and only logs a warning. However, hard-mandatory is the strictest level and does not permit the run to proceed. This option confuses hard-mandatory with advisory, which would not block the unencrypted bucket from being deployed.

A
The run proceeds to apply, but the policy failure is recorded in the audit log.
Why it fails: Recording failures in the audit log happens for all policy evaluations, but hard-mandatory does not allow the run to proceed to apply. This option incorrectly implies that the apply can continue despite a hard-mandatory failure, which would defeat the purpose of strict enforcement.
B
The run is paused, and an organization owner must manually override the policy to proceed.
Why it fails: Hard-mandatory policies cannot be overridden by any user, including organization owners. The run is not paused for manual approval; it is immediately halted. This option incorrectly suggests that an override is possible, which contradicts the strict enforcement of hard-mandatory.
C
The run continues, but the policy failure is logged as an advisory warning.
Why it fails: Advisory enforcement allows the run to continue and only logs a warning. However, hard-mandatory is the strictest level and does not permit the run to proceed. This option confuses hard-mandatory with advisory, which would not block the unencrypted bucket from being deployed.
D
The run is halted immediately, and the apply cannot proceed.
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.

Question 5mediummultiple choice

You have an AWS EC2 instance managed by Terraform. The operations team occasionally updates the instance's tags directly in the AWS Console to reflect temporary maintenance status. You want Terraform to ignore these external tag changes and not revert them during the next apply. However, you still want Terraform to manage other attributes of the instance. Which lifecycle meta-argument should you use?

Trap 1: replace_triggered_by = [aws_ec2_tag.example]

replace_triggered_by is used to force replacement of a resource when another resource or attribute changes. It does not ignore changes; instead, it triggers replacement. Using this would cause the EC2 instance to be replaced whenever the referenced resource changes, which is not desired and would not ignore tag changes.

Trap 2: ignore_changes = all

ignore_changes = all would cause Terraform to ignore all attribute changes for the EC2 instance, not just tags. This would prevent Terraform from managing any aspect of the instance, including critical settings like instance type or security groups. The requirement is to ignore only tags while still managing other attributes, so this is too broad.

Trap 3: prevent_destroy = true

prevent_destroy protects the instance from being destroyed but does nothing to ignore tag changes. It would not prevent Terraform from reverting tag modifications; it only blocks destruction. This does not meet the requirement to ignore external tag changes.

A
ignore_changes = [tags]
ignore_changes = [tags] tells Terraform to ignore any changes to the tags attribute of the EC2 instance. This means that if tags are modified outside of Terraform, the next plan will not show a diff for tags, and apply will not revert them. Other attributes remain managed, which aligns with the requirement to ignore only tags.
B
replace_triggered_by = [aws_ec2_tag.example]
Why it fails: replace_triggered_by is used to force replacement of a resource when another resource or attribute changes. It does not ignore changes; instead, it triggers replacement. Using this would cause the EC2 instance to be replaced whenever the referenced resource changes, which is not desired and would not ignore tag changes.
C
ignore_changes = all
Why it fails: ignore_changes = all would cause Terraform to ignore all attribute changes for the EC2 instance, not just tags. This would prevent Terraform from managing any aspect of the instance, including critical settings like instance type or security groups. The requirement is to ignore only tags while still managing other attributes, so this is too broad.
D
prevent_destroy = true
Why it fails: prevent_destroy protects the instance from being destroyed but does nothing to ignore tag changes. It would not prevent Terraform from reverting tag modifications; it only blocks destruction. This does not meet the requirement to ignore external tag changes.

Question 6easymulti select

Which TWO of the following functions are most useful for manipulating lists?

Trap 1: keys()

keys() extracts the key names from a map or object, returning a collection of identifiers rather than manipulating an existing list. It is genuinely used to enumerate available fields or properties, but list manipulation requires functions that operate on list elements directly, not on map keys.

Trap 2: lookup()

lookup() retrieves a value from a map or object by key; it returns a single matched value rather than transforming or combining list elements. It is genuinely used for key-based retrieval in configuration and mapping scenarios, but list manipulation requires functions that iterate over or restructure the collection itself.

Trap 3: merge()

merge() combines two maps or objects into one, operating on key-value structures rather than ordered list elements. It is genuinely used to consolidate configuration objects, but list manipulation requires functions that add, remove, or transform elements within a collection, which merge() does not do.

A
keys()
Why it fails: keys() extracts the key names from a map or object, returning a collection of identifiers rather than manipulating an existing list. It is genuinely used to enumerate available fields or properties, but list manipulation requires functions that operate on list elements directly, not on map keys.
B
concat()
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.
C
flatten()
The `flatten()` function collapses nested arrays into a single-level array, directly satisfying the requirement to manipulate list structures. It removes inner array boundaries, producing one flat list from multi-dimensional input. This makes it essential when downstream operations need a uniform, iterable collection rather than nested elements.
D
lookup()
Why it fails: lookup() retrieves a value from a map or object by key; it returns a single matched value rather than transforming or combining list elements. It is genuinely used for key-based retrieval in configuration and mapping scenarios, but list manipulation requires functions that iterate over or restructure the collection itself.
E
merge()
Why it fails: merge() combines two maps or objects into one, operating on key-value structures rather than ordered list elements. It is genuinely used to consolidate configuration objects, but list manipulation requires functions that add, remove, or transform elements within a collection, which merge() does not do.