I85PREP
⌘ K
Certified Backstage Associate study materials
Certified Backstage Associate study resources

Certified Backstage Associate practice questions

One question at a time. Build your Certified Backstage Associate understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Backstage Development Workflow

In a Backstage app, which command scaffolds a new frontend plugin package in the default plugins directory?

  1. yarn backstage-cli new --select plugin Correct answer.
  2. yarn create backstage-plugin
  3. yarn workspace create-plugin
  4. yarn backstage-cli plugin:create

Explanation

The Backstage CLI exposes the new command, and passing --select plugin generates a frontend plugin package under plugins/ using the built-in template. The generated package includes package.json, src/, and dev/ entries wired to the app. Other forms are not valid CLI invocations in the standard Backstage repo tooling.

Question 2Backstage Development Workflow

A developer runs yarn start in the root of a Backstage app. What does this primarily launch?

  1. The backend service only
  2. The plugin unit test watcher
  3. The frontend app dev server with hot reload Correct answer.
  4. A one-off production build of all packages

Explanation

In the default app package, yarn start runs the Backstage CLI start command, which serves the frontend app in development mode with hot module reloading. It does not build for production or run tests. The backend is started separately, typically with yarn start-backend.

Question 3Backstage Development Workflow

Which file in a Backstage frontend plugin declares the plugin's exported plugin object created with createPlugin?

  1. dev/index.ts
  2. package.json
  3. src/plugin.ts Correct answer.
  4. src/index.ts

Explanation

The conventional location for the createPlugin call is src/plugin.ts, which exports the plugin instance that the app imports and registers. src/index.ts typically re-exports the plugin and its components for consumers. The dev entry is only for standalone local development.

Question 4Backstage Development Workflow

A plugin needs to expose a page component to the app. Which export pattern allows the app to import the component from the plugin package root?

  1. Declare it in the app-config.yaml
  2. Register it in the catalog-info.yaml
  3. Add it to the plugin's package.json main field only
  4. Export the component from src/index.ts Correct answer.

Explanation

Consumers import from the package root, so public components must be re-exported through src/index.ts. The package main field points to compiled output, not a place to enumerate components. app-config.yaml and catalog-info.yaml hold configuration and catalog metadata, not JavaScript exports.

Question 5Backstage Development Workflow

Which command runs the unit tests for a single plugin package in watch mode during local development?

  1. yarn backstage-cli package test Correct answer.
  2. yarn lint --watch
  3. yarn backstage-cli package build --watch
  4. yarn tsc --watch

Explanation

The Backstage CLI package test command wraps Jest and runs in watch mode by default for interactive development. It discovers test files within the package and reports results per workspace. TypeScript compilation and linting are separate commands.

Question 6Backstage Development Workflow

What is the purpose of the app-config.yaml file at the root of a Backstage app?

  1. It defines the plugin's TypeScript compiler options
  2. It provides static configuration consumed by frontend and backend at startup Correct answer.
  3. It stores the React component tree
  4. It lists npm dependencies for the workspace

Explanation

app-config.yaml is the primary static configuration source, read at startup and merged with environment-specific config files. It holds settings such as integrations, catalog locations, and auth providers. It is not a code or dependency manifest.

Question 7Backstage Development Workflow

A developer wants a local config override that is not committed to version control. Which file does Backstage read for that purpose by default?

  1. app-config.test.yaml
  2. app-config.local.yaml Correct answer.
  3. app-config.secrets.yaml
  4. app-config.production.yaml

Explanation

Backstage merges app-config.local.yaml over the base config when it exists, and the default .gitignore excludes it, making it suitable for local-only overrides. Production and test variants are for those environments. secrets is not a recognized default filename.

Question 8Backstage Development Workflow

Which CLI subcommand generates API documentation for a plugin package in Backstage?

  1. yarn backstage-cli repo test
  2. yarn backstage-cli repo build Correct answer.
  3. yarn backstage-cli package build
  4. yarn backstage-cli package lint

Explanation

The repo build command runs builds across the monorepo and includes API report generation for packages that use api-extractor. It produces the api-report markdown used to track public API changes. package build builds a single package without the repo-wide API report step.

Question 9Backstage Development Workflow

When a plugin's public API changes, the API report check fails in CI. What is the expected developer action in Backstage?

  1. Add the change to a CHANGELOG without regenerating
  2. Regenerate the report and commit the updated file with the change Correct answer.
  3. Delete the api-report file and disable the check
  4. Mark the package private to skip the check

Explanation

