Certifications · CBA · Mock Exam · Set 2

CBA Mock Exam · Set 2

This is the second of two full-length CBA practice papers on this course — fifty original questions, weighted to the official four domains and their published percentages (Customizing Backstage 32%, Development Workflow 24%, Infrastructure 22%, Catalog 22%), split into a clean 16/12/11/11 across those weights and sat in one unbroken, closed-book 90-minute sitting exactly like the real Certified Backstage Associate exam. Every question below is new; none repeat Set 1, so a strong score here confirms you actually know the material — the React, the YAML, the Yarn commands — rather than that you memorized one paper's answer key. Unlike this shelf's infrastructure exams, don't expect a single question about clusters or CRDs: CBA tests one framework you build and own, and this paper tests it exactly that way. Read each stem, commit to an answer, then open the worked explanation directly underneath before moving on. Score yourself against the 75% pass mark at the end, broken down by domain, so a weak spot points you straight back to the exact page that fixes it.

Where Set 2 fits in your CBA prep

☺ Like you're 10: First you learn the four topics, then you take the first practice quiz, fix what it found, and only then take this second, trickier-feeling quiz to prove the fix actually stuck.

The intended order on this course is: read CBA — the exam for the four domains and what each actually tests, work through the practice question bank topic by topic with no clock running, sit Set 1 as your first full-paper checkpoint, fix whatever domain it exposed, and only then sit this paper. Set 2 isn't easier or harder than Set 1 by design — it draws on the same four domains in the same 16/12/11/11 proportion — but a handful of these questions lean on the exact edge cases a first pass through the material tends to skate past: a plugin installed on only one side of the frontend/backend split, a Location that has to be deleted rather than the ghost entity it produced, a Dockerfile question that tests whether you actually know which package gets containerized and why. If a domain score sags here in the same place it sagged on Set 1, that's not bad luck twice — that's a real gap, and the study plan tells you how much time to budget for closing it before you book the real thing.

This paper assumes you've read the domain material, not that you're seeing any of it for the first time — if a term below is unfamiliar rather than just rusty, that's a sign to go back to Backstage and The Backstage Portal Model before spending more of your ninety minutes here.

Sit it like the real thing

☺ Like you're 10: No notes, no open tabs, one sitting, ninety minutes on the clock — and answer every question, because a guess has a chance and a blank has none.

The CBA is knowledge-based and multiple choice, not a live coding exercise — there's no IDE to open and no terminal to type into during the exam itself, even though the subject matter is a monorepo you'd normally be typing into constantly. Treat this practice paper, like the real thing, as fully closed-book: close every other tab, put your phone away, and sit the fifty questions below in one sitting with nothing open but this page. As with most closed-book multiple-choice exams, there is little reason to ever leave a question blank — a considered, eliminate-the-obviously-wrong-options guess only ever helps your score, never hurts it. If a question is stumping you past a minute or so, mark your best guess, move on, and come back if time allows at the end rather than letting one item eat a disproportionate share of the clock.

Your 90-minute budget

☺ Like you're 10: Fifty questions, ninety minutes — split into five eighteen-minute chunks, so you can tell early if you're falling behind instead of finding out with five questions left.

Fifty questions in ninety minutes is just under two minutes each, and this paper — like the real exam — doesn't spread its harder items evenly across the numbering. The schematic below splits the sitting into five 18-minute blocks of ten questions apiece, so you have a clean pace checkpoint roughly every eighteen minutes, and shows how those fifty questions divide against the real domain weights: sixteen on Customizing Backstage, twelve on Development Workflow, eleven each on Infrastructure and Catalog.

If a question runs past roughly a minute without a confident answer, don't stall — eliminate what you can, commit to your best remaining option, and move on. Each explanation sits directly under its question rather than in a separate answer key at the end, so the only discipline required is not opening it before you've actually decided.

The paper — 50 questions in exam order

☺ Like you're 10: Fifty questions, five blocks of ten, every topic 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 tags covered to see how many you can still place from content alone. Three questions below are marked (Select TWO); full credit there needs both correct letters.

