CBA Practice Questions

Twenty-four single-best-answer questions, built the way the real CBA builds them: one stem, four options, exactly one option that answers this stem better than the other three. They're split across all four domains from the CBA blueprint in proportion to their weight — eight on Customizing Backstage, six on the Development Workflow, five each on Infrastructure and the Catalog — so a strong or weak score in one section tells you something real about where your marks would actually land. This page is untimed and open-book on purpose: work through it slowly, read every explanation even for questions you got right, and only once these twenty-four stop surprising you should you move on to the two full, weighted, timed papers — Mock Exam · Set 1 and Mock Exam · Set 2.

How this bank is built

☺ Like you're 10: The biggest pile of questions covers the biggest part of the real test. Study in that order and you're spending your time where the marks actually are.

The CBA curriculum weights its four domains 32 / 24 / 22 / 22, and this bank mirrors that shape rather than splitting twenty-four questions evenly into four piles of six. Customizing Backstage gets the largest single share, because it's nearly a third of the real paper and, unlike everything else on the cloud-native shelf, it's mostly React. Infrastructure and the Catalog — the two domains that feel the most like "regular platform work" — still get five full questions each, because together they're 44% of the exam.

Customizing Backstage — 8 questions

☺ Like you're 10: This is the front desk's own construction kit — which drawer holds the screwdrivers, and which drawer you're never, ever supposed to leave unlocked.

Thirty-two percent of the real exam — the single largest domain — is Customizing Backstage: frontend versus backend plugins, editing React in App.tsx and EntityPage.tsx, Material UI, and the scaffolder's credentials. It's the domain that catches operations people off guard, because it's mostly software development, not configuration.

Q1. A team runs yarn workspace app add @backstage/plugin-kubernetes and nothing else. Afterwards, a "Kubernetes" tab appears on the entity page, but it stays permanently empty — no data, no error message beyond a failed network call in the browser console. What's the most likely cause?

• A. The matching backend half, @backstage/plugin-kubernetes-backend, was never added to packages/backend — so there's no server-side route holding cluster credentials to actually answer the request.
• B. The tab needs a Material UI Grid wrapper, or it silently refuses to fetch data.
• C. The plugin needs to be listed under catalog.locations in app-config.yaml.
• D. EntityPage.tsx doesn't support Kubernetes-shaped entities by design.

Q2. Which statement correctly distinguishes a frontend plugin from a backend plugin?

• A. A frontend plugin may safely embed a GitHub App private key, because bundled JavaScript never actually leaves the user's browser in practice.
• B. A backend plugin runs in Node, installed into packages/backend, and may hold real credentials — database connections, API tokens, service-account keys; a frontend plugin runs in the browser and must never hold any of those, because anything shipped to the browser is public.
• C. Frontend and backend plugins live in the same package and can never be installed independently of one another.
• D. Only a backend plugin can render a tab or a card on the entity page.

Q3. A platform engineer needs to (a) add an entirely new top-level route reachable from the app's own sidebar, and (b) add a tab that appears only on Component entities of type website. Which two files does "Make changes to React code in Backstage App" point to for these two changes, respectively?

• A. App.tsx for (a); EntityPage.tsx for (b) — App.tsx declares routes and top-level structure, while EntityPage.tsx decides which tabs and cards render per entity kind and type.
• B. EntityPage.tsx for both — it controls every route in the app, not only per-entity tabs.
• C. app-config.yaml for both, since routing is configuration rather than code.
• D. App.tsx for both, since EntityPage.tsx only affects the sidebar, never entity tabs.

Q4. A team builds a custom card for the entity Overview page. It hardcodes its own raw CSS grid instead of Material UI's Grid, ignoring the layout every stock card on the page already uses. What's the most likely consequence, and which named competency does it bear on?

• A. None — CSS Grid is strictly superior to Material UI's Grid, so there's no real consequence either way.
• B. The card will visually misalign with the surrounding gridItem-based layout, because Backstage's own component library and every stock card are built on Material UI's Grid/Card/Typography primitives — this is exactly what "Using Material UI components" tests as its own line item.
• C. The build will fail to compile, since custom CSS is disallowed anywhere in a Backstage app.
• D. The card will only render correctly when the browser is in dark mode.

