Certified Backstage Associate (CBA): Complete Study Guide

CBA exam facts and exact practice distribution

The Certified Backstage Associate credential validates a beginner foundation in the Backstage developer-portal framework. The Linux Foundation emphasizes standardized developer platforms, productivity, onboarding, collaboration, and the ability to work with Backstage. The product page lists an online, proctored, multiple-choice exam with 60 questions in 90 minutes. It lists Beginner experience level, two attempts, 12-month exam eligibility, and two-year certification validity. Purchase conditions can change, so use the official page for decisions.

The public blueprint has four domains. PrepKloud converts the percentages into an exact 50-question distribution:

This allocation is exact: $12+11+11+16=50$. Each question has four options, a zero-based answer array, a detailed explanation, and an official HTTPS reference.

What Backstage is

Backstage is an open source framework for building developer portals. It does not arrive as a complete representation of an organization. An adopter builds an App: a deployed instance that wires core capabilities, plugins, integrations, configuration, identity, and design choices into a consistent experience.

Out of the box, Backstage includes a Software Catalog for software and ownership metadata, Software Templates for standardized creation, TechDocs for documentation as code, and a plugin ecosystem. The value is not simply placing links on one page. Catalog entities provide context around which plugins can organize CI, monitoring, Kubernetes, documentation, APIs, and other tools.

Keep three terms distinct. Core is the base functionality maintained by the project. App is an organization's integrated instance. Plugins provide features that the app composes. This separation explains why organization-specific work should usually live in app integration, extensions, modules, services, themes, and configuration—not in a permanent fork of core.

Domain 1: development workflow

The official standalone guide starts with a Unix-like environment or WSL, current supported Node.js and Yarn, a GNU-like build environment, Git, Docker, and documented disk and memory capacity. It uses npx @backstage/create-app@latest to generate a new application. Record the version actually selected; “latest” is time-dependent and cannot make an old build reproducible by itself.

The generated root contains app-config.yaml, catalog-info.yaml, package.json, and Yarn workspaces. packages/app is the frontend entry point. packages/backend powers backend features. The root package coordinates the monorepo, but ordinary dependencies should normally be installed in the workspace that consumes them. This preserves package boundaries and prevents accidental availability caused by hoisting.

Dependency installation and TypeScript compilation answer different questions. A successful install means package resolution completed; yarn tsc or the project's corresponding check validates type contracts. Tests verify behavior. Linting checks source conventions and selected correctness rules. A build produces deployment artifacts. A local start proves runtime initialization. Do not substitute one green signal for all of them.

The generated yarn start workflow launches frontend and backend local-development processes. If the browser does not open, the official guide points to localhost port 3000. When a page fails, correlate browser console and network calls with backend request and plugin logs. That boundary-oriented approach distinguishes a React rendering problem, missing route, backend 404, authentication failure, configuration error, and database outage.

Dependency discipline

Backstage is a large TypeScript package ecosystem. Review package and lockfile changes together. Peer-dependency warnings can reveal incompatible framework, app, or plugin versions. Resolve them against current Backstage compatibility and versioning guidance instead of suppressing all warnings. Avoid editing node_modules: the next install replaces it and no reviewer can reconstruct the change.

Container builds

Backstage supplies Docker build guidance, but a secure build remains the adopter's responsibility. Restrict the context with .dockerignore. Do not copy Git history, caches, local config, cloud credentials, package-manager tokens, or development databases. Build required bundles, copy only runtime artifacts, use external runtime configuration, and run without root where the supported image pattern allows. Inspect the resulting filesystem and layers using dummy canaries.

Domain 2: infrastructure and configuration

The high-level runtime architecture has a frontend, one or more backends, and databases. The frontend presents core and plugin experiences to the user. The backend wires plugins, core services, and HTTP APIs. Databases store plugin data. Built-in backend plugins use logical database separation so schemas and migrations can evolve with reduced coupling.

Backstage's default standalone installation uses in-memory SQLite and demo content. The documentation explicitly says this is not production-ready. The architecture guide identifies PostgreSQL as the preferred production database. A production plan also needs scoped credentials, backups, restoration, migration behavior, connection management, availability, monitoring, and controlled deletion.

