Preparing for the Terraform Associate Exam
Day 23 of 30: Key Resources, Honest Self-Audit and a Study Plan That Actually Works
Introduction
The book is done. The infrastructure is built. Now comes the part most people rush, exam preparation. Day 23 is a full pivot away from building things and toward making sure I can answer questions about them under timed conditions.
Here is what I did today: audited myself honestly against every exam domain, identified exactly where my gaps are, built a structured study plan for the remaining days and ran through the official practice questions. This post covers all of it.
The Exam Domains and My Honest Self-Audit
The Terraform Associate exam covers nine domains. Here is my honest green/yellow/red rating for each based on 22 days of hands-on work:
The CLI section alone is 26% of the exam. Most people underestimate how deep the exam goes on command flags and behaviors, not just knowing that terraform state rm exists but knowing exactly what it does to real infrastructure.
The CLI Commands You Must Know Cold
These 15 commands are the ones that appear most frequently in exam questions. For each one you need to know what it does, when you would use it, and critically what it does and does not do to real infrastructure and state.
terraform init Downloads provider plugins, configures the backend and initializes modules. Run this first in any new working directory or after adding a new provider or module.
terraform validate Checks that your configuration is syntactically correct and internally consistent.
terraform fmt Formats your Terraform code to the canonical style. Run with -recursive to format all files in subdirectories. Run with -check to verify formatting without making changes.
terraform plan Generates an execution plan showing what Terraform will do to reach the desired state. Always save with -out to pin the plan for apply. Does not make any changes to real infrastructure.
terraform apply Executes the changes required to reach the desired state. Always apply from a saved plan file. If run without a plan file, generates a new plan first and prompts for confirmation.
terraform destroy Destroys all infrastructure managed by the current configuration. Equivalent to running terraform apply with every resource marked for deletion.
terraform output Reads output values from the current state. Useful for scripting ( pipe the output of one Terraform workspace into another).
terraform state list Lists all resources currently tracked in state. Useful for quickly seeing what Terraform manages without reading the state file directly.
terraform state show Shows all attributes of a specific resource in state. Use when you need to see the current values Terraform has recorded for a resource.
terraform state mv Moves a resource within state, either to a new address in the same state or to a different state file entirely. Does not touch real infrastructure. Use when refactoring module structure without destroying and recreating resources.
terraform state rm Removes a resource from state without destroying the real infrastructure. Use when you want Terraform to stop managing a resource, for example when handing it off to another team or another Terraform configuration.
terraform import Imports existing infrastructure into Terraform state. Use when you have resources that were created manually or by another tool and you want Terraform to start managing them.
terraform workspace Manages Terraform workspaces. Key subcommands: list, new, select, show, delete. Workspaces allow multiple state files from the same configuration.
terraform providers Shows the providers required by the current configuration and their versions. Use terraform providers lock to update the lock file with new provider version constraints.
terraform graph Outputs a dependency graph of all resources in the current configuration in DOT format. Pipe to Graphviz to visualize. Useful for understanding complex dependency chains.
Non-Cloud Providers
Terraform is not just for AWS, Azure and GCP. The exam regularly tests the random and local providers. Here is a working example of both:
resource "random_id" "example" {
byte_length = 8
}resource "random_password" "db" {
length = 16
special = true
}
resource "local_file" "example" {
content = "Hello from Terraform"
filename = "${path.module}/output.txt"
}The random provider is useful for generating unique resource names, database passwords and suffixes that prevent naming conflicts. The local provider is useful for writing rendered templates to disk during a Terraform run.
Provider Aliases: Two Regions, One Configuration
provider "aws" {
region = "us-east-1"
}provider "aws" {
alias = "west"
region = "us-west-2"
}
resource "aws_s3_bucket" "west_bucket" {
provider = aws.west
bucket = "my-west-bucket"
}Provider aliases let you use the same provider with different configurations in the same Terraform configuration. The most common use case is deploying resources across multiple regions or multiple AWS accounts.
My Study Plan for Days 24–30
The CLI section gets the most time because it is the largest domain and the one where the exam goes deepest on details that hands-on work alone does not cover.
Five Original Practice Questions
Question 1 You run terraform state rm aws_s3_bucket.example. What happens to the real S3 bucket in AWS?
Get Winjoyntinyari’s stories in your inbox
Join Medium for free to get updates from this writer.
A) The bucket is deleted from AWS
B) The bucket is marked for deletion on the next apply
C) Nothing — the bucket remains in AWS but Terraform no longer tracks it D) Terraform throws an error because the bucket still exists
Correct answer: C. terraform state rm only removes the resource from Terraform's state file. The real infrastructure is completely untouched. On the next terraform plan, Terraform will not know the bucket exists.
Question 2 A team member manually deleted an EC2 instance that Terraform manages. What does terraform plan show?
A) No changes — Terraform only knows what is in the configuration
B) The instance as a resource to be created
C) An error because the state file is corrupted
D) The instance as a resource to be destroyed
Correct answer: B. Terraform detects drift by comparing state to real infrastructure. The state says the instance exists, real infrastructure says it does not — so Terraform plans to create it.
Question 3 Which of the following is the correct order of variable precedence in Terraform, from lowest to highest?
A) Default → terraform.tfvars → environment variables → -var flag
B) -var flag → environment variables → terraform.tfvars → default
C) terraform.tfvars → default → environment variables → -var flag
D) Default → environment variables → terraform.tfvars → -var flag
Correct answer: A. Default values have the lowest precedence. Values in terraform.tfvars override defaults. Environment variables prefixed with TF_VAR_ override tfvars. The -var flag at the command line has the highest precedence and overrides everything.
Question 4 You want to deploy the same Terraform configuration to three environments, dev, staging, and production, with separate state files for each. Which two approaches achieve this?
A) Using Terraform workspaces or using separate directories for each environment
B) Using multiple provider blocks or using Terraform Cloud
C) Using separate state files manually or using terraform import
D) Using count meta-argument or using for_each meta-argument
Correct answer: A. Workspaces maintain separate state files from the same configuration. Separate directories with their own backend configurations also achieve separate state. Both are valid approaches with different tradeoffs.
Question 5 When does a Sentinel policy run in the Terraform Cloud workflow?
A) Before terraform plan is generated
B) After terraform plan, before terraform apply
C) After terraform apply completes
D) During terraform init
Correct answer: B. Sentinel policies run after the plan is generated and before apply is permitted. If a policy fails, the apply is blocked automatically. This is what makes Sentinel a preventive control rather than a detective one.
Key Tips for the CLI Section
The CLI section trips up more prepared candidates than any other domain. Three specific things to know:
First, know the difference between what a command does to state and what it does to real infrastructure. terraform state rm touches state only. terraform destroy touches both. The exam constructs scenarios specifically to test this distinction.
Second, know the -target flag, what it does, when it is useful and why HashiCorp recommends avoiding it in regular workflows. Targeting individual resources bypasses the dependency graph and can leave infrastructure in an inconsistent state.
Third, know terraform fmt --check vs terraform fmt. One reports formatting issues without changing files. The other fixes them in place.
#30DayTerraformChallenge #Terraform #TerraformAssociate #DevOps #IaC #AWSUserGroupKenya #EveOps
