Question 1

What is the purpose of the terraform.tfstate file?

Accepted Answer

Tracks the current state of deployed infrastructure (real-world mapping). Terraform needs some way to remember what it's already created and how that maps to your actual cloud resources, and that's exactly what the state file does. Without it, Terraform couldn't tell what's changed (drift) or compute an accurate plan for what to do next.

Question 2

[Terraform] How do you share modules across teams securely?

Accepted Answer

Publish to private Terraform Registry (Terraform Cloud/Enterprise) or Git (with version tags). Copying module code into every repo means a bug fix has to be applied in a dozen places, and a plain relative path like ../local-module isn't something other teams can even reach. Publishing to a private registry or a version-tagged Git repo lets teams pull a specific, stable version of a shared module without duplicating any code.

Question 3

A `null_resource` uses a local-exec provisioner that runs a shell script inserting a row into an external database whenever the resource is created. Running `terraform apply` twice in a row, with no configuration changes, inserts the row twice, creating a duplicate. Why doesn't Terraform prevent this?

Accepted Answer

Terraform's idempotency guarantee covers whether it reapplies the same resource creation action for identical config, not what an arbitrary script inside a provisioner does; the script itself has to be written to be idempotent. Terraform's core idempotency guarantee is about its own resource lifecycle: reapplying the same configuration against infrastructure that already matches it produces no further changes, because Terraform compares desired state against actual state and only acts on differences. A local-exec provisioner is just an arbitrary shell command with no concept of desired versus actual state, so it reruns once per resource creation (or whenever its triggers change), but whether the script's own effect, like an INSERT statement, is safe to repeat is entirely up to whoever wrote it. null_resource is a normal, still-supported resource used specifically to attach provisioners without an underlying cloud object, and provisioners are treated as a last resort precisely because they sit outside Terraform's usual state-comparison model.

Question 4

In Terraform, what is the primary purpose of a module?

Accepted Answer

To package a reusable, self-contained set of resources that can be called multiple times with different input variables. A module is a folder of configuration that groups related resources together, like a VPC module bundling subnets, route tables, and gateways, so that same bundle can be called repeatedly with different input variables instead of copy-pasting the same HCL for every environment or team. Encryption of state, locking concurrent runs, and rollback on failure are all real Terraform-adjacent concerns, but none of them are what a module is for. Modules exist purely for organizing and reusing configuration.

Question 5

A team defines an `aws_db_instance` resource with `password = var.db_password` and applies it successfully. Months later, a security audit flags that the database password is sitting in plaintext inside terraform.tfstate. What is the best explanation and mitigation?

Accepted Answer

Terraform state stores the full attributes of every managed resource, including sensitive ones, in plaintext by default, so state should live in an encrypted remote backend with tightly controlled access rather than be committed to version control. Terraform's state file is essentially a full JSON snapshot of every attribute of every managed resource, and that includes secrets like database passwords in plaintext, regardless of whether the source variable was marked sensitive. Marking a variable sensitive only suppresses it from being printed in CLI plan and apply output and logs, it does NOT remove or encrypt that value in state, which is why assuming otherwise is a common mistake. The real mitigation is treating the state file itself as a secret: an encrypted remote backend with strict access control, and never committing state to git.

Question 6

[Ansible] How do you test Ansible roles before deploying to production?

Accepted Answer

Use Molecule + Docker/Vagrant to create test instances, converge, verify. Testing directly on production is exactly the risk you're trying to avoid. Molecule spins up disposable test instances (via Docker or Vagrant), runs your role against them, and checks the result, so you catch problems on a throwaway environment before the role ever touches a real server.

Question 7

[IaC General] What does declarative infrastructure mean?

Accepted Answer

You describe the desired end state; the tool figures out how to achieve it. Declarative means you describe the outcome you want ('I want 3 servers running this image') and let the tool figure out how to get there, rather than writing out every individual step yourself like you would in an imperative script or by clicking through a console manually.

Question 8

[Ansible] Which feature ensures idempotency (running twice has same effect as once)?

Accepted Answer

Using declarative modules (e.g., file, package, service). Modules like file, package, and service always check the current state of the system BEFORE making a change, so if something's already in the right state, they simply do nothing. That's what makes running a playbook twice as safe as running it once, versus a raw shell or command module that just blindly re-executes whatever you told it to.

Question 9

A security group was created manually in the AWS console before a team adopted Terraform. They've now written an `aws_security_group` resource block that matches it exactly, but running `terraform apply` would create a brand-new duplicate security group instead of managing the existing one. What should they do instead?

Accepted Answer

Run `terraform import` to bind the existing security group's real-world ID to the new resource address in state, then reconcile any config differences the next plan reports. terraform import is built exactly for this situation: it takes a resource address already declared in configuration plus an existing cloud resource's ID, and creates an entry for it in state so Terraform starts managing the real object instead of creating a competing duplicate. Deleting the working security group first is needlessly destructive and risks an outage if anything currently depends on it. terraform refresh only updates the recorded attributes of resources Terraform is already tracking in state, it can't adopt a resource with no state entry at all, and create_before_destroy is a lifecycle setting that governs replacement ordering, unrelated to adopting unmanaged resources.

Question 10

[CloudFormation] What file format(s) can define a CloudFormation template?

Accepted Answer

JSON or YAML. AWS built CloudFormation to accept templates written in either JSON or YAML, it doesn't force you into just one. Most people end up preferring YAML since it supports comments and a shorter, more readable syntax for its special functions.

Infrastructure as Code Quiz

1. What is the purpose of the terraform.tfstate file?

2. [Terraform] How do you share modules across teams securely?

4. In Terraform, what is the primary purpose of a module?

5. A team defines an `aws_db_instance` resource with `password = var.db_password` and applies it successfully. Months later, a security audit flags that the database password is sitting in plaintext inside terraform.tfstate. What is the best explanation and mitigation?

6. [Ansible] How do you test Ansible roles before deploying to production?

7. [IaC General] What does declarative infrastructure mean?

8. [Ansible] Which feature ensures idempotency (running twice has same effect as once)?

10. [CloudFormation] What file format(s) can define a CloudFormation template?

Ready for the real thing?

Welcome to OpsQuiz!