Configuration layering and visibility

Static configuration uses app-config.yaml as the required base by default and app-config.local.yaml as an optional local layer. BACKSTAGE_ENV can select one or more environment layers. Command-line config flags can load other files. Environment and file substitutions can inject values. Understand the documented order rather than guessing which value wins.

Configuration is shared conceptually, but not all values are sent to the frontend. Plugin schemas use a visibility keyword to select keys available to browser code; backend is the default. Anything sent to the frontend must be considered public to an authenticated user who can inspect source, runtime objects, or network traffic. Never place database passwords, OAuth client secrets, API tokens, or private keys in frontend-visible configuration.

Packages and plugins contribute configuration schemas that are combined. Use backstage-cli config:check to validate effective settings. A clean YAML parse does not prove keys are recognized, correctly typed, or safely visible.

Deployment

Backstage can be deployed in many ways. The official deployment overview recommends using the organization's established software-delivery pattern and illustrates building an image, storing it in a registry, referencing it in a Kubernetes Deployment, and applying it. The principle matters more than the substrate: immutable artifact, external environment config, secret management, health checks, logs, rollback, database lifecycle, and ownership.

Backend architecture can be one deployment or several. Backend plugins operate independently, and plugins separated into different processes communicate over the wire. Splitting introduces routing, authentication, authorization, service identity, observability, database, and failure-mode decisions. It is not automatically superior to a well-operated monolith.

Domain 3: Software Catalog

The Software Catalog tracks ownership and metadata for software such as services, websites, libraries, data pipelines, and ML models. Its common model expects owner-maintained YAML near source code, ingested and presented through the catalog. Backstage is not meant to replace Git as the metadata editing workflow.

Entity shape and model

The common envelope contains apiVersion, kind, metadata, and a kind-specific spec where applicable. Metadata.name is the machine reference name; title is an optional display value. Namespace bounds name uniqueness and defaults to default. Labels classify as key-value data. Tags are single values. Links are human-facing contextual URLs. Annotations often reference external systems and may drive plugins.

A Component requires type, lifecycle, and owner. Components can provide or consume APIs, depend on Resources or Components, and belong to Systems. APIs are first-class interfaces. Resources represent infrastructure. Systems group related components and resources; Domains group systems into bounded business contexts. Users and Groups model organizational structure. Location points to other catalog data. Template describes a scaffolding workflow.

Catalog ownership is descriptive. The official descriptor guidance warns against using spec.owner to assign runtime authorization. A team shown as owner is a discoverability and accountability signal, not proof that a person currently holds a role in a production system.

Do not author relations or status in input descriptors. Processors derive relations from declarations and context. Status reports processed output such as catalog errors. Consumers should use final relations returned by the catalog API. Use string entity references; metadata.uid can change when an entity is unregistered and registered again.

Adding and updating entities

Users can manually register a full source-control URL to YAML. Static app configuration can register locations. Software Templates can create and register software. External integrations can synchronize larger authoritative sources. Teams update owner-maintained YAML through normal Git review, and the catalog refreshes from that source.

The life of an entity

Ingestion begins with entity providers, which own buckets of raw entities and issue additions, updates, and removals. Processing applies policies and processors, potentially changing data and emitting children, errors, and relations. Stitching combines processed entity bodies, relations, and errors into final API-visible output and updates filtering data.

An entity provider is the common pattern for a scheduled or event-driven external source. A processor is appropriate for reading custom location types, enriching or validating entities, or emitting child entities. Incremental providers handle data sources too large for one in-memory fetch.

Errors can be asynchronous. A registered file may disappear later or become invalid. Inspect catalog backend events, entity status, logs, and unprocessed-entity capabilities. When a processing parent stops emitting a child and nothing else maintains it, the child can become orphaned and receive an annotation. Provider deletions have eager graph effects. Explicitly deleting an entity maintained by a parent may only make it reappear.

Domain 4: customizing Backstage

Customizing Backstage is the largest domain at 32%. Learn the modern frontend and backend systems and recognize that older plugin documentation is marked legacy. Existing apps may contain legacy patterns, but new work should begin with current guidance.

Frontend composition