Backstage tracks public API surface with api-extractor reports, so an intentional API change requires regenerating the report and committing it alongside the code. This keeps reviewers aware of breaking or additive changes. Deleting or bypassing the report removes that safeguard.

Question 10Backstage Development Workflow

A plugin must read a configuration value at runtime in the frontend. Which API does Backstage provide for this?

  1. createPlugin directly
  2. configApiRef from @backstage/core-plugin-api Correct answer.
  3. the catalogApiRef
  4. the window.config global object

Explanation

The frontend reads configuration through the configApiRef utility API, which exposes methods like getString and getOptionalString. This keeps config access consistent and testable via the app's API provider. Global window objects and unrelated refs are not the intended mechanism.

Question 11Backstage Development Workflow

Which Backstage CLI flag limits test execution to files matching a pattern when running package tests?

  1. --testPathPattern Correct answer.
  2. --match
  3. --filter
  4. --only

Explanation

The package test command passes arguments through to Jest, and Jest uses --testPathPattern to restrict which test files run. This is useful when iterating on a subset of tests. The other flags are not Jest options for path filtering.

Question 12Backstage Development Workflow

A developer wants to run a plugin in isolation with its own dev page. Which directory convention does the Backstage CLI use for this?

  1. dev/ Correct answer.
  2. test/
  3. src/dev
  4. standalone/

Explanation

Plugins created by the CLI include a dev/ directory with an index.tsx that mounts the plugin in a minimal app for standalone development. Running the package start script serves that dev page. The other directory names are not the CLI convention for this purpose.

Question 13Backstage Development Workflow

Which command validates that the workspace dependency graph and package manifests are consistent across a Backstage monorepo?

  1. yarn backstage-cli versions:bump
  2. yarn backstage-cli repo clean
  3. yarn backstage-cli repo lint Correct answer.
  4. yarn backstage-cli repo list-deprecations

Explanation

repo lint runs consistency checks across the monorepo, including package manifest and dependency validation, alongside code linting. It catches mismatches that a single-package lint would miss. The other commands handle deprecation listing, cleaning, and version bumps.

Question 14Backstage Development Workflow

A developer adds a new dependency to a plugin package. Which step keeps the monorepo lockfile consistent?

  1. Delete node_modules and commit it
  2. Run yarn install at the workspace root Correct answer.
  3. Run yarn backstage-cli package build
  4. Edit package.json manually and skip installing

Explanation

Backstage apps use Yarn workspaces, so dependency changes must be resolved by running yarn install at the root to update the shared lockfile. Committing the updated lockfile keeps installs reproducible. Building or removing node_modules does not update the lockfile correctly.

Question 15Backstage Development Workflow

Which Backstage API reference is used to obtain the current route resolution for navigating between plugin pages?

  1. discoveryApiRef
  2. storageApiRef
  3. routeRef and useRouteRef Correct answer.
  4. identityApiRef

Explanation

Route refs declare navigable locations, and useRouteRef resolves a route ref into a concrete path within the app. This decouples plugins from hardcoded URLs. The other refs provide identity, service discovery, and storage functionality.

Question 16Backstage Development Workflow

A plugin needs to call a backend endpoint exposed by another plugin. Which mechanism should the frontend use to build the request URL?

  1. Hardcode localhost:7007 with the path
  2. Read the URL from a global constant in the plugin
  3. Use discoveryApiRef to resolve the backend base URL Correct answer.
  4. Use the catalogApiRef entity address

Explanation

The discovery API resolves the base URL of a backend plugin by its plugin ID, so frontend code should combine that with the route path. Hardcoding the host breaks across environments. The catalog and global constants do not provide service discovery.

Question 17Backstage Development Workflow

Which file must be updated so a newly created plugin is discoverable by the Backstage app's package workspace?

  1. tsconfig.json only
  2. The root package.json workspaces field if the plugin lives outside default globs Correct answer.
  3. The plugin's README
  4. app-config.yaml

Explanation

Yarn workspaces discover packages through the workspaces globs in the root package.json, so a plugin placed outside those globs must be added there. The CLI template normally places plugins under plugins/, which is already covered. Config, tsconfig, and README files do not control workspace discovery.

Question 18Backstage Development Workflow

A developer wants type checking across the whole repo without emitting JavaScript. Which command is appropriate?

  1. yarn backstage-cli repo start
  2. yarn tsc --noEmit Correct answer.
  3. yarn backstage-cli repo test
  4. yarn backstage-cli package build

Explanation

