Testing Strategies for Infrastructure as Code

All courses / Architecture as Code / Module 4 / Chapter 13

Learning objectives

After the lesson the participant can:

• Explain how testing codified infrastructure differs from testing application logic.
• Design a four-stage pipeline scaffold that gives the same assurance gates on different tooling.
• Distinguish preventive policy evaluation in the pipeline from detective evaluation after deployment.
• Define guardrails for a chaos experiment described as code.

Key concepts

Architecture as Code test pyramid

A structured progression from rapid developer tests to comprehensive integration and end-to-end validation, each layer serving a distinct quality purpose. The multilayered approach finds problems early, when they are cheaper and simpler to fix.

Unit testing without deployment

Validation of individual modules and resources without deploying infrastructure. Tests check resource configurations, variable validations, output consistency and module interface contracts, using mocks so that assertions run before any cloud cost is incurred.

Shared pipeline scaffold

Four complementary stages, lint and format, contract and unit tests, policy enforcement and integration rehearsal, implemented for both Pulumi and Terraform paths so that both pass the same assurance gates and platform parity is maintained.

Preventive and detective policy evaluation

Open Policy Agent evaluates policies preventively in the pipeline, before deployment. AWS Config Rules are detective by default, evaluating resources after they have been deployed.

Chaos experiments as code

Failure scenarios such as instance loss or degraded dependencies described alongside infrastructure definitions. Failure injection policies, scheduling rules and opt-in environments live in version control, which keeps the blast radius controlled and every change reviewable.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Teaching plan

Discussion

1. The chapter says each pipeline stage should block deployment on critical failures while allowing warnings to proceed. How would you decide which findings are hard failures in your organisation?
2. Why does the chapter warn that coverage goals should focus on meaningful tests and not on the metric?
3. What must be communicated, and to whom, before a fault is injected deliberately into an environment?

Written exercise

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

1. According to the chapter, at what point does Open Policy Agent evaluate policies, in contrast to AWS Config Rules?

   1. Only during the annual compliance audit
   2. Preventively in the pipeline, before deployment
   3. Detectively, after resources have been deployed
   4. Only when a resource is deleted from the estate
   Show the answer

   B. Preventively in the pipeline, before deployment
   The chapter notes that the two act at different points: Open Policy Agent evaluates preventively in the pipeline before deployment, while AWS Config Rules are detective by default.

2. What should unit tests for codified infrastructure validate, according to the chapter?

   1. Auto-scaling behaviour under realistic production load
   2. Failover between regions during a simulated outage
   3. End-to-end deployment from a source change through the pipeline to a running system
   4. Resource configurations, variable validations, outputs and interface contracts
   Show the answer

   D. Resource configurations, variable validations, outputs and interface contracts
   Unit tests validate resource configurations, variable validations, output consistency and module interface contracts without deploying infrastructure. Load, failover and end-to-end checks belong to higher layers.

3. Which order of investment does the chapter's summary suggest, based on the testing strategy quadrant?

   1. Start with security scanning and policy testing, then add end-to-end tests where risk justifies it
   2. Start with end-to-end tests of whole environments, then add unit tests once the pipeline has become stable
   3. Start with performance testing, then add compliance tests before each audit
   4. Start with chaos experiments in production, then add static analysis
   Show the answer

   A. Start with security scanning and policy testing, then add end-to-end tests where risk justifies it
   Security scanning and policy testing offer high coverage with moderate complexity, so the chapter suggests starting there and adding end-to-end tests where the risk justifies their cost.