Certifications · CBA · Mock Exam · Set 1

CBA Mock Exam · Set 1

Fifty multiple-choice questions, weighted question-for-question to the four domains of the official CBA curriculum — sixteen on Customizing Backstage, twelve on Backstage Development Workflow, eleven each on Backstage Infrastructure and Backstage Catalog. This is the first of two CBA papers on this course: it leans on definitions and single-file, single-command recall — "which file," "which command," "which side of the split" — the way a first honest measurement of the whole syllabus should, before Set 2 pushes harder into layered scenarios that make you reason across two or three competencies at once. The CBA is knowledge-based, not hands-on — no live cluster, no terminal, no grading of code you actually type — so this is a paper you sit cold, in one block, with no notes open. Answer first, then read the explanation directly beneath your choice; the domain tag on every item tells you exactly which page to reread if you miss it.

☺ Explain it like I'm 10

This is a practice quiz about the front desk you've been studying, not a building exercise — you pick the best answer out of four (or two, when it says so), and it tells you straight away whether you got it right and why. The trick is answering before you peek at the explanation, even on the questions you're only half-sure about, because a wrong answer here is free — it just points you back to the exact page you need to reread. There's no monorepo to actually run and nothing to install for this particular quiz; the whole thing lives in your head, the same way the real one does.

🦋🐢Your hosts for this topic: Mira the Butterfly & Timmy the Turtle — Mira owns every domain this paper draws from, and Timmy holds the stopwatch and won't stop it for anything, because the discipline of sitting this cold, in one sitting, is half of what the exercise is actually for.

How this paper is weighted

☺ Like you're 10: The questions are shared out exactly the way the real test shares out its marks — the biggest topic gets the most questions, and here the arithmetic happens to come out in clean whole numbers.

The CBA's four official domain weights — 32, 24, 22, 22 — sum to exactly 100%, and against fifty questions they divide with no rounding at all: 16, 12, 11, 11, which also sum to exactly 50. That tidiness is a coincidence of picking fifty rather than some other paper size, not a property of the exam itself — don't read anything into it beyond "the arithmetic happened to be clean this time." What it does mean is that this paper's proportions track the real blueprint precisely, question for question, so your score by domain is a faithful little mirror of where the real 100% goes.

Domain	Official weight	Questions here	Where to revise
🦋 Customizing Backstage	32%	16	CBA — the exam · The Backstage Portal Model
🦫 Backstage Development Workflow	24%	12	CBA — the exam · Backstage
🦉 Backstage Infrastructure	22%	11	Backstage · CBA — the exam
🐿️ Backstage Catalog	22%	11	Missing-catalog-entity drill · CBA — the exam

◆ Key idea

Score your domains, not just your total. A 76% built from "solid everywhere except Customizing" is a much more dangerous result than the same 76% built from "strong everywhere, weak on Catalog," because Customizing alone carries nearly a third of the real paper — almost half again as much as either Infrastructure or Catalog. Fix in weight order, not in the order you happened to notice the mistakes.

Sit it like the real thing

☺ Like you're 10: No notes, no open tabs, one sitting, straight through — and never leave a question blank, because a guess has a real chance of being right and a blank one never does.

The CBA is delivered online and remote-proctored, closed-book, with no documentation allowance — unlike the hands-on Kubernetes exams this course assumes but doesn't reteach, there is no "browse the docs while you work" concession here, because there is no terminal to work in at all. Sit this paper the same way: close every other tab, set a single timer, and commit to an answer on every item even when you're genuinely unsure. Nothing published states whether Linux Foundation multiple-choice exams penalize a wrong guess beyond simply not earning the point — treat that as unconfirmed rather than fact — but the practical advice holds regardless: eliminate what you can, then commit. Never leave a question blank.

⚠ Exam details change — the official page is the authority

What's safe to state structurally: the CBA is a CNCF/Linux Foundation associate-level, knowledge-based multiple-choice exam — not hands-on, and not a lab where anyone grades a Dockerfile you actually build — delivered online under remote proctoring, with no formal prerequisite. Two numbers the Linux Foundation does publish and this paper is calibrated against: 90 minutes to sit it, and 75% or above to pass (the Linux Foundation's Multiple Choice Exam FAQ states this pass mark applies to every LF multiple-choice exam). What is not published is the real question count — third-party figures for it are unverified, so this paper's size of fifty was chosen only because it divides the four domain weights with no rounding, not because it matches a real number. Price, retake terms, eligibility window and certification validity are all revised over time too — see the full logistics table. Confirm everything on the official Linux Foundation CBA page before you register or pay — this page is a study aid, not a substitute for reading it.

The paper — 50 questions across three blocks

☺ Like you're 10: Fifty questions, three blocks, every domain mixed into every block — read the question, pick one answer (or two, when it says so), then check yourself before moving to the next.