Running the TypeScript compiler with --noEmit performs a full type check and produces no output files, which is useful in CI. The Backstage build and test commands do other work and may not surface all type errors the same way. repo start launches development servers.

Question 19Backstage Development Workflow

When creating a backend plugin, which export from the plugin package is registered with the backend system?

  1. A route ref
  2. A catalog entity descriptor
  3. A backend plugin instance created with createBackendPlugin Correct answer.
  4. A React component

Explanation

Backend plugins export an instance created with createBackendPlugin, which the backend system registers and initializes. This differs from frontend plugins, which export React-based plugin objects. Route refs and catalog descriptors serve different layers.

Question 20Backstage Development Workflow

A developer needs to add a new route to an existing frontend plugin and wants the path to be resolvable by other plugins. What should be created and exported?

  1. A new createPlugin call
  2. A route ref exported from the plugin package Correct answer.
  3. A new app-config key
  4. A backend service factory

Explanation

A route ref represents a navigable location and can be exported so other plugins resolve it with useRouteRef instead of hardcoding paths. The plugin is bound to route refs through its createPlugin routes configuration. Config keys and backend factories do not provide frontend route resolution.

Question 21Backstage Development Workflow

A plugin test fails because it calls useApi without a provider. What is the recommended fix in a Backstage test?

  1. Replace useApi with a direct import of the API implementation
  2. Disable the failing test
  3. Wrap the component in TestApiProvider with the required API refs Correct answer.
  4. Mock the hook with jest.mock for every test

Explanation

Backstage provides TestApiProvider from its test utilities, which supplies API implementations to the React tree during tests. Wrapping the component with the needed refs resolves the missing provider error while keeping the real hook behavior. Mocking the hook or importing implementations directly bypasses the intended DI pattern.

Question 22Backstage Development Workflow

A developer notices the app uses a different config value in production than locally despite identical app-config.yaml. Which explanation best fits Backstage's config loading?

  1. Yarn workspaces rewrite config at install time
  2. Production ignores app-config.yaml entirely
  3. Environment-specific config files and environment variables are merged over the base config Correct answer.
  4. The frontend caches the config from the first build

Explanation

Backstage merges configuration from multiple sources, including environment-specific YAML files and environment variable overrides, on top of the base app-config.yaml. This layering explains differing values across environments. The base file is not ignored, and neither builds nor installs rewrite configuration.

Question 23Backstage Development Workflow

A monorepo build fails only in CI with an API report mismatch, while local builds pass. Which cause is most likely?

  1. The CI runner lacks node_modules
  2. The updated api-report file was generated locally but not committed Correct answer.
  3. CI uses a different Node version that changes the API surface
  4. The plugin has no README

Explanation

The API report check compares the committed report against the freshly generated one, so a local pass with a CI failure usually means the regenerated report was never committed. The report file is the artifact under comparison. Node version differences and missing docs do not produce this specific mismatch.

Question 24Backstage Development Workflow

A team wants a plugin's dev page to render with realistic catalog data. Which approach fits Backstage's development workflow?

  1. Point the dev app's API factory at a mock catalog client Correct answer.
  2. Commit production catalog data into the plugin source
  3. Disable the catalog API in the dev harness
  4. Hardcode entity data inside the component render

Explanation

The dev harness can supply custom API implementations, so a mock catalog client provides realistic data without touching production services. This keeps test data out of the plugin source and preserves the DI pattern. Disabling the API or hardcoding data inside render breaks the component's contract.

Question 25Backstage Development Workflow

Which command creates a new backend plugin package using the Backstage CLI?

  1. yarn backstage-cli new --select backend-plugin Correct answer.
  2. yarn backstage-cli new --select plugin
  3. yarn backstage-cli backend:create
  4. yarn create backend-plugin

Explanation

The new command accepts a --select value that chooses the template, and backend-plugin is the template for a backend plugin package. The plain plugin template produces a frontend plugin. The other invocations are not valid CLI forms.

Question 26Backstage Development Workflow

In a Backstage monorepo, which directory is the standard location for the frontend plugin packages created by the CLI?

  1. packages/
  2. plugins/ Correct answer.
  3. src/plugins/
  4. apps/

Explanation

The Backstage CLI scaffolds frontend and backend plugins into the top-level plugins/ directory, while the app itself lives under packages/app and the backend under packages/backend. Keeping plugins in plugins/ lets the workspace tooling and the app's package imports resolve them consistently.

Question 27Backstage Development Workflow

