Practice Infrastructure as Code testing vocabulary: unit testing IaC with Terratest and pytest, real infrastructure in tests, mocking cloud providers, linting, and reading terraform plan output.
0 / 15 completed
1 / 15
The platform team writes ___ tests for their Terraform modules using Terratest.
IaC unit tests verify that individual modules or resources behave as expected. Terratest (Go) and pytest-terraform (Python) are popular frameworks. Unlike application unit tests, IaC unit tests often provision real cloud resources because infrastructure cannot be meaningfully tested without it.
2 / 15
A Terratest test ___ up real infrastructure in AWS to verify the module, then tears it down after.
'The module test spins up real infrastructure' means Terratest actually calls AWS/GCP/Azure APIs to create resources, runs assertions against them, and then destroys them. This catches issues that mocks miss but is slower and costs money.
3 / 15
For fast feedback the CI pipeline ___ the cloud provider in unit tests, avoiding real API calls.
Mocking the cloud provider in IaC unit tests means using tools like LocalStack (AWS), the Terraform testing framework's mock_provider, or similar to simulate API responses locally. Tests run faster and do not incur cloud costs, but cannot catch all real-world issues.
4 / 15
The CI pipeline runs ___ on all Terraform files to catch style and misconfiguration issues before plan.
IaC linting tools like tflint (Terraform), cfn-lint (CloudFormation), or checkov check HCL/YAML for syntax errors, deprecated resource types, missing required variables, and policy violations — catching issues before any infrastructure is provisioned.
5 / 15
The pull request review includes the terraform ___ output: it shows 3 resources will be destroyed.
terraform plan generates an execution plan showing exactly which resources will be added (+), changed (~), or destroyed (-) if terraform apply is run. Reviewing the plan output before applying is a critical safety practice, especially when deletions are shown.
6 / 15
During a code review of a Terraform module designed to provision EC2 instances, Sarah notices the following comment from Mark:
'This test uses `terraform plan` and then runs `terratest verify` against the output. It seems like a good approach for ensuring infrastructure changes are reflected correctly.'
What is the primary reason why Mark's suggestion might be considered suboptimal?
The key here is understanding that terraform plan only *simulates* infrastructure changes. It doesn't actually execute them or confirm they've been applied correctly to the real environment. terratest verify specifically tests against the actual state of the provisioned resources, making it a more robust validation method. Mark's suggestion misses this crucial difference.
7 / 15
You're working with the team on an IaC project using Pulumi. During a Slack discussion about testing, David suggests using mocks for external services.
David says: 'We should use mocks to simulate our database calls during unit tests so we don't need to spin up a real database instance.'
What is the primary benefit of this approach?
Mocks are invaluable for isolating components during unit testing. By simulating external dependencies like databases, you remove the variability and complexity of a real system, allowing you to focus solely on the logic within your code. This isolation makes tests more reliable, faster, and easier to debug – the core goal of good unit testing.
8 / 15
As a DevOps engineer, you're reviewing a PR that introduces a new CI pipeline for Terraform deployments. The pipeline includes a step to run terraform validate on all modules before proceeding with the plan. What is the primary purpose of this validation step?
terraform validate performs a static analysis of your Terraform configuration. It checks for syntax errors, incorrect module names, and other issues that would prevent the terraform plan or terraform apply commands from succeeding. It's a crucial early-stage check to catch problems before they impact deployment.
9 / 15
During a standup meeting, the team lead asks: 'How are we ensuring our infrastructure as code deployments are resilient to unexpected changes in AWS service configurations?'
Which of the following testing strategies would MOST effectively address this concern?
While frequent terraform plan checks can *detect* drift, they don't address it. The most effective approach is to use a tool like Terratest that can proactively manage and restore your infrastructure to a known-good state in response to configuration changes – actively testing resilience rather than just passively observing drift.
10 / 15
You're investigating an issue where the CI pipeline is failing after a Terraform module update. The error message indicates: 'Resource 'aws_instance' has been changed by a deployment'.
What should you do to diagnose this problem?
The error message clearly points to a change in an AWS EC2 instance. Running terraform plan will reveal *exactly* what modifications were made by the deployment, allowing you to understand why the terratest verify test failed – it's crucial to examine the planned changes before jumping to conclusions or rolling back blindly.
11 / 15
During a code review of a Terraform module designed to provision EC2 instances, Sarah notices the following comment from Mark:
'This test uses `terraform plan` and then runs `terratest verify` against the output. It seems like a good approach for ensuring infrastructure changes are reflected correctly.'
What is the primary reason why Mark's suggestion might be considered suboptimal?
The key here is understanding that terraform plan only *simulates* infrastructure changes. It doesn't actually execute them or confirm they've been applied correctly to the real environment. terratest verify specifically tests against the actual state of the provisioned resources, making it a more robust validation method. Mark's suggestion misses this crucial difference.
12 / 15
You're working with the team on an IaC project using Pulumi. During a Slack discussion about testing, David suggests using mocks for external services.
David says: 'We should use mocks to simulate our database calls during unit tests so we don't need to spin up a real database instance.'
What is the primary benefit of this approach?
Mocks are invaluable for isolating components during unit testing. By simulating external dependencies like databases, you remove the variability and complexity of a real system, allowing you to focus solely on the logic within your code. This isolation makes tests more reliable, faster, and easier to debug – the core goal of good unit testing.
13 / 15
As a DevOps engineer, you're reviewing a PR that introduces a new CI pipeline for Terraform deployments. The pipeline includes a step to run terraform validate on all modules before proceeding with the plan. What is the primary purpose of this validation step?
terraform validate performs a static analysis of your Terraform configuration. It checks for syntax errors, incorrect module names, and other issues that would prevent the terraform plan or terraform apply commands from succeeding. It's a crucial early-stage check to catch problems before they impact deployment.
14 / 15
During a standup meeting, the team lead asks: 'How are we ensuring our infrastructure as code deployments are resilient to unexpected changes in AWS service configurations?'
Which of the following testing strategies would MOST effectively address this concern?
While frequent terraform plan checks can *detect* drift, they don't address it. The most effective approach is to use a tool like Terratest that can proactively manage and restore your infrastructure to a known-good state in response to configuration changes – actively testing resilience rather than just passively observing drift.
15 / 15
You're investigating an issue where the CI pipeline is failing after a Terraform module update. The error message indicates: 'Resource 'aws_instance' has been changed by a deployment'.
What should you do to diagnose this problem?
The error message clearly points to a change in an AWS EC2 instance. Running terraform plan will reveal *exactly* what modifications were made by the deployment, allowing you to understand why the terratest verify test failed – it's crucial to examine the planned changes before jumping to conclusions or rolling back blindly.
Practice Infrastructure as Code testing vocabulary: unit testing IaC with Terratest and pytest, real infrastructure in tests, mocking cloud providers, linting, and reading terraform plan output.
How many exercises are in this module?
This module has 15 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Infrastructure as Code exercises?
Browse the full Infrastructure as Code hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.