Block 1 — Q1–10

Q1 (🦉 Infrastructure). What is the Backstage frontend, architecturally?

• A. A server-rendered application with no client-side JavaScript
• B. A React single-page app that holds no secrets and only ever talks to the backend over HTTP
• C. A standalone binary compiled separately from the rest of the monorepo
• D. A CLI tool with no browser component at all

Check the answer

B. Anything shipped to a browser is public by definition, so the frontend can never hold a secret — every request that needs one goes to the backend over HTTP instead.

Q2 (🦋 Customizing). Which statement correctly distinguishes a Backstage frontend plugin from a backend plugin?

• A. A frontend plugin is written in Python; a backend plugin is written in Go
• B. A frontend plugin is React, installed into packages/app, and runs in the browser; a backend plugin is Node, installed into packages/backend, and may hold credentials
• C. Frontend and backend plugins are two names for the exact same package
• D. Only backend plugins are ever optional to install

Check the answer

B. The split follows directly from where each half runs — one in the browser, public by nature; one on the server, allowed to hold secrets.

Q3 (🐿️ Catalog). Structurally, what is a Backstage catalog entity?

• A. A binary blob stored in the catalog database with no human-readable form
• B. A YAML document with a Kubernetes-shaped envelope — apiVersion, kind, metadata, spec — under backstage.io/v1alpha1
• C. A row in a spreadsheet imported once at setup
• D. A compiled TypeScript class instantiated at runtime

Check the answer

B. Every entity is a plain, versionable YAML document — the same shape as a Kubernetes manifest, which is exactly why it feels familiar the first time you see one.

Q4 (🦫 Development Workflow). Which command scaffolds a brand-new Backstage project?

• A. yarn create backstage
• B. npx @backstage/create-app@latest
• C. docker run backstage/init
• D. backstage new-app --template default

Check the answer

B. This is the one command every CBA candidate should be able to type from memory — it produces the Yarn workspace that everything else in this domain operates on.

Q5 (🦉 Infrastructure). What does the Backstage backend own that the frontend never can?

• A. The page's CSS
• B. The database connection, credentials for integrations like GitHub, and any route that reaches a third-party system
• C. The user's browser cache
• D. The React component tree

Check the answer

B. Everything that must stay secret lives behind the backend — it's the only half of the split allowed to hold a key.

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

• A. The whole application fails to build
• B. The Kubernetes tab renders but stays empty or errors, because it has no backend counterpart to call
• C. Nothing — frontend-only plugins always work standalone
• D. The catalog silently deletes all Kubernetes-related entities

Check the answer

B. "I installed the plugin but the tab is empty" is almost always "you installed one half" — many plugins ship as a matched pair for exactly this reason.

Q7 (🦫 Development Workflow). create-app produces a Yarn workspace containing which two primary packages?

• A. packages/client and packages/server
• B. packages/app (the React frontend) and packages/backend (the Node backend)
• C. src/frontend and src/backend
• D. A single unified package with no split at all

Check the answer

B. The client-server split isn't just a runtime concept — it's baked into the workspace's directory layout from the moment you scaffold it.

Q8 (🐿️ Catalog). What is the conventional filename and location for a component's catalog descriptor?

• A. backstage.json, kept only in a dedicated config repo
• B. catalog-info.yaml, at the root of the repo it describes
• C. component.xml, inside a dedicated /catalog directory
• D. metadata.toml, committed to the Backstage monorepo itself

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 instead of drifting out of date somewhere else.

Q9 (🦉 Infrastructure). Which database is appropriate for a production Backstage deployment, and which is development-only?

• A. MySQL for production; MongoDB for development
• B. PostgreSQL for production; SQLite is development-only, since it doesn't survive a process restart
• C. SQLite for production; PostgreSQL for development
• D. Both are equally suitable for production at any scale

Check the answer

B. SQLite forgets everything the moment the process restarts — fine on a laptop, unacceptable the moment a real team depends on the catalog persisting.

