Infrastructure Tests and Security Tests: Configuration Before Production

What kind of test this is

Infrastructure test checks environment code and configuration.

It can cover:

Terraform
OpenTofu
Helm
Kubernetes manifests
Dockerfile
CI/CD pipeline
routing
NetworkPolicy
RBAC

Security test checks security risk.

At this layer it often means:

secrets
permissions
container images
dependencies
network exposure
TLS
policy
hardening

These groups overlap.

A policy test for Kubernetes can be both an infrastructure test and a security test.

Policy tests

Policy test checks whether configuration satisfies organization or platform rules.

Examples:

container does not run as root
Deployment has a readinessProbe
Service is not public without approval
Pod has resource limits
Ingress has TLS
Terraform does not create a public bucket
RBAC does not grant wildcard permissions

These are decisions a regular application test will not see.

The application can work.

The environment can still be wrong.

Deployment tests

Deployment test checks the release process itself.

Not only whether the code works.

Examples:

artifact has the right tag
migrations run before the application
readinessProbe blocks traffic to an unready Pod
rollback restores the previous version
canary receives only part of traffic
feature flag has the expected state

Without such tests, a pipeline can look professional and still promote the wrong version.

Security tests

A security test does not have to mean a full pentest.

In a pipeline it often starts with simple automated checks:

SAST
dependency scanning
container image scanning
secret scanning
IaC scanning
DAST for selected endpoints

This does not catch everything.

But it catches a class of bugs that should not be found by a customer or attacker.

A security test is especially important where a change looks like configuration.

A public bucket, overly broad RBAC, or missing NetworkPolicy may not change any application test.

But it can change the attack surface.

Synthetic tests

Synthetic test runs after deployment from the perspective of an external observer.

It can check:

whether the page responds
whether login works
whether the certificate is valid
whether an endpoint from a specific region has acceptable time
whether checkout passes a minimal scenario

A synthetic test does not replace the pipeline.

It is an additional layer saying whether the production system is really usable.

Chaos tests

Chaos test deliberately breaks a controlled part of the system.

For example:

kills a Pod
cuts off a dependency
increases latency
blocks DNS
fills disk

It is not done to prove bravery.

It is done to check resilience assumptions:

does retry work
is timeout configured
does fallback make sense
does the alert arrive
does the runbook lead to repair

A chaos test without observability is risky, because you can break the system and learn nothing.

Tool from the stack

For infrastructure tests I would choose Conftest with OPA policies for Terraform, OpenTofu, and Kubernetes manifests.

It fits the DevOps layer because it tests configuration before deployment.

Example rules:

no public buckets
no containers running as root
readinessProbe required
resource limits required
wildcard RBAC forbidden

For security scans I would add Trivy for images and dependencies.

Inside the cluster, Kyverno is a good continuation, because the same intent then runs as admission control.

The final gate

Infrastructure tests and security tests close the series because they sit farthest from the function, but very close to production.

At this layer the question is:

does the environment we are sending the change to still satisfy the assumptions of the application and organization?

Without this layer, production becomes the final tester of configuration.

And production is a very expensive testing tool.