14 Glossary
Key terms used throughout this guide.
14.1 Apply
The Terraform operation that executes the changes described in a plan, creating, updating, or destroying real cloud resources. Running terraform apply makes changes to your infrastructure immediately.
14.2 Backend
The location where Terraform stores its state file. In this team’s infrastructure, the backend is a remote Cloud Storage bucket, so that state is shared across the team and not stored on a local machine.
14.3 Blast radius
The scope of potential damage if a change goes wrong. A resource that affects only one service account has a small blast radius; a change to a shared network or organisation-level IAM policy has a large one. Keeping blast radius small is a core infrastructure review principle.
14.4 CI/CD
Continuous integration and continuous deployment. In this context, the automated pipelines (GitHub Actions) that run linting, validation, and security checks on every pull request, and deploy changes on merge.
14.5 Destroy
The Terraform operation that removes a resource from both the cloud environment and the state file. Destructive changes appear as - in a plan output.
14.6 Drift
The difference between what Terraform’s state file believes exists in your cloud environment and what actually exists. Drift occurs when changes are made outside Terraform — for example, manually through the cloud console. Running terraform plan will show drift as unexpected changes.
14.7 Idempotency
The property of an operation that produces the same result regardless of how many times it is run. Terraform apply should be idempotent: running it twice with no code changes should produce no changes on the second run.
14.8 Infrastructure as Code (IaC)
The practice of managing and provisioning cloud infrastructure through machine-readable configuration files rather than manual processes or interactive tools. Terraform is the IaC tool used in this team.
14.9 Least privilege
The principle that a user, service account, or system component should be granted only the permissions it needs to perform its function — nothing more. Applying least privilege limits the damage that can be caused by a mistake or a compromised credential.
14.10 Module
A reusable, self-contained unit of Terraform configuration. Modules are stored in modules/ and called from root modules in each environment directory. Using modules avoids repeating the same configuration across environments.
14.11 OFFICIAL
The baseline security classification for most UK government work. Data that is OFFICIAL requires standard controls but is not considered sensitive enough to warrant enhanced protective measures. See the Government Security Classifications Policy for the authoritative definition.
14.12 OFFICIAL-SENSITIVE
A handling caveat within the OFFICIAL classification, used for information that warrants additional access controls. Infrastructure handling OFFICIAL-SENSITIVE data should be documented with the service’s security and information management leads before it is built.
14.13 Plan
The Terraform operation that computes the difference between your configuration and the current state, and shows what changes would be made by terraform apply. A plan does not make any changes. See Reading a Terraform plan for how to read one.
14.14 Provider
A plugin that allows Terraform to interact with a specific cloud platform or service. This team uses the hashicorp/google provider for Google Cloud Platform resources. Provider versions should be pinned to avoid unexpected changes from provider updates.
14.15 Root module
The top-level Terraform configuration for a specific environment — the main.tf, variables.tf, outputs.tf, versions.tf, and backend.tf files in directories like 01_sandbox/. Root modules call reusable modules and define what is actually deployed in each environment.
14.16 State file
The file (terraform.tfstate) in which Terraform records what resources it has created and their current configuration. The state file is the source of truth for what Terraform believes exists in your cloud environment. It is stored remotely in a Cloud Storage bucket and must not be edited manually.
14.17 Trust boundary
The perimeter within which resources share the same access controls, identity model, and security policies. In this team’s infrastructure, each Google Cloud project is a trust boundary for one environment. Keeping environments in separate projects means that a compromise in sandbox cannot directly affect production.
14.18 Workspace
A Terraform feature that allows multiple state files to be managed from the same configuration. This team does not use workspaces to separate environments — each environment has its own root module directory instead, which provides stronger separation.