Multi-Project Platform Thinking

Study CGOA on a Monday and CBA on a Tuesday and it's easy to walk away with nine separate subject folders — GitOps vocabulary in one, Backstage plugins in another — instead of what they actually are: nine certifications built around one internal platform, each proving fluency in a different subsystem of the same machine for shipping and safely running change. This page draws that machine as one system instead of nine electives. It follows a single code change from the moment a developer requests a new service in a portal, through the GitOps engine that turns Git into a cluster's desired state, past a policy engine that can reject the change outright, across a service mesh that governs every packet it ever sends, into an observability stack that watches the whole thing happen — and shows exactly which certification owns which leg of that journey. Read the nine blueprints for the vocabulary. Read this page for the wiring diagram nobody hands you until after you've already passed all nine.

Five subsystems, not nine electives

☺ Like you're 10: Nine badges sounds like nine different classes. It's really five departments doing five different jobs, plus the building they all work inside.

The certifications hub already sorts these nine into six families by what part of the platform they cover — that page's job is the map. This page's job is the traffic: showing those families actually operating together, in order, on one real change, instead of sitting next to each other in a table. Strip the nine down to what they're really building and you get five working subsystems, not nine: a developer portal that's the human front door (CBA), a GitOps engine that turns a Git commit into a cluster's desired state and builds what it needs to get there (CGOA, CAPA), a policy engine that can reject a bad change before it's ever persisted (KCA), a service mesh and data plane that governs every packet between services once they're running (ICA, CCA), and an observability stack that watches the whole thing happen, continuously (OTCA, PCA). Underneath all five sits LFCS's Linux — not a sixth peer competing for a slot in the list, but the substrate every one of the other five is quietly a Linux process running on, the same way the certifications hub draws it as a foundation band rather than a sixth family box.

This is the same instinct the platform-engineering discipline itself is built on — see Platform Engineering's treatment of a platform as one product, not a pile of adopted tools — applied here to one specific, concrete stack of nine CNCF projects instead of the abstract case for platform teams in general.

Walking one change through five subsystems

☺ Like you're 10: Follow one single delivery — one new service, requested once — all the way from a form to a running, watched, protected pod, and count how many different guards it passes on the way.

A developer opens the portal and fills out a "New Service" form — name, owning team, parent system. Backstage's scaffolder renders a skeleton with those answers already substituted into catalog-info.yaml, and opens a pull request into the repository the GitOps engine watches — the portal's whole job here is finished the instant that PR exists; everything from here on is a different subsystem's turn. A human reviews and merges it. That merge is the moment the change becomes desired state: the repository, not any person's memory, now says what should be running. Before the manifests reach a cluster, Argo Workflows builds, tests and packages the actual container image — the build-time half of the GitOps engine, and a genuinely separate job from what happens next. Argo CD's reconciler — the declare-time half — notices the new Application, diffs it against the live cluster, and starts applying it.

Every object Argo CD tries to write passes through Kyverno's two admission windows before it ever reaches etcd — mutate first, validate second — and a rule with failureAction: Enforce can reject the whole object outright, no rollback needed because nothing was ever persisted. Only past that gate does a Pod actually get scheduled. The moment it starts, it joins the service mesh's data plane — Istio and Cilium issue it a cryptographic identity, encrypt its traffic, and enforce whatever AuthorizationPolicy or CiliumNetworkPolicy applies, on every single packet it ever sends or receives, for as long as it's alive. And from its very first request, OpenTelemetry emits spans and Prometheus scrapes metrics — the one subsystem in this chain that never finishes, because it's still running the moment every other station has already done its one job and moved on.

Notice the GitOps engine alone claims three of the seven stations, not because it's secretly three subsystems but because CAPA's own published domain weights already draw this exact seam: Argo Workflows is 36% of that exam and is almost entirely build-time competencies — steps, DAGs, artifacts — while Argo CD is 34% and is almost entirely declare-time competencies — Applications, sync policies, health. Git itself sits between them as the specification neither controller owns; it's the state store both read from and write to, not a service either one runs.

One manifest can carry instructions for four of the five subsystems at once, which is the most concrete way to see the platform as one thing rather than five:

# One Deployment template, four subsystems' worth of instructions —
# nothing below is Argo-specific config; each line is read by a
# DIFFERENT one of the certifications on this shelf.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
  namespace: prod
  labels:
    app.kubernetes.io/part-of: commerce        # Backstage's catalog (CBA) ties this
                                                  # workload back to a System entity
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: checkout
        istio.io/dataplane-mode: ambient         # Istio (ICA) — joins the mesh, no sidecar needed
      annotations:
        instrumentation.opentelemetry.io/inject-python: "true"  # OTel Operator (OTCA)
        prometheus.io/scrape: "true"                             # Prometheus (PCA)
        prometheus.io/port: "9464"
    spec:
      containers:
        - name: checkout
          image: registry.internal/checkout:sha-8f21a9c   # built by Argo Workflows
                                                              # (CAPA) before this file
                                                              # was ever committed
          resources:
            requests: { cpu: 100m, memory: 128Mi }   # Kyverno (KCA) rejects this object
            limits:   { cpu: "1",  memory: 512Mi }    # at admission if these two lines
                                                          # are missing — see below

