Terraform configuration

A practitioner is choosing a Terraform collection type to hold a group of values where duplicates are meaningless and the ordering of elements should not matter. Which complex type best matches these requirements?

• AA list, because it stores an ordered sequence and quietly discards any duplicate values that are added to it.
• BA set, because it stores an unordered collection of unique values of the same type and treats repeated values as one.check_circle Correct
• CA map, because it stores values under unique string keys and therefore ignores both ordering and duplication.
• DA tuple, because it stores a fixed sequence of elements and removes any element that appears more than once.

Why A is wrong: A list is ordered and preserves duplicates, so it neither ignores order nor removes repeated values; the claim that it discards duplicates is untrue.

Why B is correct: A set is unordered and holds only distinct values of a single element type, which is exactly what is wanted when duplicates carry no meaning and order is irrelevant.

Why C is wrong: A map does key each value uniquely, but it is a keyed structure rather than a plain collection of values, so it does not match a requirement expressed purely in terms of values.

Why D is wrong: A tuple has a fixed length and ordered positions and may hold elements of differing types; it neither drops duplicates nor ignores order, so it fails the requirement.

Which statement most accurately describes how Terraform stores the value of a resource attribute that holds a database password once it has been applied?

• AIt is stored in the state file as plaintext, so anyone with access to the state can read it.check_circle Correct
• BIt is stored as a one-way hash in state, so the original secret cannot be recovered from the file.
• CIt is stored only in memory during the run and never written to the state file.
• DIt is stored encrypted with a key derived from the provider credentials before being written to state.

Why A is correct: Terraform records all managed attribute values, including secrets, as plaintext in state, which is why protecting state access is essential.

Why B is wrong: Hashing would prevent Terraform from using the value in later operations; state must retain the usable plaintext, so no one-way hashing is applied.

Why C is wrong: This is tempting because it sounds secure, but Terraform persists attribute values to state so they survive between runs, rather than keeping them only in memory.

Why D is wrong: Terraform does not encrypt individual attributes with provider-derived keys; the value is written in plaintext unless the backend itself encrypts the whole file.

A module author wants Terraform to verify that a newly created load balancer ends up with a DNS name assigned, treating a missing name as a bug in the resource or provider rather than bad user input. Where should this assertion live?

resource "aws_lb" "web" {
  name               = var.lb_name
  internal           = false
  load_balancer_type = "application"
  subnets            = var.subnet_ids
}

• AIn a variable validation block, checking that var.lb_name is not empty before planning.
• BIn a precondition on the aws_lb resource that references its own dns_name attribute.
• CIn a separate check block scoped to a data source that queries the load balancer later.
• DIn a postcondition on the aws_lb resource that asserts self.dns_name is not empty.check_circle Correct

Why A is wrong: Validating the input name checks user input, but it cannot confirm the provider actually assigned a DNS name after creation.

Why B is wrong: A precondition runs before the resource is created, so its dns_name is not yet known and cannot be asserted there.

Why C is wrong: A check block only reports and would need an extra data source, so it neither guarantees failure nor targets the resource output directly.

Why D is correct: A postcondition evaluates after the resource is created and can reference self, making it the right place to assert the provider produced a DNS name.

A team member wants Terraform to create and manage the lifecycle of an S3 bucket, so that terraform destroy would later remove it. Which block type should they use to declare it?

____ "aws_s3_bucket" "artifacts" {
  bucket = "team-build-artifacts"
}

• AA data block, because data blocks are how Terraform provisions and tracks new infrastructure objects.
• BA resource block, because resource blocks declare managed objects that Terraform creates, updates, and can destroy.check_circle Correct
• CA provider block, because the provider is what physically creates the bucket in the account.
• DAn output block, because outputs are what expose and persist the created bucket in state.

Why A is wrong: Data blocks only read existing objects and never create or destroy them, so choosing one here reflects a common resource-versus-data mix-up.

Why B is correct: Managed resources are declared with resource blocks, and only these are created, updated in place, and removed by destroy.

Why C is wrong: The provider supplies credentials and API access but does not itself declare an object to manage, so it cannot stand in for a resource block.

Why D is wrong: Outputs surface values from other objects and create nothing, so they cannot be the block that brings the bucket under management.

How does Terraform use its dependency graph to decide the order in which resources are created?

• AIt orders resources by type, creating networking resources first and compute resources last regardless of references
• BIt processes every resource strictly one at a time in the order the blocks are written in the files
• CIt creates all resources simultaneously and then retries any that fail because a dependency was missing
• DIt walks the graph so that any resource is processed only after every resource it depends on, and independent resources may run in parallelcheck_circle Correct

Why A is wrong: There is no fixed type-based ordering; sequencing follows the graph edges rather than a built-in category ranking, so this is incorrect.

Why B is wrong: Tempting because sequential file order feels deterministic, but Terraform parallelises independent nodes and ignores block order, so this is wrong.

Why C is wrong: Terraform does not create everything at once and retry on failure; the graph prevents dependency violations up front, so this misdescribes the mechanism.

Why D is correct: Correct: Terraform performs a topological walk of the graph, creating a node only once its dependencies are complete, and parallelises nodes that have no ordering relationship between them.