The app instance wires the frontend. Extensions are visual and nonvisual building blocks attached into an extension tree. Plugins contribute features and extensions. Extension overrides can replace or augment existing extensions without modifying their package. Utility APIs define typed shared capabilities whose implementation can be supplied by the app. Route references let plugins link without hard-coding concrete paths; app route bindings resolve the composition.

Frontend work uses TypeScript and React, along with supported Backstage design patterns and Material UI components appropriate to the app version. A component is not complete because its happy path renders. Explicitly model loading, empty, error, denied, stale, timeout, and success states. Validate headings, labels, semantic controls, keyboard access, focus, contrast, zoom, responsive layout, and reduced motion.

Backend plugins, services, modules, and extension points

A backend instance is a deployment unit that wires plugins. Backend plugins supply server-side features. Core services provide logging, configuration, database, HTTP routing, identity, and other shared capabilities. Services are also customization points. Extension points expose plugin-specific contracts. Modules use those extension points to add a feature—such as a catalog entity provider—to one plugin and are deployed in the same backend instance.

Avoid direct imports from another plugin's internal implementation. Use supported public libraries, routes, services, extension points, or network APIs. This preserves plugin evolution and upgradeability. If a frontend needs a private third-party credential, mediate the request through an authenticated backend plugin or carefully configured backend proxy. A browser bundle cannot keep a secret.

Catalog-aware customization

Many plugins become valuable in entity context. A component page can show CI, monitoring, Kubernetes, or service health based on annotations and stable entity references. Handle missing annotation, unsupported kind, denied permission, stale data, and backend outage explicitly. Do not infer external authorization from catalog owner alone.

Three projects that join the domains

The CBA project collection begins with a development-to-deployment baseline: create a current app, map workspaces, compile TypeScript, layer configuration, use PostgreSQL, build a minimal non-root image, add health and bounded logs, inject six failures, measure, and tear down.

The second project models a synthetic organization with Groups, Users, Domains, Systems, Components, APIs, Resources, and Locations. It uses manual, static, and provider ingestion, traces processing and stitching, exercises orphan and deletion behavior, and diagnoses malformed, missing, duplicate, reference, policy, and orphan failures.

The third project creates a catalog-aware service-health feature. A frontend extension uses React and route references. An authenticated backend plugin keeps a dummy token server-side. A module registers a provider through an extension point. App composition adds bindings and a theme override. Tests cover permission, accessibility, stale data, routing, config, malformed response, timeout, backend outage, and dependency compatibility.

A six-week blueprint-weighted plan

Weight time toward customization while retaining the architecture that makes it understandable. Complete the 50 original questions under a 90-minute timer, then explain why each distractor belongs to another layer. Use the 40 flashcards for spaced recall, not as a substitute for building.

Multiple-choice reasoning strategy

First classify the layer: package workflow, browser frontend, backend plugin, service, database, static config, catalog source, provider, processor, stitcher, or app integration. Second identify ownership: does the app wire it, does a plugin expose it, does a module extend it, or does a source own the entity? Third identify visibility: browser-visible, backend-only, database-persisted, or source-controlled. Many distractors become clearly wrong when the layer, owner, or visibility is inconsistent.

For catalog scenarios, trace source → provider/location → processing → relations/errors → stitching → API/UI. For customization, trace plugin public contract → app extension or module → route/service/config → runtime state. For deployment, trace source → TypeScript and tests → build context → image → runtime configuration → backend → database.

Watch absolute language. Backstage does not automatically make local SQLite production-ready, catalog owner an authorization grant, browser config secret, a UID stable, or a plugin internal import supported. Select answers that preserve explicit boundaries and documented extension mechanisms.

Official references

• Linux Foundation Certified Backstage Associate
• Linux Foundation Candidate Handbook
• Multiple-choice exam instructions
• What is Backstage?
• Standalone installation
• Architecture overview
• Static configuration
• Deploying Backstage
• Software Catalog
• Entity descriptor format
• Life of an entity
• Catalog external integrations
• New frontend system
• New backend system
• Backstage design system

Continue preparing

• CBA roadmap
• 50 original CBA questions
• 40 CBA flashcards
• Three CBA projects
• Cloud Native Platform Engineer roadmap
• Editorial policy

Frequently asked questions