What is the primary purpose of testing a plugin locally in Backstage?

To verify the plugin functions correctly before deploying it to a shared environment

To automatically deploy the plugin to production

To measure the plugin's performance under heavy load

To generate documentation for the plugin

A developer has written a new Backstage plugin and wants to test it locally before deploying. They want to verify that the plugin's frontend component renders correctly and that its backend API responds as expected. What is the most efficient way to do this?

Run `yarn test` to execute the plugin's unit tests.

Use `curl` to test the backend API directly without starting the app.

Run `yarn build` and then serve the built files.

Run `yarn start` and navigate to the plugin's route in the browser.

Which part of the Backstage development environment typically triggers a full page reload when its code changes?

Frontend code (React components)

Configuration files (app-config.yaml)

Backend code (Node.js services)

A developer is debugging a frontend issue in a Backstage plugin. The plugin's component is not rendering as expected, and they want to inspect the component's props and state at runtime. What tool should they use?

The Backstage CLI's `debug` command.

The browser's developer tools, specifically the React DevTools extension.

A network monitoring tool like Wireshark.

The terminal output from the Backstage dev server.

A developer is debugging an issue where a Backstage plugin behaves differently in local development compared to production. The plugin uses a configuration value that is set in `app-config.production.yaml` but not in `app-config.yaml`. What is the most likely reason for the difference?

The plugin is using a different code path in production.

The plugin has a bug that only appears in production.

The configuration value is not available in local development because it is only defined in the production config.

The production config is loaded locally by default.

Certified Backstage Associate (CBA)

Domain 1Objective 2

Understand Local Development Workflows CBA Practice Questions (Page 3)

Part of the Backstage Development Workflow domain, which accounts for 24% of the CBA exam. Linux Foundation does not publish an official question count, but from its 90-minute exam (~35–60 total, ~8–14 in this domain), expect 2–3 from this objective — we provide 16 practice questions to prepare you well beyond it. (estimate)

16questions here

4free pages

6concepts

24%of the exam

Questions 11–15

11foundation · easy
What is the primary purpose of testing a plugin locally in Backstage?
Select an answer first
12application · medium
A developer has written a new Backstage plugin and wants to test it locally before deploying. They want to verify that the plugin's frontend component renders correctly and that its backend API responds as expected. What is the most efficient way to do this?
Select an answer first
13foundation · easy
Which part of the Backstage development environment typically triggers a full page reload when its code changes?
Select an answer first
14application · medium
A developer is debugging a frontend issue in a Backstage plugin. The plugin's component is not rendering as expected, and they want to inspect the component's props and state at runtime. What tool should they use?
Select an answer first
15expert · hard
A developer is debugging an issue where a Backstage plugin behaves differently in local development compared to production. The plugin uses a configuration value that is set in `app-config.production.yaml` but not in `app-config.yaml`. What is the most likely reason for the difference?
Select an answer first

Finished these 5 questions?

Review the revealed explanations, or continue through the curriculum.

Next 5 questions →Back to CBA

Free Basic Practice is a study aid with revealable answers — not a scored exam. Examers.io is independent and not affiliated with or endorsed by Linux Foundation. “CBA” is a trademark of its owner, used for identification only.