A developer runs `yarn backstage-cli repo start` at the root of a Backstage workspace. What does this command do?

  1. It starts the app and backend together in a single dev session. Correct answer.
  2. It runs the unit tests for every package in watch mode.
  3. It builds production bundles for the app and backend.
  4. It regenerates the API reports for all plugin packages.

Explanation

`repo start` is the workspace-level dev command that launches both the frontend app and the backend package with a shared configuration, so developers can exercise real plugin-to-backend traffic locally. It is a development server, not a test, build, or API-report command.

Question 28Backstage Development Workflow

Which behavior distinguishes `yarn backstage-cli package test` from running Jest directly in a plugin package?

  1. It applies the Backstage Jest preset, including the jsdom environment and module mocks. Correct answer.
  2. It only runs tests that have been explicitly tagged for CI.
  3. It runs each test file in a separate Node process for isolation.
  4. It skips type checking and transpiles with the TypeScript compiler API.

Explanation

The Backstage CLI wraps Jest with a preset that configures the test environment, transforms, and common mocks expected by Backstage packages. Running Jest bare would miss that preset and could fail on imports that rely on it.

Question 29Backstage Development Workflow

A developer wants to check a single plugin's code for lint violations using the Backstage CLI. Which invocation is appropriate when run from the workspace root?

  1. yarn backstage-cli package lint Correct answer.
  2. yarn backstage-cli plugin lint
  3. yarn backstage-cli repo lint
  4. yarn backstage-cli lint --all

Explanation

`package lint` runs the linter within the current package, so it is invoked from the plugin directory (or via a workspace filter) to scope checks to that plugin. The workspace-wide variant is `repo lint`, which lints every package.

Question 30Backstage Development Workflow

When the Backstage CLI scaffolds a new frontend plugin, what is the purpose of the generated `dev/index.tsx` file?

  1. It registers the plugin's routes into the main app router.
  2. It defines the plugin's exported extension points for consumers.
  3. It provides a standalone entry point that renders the plugin in a dev harness. Correct answer.
  4. It configures the plugin's backend proxy settings for local development.

Explanation

The dev entry point lets a developer run the plugin on its own with `yarn start` inside the package, rendering it in a minimal harness instead of the full app. This shortens the feedback loop when iterating on a single plugin.

Question 31Backstage Development Workflow

A developer edits a shared package under `packages/` that a plugin imports. Local type checks pass, but the plugin's tests fail to resolve the new export. Which action most likely resolves the issue?

  1. Disable the plugin's Jest preset so it stops resolving workspace packages.
  2. Delete the plugin's node_modules directory and reinstall.
  3. Rebuild the shared package so its declaration output reflects the new export. Correct answer.
  4. Add the export to the plugin's API report manually.

Explanation

Workspace packages are consumed through their built declaration output, so a new export is invisible until the shared package is rebuilt. Reinstalling or editing reports does not regenerate the type declarations that the consuming plugin resolves.

Question 32Backstage Development Workflow

Which file in a scaffolded Backstage plugin package declares the package name, version, and its dependency on `@backstage/core-plugin-api`?

  1. api-report.md
  2. catalog-info.yaml
  3. tsconfig.json
  4. package.json Correct answer.

Explanation

`package.json` holds the package identity, scripts, and dependency ranges that the workspace uses for resolution. The other files describe catalog metadata, compiler settings, or the public API surface rather than dependencies.

Question 33Backstage Development Workflow

A developer adds a new exported React component to a plugin. What must be done for the API report check to pass in CI?

  1. Remove the component from the plugin's index export list.
  2. Increment the plugin's major version in package.json.
  3. Add the component to the plugin's dev harness entry point.
  4. Run the API report command to update the committed report file. Correct answer.

Explanation

The API report is a committed snapshot of the package's public surface, so any intentional export change requires regenerating and committing that report. Version bumps and dev harness edits do not alter the report contents.

Question 34Backstage Development Workflow

Which command should a developer run to type-check the entire Backstage workspace without producing JavaScript output?

  1. yarn backstage-cli repo test
  2. yarn backstage-cli repo build
  3. yarn backstage-cli package build
  4. yarn tsc --noEmit Correct answer.

Explanation

Running the TypeScript compiler with `--noEmit` performs type checking only and writes no output files. Build commands emit bundles, and the test command executes tests rather than a workspace-wide type check.

Question 35Backstage Development Workflow