Each question names its domain in parentheses so you can total your score by domain afterward — the real exam won't label them, so once you've sat this cold, consider a second pass with the labels covered to see how many you can still place from content alone. A handful of questions are marked (Select TWO); full credit there needs both correct letters.

Block 1 — Q1–17

Q1 (Customizing Backstage). Which file in a Backstage app decides which tabs and cards appear for a given entity's kind and type?

A. app-config.yaml
B. EntityPage.tsx
C. package.json
D. catalog-info.yaml

Check the answer

B. EntityPage.tsx decides the tabs and cards per kind and type. app-config.yaml is runtime configuration, catalog-info.yaml describes one entity, and package.json just lists dependencies.

Q2 (Backstage Development Workflow). Which single command scaffolds a brand-new Backstage app as a Yarn workspace?

A. yarn create backstage-app
B. npx @backstage/create-app@latest
C. npm init backstage
D. backstage new app

Check the answer

B. npx @backstage/create-app@latest is the scaffold command, producing a Yarn workspace with packages/app and packages/backend. None of the other three are real Backstage tooling.

Q3 (Backstage Infrastructure). In the client-server split, which side is permitted to hold a GitHub App's private key?

A. The frontend, packages/app
B. Either side, since both run inside the same trust boundary
C. The backend, packages/backend
D. Neither — Backstage has no mechanism for holding such a credential at all

Check the answer

C. Anything shipped to packages/app ships to the browser and is public. Only the backend, which never ships to a client, may hold a real credential — and the standard pattern is a separate credentials file included into the backend's config, not a literal inline value.

Q4 (Backstage Catalog). Which annotation, added under metadata.annotations, lights up the Docs tab on an entity's page?

A. backstage.io/kubernetes-id
B. backstage.io/orphan
C. backstage.io/techdocs-ref
D. backstage.io/managed-by-location

Check the answer

C. backstage.io/techdocs-ref lights up the Docs tab. kubernetes-id wires the Kubernetes tab, and managed-by-location/orphan are set automatically for you and used when debugging ingestion.

Q5 (Customizing Backstage). A frontend plugin needs data from GitHub's API, so a developer hardcodes a personal access token as a string inside a React component to call it directly from the browser. What's wrong with this design?

A. Nothing — frontend plugins may hold any credential their own feature needs
B. React components cannot make outbound HTTP calls under any circumstances
C. Anything shipped to packages/app is public — the token is now exposed to every visitor, and the call should be proxied through a backend plugin instead
D. GitHub tokens only function when called from a Node process, so the call would simply fail

Check the answer

C. The frontend is a browser bundle; anything embedded in it is visible to anyone who opens dev tools. Third-party calls that need a credential belong in a backend plugin, which the frontend then calls without ever seeing the token itself.

Q6 (Backstage Development Workflow). By default, on which ports do the frontend and backend listen when you run yarn dev on a fresh create-app project?

A. 3000 and 7007
B. 8080 and 8081
C. 80 and 443
D. 3000 and 3001

Check the answer

A. The app serves on :3000 and the backend answers on :7007, both with hot reload while yarn dev runs.

Q7 (Backstage Infrastructure). Why is SQLite considered unacceptable for a production Backstage deployment?

A. SQLite cannot store YAML-shaped data
B. It is development-only and does not survive a process restart, so the catalog's data is lost
C. SQLite requires a paid license for production use
D. Backstage's catalog schema is incompatible with any relational database

Check the answer

B. SQLite is fine for a laptop demo, but it has no persistence guarantee across a restart — a production catalog needs PostgreSQL, configured under backend.database.

Q8 (Backstage Catalog). Where does a catalog-info.yaml file conventionally live?

A. In a central platform-config repository only, never alongside application code
B. At the root of the repository it describes
C. Inside packages/backend/config
D. It has no conventional location; the catalog only reads from app-config.yaml

Check the answer

B. Living at the root of the repo it describes is the whole trick — the description ships with the code, so it stays true as the code changes.

Q9 (Customizing Backstage). A team installs @backstage/plugin-kubernetes into packages/app but never installs @backstage/plugin-kubernetes-backend. What's the most likely symptom?

A. The whole app fails to build
B. The Kubernetes tab renders but shows an empty or broken card, because only half the plugin pair was installed
C. yarn tsc fails immediately
D. The catalog stops ingesting entities entirely

Check the answer

B. Many plugins ship as a matched frontend/backend pair. Installing only the frontend half gives you a tab or card with nowhere to fetch its data from.

Q10 (Backstage Development Workflow). What does yarn tsc do in a Backstage monorepo, and why does the curriculum treat it as more than a style check?

A. It formats code automatically; it's cosmetic only
B. It runs the test suite; a failure blocks merges but not builds
C. It type-checks the whole TypeScript workspace; because Backstage is fully TypeScript, a type error here is a real build-blocking gate
D. It bundles the frontend for production; it has no effect on the backend

