Example

A company receives a proposal for building a cloud environment. It mentions landing zone, GitOps and policy as code, and nobody in the meeting asks, because everyone assumes the others know.

What gets commissioned is a text both sides read differently. Later it turns out that one side understood handover to mean a piece of documentation and the other a running environment including the code.

That costs a renegotiation, a postponed date and the trust for the next tender. Two minutes of looking things up before the meeting would have been enough.

A

Agent

A programme that uses a language model to complete a task in several steps on its own: it decides which tool to call next instead of merely answering. The difference from a chat is the action, because an agent does not only read, it also creates tickets or changes data. That is why the question of what it may do matters more than the question of how well it writes. See also: MCP.

API gateway

The component that sits in front of your interfaces and accepts, checks and forwards every call. It enforces in one place what every service would otherwise have to handle on its own: sign-in, rate limiting, logging. See also: API management.

API management

The platform around the gateway, with administration of the interfaces, versions and access, a portal for developers and analysis of usage. The gateway executes at runtime what is defined here. Whoever runs a handful of internal interfaces rarely needs it; whoever exposes them to third parties almost always does. See: What is API management?

B

Blast radius

The area a mistake or a break-in can reach before something stops it. An environment where everything lives in one account has a large radius; separate accounts per environment have small ones. The question behind it is: what breaks if exactly this one spot fails? See also: Least privilege.

C

CI/CD

The automated path from source code to the running application. CI stands for continuous integration, the constant merging and checking of changes, CD for continuous delivery of the result. Because every change takes the same path, this is also the place where checks take hold while a fix is still cheap. See also: Shift left.

Container

An application together with everything it needs to run, in one sealed package. It behaves the same on the laptop as on the server, because the environment is part of the package. The comparison that holds up: the shipping container, whose contents do not concern the crane. See also: Kubernetes.

Container registry

The storage location servers fetch container images from. Whoever may write there determines what runs in production, which is why the registry is one of the places where access rights really count. See also: SBOM.

CSPM

Cloud security posture management, meaning tools that continuously scan a cloud environment for misconfigurations: open storage, overly broad permissions, missing encryption. They find what has crept in between two projects and make the current state comparable. They do not replace a rule that prevents the mistake in the first place. See also: Policy as code.

D

Data processing on behalf

The case where a service provider processes personal data on behalf of and under the instructions of its customer, for example a cloud provider. The General Data Protection Regulation requires a contract for this that records purpose, duration and protective measures. Responsibility for the data stays with the customer. See also: Data residency.

Data residency

The question of which country data actually resides and is processed in. A data centre in Germany answers it only halfway, because operations, support and backups can take place elsewhere. A contract should commit to both. See also: Sovereignty.

DevSecOps

The practice of putting security checks into the same track where building and shipping happen anyway, instead of attaching them at the end. Security becomes the team's task rather than another department's sign-off. This only holds up if the checks are fast and produce few false alarms. See also: Shift left.

Drift

The state in which the actual environment deviates from what the code says. It usually starts harmlessly, because someone changes something by hand during an incident and never folds it back into the code. Every unnoticed deviation makes the next automated change unpredictable. See also: Infrastructure as code.

F

FinOps

The practice of making cloud costs visible where they arise, so the teams can steer them themselves. The prerequisite is clean attribution: every resource has a label that says what it belongs to. Without this attribution, the month ends with a sum nobody can explain. See also: Landing zone.

G

GitOps

An operating model in which the desired state of managed resources is versioned and agents continuously reconcile it with actual state. Automatic corrections depend on the managed scope and configuration. Reviews and access rules must be configured. See also: Drift.

Golden path

A prepared, documented path for a recurring task, such as setting up a new service. It is built so that the path that meets the house rules is also the most convenient one. Voluntary use is a good signal; mandatory use alone does not prove the benefit. See: What is Platform Engineering?

H

Hyperscaler

The large, globally operated cloud providers, above all Amazon Web Services, Microsoft Azure and Google Cloud. They offer a very large number of services at low entry cost, and they shape the terms everyone else talks in afterwards. See also: Shared responsibility.

I

Identity provider

The service that knows who works at the company and confirms to other applications that someone is who they claim to be. Instead of maintaining a separate password in every application, every application asks there. Access can be managed centrally; revocation must also account for existing sessions and tokens. See also: SSO.

Infrastructure as code

Servers, networks and permissions are described as a text file instead of clicked together in a console. The same file produces the same environment every time, and a change is reviewed like application code. The real gain is repeatability, because an environment that exists only once cannot be rolled back. See: What is Infrastructure as Code?

Internal Developer Platform

The internal offering development teams use to serve themselves: prepared paths into production, ready-made building blocks and a directory that says what exists and who owns it. It replaces the request to a central team with a button. It becomes worthwhile only once the same task comes up often enough. See: Internal Developer Platform.

K

Kubernetes

A system that distributes applications in containers across many machines, restarts them when one fails and multiplies them under load. It is widespread, but not a prerequisite for a platform. It takes operational work away and brings its own. See also: Container.

L

Landing zone

The prepared base structure of a cloud environment before the first application moves in: account layout, networking, identity, rules and logging. The comparison that holds up: serviced building land with roads and utilities, not the finished house. Whoever skips it retrofits the order later, under live operation. See: What is a landing zone?

Least privilege

The principle that every access gets exactly as many rights as it needs for its task, and none beyond. It works in the event of damage, because a taken-over account can only do what it was responsible for. The effort lies in the follow-up, because rights grow faster than they are taken back. See also: Blast radius.

