CBA — Certified Backstage Associate

The Certified Backstage Associate (CBA) is the CNCF and Linux Foundation’s credential for the software that fronts most internal developer platforms. Backstage is the developer portal your engineers actually see — the catalog of who owns what, the golden-path buttons, the docs that finally get read — and the CBA certifies that you can run it, configure it, fill its catalog and, above all, change its code. That last part is the surprise: this is the most developer-shaped certification on the cloud-native shelf, and a third of it is React. Here: what it is, whether it earns its place in your year, the four official domains and weights from the CNCF curriculum, and a study plan built from pages already on this site.

What the CBA is — and who it is for

☺ Like you’re 10: It’s a badge for one particular piece of software — the front desk — and it asks you to actually build and change it, not just describe it.

The CBA is a single-project certification. Where CGOA examines a specification and KCNA examines an ecosystem, the CBA examines one application you fork and own. Backstage is not a product you install and configure from a web UI; it is a TypeScript monorepo you clone, wire together, build, containerise and deploy yourself. The curriculum reflects that with unusual honesty — it asks you to install dependencies with NPM or Yarn, compile with TypeScript, build a Docker image, and edit React. Nothing in it mentions Kubernetes, manifests, clusters or kubectl: these are a web developer’s skills, applied to the piece of platform software your developers touch every day.

Who should sit it

• Platform engineers who own (or are about to own) a portal — the people whose Slack channel receives “can we add a tab for X?”
• Developer-experience and IDP teams building golden paths, where the template button is the product. See Developer experience.
• Full-stack and frontend engineers moving into platform work — the rare cloud-native certification where React and TypeScript are an advantage, not a gap.
• Consultants and integrators repeatedly asked to stand a portal up and hand it over — and managers evaluating “should we adopt Backstage?”, because the curriculum shows the size of the ongoing commitment.

Why a platform engineer would take it — and when to skip it

☺ Like you’re 10: Take it if you look after the front desk. Skip it if someone else does, or if your workshop is too small to need one yet.

Be honest about the return. This is a narrow, tool-specific badge, and nobody is hired on it alone. Its value is concentrated and real for one group: those who will spend the next year with a portal repository open.

The case for taking it

Backstage is the developer control plane of the CNCF platform reference architecture — the layer through which everything else becomes visible. Studying for the CBA forces you through the parts people usually skip and later regret: how ingestion actually works, why entities go stale, what a backend plugin is versus a frontend one, and how to deploy the thing properly rather than leaving SQLite in production. It converts a portal you inherited into a portal you understand. There is a softer benefit too: most platform engineers arrive from operations and are quietly uncomfortable in a TypeScript monorepo. The CBA gives that discomfort a syllabus, after which “add a tab to the service page” stops being a ticket you route to someone else.

How it relates to the CNPE and CNPA

The relationship is real but narrower than CGOA’s. Backstage appears in the CNPE under Platform APIs & Self-Service — the portal is the storefront in front of the self-service machinery — and in CNPA under its IDP and developer-experience material (see CNPA · IDP & DevEx). But the CBA goes far deeper into one product than either exam requires, and most of its weight sits on skills — TypeScript, React, Yarn, Docker — that neither tests at all. Study it because you will use it, not because it shortens another syllabus.

When to skip it

Skip it if you do not own a portal and are not about to. Skip it if your organisation runs a commercial portal or a distribution where you never touch the monorepo — most of the development-workflow and customization weight is then irrelevant. Skip it if you are pre-portal: thirty engineers usually need a good README and a service registry more than a Node application to keep alive, and the Backstage page here is blunt about that. And skip it if you are chasing your first credential for a job filter — CKA, CKAD or the CNPE open more doors. The certifications overview shows where everything sits.

The four official domains & their weights

☺ Like you’re 10: The test has four parts. The biggest part — nearly a third — is changing the front desk’s own code.

These come straight from the CNCF’s published Certified Backstage Associate (CBA) Exam Curriculum — the domain names, the percentages and the competency lists below are that document, not a paraphrase. Four domains, and they account for the whole paper: 32 + 24 + 22 + 22 = 100%. The bars are drawn to scale:

Every competency, domain by domain

The full curriculum — four domains, nineteen competencies, exactly as the CNCF publishes them:

Reading the shape of this blueprint

Three things jump out, and each should change how you study.

First: 56% of this exam is software development. Customizing (32%) plus Development Workflow (24%) is a clear majority, and between them they name TypeScript, NPM/Yarn, Docker, React and Material UI. If your instinct is to prepare by reading about catalogs and golden paths, you are preparing for the smaller half of the paper.

