Infrastructure as Code (IaC) with Terraform

A colleague proposes to change a production networking rule by editing the Terraform configuration, opening a pull request, and having a teammate approve the diff before it is applied. A manager asks what benefit this workflow adds compared with logging into the console and changing the rule directly. What is the best answer?

• AIt guarantees that the change can never cause an outage once the pull request is merged.
• BIt removes the need to store any state, because pull requests replace Terraform state entirely.
• CIt lets the proposed infrastructure change be reviewed and discussed as a code diff before it is applied.check_circle Correct
• DIt allows the change to be applied without running terraform plan or terraform apply at all.

Why A is wrong: Review reduces mistakes but cannot guarantee zero outages, since an approved change can still be flawed, so this overstates the benefit.

Why B is wrong: Pull requests review the configuration but do not replace state; Terraform still tracks real resources in state, so this is incorrect.

Why C is correct: Expressing infrastructure as code means changes appear as reviewable diffs, so peers can inspect and approve them before they reach production, which is the core advantage over ad hoc console edits.

Why D is wrong: The change must still be applied through Terraform to take effect; review does not bypass plan and apply, so this misdescribes the workflow.

A team stores its Terraform configuration in a Git repository and requires every change to be raised as a pull request before it is applied. Which advantage of infrastructure as code does this practice most directly provide?

• AIt removes the need to store any state, because the pull request history becomes the record of deployed infrastructure.
• BIt guarantees that no two engineers can ever run terraform apply at the same time against shared infrastructure.
• CIt automatically corrects configuration drift the moment a resource is changed in the cloud console.
• DIt allows proposed infrastructure changes to be reviewed and discussed by peers before they are applied.check_circle Correct

Why A is wrong: Wrong because reviewing changes does not replace the state file, which Terraform still needs to map configuration to real resources.

Why B is wrong: Tempting because concurrent applies are a real concern, but preventing simultaneous runs is the job of state locking, not code review.

Why C is wrong: Tempting because drift correction is valuable, but a pull request reviews a proposed code change and does not watch live resources or auto-remediate them.

Why D is correct: Correct: expressing infrastructure as code lets changes flow through the same review process as application code, so peers can inspect and approve them before they take effect.

Terraform is commonly categorised as a provisioning tool within the Infrastructure as Code landscape. What does that categorisation mean it primarily does?

• AIt creates, updates and destroys infrastructure resources such as networks, servers and managed services from a configuration.check_circle Correct
• BIt installs and configures software packages inside an already-running operating system on each host.
• CIt packages application code into container images ready to be pushed to a registry.
• DIt monitors running resources and raises alerts when performance metrics cross a threshold.

Why A is correct: As a provisioning tool, Terraform's primary job is to stand up and manage the lifecycle of infrastructure resources described in configuration.

Why B is wrong: Installing and configuring software on existing hosts is the role of configuration management tools; it is tempting because both automate infrastructure, but it is a different category from provisioning.

Why C is wrong: Building container images is the job of image-building tools, not a provisioning tool, so this confuses the artefact pipeline with infrastructure provisioning.

Why D is wrong: Monitoring and alerting belong to observability tooling; a provisioning tool creates the resources rather than watching their runtime metrics.

A practitioner writes the configuration below and runs 'terraform apply' against an empty environment. Which best describes how Terraform decides what to create?

resource "aws_s3_bucket" "assets" {
  bucket = "team-assets-2026"
}

• AIt executes each line as a sequential script, so the bucket is created only if the practitioner also writes an explicit create command.
• BIt prompts the practitioner step by step for the order in which each resource attribute should be applied to the provider.
• CIt compares the declared desired state with what currently exists and creates the bucket because nothing matching it is present yet.check_circle Correct
• DIt creates the bucket only after the practitioner manually confirms in the cloud console that the name is free to use.

Why A is wrong: This treats the configuration as imperative scripting, but Terraform is declarative; no separate create command is written, the desired state alone drives the action.

Why B is wrong: This is tempting for those expecting interactive tooling, but Terraform derives ordering itself from dependencies and does not ask the user to sequence attributes.

Why C is correct: Terraform is declarative: the file states the desired end state, and Terraform compares that to reality, then creates the bucket because it does not yet exist.

Why D is wrong: This confuses a provider-side validation with Terraform's workflow; Terraform calls the provider API during apply and does not require separate manual console confirmation of the name.

A team wants a single Terraform configuration to create a virtual machine in Google Cloud and then register that VM's IP address in a DNS zone hosted by a different provider. They worry that Terraform cannot pass a value produced by one provider's resource into another provider's resource. What should you tell them?

resource "google_compute_instance" "app" { ... }
resource "dns_a_record_set" "app" {
  addresses = [google_compute_instance.app.network_interface[0].network_ip]
}

• APassing a value between providers is impossible; the IP must be copied into a variable by hand after the VM is created.
• BThe reference works only if both resources are moved into the same provider block, since dependencies cannot cross provider boundaries.
• CTerraform will build both resources in parallel and leave the DNS record with an empty address until a second apply is run.
• DTerraform can reference the Google resource attribute from the DNS resource, creating an implicit dependency so the VM is built first and its IP is fed into the record.check_circle Correct

Why A is wrong: This reflects a common misconception, but Terraform resolves cross-provider references automatically through the dependency graph, so no manual copying is needed.

Why B is wrong: This sounds cautious but is wrong; the dependency graph spans providers, and resources from different providers cannot share a provider block anyway.

Why C is wrong: This is tempting given Terraform's parallelism, but the attribute reference forces ordering, so the record receives the IP within the same apply.

Why D is correct: Interpolating one resource's attribute into another creates an implicit dependency Terraform honours regardless of which providers the two resources belong to.