Q10 (🦋 Customizing). Which two files does "make changes to React code in Backstage App" primarily point to?

• A. package.json and tsconfig.json
• B. App.tsx (routes and top-level structure) and EntityPage.tsx (which tabs and cards appear per entity kind and type)
• C. index.html and main.css
• D. app-config.yaml and app-config.production.yaml

Check the answer

B. These are the two files every portal owner learns by heart — one shapes the whole app, the other shapes what a given entity's page looks like.

Block 2 — Q11–20

Q11 (🦫 Development Workflow). Which command resolves the entire Yarn workspace's dependencies after cloning or scaffolding a Backstage project?

• A. yarn install
• B. yarn build:all
• C. yarn tsc
• D. yarn workspace app start

Check the answer

A. yarn install resolves every dependency across the whole workspace in one pass, before anything can build or run.

Q12 (🦋 Customizing). Which of these correctly uses a Material UI layout primitive the way Backstage's own component library expects?

• A. Wrapping a custom card's content in a plain <div style="display:flex"> instead of Grid
• B. <Grid item md={6}><EntityAboutCard variant="gridItem" /></Grid>
• C. Importing a separate CSS grid framework alongside Material UI
• D. Hardcoding pixel widths instead of using any grid component

Check the answer

B. A custom card that ignores the Material UI Grid looks visibly broken next to everything else on the page, since Backstage's own components sit on top of Material UI throughout.

Q13 (🦉 Infrastructure). In app-config.yaml, what's the difference between app.baseUrl and backend.baseUrl?

• A. They must always be identical, or the app fails to start
• B. app.baseUrl is where the frontend is served; backend.baseUrl is where the API answers — these can differ depending on deployment topology
• C. app.baseUrl only matters in local development and is ignored in production
• D. backend.baseUrl configures the database connection string

Check the answer

B. Two distinct URLs for two distinct halves of the client-server split — they often match, but nothing requires them to.

Q14 (🐿️ Catalog). Which annotation lights up an entity's TechDocs tab?

• A. backstage.io/kubernetes-id
• B. backstage.io/techdocs-ref
• C. argocd/app-name
• D. backstage.io/orphan

Check the answer

B. backstage.io/techdocs-ref (commonly set to dir:.) is what tells Backstage where to find and render the documentation for that entity.

Q15 (🦫 Development Workflow). Which command runs both the frontend and backend halves together with hot reload?

• A. yarn workspace app start
• B. yarn dev
• C. yarn build:backend
• D. yarn tsc --watch

Check the answer

B. yarn dev runs both halves at once — frontend on :3000, backend on :7007 — reloading as you edit either side.

Q16 (🦋 Customizing). A developer wants to add a brand-new tab to every Component entity's page. Where do they add it?

• A. In App.tsx, inside the top-level route table
• B. In EntityPage.tsx, as a new EntityLayout.Route inside the relevant entity page definition
• C. In app-config.yaml, under a new catalog.tabs key
• D. In packages/backend/src/index.ts

Check the answer

B. Per-entity tabs and cards are exactly what EntityPage.tsx exists to control — one new EntityLayout.Route block is literally "customizing Backstage."

Q17 (🦉 Infrastructure). Why should Backstage's GitHub integration use a GitHub App rather than a personal access token belonging to one employee?

• A. GitHub Apps are free while personal access tokens always cost money
• B. A GitHub App is scoped and owned by the organization rather than tied to one person's credential, which shrinks blast radius and survives personnel changes
• C. Personal access tokens cannot authenticate to the GitHub API under any configuration
• D. GitHub Apps can only ever be granted read-only permissions

Check the answer

B. A credential tied to one person is a liability the moment that person changes teams or leaves — a scoped, org-owned GitHub App doesn't have that problem.

Q18 (🐿️ Catalog). Which annotation wires an entity's Kubernetes tab to real running pods?

• A. backstage.io/techdocs-ref
• B. backstage.io/kubernetes-id
• C. argocd/app-name
• D. backstage.io/managed-by-location

Check the answer