A developer wants to run only the tests in a plugin package that match a filename pattern. Which approach uses the Backstage CLI correctly?

  1. yarn backstage-cli package test --testPathPattern <pattern> Correct answer.
  2. yarn backstage-cli repo test <pattern>
  3. yarn backstage-cli package test --coverage=false
  4. yarn backstage-cli package test --watchAll=false

Explanation

`package test` forwards Jest options, and `--testPathPattern` filters which test files run by path. The other flags control watch mode or coverage but do not filter by filename.

Question 36Backstage Development Workflow

A new plugin package is created but the app cannot resolve it. Which change makes the plugin a member of the workspace so it can be imported?

  1. Add the plugin name to the backend's plugin list.
  2. Add the plugin path to the app's tsconfig include list.
  3. Add the plugin to the workspaces globs in the root package.json. Correct answer.
  4. Register the plugin in the app's catalog-info.yaml.

Explanation

The root `package.json` workspaces globs determine which directories are linked as workspace packages. A plugin outside those globs is not installed or linked, so imports cannot resolve regardless of TypeScript or catalog settings.

Question 37Backstage Development Workflow

What is the role of the `catalog-info.yaml` file generated alongside a new Backstage plugin?

  1. It declares the plugin as a software component entity for the Backstage catalog. Correct answer.
  2. It defines the plugin's route references for other plugins to consume.
  3. It lists the plugin's npm dependencies for the workspace resolver.
  4. It configures the plugin's runtime settings for each environment.

Explanation

The generated catalog descriptor registers the plugin as a component in the software catalog, including ownership and metadata. Runtime configuration, dependencies, and route references are handled elsewhere.

Question 38Backstage Development Workflow

A developer wants to verify that a plugin's public exports have not changed unexpectedly before pushing. Which local check best mirrors the CI API report verification?

  1. Run the linter and review warnings about unused exports.
  2. Run the plugin's dev harness and inspect the rendered output.
  3. Run the API report command and inspect the resulting diff. Correct answer.
  4. Run the workspace build and check for emitted bundle size changes.

Explanation

Regenerating the API report locally produces a diff against the committed snapshot, which is exactly what CI compares. Visual inspection, bundle sizes, and lint warnings do not capture public API surface changes.

Question 39Backstage Development Workflow

Which statement best describes how the Backstage CLI treats the `plugins/` and `packages/` directories during a workspace build?

  1. Only packages/ is built; plugins/ is consumed as source at runtime.
  2. Only plugins/ is built; packages/ is resolved from the npm registry.
  3. Both are workspace packages and are built according to their own build scripts. Correct answer.
  4. Neither is built; the app bundles all sources directly at startup.

Explanation

Both directories contain workspace packages, each with its own scripts and build output, and the workspace tooling runs those builds. Neither directory is special-cased as source-only or registry-resolved.

Question 40Backstage Development Workflow

A developer needs to add a new backend feature module and have it load when the backend starts. Where is the module registered?

  1. In the frontend app's route configuration.
  2. In the backend package's source where the backend instance is created. Correct answer.
  3. In the root package.json workspaces list.
  4. In the plugin's dev harness entry point.

Explanation

Backend features are added to the backend instance at the point where it is constructed, typically in the backend package's entry source. The dev harness, workspace globs, and frontend routes do not control backend feature loading.

Question 41Backstage Development Workflow

Which command creates a new backend plugin package in a Backstage workspace?

  1. yarn backstage-cli new --select backend-plugin Correct answer.
  2. yarn backstage-cli plugin create --backend
  3. yarn backstage-cli package create backend
  4. yarn backstage-cli repo new-backend

Explanation

`backstage-cli new` is the scaffolding entry point, and the `--select` option chooses the template, such as the backend plugin template. The other forms are not Backstage CLI subcommands.

Question 42Backstage Development Workflow

A developer wants the app to load a plugin's page at a stable route that other plugins can reference. What should be defined in the plugin's source?

  1. A route reference created with the plugin's route reference API and exported. Correct answer.
  2. A backend proxy entry mapping the path to the plugin.
  3. A catalog annotation containing the URL path.
  4. A hardcoded string path exported from the app package.

Explanation

Backstage route references are created and exported by the plugin so consumers resolve paths through the reference rather than duplicating strings. Hardcoded app paths, catalog annotations, and proxy entries do not provide a shared, typed route reference.

Question 43Backstage Development Workflow

A plugin test renders a component that calls `useApi` and throws because no API implementation is available. Which fix aligns with Backstage testing practice?

  1. Mock the module that exports useApi to return a stub value.
  2. Replace useApi with a direct import of the API implementation.
  3. Disable the test environment's strict mode so the error is ignored.
  4. Wrap the rendered component in a test API provider that supplies the required API. Correct answer.