Check the answer

C. Because the entire monorepo is TypeScript, yarn tsc is a genuine gate, not a linter suggestion — a type error stops the build cold.

Q11 (Backstage Infrastructure). Which config key would you set to point Backstage's catalog database at PostgreSQL rather than the SQLite default?

A. app.baseUrl
B. backend.database.client
C. catalog.rules
D. integrations.github

Check the answer

B. Setting backend.database.client: pg, with connection details typically pulled from environment variables, is how a production app-config.yaml moves off SQLite.

Q12 (Backstage Catalog). Which of the following is NOT one of the entity kinds named in the CBA curriculum's catalog domain?

A. Component
B. Namespace
C. System
D. Template

Check the answer

B. Namespace is a Kubernetes concept, not a Backstage catalog entity kind. The kinds you need are Component, API, Resource, System, Domain, Group, User, Location and Template.

Q13 (Customizing Backstage). "Make changes to React code in Backstage App" most directly points at which pairing of files?

A. package.json and yarn.lock
B. App.tsx and EntityPage.tsx
C. app-config.yaml and app-config.local.yaml
D. index.ts and catalog-info.yaml

Check the answer

B. App.tsx declares routes and top-level structure; EntityPage.tsx decides what appears per entity kind and type. Both are files every portal owner learns by heart.

Q14 (Backstage Development Workflow, Select TWO). A plugin ships as a matched pair. Which TWO commands correctly install both halves into a fresh app?

A. yarn workspace app add @backstage/plugin-kubernetes
B. yarn workspace backend add @backstage/plugin-kubernetes-backend
C. npm install -g @backstage/plugin-kubernetes
D. yarn global add @backstage/plugin-kubernetes-backend
E. yarn create plugin kubernetes

Check the answer

A and B. yarn workspace app add scopes the frontend half into packages/app, and yarn workspace backend add scopes the backend half into packages/backend. Global installs (C, D) and a nonexistent scaffold command (E) don't reflect how a Yarn workspace actually adds a dependency to one package.

Q15 (Backstage Infrastructure, Select TWO). Which TWO of the following correctly describe app-config.yaml layering?

A. app-config.local.yaml overrides values for local development only
B. app-config.production.yaml stacks on top of the base file for production values
C. Only one app-config file may ever exist in a Backstage project
D. Layered config files are merged at deploy time using Helm exclusively
E. ${ENV_VAR} substitution is unsupported in any app-config file

Check the answer

A and B. Configuration is one layered app-config.yaml with local and production overrides stacked on top, and ${ENV_VAR} substitution runs throughout — C, D and E all contradict that.

Q16 (Backstage Catalog). What happens if catalog.rules.allow omits Template from its list of kinds?

A. Nothing changes — Template entities ingest normally regardless of the allow-list
B. The whole catalog stops ingesting every kind, not just Template
C. Golden-path scaffolder templates silently fail to appear in the catalog, because Template entities are filtered out before they're ever shown
D. Backstage refuses to start until Template is added

Check the answer

C. The allow-list gates which kinds the catalog will accept at all — omit Template and every golden-path template silently refuses to appear, with no error to point you at why.

Q17 (Customizing Backstage). What does the new backend system's backend.add(import('@backstage/plugin-catalog-backend')) pattern replace, compared to older Backstage versions?

A. Manually wiring each plugin's router and dependencies by hand in a bespoke index.ts
B. The need for a packages/backend directory at all
C. The catalog's database configuration
D. The frontend's App.tsx routing table

Check the answer

A. The new backend system lets each plugin be added to a backend instance rather than assembled by hand — know this shape, because it's what a current create-app actually produces.

Block 2 — Q18–34

Q18 (Customizing Backstage). Which library provides Backstage's core layout primitives — Grid, Card, Typography, Button — that its own component library is built on top of?

A. Bootstrap
B. Tailwind CSS
C. Material UI
D. Chakra UI

Check the answer

C. Backstage's component library sits on Material UI, which is why "using Material UI components" is its own named competency — a custom card that ignores it looks visibly broken next to everything around it.

Q19 (Backstage Development Workflow). Which command builds a production container image from the correct Dockerfile in a Backstage monorepo?

A. docker image build . -f packages/app/Dockerfile
B. docker image build . -f packages/backend/Dockerfile
C. docker build ., with no -f flag needed since Backstage auto-detects it
D. docker image build . -f Dockerfile.frontend

Check the answer

B. The production image is built from packages/backend/Dockerfile — the compiled frontend rides inside that same image, served by the backend.

Q20 (Backstage Infrastructure). Why is the production container image built from packages/backend/Dockerfile rather than from two separate Dockerfiles for frontend and backend?