Q5. A Software Template creates new repositories, grants team access, and opens pull requests on behalf of whoever clicks the golden-path button. Which credential pattern does the curriculum favor for the scaffolder backend that performs these actions, and why?

• A. A personal access token belonging to one specific employee, manually rotated on a schedule.
• B. A scoped GitHub App credential, rather than a personal access token — because a personal token ties repository-creating, org-spanning access to one person's identity and offboarding, and can't be scoped as tightly as an App installation can.
• C. No credential at all — the scaffolder only ever writes local files and never touches a remote Git host.
• D. The end user's own browser session token, forwarded transparently through to GitHub.

Q6. A freshly generated app wires its backend with createBackend() and a series of backend.add(import(...)) calls inside packages/backend/src/index.ts, ending in backend.start(). What does this pattern reflect?

• A. The legacy backend system, now deprecated in favor of manually instantiated Express routers.
• B. The "new backend system" — each plugin is added to one shared backend instance rather than hand-assembled — which is what a current create-app produces by default.
• C. A frontend-only pattern; this file is never actually executed at runtime.
• D. A Kubernetes Operator's own reconciliation loop, running inside the Backstage process.

// packages/backend/src/index.ts — the new backend system, plugin by plugin
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-kubernetes-backend'));             // the OTHER half of the tab
backend.add(import('@backstage/plugin-scaffolder-backend'));             // golden-path templates

backend.start();

Q7. Which file holds the logic that decides which tabs and cards appear on a Component of type service versus one of type website?

• A. app-config.yaml
• B. EntityPage.tsx — it's exactly where per-kind, per-type tab and card logic lives.
• C. catalog-info.yaml, set individually per repository.
• D. packages/backend/src/index.ts

Q8. A team disables one default card on a third-party frontend plugin's page and swaps in their own card in the same slot, leaving the rest of that plugin's page untouched. Which single competency line item does this most precisely exercise?

• A. Development Workflow — building and running Backstage projects locally.
• B. Customizing Backstage plugins — the specific line item for changing a plugin's default behavior or layout without necessarily rewriting the plugin's own source.
• C. Backstage Catalog — populating the catalog.
• D. Backstage Infrastructure — configuring Backstage.

Development Workflow — 6 questions

☺ Like you're 10: This is muscle memory for running the workshop on your own laptop — install the tools, start the machine, and know exactly which half of it you're shipping in the box.

Twenty-four percent is a Node monorepo's day-to-day: create-app, Yarn workspaces, a real TypeScript gate, and a container image built from one specific Dockerfile. The reference sequence below is worth running yourself before attempting the six questions that follow.

# Create a 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

# 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 the whole workspace — a real error stops this
yarn tsc

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

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

Q9. Running npx @backstage/create-app@latest produces a Yarn workspace. Which pairing correctly matches each package to what it actually contains?

• A. packages/app is the Node backend service; packages/backend is the React frontend.
• B. packages/app is the React frontend; packages/backend is the Node backend — with app-config.yaml sitting at the workspace root, shared by both.
• C. The two packages are identical, mirrored copies used for blue/green deployments.
• D. packages/app only exists after running yarn build:all for the first time.

Q10. After yarn install && yarn dev on a freshly created app, on which two ports do the frontend and backend serve by default, respectively?

• A. Frontend :3000, backend :7007.
• B. Frontend :8080, backend :3000.
• C. Frontend :7007, backend :3000.
• D. Both on :3000; Backstage proxies backend calls invisibly through the same port.

Q11. A CI pipeline for a Backstage monorepo runs yarn tsc as a required step before yarn build:all. What does this step actually gate, and why does the curriculum treat it as a real gate rather than a formality?

• A. It only checks formatting and whitespace, and rarely fails a genuine build.
• B. Because the entire codebase is TypeScript, yarn tsc performs a real type-check across the workspace; a genuine type error stops it cold, so it functions as a hard build gate, not a lint suggestion.
• C. It silently runs the full Jest test suite under the hood.
• D. It's optional, and is skipped automatically once a build is destined for production.

Q12. A team runs yarn build:all, then docker image build . -f packages/backend/Dockerfile --tag acme/backstage:1.0. Why is the image built specifically from the backend's Dockerfile, rather than from packages/app?

