2. Control Plane Architecture

A platform is easier to understand when each system has a narrow job. GitLab should not own every infrastructure decision. Terraform should not become a place to hand-author every pipeline. Kubernetes should not decide delivery policy. A policy engine should evaluate rules, but it should not own the human approval process around them.

This separation is called control plane architecture. A control plane is the part of a system that decides what should happen. The data plane is the part that does the work. In this guide, the control planes decide how code moves from change to production.

The four main control planes

The reference platform uses four technical control planes:

Plane	Responsibility
GitLab	CI orchestration, repository enforcement, approval gates
HCP Terraform	Provisioning, workspace governance, plan review
Policy engine	Cross-system validation and compliance decisions
AWS EKS	Isolated execution substrate for GitLab runners

SRE practices sit across all four. They define whether the platform is available, observable, supportable, and reliable enough for teams to depend on.

Why beginners should care

When teams are new to DevOps platforms, it is tempting to connect tools wherever it is convenient. A CI job can call a cloud API. A Terraform module can create GitLab settings. A deployment script can update Kubernetes directly. Each choice may make sense locally, but too many shortcuts make the platform hard to reason about.

Clear control planes answer operational questions:

• If a merge request is blocked, is the issue in GitLab policy or CI configuration?
• If infrastructure cannot be applied, is the issue in Terraform state, credentials, or policy checks?
• If a pipeline is slow, is the issue GitLab scheduling or EKS runner capacity?
• If an artifact cannot be deployed, is the issue provenance, signing, or environment approval?

The architecture should make the first debugging step obvious.

Delivery flow

A normal delivery path looks like this:

1. A developer opens a merge request in GitLab.
2. GitLab applies branch, approval, and security policy requirements.
3. Reusable CI components run build, test, scan, package, sign, and deploy stages.
4. Jobs execute on EKS runner pods selected by trust tier.
5. Terraform changes go through HCP Terraform speculative plans and policy checks.
6. Evidence is emitted as SBOMs, signatures, provenance, logs, metrics, and SLO data.

That flow keeps enforcement close to the work. GitLab sees merge requests and pipelines, so it enforces delivery policy. HCP Terraform sees infrastructure plans, so it evaluates infrastructure governance. EKS runs jobs, so it owns workload isolation. Policy-as-code provides checks that can be tested and versioned.

Trust tiers

CI jobs are not all equally trusted. A feature branch running a new test script should not have the same access as a protected release job. The runner architecture separates workloads by trust:

Tier	Purpose	Secrets	Egress
sandbox	Experiments and untrusted jobs	None	Deny by default
standard	Normal feature branch CI	Minimal	Proxied
protected	Release branches and protected refs	Scoped	Restricted
privileged	Exceptional build cases	Scoped and approved	Restricted
deployment	Production deploy automation	Federated only	Explicit allow list

This is a practical response to CI risk. A pipeline is a programmable execution environment. It may run code from branches, dependencies, package manager hooks, generated scripts, and test fixtures. Treating all runners as equivalent makes the most sensitive pipeline only as isolated as the least trusted job.

Rollout rings

Do not turn every control on for every team overnight. A sudden enforcement change can stop product teams from shipping. A better approach is adoption rings:

1. Advisory controls collect evidence without blocking.
2. Critical findings and immutable artifact requirements become blocking.
3. Controls become mandatory for production-bound repositories.
4. Controls become default for all onboarded projects.

Rings let the platform team learn from real usage. They expose common failures, documentation gaps, and missing self-service paths before a control becomes mandatory everywhere.

Design pressure

The architecture is not optimized for novelty. It is optimized for clear ownership:

• GitLab owns delivery enforcement.
• HCP Terraform owns structural state and plan review.
• Policy-as-code owns testable decisions.
• EKS owns workload isolation.
• SRE practices own reliability expectations.

That split keeps the platform understandable as the organization grows. It also makes the rest of the guide easier to follow: each control belongs to one layer, even when several layers cooperate to enforce it.

Next comes GitLab, where developers see the platform most often.