Second: the catalog is only 22% — the same as infrastructure, less than customization — which surprises people, because the catalog is what everyone talks about. Note how operational its competencies are: two of the six are “troubleshooting entity ingestion” and “working with manually registered entity locations.” This is the domain of somebody who has debugged a missing service, not somebody who has read the docs.

Third: nothing here is Kubernetes. “Deploy Backstage to production” is a competency, and in most shops that deployment lands on a cluster — but the exam’s stated subject is the Backstage project itself. Do not assume your Kubernetes fluency will carry you.

What you actually need to know

☺ Like you’re 10: Four skills: run it on your laptop, know how its two halves talk, keep the big index full and correct, and change its screens.

The development workflow — 24%

This domain is muscle memory for a Node monorepo. npx @backstage/create-app@latest produces a Yarn workspace containing packages/app (the React frontend) and packages/backend (the Node backend), plus app-config.yaml at the root. yarn install resolves dependencies; yarn dev runs both halves with hot reload — frontend on :3000, backend on :7007. Because the whole thing is TypeScript, yarn tsc is a real gate: a type error stops the build.

# Create a new portal — this is a monorepo you now OWN, not an install
npx @backstage/create-app@latest --path acme-portal

# Install dependencies (Yarn workspaces) and run both halves with hot reload
yarn install
yarn dev                       # app on :3000, backend on :7007

# Run one half at a time — the client/server split made visible
yarn workspace app start
yarn workspace backend start

# Add a plugin: the frontend package AND its backend counterpart
yarn workspace app add @backstage/plugin-kubernetes
yarn workspace backend add @backstage/plugin-kubernetes-backend

# Type-check, lint and test the whole workspace
yarn tsc && yarn lint:all && yarn test:all

# Production build, then a container image from the BACKEND Dockerfile
yarn build:all
yarn build:backend --config ../../app-config.yaml
docker image build . -f packages/backend/Dockerfile --tag acme/backstage:2025.06.1

# Keep every @backstage/* package on one release line
npx @backstage/cli versions:bump

Two details there earn marks. The image is built from packages/backend/Dockerfile, because in a production build the compiled frontend is served by the backend — one image, not two. And versions:bump is the upgrade story: Backstage releases frequently, packages must move together, and a portal left alone for a year is genuinely painful to bring forward.

Infrastructure, framework and the client-server split — 22%

“Understand Backstage client-server architecture” means saying what runs where. The frontend is a React single-page app; it holds no secrets and talks to the backend over HTTP. The backend is a Node service that owns the database, the credentials for GitHub and your clusters, and every plugin that reaches a third-party system. Between them sits the catalog, backed by a database — PostgreSQL in production; SQLite is development-only and loses your data on restart. Configuration is one layered app-config.yaml, with app-config.local.yaml and app-config.production.yaml stacked on top and ${ENV_VAR} substitution throughout.

app:
  baseUrl: https://backstage.acme.internal      # where the FRONTEND is served
backend:
  baseUrl: https://backstage.acme.internal      # where the API answers
  listen: { port: 7007 }
  database:
    client: pg                                  # SQLite is DEV ONLY
    connection:
      host: ${POSTGRES_HOST}
      user: ${POSTGRES_USER}
      password: ${POSTGRES_PASSWORD}

integrations:
  github:
    - host: github.com
      apps:
        - $include: github-app-credentials.yaml # a GitHub App, not a personal token

catalog:
  rules:
    # allow-list of kinds this catalog will ingest — omit Template and your
    # golden-path templates silently refuse to appear
    - allow: [Component, API, Resource, System, Domain, Group, User, Location, Template]
  locations:                                    # STATIC registration, declared in config
    - type: url
      target: https://github.com/acme/platform-config/blob/main/catalog/org.yaml
  providers:                                    # AUTOMATED ingestion
    github:
      acmeOrg:
        organization: acme
        catalogPath: /catalog-info.yaml
        filters: { branch: main, repository: '.*' }
        schedule:
          frequency: { minutes: 30 }
          timeout:   { minutes: 3 }

☺ Like you’re 10: This one file says where the desk lives, which filing cabinet it uses, which company it belongs to, and how often to go looking for new things to add to the index.

“Deploy Backstage to production” is where the framing bites: a real database, real identity (an auth provider plus a resolver mapping a signed-in person to a User entity), secrets injected rather than committed — see External Secrets and secrets management — and a pipeline that produces that backend image. The portal is a production service with an on-call owner, not a side project.