• A. Because in a production build the compiled frontend is served by the backend — one image serves both halves, so only the backend needs its own Dockerfile.
• B. Because packages/app is never actually deployed anywhere in production.
• C. Because Docker is structurally unable to build a multi-package Yarn workspace from the frontend's own directory.
• D. Because the frontend specifically requires a Kubernetes StatefulSet rather than a plain container image.

Q13. A team wants both halves of Kubernetes-plugin functionality — the tab, and the data behind it. Which pair of commands correctly installs both?

• A. yarn workspace app add @backstage/plugin-kubernetes and yarn workspace backend add @backstage/plugin-kubernetes-backend
• B. yarn global add @backstage/plugin-kubernetes, run once from anywhere on the machine.
• C. yarn workspace backend add @backstage/plugin-kubernetes-backend, run twice.
• D. npm install -g @backstage/plugin-kubernetes-backend

Q14. What problem does npx @backstage/cli versions:bump most directly solve, and why does it matter operationally?

• A. It reformats source code according to Prettier's rules.
• B. It keeps every @backstage/* package in the workspace on one consistent release line — which matters because Backstage releases frequently and its packages generally need to move together, and a portal left unupgraded for a long stretch becomes genuinely painful to bring forward.
• C. It rotates database credentials on a fixed schedule.
• D. It converts a Yarn workspace into an npm workspace in place.

Infrastructure — 5 questions

☺ Like you're 10: This is the wiring behind the front desk — which half talks to strangers, which half holds the safe combination, and what happens to the whole index if you unplug the wrong cable.

Twenty-two percent covers the client-server split, configuration layering, and what "production-ready" actually requires — a real database, real identity, and secrets that never sit in plaintext.

Q15. Which statement correctly describes Backstage's client-server architecture?

• A. The frontend is a React single-page app holding no secrets, talking to the backend over HTTP; the backend is a Node service that owns the database and any credentials.
• B. The frontend connects directly to PostgreSQL; the backend only serves static assets.
• C. There's no meaningful split — frontend and backend share one process and one set of credentials.
• D. The backend runs entirely inside the browser via WebAssembly.

Q16. A team ships a production Backstage instance on the default SQLite database "because it worked fine under yarn dev." What's the concrete operational risk, and what replaces it?

• A. None — SQLite scales identically to PostgreSQL once traffic is moderate.
• B. SQLite is development-only: it doesn't survive a restart, so the entire catalog is lost the moment the pod recycles. Production uses PostgreSQL, configured under backend.database.
• C. SQLite requires a separate paid license once used outside local development.
• D. SQLite only supports read-only catalogs; it can never accept writes.

Q17. A team maintains app-config.yaml, app-config.local.yaml, and app-config.production.yaml, with secrets referenced as ${POSTGRES_PASSWORD}. What does this pattern demonstrate about Backstage configuration?

• A. Configuration is one flat file; the three files are simply concatenated alphabetically with no override behavior between them.
• B. Configuration is one layered system — environment-specific files stack on top of the base file, and ${ENV_VAR} substitution keeps literal secret values out of anything committed to Git.
• C. app-config.local.yaml is only ever read inside the compiled browser bundle, never by the backend process.
• D. Only app-config.yaml is actually read at runtime; the other two files exist purely as documentation.

# app-config.yaml — catalog.rules is an ALLOW-list, not a suggestion
catalog:
  rules:
    - allow: [Component, API, Resource]   # Template is missing — see Q18

Q18. Given the app-config.yaml snippet above, golden-path Software Templates have stopped appearing anywhere in the catalog UI, even though the template files themselves are still correctly registered. What's the most likely cause?

• A. The scaffolder backend plugin was never installed in the first place.
• B. Kind Template was omitted from the catalog.rules allow-list, so the catalog silently refuses to ingest Template entities even though the template files themselves are otherwise perfectly valid.
• C. Templates require a separately purchased license key that wasn't configured.
• D. Templates can only ever be added through a direct REST call, never through catalog.rules.

Q19. Beyond simply pointing at a production-grade database, what does "Deploy Backstage to production" concretely require?

• A. Nothing further — a real database alone fully satisfies the competency.
• B. Real identity — an auth provider plus a resolver that maps a signed-in person to a User entity — and secrets injected at runtime rather than committed into config.
• C. Disabling authentication entirely, since Backstage is meant to be publicly readable by default.
• D. A Kubernetes Ingress object, which the curriculum names as a strict requirement.

Catalog — 5 questions

☺ Like you're 10: This is the front desk's big index — every entry has a proper form, and the test wants to know exactly what happens when a page in that index goes missing or points at nothing.

Twenty-two percent, and the domain everyone talks about most while it's actually tied with Infrastructure, not ahead of it: entity kinds, annotations, the three ways entities get in, and troubleshooting ingestion when it goes wrong.

# catalog-info.yaml — at the ROOT of the checkout service repo
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: checkout
  annotations:
    backstage.io/techdocs-ref: dir:.          # lights up the Docs tab
    backstage.io/kubernetes-id: checkout      # wires the Kubernetes tab to real workloads
spec:
  type: service
  owner: group:default/payments-team

Q20. Which of the following is NOT one of the entity kinds the Backstage Catalog domain names?

• A. Component
• B. System
• C. Deployment
• D. Location

Q21. Given the catalog-info.yaml snippet above, what do the two annotations respectively control?

• A. Both control ownership — they determine who gets paged when the service breaks.
• B. backstage.io/techdocs-ref lights up the Docs tab, pointing at where the TechDocs source lives; backstage.io/kubernetes-id wires the Kubernetes plugin's tab to real workloads carrying that same id.
• C. techdocs-ref sets the entity's lifecycle stage; kubernetes-id sets its owner group.
• D. Neither annotation has any effect unless the entity is also of kind API.

Q22. A platform grows from 20 services to 400 across a GitHub organization. Manually registering each catalog-info.yaml URL by hand through "Register existing component" has become unmanageable. What's the correct fix, and why?

• A. Switch to an automated ingestion provider — a GitHub entity provider that crawls the organization on a schedule — which also removes entities automatically once their catalog-info.yaml disappears, unlike either manual registration or static catalog.locations.
• B. Add all 400 URLs individually under catalog.locations in app-config.yaml — this is the recommended approach at any scale.
• C. There is no automated ingestion option; manual registration is the only mechanism the catalog supports.
• D. Increase the polling frequency on the existing manual registrations to compensate.

Q23. One entity's page shows the backstage.io/orphan annotation. A separate entity's spec.owner points at a Group that was never ingested. What do these two symptoms respectively indicate, and in what order should org data be ingested to avoid the second one?

• A. Both indicate a temporary network outage; restarting the backend resolves either.
• B. Orphan means the entity's parent Location was removed while the entity itself still lingers; a dangling owner reference means the referenced Group was never ingested, so the ownership link points at nothing — ingesting org/Group data before service entities avoids the second case.
• C. Orphan means a YAML syntax error in catalog-info.yaml; a dangling owner means a duplicate entity name somewhere in the catalog.
• D. Neither is a real failure mode; both resolve themselves automatically within 24 hours with no action required.

Q24. Why is catalog-info.yaml conventionally placed at the root of the repository it describes, rather than centralized in one shared configuration repo?

• A. Backstage cannot parse a YAML file that sits outside a repository's own root under any circumstance.
• B. So the description ships with the code it describes and stays accurate as that code changes — an ownership or API change lands in the same pull request as the code change itself, instead of drifting out of sync in a separate repository.
• C. It's required purely to make Docker layer caching work correctly during the container build.
• D. Centralized configuration repositories are explicitly disallowed by the CNCF curriculum.

Scoring yourself, and what to do with a miss

☺ Like you're 10: Getting it wrong isn't the problem — not knowing why you got it wrong is. Every miss fits into one of four boxes, and each box has its own fix.

Count your correct answers and divide by 24 to get a rough percentage — this bank is too small to be a statistically precise rehearsal of the real paper, but it's plenty large enough to tell you whether a domain needs more reading before you attempt Mock Exam · Set 1.

When you miss one, resist the urge to just note the correct letter and move on — that teaches you almost nothing. File it instead:

Weigh whichever domain produced the most misses against its blueprint weight before deciding where to spend your next study session — a rough score in the 32%-weighted Customizing domain costs far more than the same rough score in a 22%-weighted one. The CBA study plan lays out exactly how to sequence reading, this bank, and the two mock exams across the days you have.