A. Because Backstage cannot be containerized in production at all
B. Because the compiled frontend is served by the backend process in a production build — it's one image and one process, not two containers talking over HTTP
C. Because packages/app has no build output of its own
D. Because Docker only supports one Dockerfile per Git repository

Check the answer

B. In production, the compiled frontend is served by the backend — one image, one process, not a frontend container calling a backend container over HTTP.

Q21 (Backstage Catalog, Select TWO). A service that used to appear on the catalog page has vanished. Which TWO checks are the most useful first steps?

A. Confirm a valid catalog-info.yaml still exists on the repository's default branch
B. Confirm the relevant provider's filter (branch/repository pattern) still matches that repository
C. Restart the Postgres container, since catalog data is always corrupted first
D. Delete and recreate the entire catalog database
E. Reinstall the frontend plugin for that entity's kind

Check the answer

A and B. A missing or unreachable catalog-info.yaml, or a provider filter that no longer matches, are the two most common causes — nothing here points at data corruption or a plugin reinstall, which are drastic, low-probability first moves.

Q22 (Customizing Backstage). Why must the scaffolder backend hold real, powerful credentials — the ability to create repositories, grant team access, and open pull requests?

A. It doesn't; the scaffolder only ever produces static text files with no external effect
B. Because creating a new service from a golden-path template genuinely requires acting on GitHub (or another SCM) on the user's behalf
C. Because the frontend requires those credentials to render the "New Service" button
D. Because catalog ingestion cannot function without them

Check the answer

B. Clicking "New Service (Golden Path)" has to actually create a repository, wire up access and open a PR — real actions on a real SCM, which is why the scaffolder backend is a credentialed robot, not a form that just writes files.

Q23 (Backstage Development Workflow). What is the purpose of npx @backstage/cli versions:bump?