The catalog — 22%

The catalog is a graph of entities, each a YAML document with a Kubernetes-shaped envelope (apiVersion, kind, metadata, spec) under backstage.io/v1alpha1. The kinds you must know are Component, API, Resource, System, Domain, Group, User, Location and Template. The file is conventionally catalog-info.yaml in the root of the repo it describes — that is the whole trick, because the description ships with the code and therefore stays true.

Annotations are their own named competency: free-form key/value pairs under metadata.annotations that plugins look for. backstage.io/techdocs-ref lights up the Docs tab, backstage.io/kubernetes-id wires the Kubernetes plugin to real workloads, argocd/app-name surfaces sync status from Argo CD. Two are set for you and matter when debugging: backstage.io/managed-by-location (which file produced this entity) and backstage.io/orphan (its parent location is gone).

# catalog-info.yaml — at the ROOT of the checkout service repo
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: checkout
  description: Takes a cart and turns it into an order.
  annotations:
    backstage.io/techdocs-ref: dir:.          # Docs tab
    backstage.io/kubernetes-id: checkout      # Kubernetes tab
    argocd/app-name: checkout-prod            # Argo CD tab
spec:
  type: service
  lifecycle: production
  owner: group:default/payments-team          # derives ownedBy / ownerOf
  system: commerce                            # derives partOf / hasPart
  providesApis: [checkout-api]
  dependsOn:
    - resource:default/checkout-db

The curriculum names the two ends of the range explicitly — working with manually registered entity locations and working with automated ingestion — and in practice there are three routes you must tell apart. Manually registered entity locations — a human pastes a URL into “Register existing component,” creating a Location. Static locations — URLs listed under catalog.locations, good for org data and templates. Automated ingestion — entity providers that crawl a whole GitHub or GitLab organisation on a schedule and, crucially, remove entities when the file disappears. Only providers scale.

Troubleshooting entity ingestion separates readers from operators. Three failure modes recur: a malformed or unreachable catalog-info.yaml shows a processing error on the entity page and the entity silently stops refreshing; an orphan lingers when its parent location was removed; and a dangling owner reference points at a Group that was never ingested, so ownership links go nowhere — ingest org data first. Everything is a plain REST API, which is how you debug it:

# What does the catalog actually think exists?
curl -s -H "Authorization: Bearer $TOKEN" \
  "$BASE/api/catalog/entities/by-query?filter=kind=component,spec.lifecycle=production" \
  | jq -r '.items[] | "\(.metadata.name)\t\(.spec.owner)"'

# Inspect one entity — check managed-by-location and any orphan annotation
curl -s -H "Authorization: Bearer $TOKEN" \
  "$BASE/api/catalog/entities/by-name/component/default/checkout" | jq '.metadata.annotations'

# Manual registration — exactly what the "Register existing component" button does
curl -s -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"type":"url","target":"https://github.com/acme/checkout/blob/main/catalog-info.yaml"}' \
  "$BASE/api/catalog/locations"

# Ghost service? Delete the LOCATION that created it, not the entity
curl -s -H "Authorization: Bearer $TOKEN" "$BASE/api/catalog/locations" | jq .
curl -s -X DELETE -H "Authorization: Bearer $TOKEN" "$BASE/api/catalog/locations/<id>"

Customizing Backstage — 32%

The largest domain, and the one that catches operations people out. Start with the distinction the curriculum names first: frontend versus backend plugins. A frontend plugin is React — pages, cards, tabs — installed into packages/app and rendered in the browser. A backend plugin is Node: it holds credentials, talks to external systems and exposes HTTP routes, and is installed into packages/backend. Many plugins ship as a pair, and “I installed the plugin but the tab is empty” is almost always “you installed one half.”

“Make changes to React code in Backstage App” means editing the two files every portal owner learns by heart: App.tsx declares routes and top-level structure, and EntityPage.tsx decides which tabs and cards appear for each kind and type of entity. “Using Material UI components” means the layout primitives — Grid, Card, Typography, Button — because Backstage’s own component library is built on Material UI, and a custom card that ignores the grid looks broken next to everything else.

// packages/app/src/components/catalog/EntityPage.tsx
import { Grid } from '@material-ui/core';
import { EntityLayout, EntityAboutCard, EntityLinksCard } from '@backstage/plugin-catalog';
import { EntityKubernetesContent } from '@backstage/plugin-kubernetes';