B. backstage.io/kubernetes-id is the pointer the Kubernetes plugin uses to find the workloads that actually belong to this entity.

Q19 (🦫 Development Workflow). Why is yarn tsc described as a real gate rather than a linter suggestion, for a Backstage project?

• A. Because the entire project is TypeScript, and a type error stops the build cold rather than merely producing a warning
• B. Because tsc silently ignores all compilation errors by default
• C. Because TypeScript checking is optional and routinely skipped in CI
• D. Because tsc only checks CSS files, not application logic

Check the answer

A. There's no "compiles with warnings" state for a Backstage monorepo — a type error is a build failure, full stop.

Q20 (🦋 Customizing). Can a frontend plugin safely store a GitHub personal access token in React component state to call the GitHub API directly from the browser?

• A. Yes, as long as the token is base64-encoded first
• B. No — anything shipped to the browser is public, and the frontend must never hold a credential like that
• C. Yes, since React component state is never exposed to network requests
• D. Only if the token is scoped to read-only access

Check the answer

B. Encoding isn't encryption, and browser memory isn't private — any secret that reaches the frontend is effectively public. Route the call through the plugin's own backend instead.

Block 3 — Q21–30

Q21 (🦋 Customizing). Backstage's own component library sits on top of which UI toolkit, meaning a custom card should follow the same visual primitives?

• A. Bootstrap
• B. Material UI
• C. Tailwind UI
• D. A fully custom, unnamed internal design system

Check the answer

B. Grid, Card, Typography, Button — Material UI is the layer everything else in the frontend is built from.

Q22 (🦉 Infrastructure). Which of these is true about "deploying Backstage to production," per the curriculum?

• A. It requires the deployment target to be a Kubernetes cluster specifically
• B. It requires a real database, a real identity/auth resolver mapping signed-in users to User entities, and secrets injected at runtime — but names no specific underlying compute platform
• C. It is satisfied once yarn dev runs successfully on a laptop
• D. It requires disabling the catalog entirely until traffic is verified

Check the answer

B. Real database, real identity, real secrets — those are the requirements. Kubernetes is one common place to run the resulting container, not a requirement of the competency itself.

Q23 (🐿️ Catalog, Select TWO). Of the three routes by which an entity gets into the catalog, which TWO are explicit — read directly from a human action or static config — rather than crawled automatically on a schedule?

• A. Manually registered entity locations (a human pastes a URL, creating a Location)
• B. Static locations (URLs listed under catalog.locations in config)
• C. Automated ingestion via entity providers that crawl a whole organization
• D. Continuous deployment triggered by a Git webhook
• E. None of the three routes are explicit

Check the answer

A and B. Manual registration and static locations are both explicit, human-authored routes into the catalog. Automated ingestion (C) is the one that crawls on a schedule instead, and (D) isn't one of the three named routes at all.

Q24 (🦫 Development Workflow). A production container image is built from which Dockerfile, and why not two separate ones for frontend and backend?

• A. packages/app/Dockerfile, because the frontend serves itself independently in production
• B. packages/backend/Dockerfile, because in a production build the compiled frontend is served by the backend — one image, one process
• C. A root-level Dockerfile.combined that merges both packages line by line
• D. Neither package needs a Dockerfile; Backstage ships its own official image for every app

Check the answer

B. Production Backstage isn't a frontend container talking to a backend container — it's one process, built from the backend's own Dockerfile, that also serves the compiled frontend assets.

Q25 (🦋 Customizing). Which best describes "customizing Backstage plugins," as distinct from writing an entirely new plugin package from scratch?

• A. Adjusting or configuring an existing plugin's exposed component — custom columns, custom props, a wrapped variant — rather than authoring a brand-new plugin
• B. Deleting the plugin's source entirely and replacing it with hand-written HTML
• C. Renaming the plugin's npm package without changing any of its code
• D. Only ever changing a plugin's version number in package.json

Check the answer

A. The competency is about shaping and configuring what already exists — not about the separate skill of authoring a plugin package from zero.