LLM (language model)

A large language model is a programme that has learned from vast amounts of text which word typically follows, and forms answers from that. It knows nothing, it computes probabilities, and that is why it can sound convincing and still be wrong. For enterprise use, what it may access matters more than the model itself. See also: RAG.

M

MCP

Model Context Protocol, an open description of how a language model talks to tools and data sources. Instead of building a separate connection for every application, everyone involved speaks the same format. Benefit and risk sit in the same place: it becomes very easy to give a model access to real systems. See: Securing MCP.

mTLS

An encrypted connection in which both sides present a certificate, not just the server. This lets services verify the identity of their counterpart. Additional access rules determine which services may access which functions. See also: Zero trust.

Multi-tenancy

Several teams or customers work on the same technical foundation without seeing or disturbing each other. The work lies in the separation: own areas, own limits, own permissions. It saves operating cost and costs design effort. See also: Internal Developer Platform.

O

Observability

The ability to tell from the outside what a system is currently doing, from metrics, logs and the tracing of individual requests. The practical test is simple: can an incident be explained without logging into the machine? Wherever the answer is no, every incident takes longer than necessary. See also: SLO.

P

Platform engineering

The discipline of building an internal platform and maintaining it like a product, so development teams can ship without asking. It sits on the foundation that cloud engineering lays. Its measure is not the technology used, but whether the teams take the prepared path voluntarily. See: What is Platform Engineering?

Policy as code

Rules for an environment are stored as code, such as "no publicly reachable storage" or "every resource needs a cost centre". The rules can be checked automatically. Depending on the integration, violations are reported or changes are blocked. See also: CSPM.

Postmortem

The written review of an incident after it has been resolved: what happened, why it could happen and what changes. It is useful as long as it is written without blame, because otherwise nobody tells the interesting details any more. Without measures that have names and dates it remains a story. See also: Runbook.

Prompt injection

The case where a language model follows instructions hidden in content it was only supposed to read, such as an email, a web page or a document. The model does not reliably distinguish between "this is the task" and "this is in the text". That is why you limit what it may access instead of trusting it. See: Securing MCP.

R

RAG

Retrieval augmented generation, roughly: answering after searching first. Instead of relying on what it has learned, the system first finds the relevant passages in your own documents and writes the answer on that basis. Supplied sources make checking easier. Quality depends both on the retrieved content and on how the model uses it to produce the answer. See: Internal AI assistants.

Runbook

A short guide for a recurring operational case: how to recognise the problem, what to check in which order and whom to call. It is written for the human who was woken up at night. A runbook nobody has read for a year is usually wrong when it matters. See also: Postmortem.

S

SAST, DAST, SCA

Three families of automated security testing. SAST reads the source code, DAST probes the running application from the outside, SCA compares the included third-party components against known vulnerabilities. Each finds what the others structurally miss, which is why none replaces another. See also: DevSecOps.

SBOM

A software bill of materials (SBOM), a machine readable list of everything a piece of software is made of, including the parts of the parts. It answers the question asked after every major vulnerability disclosure: are we affected? It only becomes useful once it is generated automatically in every build. See: SBOM: generate, verify, retain.

Secrets management

The orderly handling of passwords, access keys and certificates: stored centrally, restricted in access, rotated regularly and never in the repository. The most common finding is not an attack, but a key someone checked in for testing years ago. See also: Least privilege.

Shared responsibility

The split of who answers for which part of security in the cloud. The provider secures the data centre, the hardware and the service itself; you secure your configuration, your access and your data. Incidents in the cloud happen predominantly on the side that belongs to the customer. See: cloud security fundamentals.

Shift left

Checks move earlier in the creation process, to the left on the timeline. The reason is economic: a mistake that surfaces during the review of a change costs a comment; the same mistake in production costs a release. See also: CI/CD.

SLO

Service level objective, a self-set target for the quality of a service, for example availability or response time. Its purpose is not the number but the decision behind it: as long as the target holds, you build; if it is missed, you stabilise. An SLO without this consequence is a figure on a slide. See also: Observability.

Sovereignty

The question of how dependent an operation is on a single provider or a single legal system. It breaks down into three smaller questions: where does the data reside, who can access it, and how costly would a switch be. Blanket answers rarely help; the three sub-questions do. See also: Data residency.

SSO

Single sign-on, meaning sign in once and then use all connected applications without signing in again. For employees it is more convenient; for the company it is above all safer, because there is only one place left where access is set up and revoked. OpenID Connect is a widely used protocol for this. Background: OpenID Connect Core 1.0 (opens in a new tab).

T

Terraform state

The file in which Terraform records which resources it has created and how they relate to the code. Without it, the tool does not know on the next run whether to change something or create it anew. It belongs in a shared, locked place and not on a laptop, otherwise two people work on the same environment at once. See: Terraform for teams.

Threat modelling

A structured conversation along an architecture diagram: what do we want to protect, who could attack it, at which point, and what do we do about it. The result is an ordered list of measures, not a tool report. It pays off early, because a design is cheaper to change than a running system.

Toil

Recurring manual work in operations that improves nothing permanently: the same ticket, the same move, every week. It is the best candidate for automation, because the effort is known and the benefit repeats. Whoever does not track toil automates whatever is fun at the moment instead. See also: Runbook.

Z

Zero trust

The principle that no access is trustworthy merely because it comes from the company's own network. Every access authenticates itself and is checked, regardless of location. In implementation it is less a product than a series of decisions about identity, devices and permissions. See also: Identity provider.

Sources on GitOps, access protection and AI

Read on