const serviceEntityPage = (
  <EntityLayout>
    <EntityLayout.Route path="/" title="Overview">
      <Grid container spacing={3} alignItems="stretch">
        <Grid item md={6}><EntityAboutCard variant="gridItem" /></Grid>
        <Grid item md={6}><EntityLinksCard /></Grid>
      </Grid>
    </EntityLayout.Route>

    {/* a new tab — this is "customizing" in one edit */}
    <EntityLayout.Route path="/kubernetes" title="Kubernetes">
      <EntityKubernetesContent refreshIntervalMs={30000} />
    </EntityLayout.Route>
  </EntityLayout>
);

The backend half is wired separately. Recent Backstage versions use the new backend system, where each plugin is added to a backend instance rather than assembled by hand — know the shape, because it is what a current create-app produces:

// packages/backend/src/index.ts
import { createBackend } from '@backstage/backend-defaults';

const backend = createBackend();

backend.add(import('@backstage/plugin-catalog-backend'));
backend.add(import('@backstage/plugin-catalog-backend-module-github'));  // automated ingestion
backend.add(import('@backstage/plugin-techdocs-backend'));
backend.add(import('@backstage/plugin-kubernetes-backend'));             // the other half of the tab
backend.add(import('@backstage/plugin-scaffolder-backend'));             // golden-path templates

backend.start();

How to prepare using this site

☺ Like you’re 10: Read the pages that match each part of the test — but for this one, most of your time should be spent actually running the thing.

This site was written for the CNPE, so its Backstage coverage is deep on catalog, templates and configuration, and lighter on React. Use the pages for the concepts and a real portal on your laptop for the 56% that is development.

Domain-by-domain study map

A two-week pace

Two focused weeks is realistic if you are comfortable in a JavaScript toolchain; make it three if yarn and tsc are new. The proportions below mirror the weights.

Exam logistics — and how to verify them

☺ Like you’re 10: Some facts about the test are stable; the prices and timings change all the time. Always check the official page before you pay.

Some facts about the CBA are structural and safe to state; others are exactly the sort the Linux Foundation revises without announcement. This page separates the two deliberately, and names its sources for each.

What the official pages state

Everything in this table is either taken from the CNCF’s published CBA curriculum (the domain and blueprint rows) or read from the Linux Foundation CBA exam page and the CNCF certification listing, checked in 2026. Anything not sourced to one of those is flagged as unpublished below.

What is not published — and what you must check yourself

One figure that third-party sites quote with great confidence is not stated on either official CBA page: the number of questions. Other associate exams’ counts are not evidence for this one, so treat any specific “60 questions” claim — from anywhere — as folklore until the Linux Foundation says it. The pass mark is not folklore, however: it is simply published somewhere else. The Linux Foundation’s Multiple Choice Exam FAQ states that “a score of 75% or above must be earned to pass the Multiple Choice Exam”, and the CBA is an online, proctored, multiple-choice exam — so 75% is the bar here too. Everything else in the table above is published, but published figures still move: price and promotional bundles, duration, retake terms, the eligibility window, certification validity, proctoring and system requirements, and even the domain weights are all revised over time.

↗ Official CBA page — Linux Foundation ◆ CNCF certification catalogue ◆ Official CNCF curriculum repository ◆ Backstage documentation — the real study material

Where it sits in the ladder — and what to do next

☺ Like you’re 10: This is a specialist badge for one tool. From here you either go wider across platform engineering, or deeper into making the front desk genuinely useful.

The CBA sits on the associate rung but is unlike its neighbours: KCNA and CGOA are broad-concept exams, while CBA is a single-product skills exam. It gates nothing and nothing gates it. The certifications overview lays out the whole shelf and the routes through it.

Go wider — platform engineering proper

A portal with nothing behind it is a menu in an empty restaurant. The natural sequel is the platform itself: CNPA for the concepts and the CNPE for the hands, where the portal is one plane among five. Start with Platform as a product — the discipline that decides which buttons deserve to exist — and Team Topologies for who owns the thing once it is live.

Go deeper — make the buttons do something

The most valuable next step is wiring the storefront to real machinery: point a Software Template at a Crossplane claim so “new service” provisions a database as well as a repo, make the Argo CD tab real by putting the app under Argo CD, and hang observability links off every entity so the catalog page is the first place anyone looks in an incident. That path is laid out in Self-service & golden paths; the failure modes — chiefly a portal nobody keeps current — are in anti-patterns, and field notes has the practitioner view of what that costs.