Q26 (🐿️ Catalog). What distinguishes automated ingestion providers from static locations, in terms of what happens when the source disappears?

• A. There is no difference — both behave identically on deletion
• B. Providers remove the entity automatically when its source file disappears; a static location does not do this on its own
• C. Static locations delete entities immediately on any config change; providers never do
• D. Neither route can ever produce an orphaned entity

Check the answer

B. This is exactly why only providers scale to a whole organization — they keep the catalog honest by removing what no longer exists, not just adding what's new.

Q27 (🦉 Infrastructure). What is the "client-server split" fundamentally about?

• A. A performance optimization to reduce page load time
• B. Separating what the browser is allowed to know — public by definition — from what only the backend may hold, namely credentials and secrets
• C. A licensing boundary between the free and paid tiers of Backstage
• D. A convention with no real security implication

Check the answer

B. It's a trust boundary, not a speed trick — everything on one side of it is public, everything on the other side can be a secret.

Q28 (🦫 Development Workflow). Which command keeps every @backstage/* package aligned on one release line during an upgrade?

• A. npx @backstage/cli versions:bump
• B. yarn upgrade --latest
• C. yarn workspace app add @backstage/latest
• D. There is no such command — each package is upgraded manually, one at a time

Check the answer

A. Backstage releases often and its packages are meant to move together — versions:bump is the whole upgrade story in one command.

Q29 (🦋 Customizing). A frontend plugin card needs data from an external API (say, DORA-style delivery metrics) to render. What's the correct pattern?

• A. The frontend calls the third-party API directly, storing the required API key in a public environment variable
• B. The frontend calls its plugin's own backend route; the backend — which may hold the credential — calls the external API on its behalf
• C. The frontend and the external API are never allowed to interact, even indirectly
• D. The external API's credential is committed to app-config.yaml and read by the frontend at build time

Check the answer

B. The frontend never touches the external credential at all — it only ever talks to its own backend, which is the half of the plugin actually allowed to hold one.

Q30 (🦋 Customizing). Given the snippet <EntityLayout.Route path="/kubernetes" title="Kubernetes"><EntityKubernetesContent refreshIntervalMs={30000} /></EntityLayout.Route> added inside EntityPage.tsx, what does it accomplish?

• A. Nothing — the snippet is only valid inside App.tsx
• B. It adds a new "Kubernetes" tab to that entity page, rendering the Kubernetes plugin's content, refreshed every 30 seconds
• C. It deletes the entity's existing Overview tab
• D. It registers a new backend route at /api/kubernetes

Check the answer

B. One new EntityLayout.Route block, wired to the right content component — this is what "customizing Backstage" looks like in practice.

Block 4 — Q31–40

Q31 (🦫 Development Workflow, Select TWO). Installing a Backstage plugin that ships as a matched pair typically requires which TWO actions?

• A. yarn workspace app add @backstage/plugin-<name> — installing the frontend half into packages/app
• B. yarn workspace backend add @backstage/plugin-<name>-backend — installing the backend half into packages/backend
• C. Manually editing the PostgreSQL schema before either package is installed
• D. Deleting packages/backend entirely and rebuilding it from scratch
• E. Re-running npx @backstage/create-app@latest a second time

Check the answer

A and B. Most plugins ship as a frontend/backend pair, and both halves need their own install command into their own package — skipping either one is exactly what produces an empty tab.

Q32 (🦋 Customizing). A team confirms both halves of a plugin are installed correctly, but a new tab still doesn't appear on the entity page. What's the most likely remaining cause?

• A. The route was never added into EntityPage.tsx (or the app's top-level routes in App.tsx) — installing a package doesn't wire it up on its own
• B. The catalog database has run out of storage
• C. Yarn silently refuses to install more than two plugins per workspace
• D. TypeScript compilation always fails after a third plugin is added

Check the answer

A. Installing a plugin's packages and actually rendering it are two separate steps — the second one is a manual edit to EntityPage.tsx or App.tsx that nothing does for you automatically.

Q33 (🦉 Infrastructure). A team's catalog.rules in app-config.yaml allows only [Component, API, Resource], omitting Template. What's the resulting symptom?

• A. The backend refuses to start entirely
• B. Golden-path scaffolder templates silently fail to appear in the catalog, even though their YAML exists and is otherwise valid
• C. Every existing Component entity is deleted immediately
• D. The frontend throws a hard error on every page load

Check the answer

B. This is a quiet failure, not a loud one — the templates simply never show up, because the kind that would carry them was never allowed through in the first place.

Q34 (🐿️ Catalog). What are the two annotations Backstage sets on an entity automatically, without a human authoring them by hand?

• A. backstage.io/techdocs-ref and backstage.io/kubernetes-id
• B. backstage.io/managed-by-location (which file produced this entity) and backstage.io/orphan (its parent location is gone)
• C. argocd/app-name and backstage.io/source-location
• D. There are no annotations Backstage ever sets automatically

Check the answer

B. These two are set for you and matter most when debugging — one tells you where an entity came from, the other tells you its source has vanished.

Q35 (🦫 Development Workflow). What's the purpose of running yarn workspace backend start instead of yarn dev?

• A. It runs just the backend half alone, useful for isolating a backend-only issue, and makes the client-server split concrete in practice
• B. It is functionally identical to yarn dev in every respect
• C. It compiles the frontend only, skipping the backend entirely
• D. It is the only command capable of starting the catalog database

Check the answer

A. Running one half at a time is a genuinely useful debugging move — and a good reminder that the two halves really are separate processes, not one monolith.

Q36 (🦋 Customizing). Why does the curriculum call out writing a custom card with inline styles instead of Material UI primitives as a problem, even if it "looks fine" on the developer's own screen?

• A. Inline styles are technically forbidden by the TypeScript compiler
• B. It breaks visual consistency and responsive behavior with the rest of Backstage's component library, which is built entirely on Material UI
• C. Inline styles make a component impossible to test
• D. It has no real consequence — the concern is purely stylistic and doesn't matter for the exam

Check the answer

B. A card that skips the shared primitives doesn't just look different — it stops responding to breakpoints the way every card around it does.

Q37 (🦉 Infrastructure). Which statement best captures "understand the Backstage framework" as a named competency?

• A. Backstage is a product you install and configure, the same way you'd install Cilium or Kyverno
• B. Backstage is a framework, not a product — you scaffold a monorepo with create-app, and from that point on you own its build, database, plugins, and upgrades
• C. Backstage requires no build step of any kind once scaffolded
• D. Backstage's frontend and backend must always run in separate Kubernetes clusters

Check the answer

B. This single fact is what every other domain on this exam derives from — Backstage hands you a codebase, not a values file to override.

Q38 (🐿️ Catalog). An entity's page shows a "processing error" and the entity appears to have stopped refreshing. What's the most likely cause?

• A. A malformed or unreachable catalog-info.yaml
• B. The catalog database has too many entities to process at once
• C. The entity's owner changed teams recently
• D. The frontend's Material UI theme failed to load

Check the answer

A. A broken or unreachable descriptor file is the classic cause of a stuck, erroring entity — troubleshooting starts by checking that file, not the database.

Q39 (🦫 Development Workflow). Does the "Download and install dependencies for a Backstage project with NPM/Yarn" competency cover only the first-time install, or ongoing dependency management too?

• A. Only the very first install, immediately after scaffolding — nothing afterward
• B. Ongoing management as well — adding, removing, and upgrading packages within the workspace over the project's lifetime
• C. It refers exclusively to global npm packages installed outside any workspace
• D. It only applies to the backend package, never the frontend

Check the answer

B. A real portal's dependency graph keeps changing long after day one — this competency is about that whole lifecycle, not a single command run once.

Q40 (🦋 Customizing). Which of the following is a valid job for a backend plugin specifically, not a frontend plugin?

• A. Rendering a tab, card, or page on the entity view
• B. Fetching a third-party API, persisting data, and exposing an /api/<plugin> route
• C. Styling a component with Material UI's Typography
• D. Declaring a new top-level route in App.tsx

Check the answer

B. Anything that needs a credential, persistence, or a call to an external system belongs on the backend — the frontend's job is display, not custody of secrets.

Block 5 — Q41–50

Q41 (🐿️ Catalog). A component entity's spec.owner references group:default/platform-team, but that Group was never ingested into the catalog. What does this produce, and how is it fixed?

• A. A "dangling owner reference" — ownership links go nowhere; fix by ingesting org/group data first so the reference resolves
• B. The component entity is deleted automatically within an hour
• C. Nothing — owner references are purely cosmetic and never validated
• D. The backend refuses to start until the reference is removed

Check the answer

A. The entity itself is fine — it's the link that goes nowhere. Ingesting organizational data (Groups, Users) before or alongside component data is what prevents this.

Q42 (🦋 Customizing, Select TWO). Which TWO of the four official CBA domains combine to make software development — TypeScript, NPM/Yarn, Docker, React, Material UI — a clear majority of the exam's weight?

• A. Customizing Backstage (32%)
• B. Backstage Development Workflow (24%)
• C. Backstage Infrastructure (22%)
• D. Backstage Catalog (22%)
• E. No two domains combined exceed half the exam

Check the answer

A and B. 32% plus 24% is 56% — a clear majority, and both domains name TypeScript, NPM/Yarn, Docker, React, and Material UI explicitly.

Q43 (🦉 Infrastructure). Why is SQLite unacceptable once a whole team, rather than one developer's laptop, depends on the catalog?

• A. SQLite cannot represent YAML-derived data structures at all
• B. SQLite's data doesn't survive a process restart, so a shared team catalog would repeatedly reset to empty, and it isn't built for safe concurrent access from multiple processes
• C. SQLite requires a paid license once more than one engineer connects to it
• D. SQLite is actually the recommended choice for any production Backstage deployment

Check the answer

B. What works fine for one person's local yarn dev session falls apart the moment persistence and concurrent access actually matter.

Q44 (🦫 Development Workflow). Which sequence correctly produces a deployable container image after code passes yarn tsc?

• A. yarn build:all, then yarn build:backend --config ..., then docker image build . -f packages/backend/Dockerfile
• B. docker image build . alone, with no prior build step of any kind
• C. yarn dev, left running indefinitely, which is itself a valid production deployment
• D. npx @backstage/create-app@latest, run a second time against the same directory

Check the answer

A. Compile the whole workspace, produce the backend's production bundle, then containerize it — in that order, from the backend's own Dockerfile.

Q45 (🐿️ Catalog). A "ghost" service still appears on the catalog page even though its source repository was deleted weeks ago. What's the correct fix?

• A. Delete the entity directly through the catalog UI's entity page
• B. Delete the Location that originally created it, via the catalog Locations API — not the entity itself
• C. Restart the whole backend process, which clears all stale entities automatically
• D. Nothing can be done; the entity is permanent once created

Check the answer

B. The entity is downstream of the Location that produced it — remove the source, and the entity that depended on it stops being recreated.

Q46 (🦋 Customizing). What's the functional difference between what App.tsx controls and what EntityPage.tsx controls?

• A. They control identical things and either file can be edited interchangeably
• B. App.tsx declares routes and top-level app structure; EntityPage.tsx decides which tabs and cards appear for a given entity's kind and type specifically
• C. App.tsx is backend-only configuration; EntityPage.tsx is frontend-only configuration
• D. EntityPage.tsx controls the whole app; App.tsx is deprecated and unused in current Backstage versions

Check the answer

B. One is the app's skeleton, the other is what fleshes out a single entity's page — different scopes, both frequently edited.

Q47 (🦉 Infrastructure). Backstage configuration lives in one layered app-config.yaml. How are local and production-specific values typically applied on top of it?

• A. By maintaining two entirely separate, unrelated codebases — one per environment
• B. By stacking local and production override files on top of the base config, with ${ENV_VAR} substitution used throughout for anything environment-specific
• C. By hardcoding every environment's values directly into App.tsx
• D. Backstage does not support environment-specific configuration of any kind

Check the answer

B. Layered config files plus environment-variable substitution is how the same base configuration adapts across local development, staging, and production without duplicating the whole file.

Q48 (🦫 Development Workflow). Why does it matter for exam prep that "Development Workflow" and "Customizing Backstage" are tightly coupled, rather than separate, unrelated topics?

• A. It doesn't matter — the two domains never interact in practice
• B. You can't meaningfully run yarn dev and see your changes without also being able to edit the React and TypeScript it's compiling — the tooling and the code it builds are two sides of one skill
• C. Development Workflow is exclusively about infrastructure and never touches application code
• D. Only one of the two domains is actually tested on the real exam

Check the answer

B. Studying the Yarn commands without also being comfortable editing the TypeScript they build leaves half the picture missing — and vice versa.

Q49 (🐿️ Catalog). Beyond Component, which catalog kinds does the curriculum's "populate catalog" competency name explicitly?

• A. Only Service and Website — Backstage-specific kinds not shared with any other system
• B. API, Resource, System, Domain, Group, User, Location, and Template
• C. Only Kubernetes-native kinds such as Deployment and Pod
• D. There is only ever one valid kind: Component

Check the answer

B. The catalog is a graph of several distinct kinds, not just services — knowing the full set (and that Group/User drive ownership) matters for both populating and troubleshooting it.

Q50 (🦋 Customizing). An operations-minded candidate, strong in Kubernetes and YAML from the rest of this course's shelf, still tends to lose the most points on this specific domain. Why?

• A. Customizing tests React, TypeScript, and Material UI skills that Kubernetes-focused study doesn't build — unlike the catalog's YAML, which resembles the familiar Kubernetes-shaped envelope
• B. Customizing is actually the smallest domain on the exam, so it rarely matters either way
• C. Kubernetes knowledge directly answers most Customizing questions without any additional study
• D. This domain was recently removed from the official curriculum

Check the answer

A. At 32% — the largest single domain — Customizing rewards frontend and TypeScript fluency specifically, a genuinely different skill set from the CRD-and-cluster instincts the rest of this course builds.

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.

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 API, the file, or the command is a real content gap — reread the linked domain page 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. CBA is deliberately narrow — one project, four domains — so most of the deep material lives right here on Golden Astronaut; where the topic is general platform-engineering ground rather than unique to Backstage, the fuller comparison lives on the sibling Platform Engineering CBA page.

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.

Check your answers

1. Customizing Backstage 32%, Backstage Development Workflow 24%, Backstage Infrastructure 22%, Backstage Catalog 22%. Against fifty questions those weights divide with no rounding at all: 16, 12, 11, 11 — which is exactly why fifty was chosen as this paper's size.
2. Customizing Backstage and Backstage Development Workflow, summing to 56% — a clear majority built entirely from TypeScript, NPM/Yarn, Docker, React, and Material UI.
3. Manual registration (a human registers a URL, creating a Location), static locations (URLs under catalog.locations in config), and automated ingestion via entity providers. Only providers remove entities automatically once their source file disappears.
4. Because the entity is downstream of the Location that produced it — deleting the entity directly leaves the Location in place, which will simply recreate it on the next ingestion pass. Removing the Location is what actually stops it.
5. Officially published: the 90-minute duration and the 75% pass mark (from the Linux Foundation's Multiple Choice Exam FAQ). This paper's own choice: the fifty-question count and every specific question — the Linux Foundation does not publish CBA's real question count. Confirm both, and everything else, on the official Linux Foundation CBA page before you register.
6. A content gap is a question you missed because you genuinely didn't know the fact — the fix is rereading the linked page and retrying the question cold later. A confidence problem is a question you missed despite roughly knowing the material, from second-guessing or time pressure — the fix is more timed reps, not more reading, since the knowledge was already there.

That's the full sitting. Reread whichever domain cost you the most, give it a day to settle, then compare this score against Set 1 — if the same domain sagged on both papers, that's the one to fix before you book the real thing.