Phase 5: Platform Engineering

Infrastructure testing: plan validation, policy-as-code & dry runs

Intermediate ~2 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you’re building an amazing, super-complicated LEGO castle. You have a massive instruction book, full of steps telling you exactly which brick goes where (that instruction book is like the "code" we write for computer systems). Before you even snap one brick together, what’s a smart thing to do? You’d probably look through the instructions really carefully, right? You’d check if you have all the pieces it says you need, and if any step seems impossible, like "attach a square brick to a round hole where there isn't one." This careful checking of your plan before you start building is what we call "plan validation" for computer systems. It's like a practice run in your head, making sure your castle design is actually possible.

A special computer helper looks at your instructions and says, "Yep, this looks like a castle you could build with the pieces available," or "Woah, hold on! You asked for a 'rainbow-striped invisible' brick, and those don't exist!" This check makes sure you haven't made any silly typos, like asking for a super-fast computer part that doesn't actually exist in the real world, or trying to put a piece where it simply won't fit. It's making sure your design is possible to build.

But just because you can build something, does it mean you should? Now, imagine your parents have some extra rules for your LEGO castle. Maybe they say, "No part of the castle can stick out past the edge of the table" (a safety rule), or "all towers must be at least three bricks tall" (a design rule). These aren't in your instruction manual, but they are important rules you have to follow. "Policy-as-code" is like having those extra rules for building your computer systems, but written down in a special computer language too. Instead of just checking if your plan can be built, it checks if it should be built according to these important rules. For example, a rule might be "you can never build a public part of your system that anyone on the internet can just look into," or "every new computer system must have a special label saying who owns it."

So, first, the computer checks if your castle plan makes sense and uses real bricks that exist. Then, it checks if your castle plan follows all the extra rules your parents set. Only if both are true can you start building for real! This means you can be much more confident that what you're building is not only possible but also safe, secure, and follows all the important guidelines for your computer systems. It helps catch potential problems super early, before they become a big headache, just like catching a typo in your LEGO instructions before you waste time trying to put a non-existent piece together.

When managing infrastructure with code, preventing errors before they impact live systems is paramount for an SRE. Infrastructure testing provides this safety net. The first crucial step is plan validation, which involves checking your IaC configuration for correctness without actually deploying anything. Tools like terraform plan or aws cloudformation validate parse your code to ensure it's syntactically sound, logically consistent, and that all specified resources and parameters are valid according to the cloud provider's API. This essential dry run identifies immediate issues, such as misspelled resource types or invalid region names, ensuring that the intended state is even possible to achieve.

Beyond mere syntax, policy-as-code introduces a layer of automated governance. While plan validation confirms if something can be built, policy-as-code dictates if it should be built according to your organization's security, compliance, cost, or operational standards. This involves defining rules, such as "no public S3 buckets," "all compute instances must have specific tags," or "databases must be encrypted at rest," directly within your IaC pipeline. Tools like Open Policy Agent (OPA) or HashiCorp Sentinel evaluate your infrastructure plans against these policies before deployment, automatically blocking non-compliant changes and shifting security and compliance left in your development cycle.

Finally, dry runs serve as a critical simulation step, often overlapping with plan validation but emphasizing the full impact analysis. A dry run provides a detailed report of all changes that would occur if the IaC were applied, including creations, updates, and deletions of resources. For instance, terraform plan doesn't just validate syntax; it communicates exactly what actions Terraform will take to reach the desired state. This comprehensive preview allows SREs to understand the precise implications of their changes, identify any unintended consequences, gain confidence, and get final approvals from stakeholders, ensuring a predictable and safe deployment process without ever touching the live infrastructure.

Key Takeaways

  • Infrastructure testing (validation, policy, dry runs) prevents errors and ensures compliance early in the IaC pipeline.
  • Plan validation checks IaC syntax and resource validity before any deployment.
  • Policy-as-Code enforces organizational rules (security, cost, compliance) automatically on your infrastructure plans.
  • Dry runs simulate proposed changes, showing the exact impact on your infrastructure before applying them.

Code Example

bash
# Example 'terraform plan' command and output:
$ terraform plan

Terraform will perform the following actions:

  # aws_s3_bucket.my_app_bucket will be created
  + resource "aws_s3_bucket" "my_app_bucket" {
      + acl    = "private"
      + bucket = "my-application-bucket-12345"
      # ... other attributes omitted for brevity
    }

Plan: 1 to add, 0 to change, 0 to destroy.

How this code works

The terraform plan command is a vital step in infrastructure testing, acting as a "dry run" to validate intended changes without actually provisioning any resources. Its job is to generate a comprehensive report detailing exactly what actions Terraform proposes to take based on the current configuration and the existing state of the infrastructure. This output is crucial for reviewing and confirming that the planned changes align with expectations and policies, preventing unintended modifications or security risks before anything is deployed to the cloud environment. It's the primary mechanism for "plan validation" before commitment.

Executing $ terraform plan produces a summary of proposed actions. The line "Terraform will perform the following actions:" introduces the detailed breakdown. Here, + resource "aws_s3_bucket" "my_app_bucket" indicates that a new AWS S3 bucket, logically named my_app_bucket, will be created (the + signifies addition). Nested within this are the specific attributes being set, such as acl = "private" for access control and bucket = "my-application-bucket-12345" for its unique name. A subtle but important point for beginners is that despite showing detailed actions, terraform plan performs no actual modifications to cloud resources; it purely presents a forecast. The final line, "Plan: 1 to add, 0 to change, 0 to destroy," provides a concise summary of the total intended operations.

Resources

Related Articles

Hand-picked reads to go deeper on infrastructure as code.

Back to Site Reliability Engineer Roadmap