Five control points on one timeline, not five overlapping tools

☺ Like you're 10: It looks like five different guards checking the same delivery truck five times. It's actually five different checkpoints on five different stretches of road — nobody re-checks what the last guard already cleared.

The reason none of this is redundant is that each subsystem gets exactly one moment in a change's life when it's even capable of acting, and those moments never overlap. Call it a control point: the specific instant a subsystem can still change the outcome, after which it's someone else's turn entirely. The portal isn't really a control point in this sense at all — it's the origin, the moment a human states intent, before any of the five enforcement-shaped subsystems get a say. From there, five real control points run in a fixed order, and skipping any one of them doesn't make the platform simpler — it just means nothing catches that particular class of problem, ever.

Same shape, different layer: the design DNA these nine share

☺ Like you're 10: Nine different toolboxes turn out to share several of the exact same tools inside them — the same kind of loop, the same kind of form, the same kind of gate — just used for nine different jobs.

The nine tools aren't just adjacent in the request lifecycle — several of them are built out of the same small set of structural ideas, reused at a different layer each time. The closed-loop reconciler is the clearest case: Argo CD's control loop drives the whole Declare station, but it isn't the only reconciler on this shelf. Kyverno runs a separate background scan controller that periodically re-checks objects that already existed before a policy was installed, producing a PolicyReport the same way Argo CD produces a sync status — a second reconcile loop, at a different layer, closing a different gap. Cilium's per-node agent runs a third: continuously syncing its eBPF maps to whatever identity and network-policy state the Kubernetes API currently declares, the exact sensor-comparator-actuator shape from GitOps Philosophy, just enforcing packets instead of manifests.

The mutating admission webhook shows up twice for two genuinely unrelated jobs. Kyverno registers one to enforce policy — reject or rewrite an object before it's persisted. Istio's sidecar injector registers one for a completely different reason — add a proxy container to a pod at creation time. Same Kubernetes primitive, same admission-control phase, two certifications' worth of unrelated functionality riding the identical mechanism. And eBPF is the deepest shared substrate on this shelf: it's the whole story behind CCA's datapath, and it's also what Hubble uses to generate the network-flow visibility that feeds straight back into the observability station — one kernel primitive, funding two different families' worth of exam content.

Where cross-layer blindness actually bites

☺ Like you're 10: Three different guards can each honestly say "everything I checked looked fine" — and the truck can still be carrying something broken, because none of the three checked the same thing.

The failure mode nine separate blueprints never show you is the one where every subsystem is individually correct and the outcome is still broken. A Kyverno rule requiring resource limits sits in failureAction: Audit — someone flipped it during a demo months ago and never flipped it back. A Deployment with no limits block merges. Argo CD applies it, and its own dashboard reports Synced, Healthy — genuinely, correctly, from Argo CD's own vantage point, because the live cluster matches Git exactly. The pod schedules fine, joins the mesh fine, serves traffic fine, for a while. Then it gets OOMKilled under real load, restarts, gets OOMKilled again — and the only subsystem positioned to notice is the one watching continuously, after every other station has already finished its one job and moved on.

This is the concrete version of the abstract control-point table above: Admit and Observe are different stations on purpose, and a policy sitting in Audit mode doesn't merely weaken the Admit station — it silently turns the whole burden of catching that class of problem over to Observe, hours or days later, after the object is already running in production. Nothing about that failure required a single tool to be broken. It only required treating five subsystems' worth of "looks fine to me" as equivalent to one platform-wide "this is fine."

Draw your own map

☺ Like you're 10: The nine-badge shelf is a general map. The one worth actually memorizing is the smaller one for the stack you personally touch.

Where the five-subsystem picture doesn't hold

☺ Like you're 10: Not every mission needs every console staffed. A short hop doesn't need the same crew as a trip to orbit.

Be honest about what this page is and isn't. It's a reference architecture — the shape a platform takes if it eventually needs everything all nine certifications teach — not a checklist every team is behind schedule for not implementing. Service Mesh Architecture's own closing section already makes the case in full for the Run station specifically: a small enough service count, watched closely enough by a small enough team, can genuinely not need a mesh at all, and adopting one anyway adds a whole distributed system's worth of failure modes for capabilities a simpler setup already covered. The same honesty applies to Origin — plenty of platforms run perfectly well on a README and a Slack channel instead of a Backstage instance, right up until the service count outgrows what any one person can hold in their head.

Passing all nine certifications on this shelf proves you understand every station on this page's diagrams. It does not prove your organization runs all five subsystems, and it's worth resisting the pull to treat "we should adopt everything I got badged in" as this page's takeaway. The actual skill this page is arguing for is smaller and more durable than that: given any platform — the one you already run, or one you're evaluating for a new job — being able to say, station by station, which of these five jobs is being done, which subsystem is doing it, and which stations are quietly missing. That question travels to a stack that's never heard of any of these nine tools by name. The tools change. The five jobs — origin, build, declare, admit, run, observe — mostly don't.