Explanation

Backstage provides a test API provider that supplies API implementations to the React tree, matching how the real app injects them. Mocking the hook module or importing implementations directly bypasses the dependency injection contract the component relies on.

Question 44Backstage Development Workflow

A developer runs the app locally and sees configuration values from a file that is not committed to version control. Which mechanism explains this?

  1. The app reads environment variables only and ignores YAML files.
  2. The app falls back to defaults defined in the plugin source.
  3. The app loads configuration from the software catalog entities.
  4. The app merges app-config.local.yaml over the base configuration. Correct answer.

Explanation

Backstage merges a local override file on top of the base app configuration during local development, which is why uncommitted values appear. Environment variables and catalog entities are separate configuration sources, and source defaults do not explain file-based overrides.

Question 45Backstage Development Workflow

A developer wants to confirm which configuration keys a plugin actually reads at runtime. Which approach is most reliable?

  1. Assume the keys match the plugin's catalog-info.yaml annotations.
  2. Search the plugin source for calls to the config API and inspect the keys used. Correct answer.
  3. Check the plugin's API report for configuration key names.
  4. Read the app's route configuration for the plugin's path.

Explanation

Configuration keys are read through the config API in source, so searching for those calls reveals the actual keys and their expected shapes. Catalog annotations, routes, and API reports do not enumerate configuration keys.

Question 46Backstage Development Workflow

What does the Backstage CLI's `package build` command produce for a frontend plugin?

  1. A development server with hot reload enabled.
  2. Compiled output and type declarations suitable for consumption by the app. Correct answer.
  3. An updated API report reflecting the plugin's exports.
  4. A Docker image containing the plugin and its dependencies.

Explanation

`package build` compiles the package into distributable output, including declarations, which consuming packages resolve. It does not start a dev server, produce container images, or update API reports.

Question 47Backstage Development Workflow

A CI job fails at the API report step only after a developer merged a branch that changed a shared type. What is the most likely explanation?

  1. The CI runner has a stale cache of the plugin's source files.
  2. The plugin's package.json version was not incremented.
  3. The shared type change altered the plugin's public surface without a report update. Correct answer.
  4. The plugin's dev harness was not rebuilt before the check.

Explanation

When a shared type used in a plugin's exported signatures changes, the plugin's public API surface changes and its committed report no longer matches. Caches, version bumps, and dev harness builds do not affect the report comparison.

Question 48Backstage Development Workflow

A developer needs to run the frontend app against a locally running backend while iterating. Which approach fits the Backstage development workflow?

  1. Deploy the backend to a staging cluster for every local change.
  2. Build production bundles and serve them from a static file server.
  3. Run only the plugin's dev harness and stub all backend calls.
  4. Start the app and backend together with the workspace dev command. Correct answer.

Explanation

The workspace dev command starts the app and backend together so local changes exercise real request paths. Production bundles, stubbed harnesses, and remote deployments do not give the tight local feedback loop the workflow is designed for.

Question 49Backstage Infrastructure

In a Backstage deployment, which component is responsible for serving the frontend single-page application and proxying requests to the backend plugin host?

  1. The `@backstage/plugin-app-backend` plugin Correct answer.
  2. The `@backstage/app-defaults` package
  3. The `@backstage/backend-common` library
  4. The `@backstage/plugin-catalog-backend` module

Explanation

The app-backend plugin serves the compiled frontend static assets and forwards API calls to the backend host, which is why it must be registered in the backend entry point. The catalog backend and backend-common are libraries and plugins that provide catalog data and shared server utilities, not static asset serving. app-defaults only supplies frontend defaults.

Question 50Backstage Infrastructure

A team wants to add a new backend plugin to their Backstage instance. Where must the plugin's router be registered so its routes become reachable under the backend base URL?

  1. In the plugin's own `package.json` under a `backstage.routes` field
  2. In the frontend `packages/app/src/App.tsx` route definitions
  3. In the `packages/backend/src/index.ts` file, typically via `backend.add()` or the legacy `apiRouter.use()` pattern Correct answer.
  4. In the `app-config.yaml` under a `backend.routers` list

Explanation

Backend plugins are wired into the backend service in the backend entry point, either through the new backend system's `backend.add()` calls or the legacy `apiRouter.use()` composition. Configuration files and package.json do not register HTTP routers, and the frontend App.tsx only defines client-side routes.