8  Environment-specific review

Not all Terraform changes carry the same risk. A change to a sandbox environment that uses only synthetic data is very different from a change to the production environment that processes live operational data. This chapter explains how to calibrate your review based on the target environment.

8.1 The four environments

This organisation uses four environments, each with its own Terraform root in the terraform/ directory:

Directory Environment Purpose
01_sandbox/ Sandbox Early exploration, proof of concept, low-risk experimentation
02_dev_nonprod/ Non-production Day-to-day development, integration, and feature testing
03_stg_prod/ Pre-production Final validation and operational rehearsal before go-live
04_prd_prod/ Production Live service delivery and operational processing

Each environment is a separate Google Cloud project. This separation is the trust boundary — identities, state, quotas, policies, and audit trails are isolated by environment. A mistake in sandbox cannot directly affect production.

8.2 What changes between environments

As infrastructure moves from sandbox towards production, several things should change:

  • Data: Sandbox should use only synthetic, anonymised, or openly published data. Production may process live operational data, depending on the service’s approval.
  • Access controls: Production access should be restricted to the smallest practical group. Non-production environments can be more permissive.
  • Monitoring and logging: Production and pre-production should have audit logging, alerting, and monitoring configured. These are optional in sandbox.
  • Deletion protection: Stateful resources such as databases and storage buckets should have prevent_destroy = true in pre-production and production.
  • Encryption: Explicit at-rest and in-transit encryption configuration should be present in pre-production and production.
  • Resilience: Production resources may need high-availability configuration (multi-region storage, read replicas) that is unnecessary in lower environments.

8.3 Review expectations by environment

Sandbox

Sandbox is the most forgiving environment. The intent is to allow experimentation without the overhead of production-grade controls.

What to check:

  • The code does not reference production project IDs or real data sources
  • There are no hardcoded secrets
  • The change is clearly scoped to 01_sandbox/ and does not affect shared modules unexpectedly
  • Even in sandbox, IAM should be reasonably scoped — wide-open permissions are a bad habit to normalise

What is acceptable that would not be in production:

  • Missing deletion protection on resources
  • Less strict firewall rules
  • Reduced or absent logging configuration
  • Use of less expensive, lower-resilience resource tiers

Non-production

Non-production is used for day-to-day development. It should have baseline controls in place, because integration testing with broken security configurations provides false assurance.

What to check (in addition to sandbox checks):

  • IAM bindings follow least privilege
  • Logging is enabled on resources that will carry logging in production
  • Variable defaults are not set to production values
  • The code is structured so it can be promoted to pre-production without significant rework

What to watch for:

  • OFFICIAL-SENSITIVE data in non-production should be by exception only and agreed with the information owner
  • Service accounts should not have cross-environment permissions

Pre-production

Pre-production should mirror production controls as closely as practical. Its purpose is operational rehearsal — if it does not match production, the rehearsal is not meaningful.

What to check (in addition to non-production checks):

  • Deletion protection is enabled on stateful resources
  • Monitoring and alerting are configured
  • The resource configuration matches production (same instance types, same network topology, same encryption settings)
  • Access controls are as restrictive as production

What to watch for:

  • Pre-production may use production-like data in some cases. If so, the same data handling controls as production should apply
  • Changes that diverge from the production configuration without explanation

Production

Production changes require the highest level of scrutiny. Mistakes here affect live services and potentially real data.

What to check (in addition to pre-production checks):

  • Is there a terraform plan output attached? You should not approve a production change without having seen what it will do.
  • Are destructive changes (-/+ in the plan) clearly expected and explained? If not, block the PR and ask.
  • Is deletion protection enabled on all stateful resources?
  • Has the change been tested in pre-production first?
  • Are there any IAM changes? If so, have they been reviewed with particular care?

Escalate to a platform engineer if:

  • You are not confident you understand all implications of the change
  • The plan shows unexpected replacements
  • The change touches network perimeter rules, organisation-level policies, or audit logging configuration

8.4 Security classifications

UK government uses OFFICIAL, OFFICIAL-SENSITIVE, SECRET, and TOP SECRET as its security classification scheme. This team’s work is almost entirely within OFFICIAL. For the purposes of this infrastructure:

  • Most routine service data is handled at OFFICIAL
  • OFFICIAL-SENSITIVE data requires additional handling controls and should be documented with the service’s security and information management leads before infrastructure is built to process it

If a PR introduces infrastructure intended to process OFFICIAL-SENSITIVE data, and this has not been agreed with the information owner and documented, block the PR and raise the issue before approving.

8.5 Checking the right environment is targeted

A common mistake is submitting a change against the wrong environment directory. Always check:

  • Does the PR description say which environment is being changed?
  • Do the changed files match? A PR described as “adds storage bucket to sandbox” should only touch 01_sandbox/.
  • Are any shared modules changed? If so, understand which environments will be affected.
  • Does the backend.tf in the changed directory point to the correct state backend for that environment?