A. It deletes unused dependencies from package.json
B. It upgrades every @backstage/* package in the workspace together, onto one consistent release line
C. It bumps the Node.js runtime version only
D. It increments your own application's semantic version, unrelated to Backstage's own packages

Check the answer

B. Backstage releases frequently and its packages must move together — versions:bump is the whole upgrade story, and a portal left alone for a year is genuinely painful to bring forward without it.

Q24 (Backstage Infrastructure). A team wants Backstage's GitHub integration to authenticate as an application with narrowly scoped, revocable permissions rather than as an individual's personal account. What should integrations.github reference?

A. A personal access token stored as a plain string in app-config.yaml
B. A GitHub App, included via a separate credentials file rather than inlined
C. The organization owner's own SSH key
D. A shared team password stored in a chat channel

Check the answer

B. A GitHub App, referenced with $include from a separate file, is the recommended pattern — scoped, revocable, and never a personal token tied to one employee.

Q25 (Backstage Catalog). What is an "orphan" entity in the Backstage catalog?

A. An entity whose owner Group was never ingested
B. An entity with no annotations at all
C. An entity whose parent Location was removed, but the entity record itself lingers
D. Any entity created through manual registration

Check the answer

C. An orphan lingers on after the Location that originally produced it has been removed — it's one of the three recurring failure modes worth recognizing on sight.

Q26 (Customizing Backstage). A card you've added to EntityPage.tsx renders visibly narrower or misaligned compared to Backstage's own built-in cards on the same page. What has most likely gone wrong?

A. The entity's YAML is malformed
B. The card wasn't wrapped in Material UI's Grid/Card primitives the way the rest of the app is
C. The backend plugin for that card was never installed
D. yarn tsc failed silently

Check the answer

B. Because the app's whole layout system sits on Material UI, a custom card that skips Grid looks visibly out of place next to everything built with it.

Q27 (Backstage Development Workflow). Which command runs only the backend half of a Backstage app, isolated from the frontend, useful when debugging backend-only issues?

A. yarn workspace backend start
B. yarn dev --backend-only
C. yarn build:backend
D. yarn tsc --project backend

Check the answer

A. yarn workspace backend start (and its counterpart yarn workspace app start) runs one half at a time — the client-server split made concrete in a command.

Q28 (Backstage Infrastructure). "Deploy Backstage to production" names a competency broader than "run docker build." Which of the following is genuinely part of it, beyond having a database?

A. A real auth provider plus a resolver mapping a signed-in person to a User entity
B. Switching the frontend from React to a server-rendered framework
C. Removing the backend entirely and running the frontend standalone
D. Disabling TypeScript compilation for faster builds

Check the answer

A. Real identity — an auth provider plus a resolver — sits alongside a real database and injected secrets as part of what "production" actually means for a Backstage deployment.

Q29 (Backstage Catalog). What is a "dangling owner reference," and what should you check first when you find one?

A. An entity with two owners listed at once; check for a YAML syntax error
B. A spec.owner pointing at a Group entity that was never itself ingested, so ownership links resolve to nothing; ingest org/group data first
C. An entity annotated with the wrong techdocs-ref path; check the TechDocs build logs
D. A Location pointing at a URL that returns a 404; check the repository's visibility settings

Check the answer

B. Ownership links go nowhere when the referenced Group was never ingested — the fix is ingesting org data first, not chasing the individual component's YAML.

Q30 (Customizing Backstage, Select TWO). Which TWO statements correctly distinguish frontend from backend Backstage plugins?

A. A frontend plugin runs in the browser as React and must never hold a secret
B. A backend plugin runs as a Node service and is where credentials like a GitHub App token belong
C. Frontend plugins are installed into packages/backend
D. Backend plugins render tabs and cards directly in the entity page's HTML
E. Only backend plugins are written in TypeScript

Check the answer

A and B. The frontend/backend split is exactly this: React in the browser holding no secrets, versus Node holding credentials, database access and routes. C, D and E all invert or misstate the split.

Q31 (Backstage Development Workflow). What does yarn build:all produce, as distinct from yarn build:backend?

A. yarn build:all compiles nothing; it's an alias for yarn tsc
B. yarn build:all produces a full production build across the workspace, while yarn build:backend specifically builds the backend bundle later packaged into the container image
C. yarn build:all only builds the frontend; yarn build:backend is required first for it to work at all
D. The two commands are interchangeable and produce identical output

Check the answer

B. build:all is the workspace-wide production build; build:backend targets specifically the backend bundle that then feeds the Dockerfile.

Q32 (Backstage Infrastructure). Which of these correctly describes app.baseUrl and backend.baseUrl in a straightforward single-service deployment?

A. They must always point at two entirely separate hostnames
B. app.baseUrl has no effect once the app is built for production
C. In production, both commonly point at the same origin, since the backend both answers the API and serves the compiled frontend
D. backend.baseUrl is only used during local development and is ignored in production

Check the answer

C. Because the backend serves the compiled frontend directly in production, both URLs commonly resolve to the same origin — one process answering both jobs.

Q33 (Backstage Catalog). A "Register existing component" click in the UI, where a human pastes a repository URL, creates which kind of object?

A. A Component entity directly, bypassing any Location
B. A Location, which the catalog then processes into one or more entities
C. A System entity representing the whole organization
D. A permanent database index with no catalog object at all

Check the answer

B. Manual registration creates a Location — the catalog then reads whatever that Location points at and ingests the entities it describes.

Q34 (Customizing Backstage). A backend plugin needs to expose a new HTTP route other parts of the system can call. Where is that route typically exposed, and what must the code serving it never do?

A. Under /api/<plugin-name>; it must never leak the credentials it holds internally into the response body
B. Under /static/<plugin-name>; credentials are fine here since it's a GET-only route
C. It's exposed directly by App.tsx in the frontend
D. Backend plugins cannot expose HTTP routes at all

Check the answer

A. A backend plugin's typical job is exposing /api/<plugin>, fetching from a third-party API or persisting data — and the credentials it holds to do that must never be echoed back into a response a browser can read.

Block 3 — Q35–50

Q35 (Customizing Backstage). What is the essential difference between "customizing Backstage plugins" (the exam competency) and building an entirely new plugin from a blank template?

A. There is no difference — both are the same competency
B. Customizing means configuring, extending or reconfiguring an existing plugin's behavior — routes, cards, config — rather than authoring a wholly new plugin package from scratch
C. Customizing only ever applies to backend plugins
D. Customizing is only possible using a dedicated CLI scaffolding command with no manual editing

Check the answer

B. The competency is about reshaping what already exists — a new tab, a reconfigured card, an edited route — not necessarily authoring a brand-new plugin package.

Q36 (Backstage Development Workflow). Which best describes what "understand local development workflows" tests, beyond simply running yarn dev once?

A. Knowing that packages can be started independently (yarn workspace app start / yarn workspace backend start) to isolate one half while debugging
B. Memorizing every flag of the Yarn CLI
C. Knowing that Backstage cannot be developed locally at all — only in CI
D. Knowing how to configure a remote desktop session

Check the answer

A. Being able to isolate and run one half of the app at a time is a genuinely useful debugging skill this competency is checking for, not just "can you type yarn dev."

Q37 (Customizing Backstage). A frontend plugin card wants to display Kubernetes pod status for a service. Which backend plugin must be added alongside the frontend one for that data to actually appear?

A. @backstage/plugin-techdocs-backend
B. @backstage/plugin-kubernetes-backend
C. @backstage/plugin-scaffolder-backend
D. No backend plugin is needed; Kubernetes data comes straight from the browser

Check the answer

B. The Kubernetes tab's frontend card has nothing to render without @backstage/plugin-kubernetes-backend installed and wired into the backend — the browser never talks to a cluster directly.

Q38 (Backstage Catalog). Everything in the catalog is reachable through a plain REST API. Which request correctly deletes the Location responsible for a ghost entity, without touching entities from other locations?

A. DELETE /api/catalog/entities/by-name/component/default/<name>
B. DELETE /api/catalog/locations/<id>
C. POST /api/catalog/refresh
D. PUT /api/catalog/entities

Check the answer

B. Deleting the Location is the correct fix — deleting the entity directly (A) just gets recreated on the next ingestion cycle, since the source that produced it is still registered.

Q39 (Customizing Backstage). Which markup would you reach for to lay out two cards side by side, each taking half the row's width, on a new EntityLayout.Route?

A. <Grid container spacing={3}><Grid item md={6}>...</Grid><Grid item md={6}>...</Grid></Grid>
B. A plain HTML <table> with one row and two cells
C. Two <div> elements floated left at 50% width each with inline styles
D. <EntityLayout.Route> alone, with no further markup

Check the answer

A. A Grid container with two Grid item md={6} children is the idiomatic Material UI way to split a row in half — matching the sizing and spacing every other card in the app already uses.

Q40 (Backstage Development Workflow). Which flag or file lets you layer production-specific values on top of the base config when invoking yarn build:backend?

A. --config, pointing at an additional app-config.production.yaml layered on top of the base file
B. --production, a boolean with no file argument
C. There is no way to layer configuration at build time
D. NODE_ENV=production alone, with no --config flag ever required

Check the answer

A. Passing an extra --config file layers production overrides on top of the base app-config.yaml — the same layering mechanism the Infrastructure domain tests from the configuration side.

Q41 (Backstage Infrastructure). Which statement correctly describes where the catalog sits in the client-server architecture?

A. Inside the browser, cached entirely in local storage
B. Backed by a database the backend owns and serves through its API — the frontend never talks to the database directly
C. It is a separate microservice unrelated to either packages/app or packages/backend
D. It exists only at build time and has no runtime component

Check the answer

B. The catalog sits between frontend and backend conceptually, but physically it's a database the backend owns; the browser only ever sees it through the backend's API.

Q42 (Customizing Backstage, Select TWO). Which TWO files would you most directly touch to add a working "Kubernetes" tab — visible in the browser and backed by real cluster data — to a service's entity page?

A. packages/app/src/components/catalog/EntityPage.tsx
B. packages/backend/src/index.ts
C. app-config.local.yaml only
D. package.json's devDependencies only
E. .gitignore

Check the answer

A and B. The frontend route lives in EntityPage.tsx; the backend plugin that actually reaches the cluster has to be registered in packages/backend/src/index.ts. Neither half alone produces a working tab.

Q43 (Customizing Backstage). What is the risk of granting the scaffolder backend's GitHub App overly broad organization permissions rather than scoping it tightly to the platform team's own template repositories?

A. There is no risk; broader scopes only ever improve reliability
B. A compromised or misused scaffolder could create or modify infrastructure well beyond what golden-path templates were meant to touch
C. Broad scopes are required for the scaffolder to function at all
D. GitHub Apps cannot be scoped narrowly regardless of configuration

Check the answer

B. The scaffolder is a credentialed robot — the whole point of scoping it tightly is limiting the blast radius if a template is ever misused or the credential is ever compromised.

Q44 (Backstage Development Workflow). A developer runs yarn tsc and it reports no errors, then edits a .tsx file and removes a required prop from a component. What should the very next yarn tsc run do?

A. Nothing — prop types aren't checked by tsc
B. Fail, flagging the missing required prop as a type error, before the build proceeds
C. Silently patch the missing prop with a default value
D. Only fail if yarn build:all is also run afterward

Check the answer

B. A missing required prop is exactly the kind of thing tsc is meant to catch before it ever reaches a build — that's what makes it a real gate rather than a formality.

Q45 (Backstage Infrastructure). Which of these is the correct interpretation of "understand the Backstage framework" as a named competency, distinct from "configure Backstage"?

A. They are identical competencies tested with duplicate questions
B. "Understand the framework" concerns what Backstage fundamentally is — an app you create and own, not a product you install — while "configure Backstage" concerns the specific settings inside app-config.yaml
C. "Understand the framework" only applies to CNCF staff, not candidates
D. "Configure Backstage" supersedes and replaces "understand the framework" in the current curriculum

Check the answer

B. One competency is conceptual — Backstage as a framework you scaffold and own — and the other is practical: the actual config keys you set. Both live under Infrastructure, but they're testing different things.

Q46 (Backstage Catalog). A colleague insists the fix for a ghost entity still showing on the catalog page is always to delete the entity object directly through the API. Why is this the wrong general approach?

A. It isn't wrong; deleting the entity directly is always correct
B. Deleting the entity without removing its Location means the next ingestion cycle simply recreates it — the Location is the actual source, and it's what should be removed
C. The catalog API has no entity-delete endpoint at all
D. Entities can only be deleted by restarting the whole backend process

Check the answer

B. Deleting the entity treats the symptom, not the source — the Location that keeps re-registering it is what actually needs to go.

Q47 (Customizing Backstage). "Understand frontend versus backend plugins" is listed first among the Customizing Backstage competencies. Why does the curriculum likely put it first?

A. Because it's the least important of the four and traditionally listed last, reversed here for no particular reason
B. Because nearly every other Customizing competency — editing React code, using Material UI, customizing a plugin's behavior — depends on first knowing which half of the split you're actually working in
C. Because frontend and backend plugins are functionally identical and the distinction is only cosmetic
D. Because the exam only asks about backend plugins in practice

Check the answer

B. Every other competency in this domain presumes you already know which side of the split you're editing — get that wrong and the rest of the domain doesn't make sense.

Q48 (Backstage Development Workflow). Compared to yarn install, what does yarn workspace app add @backstage/plugin-kubernetes specifically do?

A. It resolves dependencies for the entire workspace, identically to yarn install
B. It adds a dependency scoped to just the app package, rather than touching every package in the workspace
C. It installs a plugin globally, usable by any Backstage app on the machine
D. It has no effect unless yarn install is never run first

Check the answer

B. yarn workspace <name> add scopes the dependency to one package in the workspace — the frontend/backend split made concrete in a package-manager command.

Q49 (Backstage Infrastructure). Two engineers disagree about where a plugin's third-party API credentials should be injected in a production deployment. One says "bake them into the Docker image at build time"; the other says "inject them from the environment at runtime." Which is more consistent with the "deploy to production" competency?

A. Baking secrets into the image, because it simplifies the deployment pipeline
B. Injecting from the environment at runtime, so secrets are never committed or baked into a distributable artifact
C. Neither — secrets should be typed directly into app-config.yaml and committed
D. It doesn't matter; Backstage encrypts image contents automatically

Check the answer

B. Runtime injection keeps secrets out of a distributable image and out of source control — the same "secrets injected at runtime, never committed" pattern the Infrastructure domain names elsewhere.

Q50 (Backstage Catalog). Which single sentence best distinguishes "manually registered entity locations" from "automated ingestion," as two separate named competencies?

A. They're the same competency under two different exam-guide headings
B. Manual registration is a human pasting one URL at a time via the UI or API; automated ingestion is a scheduled provider crawling a whole organization and adding or removing entities as repositories appear or disappear
C. Manual registration only works for Kubernetes-shaped YAML; automated ingestion works for any file format
D. Automated ingestion requires no catalog.providers configuration at all

Check the answer

B. One is a person registering a single URL by hand; the other is a scheduled provider crawling an organization at scale — and only the provider route removes entities automatically when their source file disappears.

Score yourself

☺ Like you're 10: Count your correct answers out of fifty, turn it into a percentage against the real 75% pass mark, then look at which domain cost you the most points — that second part is the part that actually helps.

The Linux Foundation's Multiple Choice Exam FAQ states that a score of 75% or above is required to pass any LF multiple-choice exam, and the CBA is one. Treat 75% here as a target to clear comfortably, not a calibrated prediction of the real sitting — this paper's wording is ours, not the CNCF's, and it isn't tuned to match the real exam's difficulty.

Domain	Questions in this paper	Your score	If you're under two-thirds, go here
🦋 Customizing Backstage	Q1, 5, 9, 13, 17, 18, 22, 26, 30, 34, 35, 37, 39, 42, 43, 47	/16	CBA — the exam
🦫 Backstage Development Workflow	Q2, 6, 10, 14, 19, 23, 27, 31, 36, 40, 44, 48	/12	Backstage
🦉 Backstage Infrastructure	Q3, 7, 11, 15, 20, 24, 28, 32, 41, 45, 49	/11	Backstage
🐿️ Backstage Catalog	Q4, 8, 12, 16, 21, 25, 29, 33, 38, 46, 50	/11	Missing-catalog-entity drill
Total	50 questions	/50	75% (38/50) to clear comfortably

Whatever you scored, sort your misses into two piles before you move on, because on a paper like this one they mean different things. A question you got wrong because you genuinely didn't know the file, the command, or the annotation is a real content gap — reread the linked domain section and redo that exact question cold in a couple of days. A question you got wrong despite roughly knowing the material — you second-guessed yourself, or confused two similarly worded options under time pressure — is a confidence problem, not a knowledge gap, and the fix is more timed reps, not rereading content you already have. Either way, don't retake this exact paper minutes later; go read first, then come back.

Where each domain is taught

☺ Like you're 10: Every question above traces back to one of a handful of pages. Go back to the page, not to the wider internet.

Nothing in this paper examines anything that isn't covered somewhere on this course. Where a subject is genuinely Backstage-specific, the pages live right here on Golden Astronaut; where it's general platform-engineering ground shared with Backstage rather than unique to it, the deeper read lives on the sibling Platform Engineering CBA overview, which covers the same four domains from the other side of the trio.

🦋 · 32%

Customizing Backstage

Frontend vs. backend plugins, editing App.tsx and EntityPage.tsx, Material UI, and the scaffolder's own security model.

🦫 · 24%

Backstage Development Workflow

create-app, yarn dev, the yarn tsc gate, plugin installs, and building the production container image.

🦉 · 22%

Backstage Infrastructure

The client-server split, app-config.yaml layering, PostgreSQL vs. SQLite, and what "deploy to production" actually requires.

🐿️ · 22%

Backstage Catalog

Entity kinds, annotations, the three ingestion routes, and the three failure modes worth recognizing on sight.

Beyond the domain pages, the wider revision kit still applies: flashcards for the vocabulary, the self-check quiz for mixed recall, the glossary for anything a question assumed you already knew, and the CBA study plan for how to sequence all of this against your remaining prep time. If the hands-on side of this paper felt shakier than the recall side, the capstone's portal stage and Developer experience are worth a look too.

🎬 At Mission Control
🐰Remy: Forty-four out of fifty! Client-server split, catalog kinds, done, done, next paper!
🦋Mira: Which domain hid the other six, Remy? Forty-four sounds great until one domain swallowed most of them.
🐰Remy: ...fine. Customizing. I kept assuming any card I wrote would just line up correctly without wrapping it in Grid.
🦊Foxy: Wait, Material UI actually matters? I thought that was decoration.
🦋Mira: It's the layout system the entire app is built on, Foxy. Skip it and your card doesn't just look wrong — it's the exact "customizing" competency worth the most marks on the whole paper.
👺Gizmo: Or just copy someone else's EntityPage.tsx wholesale and never touch Material UI directly. Ship it! 😈
🐢Timmy: That's exactly the gap this paper is built to catch, Gizmo. Copying a page tells you nothing about whether you understand the primitives underneath it.
🐰Remy: Fine, fine — I'll actually open EntityPage.tsx and read the Grid section properly before I re-sit against Set 2.

🐢 Timmy's checkpoint

1. Name the four CBA domains and their weights, in weight order. 2. A frontend plugin is installed with no matching backend plugin — what's the most likely symptom, and why? 3. Name the three ways an entity enters the Backstage catalog, and which one scales to a whole organization. 4. Which file builds the production container image, and why does the compiled frontend ride inside it? 5. Why is SQLite unacceptable for a production Backstage deployment, and what replaces it? 6. Ghost entity still showing on the catalog page — what's the correct fix, and what's the common wrong one? 7. Name one thing this exam publishes officially and one thing it deliberately does not — and where would you go to confirm either before booking?

Check your answers

Customizing Backstage 32%; Backstage Development Workflow 24%; Backstage Infrastructure 22%; Backstage Catalog 22%.
The plugin's frontend half renders — a tab or a card — but it has nowhere to fetch its data from, so it typically shows empty or broken. Most plugins ship as a matched pair, and installing only one half is the single most common cause of "I installed the plugin and nothing shows up."
Manual registration (a human registers a URL, creating a Location), static locations (URLs under catalog.locations in config), and automated ingestion via entity providers that crawl an organization on a schedule. Only providers scale — and they also remove entities when the underlying file disappears.
packages/backend/Dockerfile. The compiled frontend rides inside it because in a production build the backend serves the frontend itself — one image and one process, not two containers.
SQLite is development-only — it does not survive a process restart, so the catalog vanishes with it. Production uses PostgreSQL, configured under backend.database with credentials injected from the environment rather than committed.
Delete the Location that created the ghost entity, not the entity itself — deleting the entity directly just gets it recreated on the next ingestion cycle, since the source that produced it is still registered.
Officially published: the 90-minute duration and the 75% pass mark (from the Linux Foundation's Multiple Choice Exam FAQ). Not published: the real question count — any third-party figure for it is unverified. Confirm both, and everything else, on the official Linux Foundation CBA page before you register.

That's the full sitting. Reread whichever domain cost you the most, give it a day to settle, then move on to Set 2 — the scenario-heavy paper that assumes this baseline is already solid.

⏱️ The two CBA papers

Set 1 (you are here) · Set 2. Both are fifty questions on the same 16 · 12 · 11 · 11 domain split, so the scores are directly comparable — Set 1 leans on single-file, single-command recall, Set 2 leans harder into layered scenarios spanning two or three competencies at once. See the CBA study plan for where each paper fits against your remaining prep time, the practice-question bank for shorter drills in between, and CBA — the exam for the full domain writeup and official logistics.