IDPs and Developer Experience

The joint-smallest domain on the CNPA blueprint at 8% — tied with Measuring your Platform — and the one that explains why the others exist. GitOps, CRDs, pipelines and policy engines are machinery; the Internal Developer Platform is what that machinery feels like from outside. Because CNPA is knowledge-based and multiple-choice, your job is not to build a portal but to state, crisply, what an IDP is, how it differs from a portal, what an API-driven service catalog holds, and where AI fits into platform automation. The four official competencies are the four big sections below.

Where this domain sits. The published CNPA curriculum has six domains: Platform Engineering Core Fundamentals 36% · Platform Observability, Security, and Conformance 20% · Continuous Delivery & Platform Engineering 16% · Platform APIs and Provisioning Infrastructure 12% · IDPs and Developer Experience 8% · Measuring your Platform 8%. That is 100% in total, and the four competencies listed for this domain in the CNCF curriculum document are Simplified Access to Platform Capabilities, API-Driven Service Catalogs, Developer Portals for Platform Adoption and AI/ML in Platform Automation — nothing else.

What an Internal Developer Platform actually is

☺ Like you’re 10: An IDP is the whole kitchen plus the counter — not just the menu board on the wall.

An Internal Developer Platform (IDP) is the curated, self-service layer a platform team builds so developers can go from idea to running software without filing tickets or becoming infrastructure experts. It is not one product you install: it is an assembled set of capabilities — create a service, get an environment, get a database, ship it, watch it, secure it — behind consistent interfaces. The CNCF Platforms White Paper frames it exactly so: capabilities, offered as a product, to internal users — the same framing you meet in What Is Platform Engineering and, for the exam, in Platform Engineering Core Fundamentals.

Platform, portal, golden path: three words the exam separates

Multiple-choice questions love a distinction people blur in daily speech, and this is the classic one. Learn these three as three sentences and half the domain is banked.

The interfaces an IDP exposes

A good platform meets developers where they already work, so one capability is usually reachable through several surfaces that funnel into one API. That is the difference between a platform and a pile of scripts: the contract is the API; every surface is a client of it.

For the architecture behind that API — the five platform planes — see Reference Architecture; the portal lives almost entirely in the developer control plane.

Simplified Access to Platform Capabilities

☺ Like you’re 10: Give people a short menu instead of the whole kitchen — but leave a door for the chefs who need it.

“Simplified access” means each capability sits behind an interface whose vocabulary is the developer’s, not the infrastructure’s. Dot asks for “a small Postgres for checkout” instead of picking an instance class, a subnet group and a backup window. Everything she did not ask about still happens — the platform decided it once, for everyone.

Abstraction: hide the accidental, expose the essential

The design skill is choosing which knobs to surface. Expose what genuinely differs between teams (size, region, environment, retention); absorb what should be identical everywhere (encryption, tagging, backups, network placement, logging). Over-exposing yields a forty-field form nobody fills in correctly; over-hiding yields an abstraction that cannot express real needs and gets bypassed. Both are exam-worthy; both get more room in Self-Service & Developer Portals.

The interfaces developers actually use

“Simplified access” does not mean “a web form.” Recognise several legitimate interfaces and the trade-off each makes; a mature platform offers two or three of them over the same underlying API.

The surfaces differ but should resolve to the same declarative request object, so permissions, policy and audit are enforced once. That is why custom resources make such a natural platform API — and why the Platform APIs and Provisioning Infrastructure domain pairs with this one. To build the thing rather than just name it, work Lab · Platform APIs and drill Practice · Platform APIs.

Score — one workload spec, many runtimes

A recurring example is a workload specification: the developer describes what the app needs, the platform decides how. Score (a CNCF Sandbox project since 2024, score.dev) is the best-known open spec — one file of containers and dependencies, converted by an implementation such as score-k8s or score-compose into Kubernetes manifests or a Docker Compose file.

apiVersion: score.dev/v1b1
metadata:
  name: checkout

containers:
  main:
    image: ghcr.io/acme/checkout:1.4.3
    variables:
      DB_URL: "${resources.db.uri}"   # the platform fills this in
    resources:
      limits: { cpu: "500m", memory: "512Mi" }

resources:
  db:
    type: postgres                    # WHAT is needed — not which cloud, size or subnet
  route:
    type: dns

You will not be asked to write Score from memory, but recognise the shape and name the idea it embodies: separation of the developer’s intent from the platform’s implementation. A Crossplane claim says the same thing about infrastructure.

Paved roads and escape hatches

Simplified access works because the simple route is genuinely the best route — faster, safer, already wired to logging, dashboards and on-call. It stops working the moment it is the only route.

API-Driven Service Catalogs

☺ Like you’re 10: A catalog is the platform’s address book — every service, who owns it, what it depends on — kept current by machines, not by people remembering.

A service catalog is a structured, queryable inventory of what your organisation runs and owns: services, the APIs they expose, the infrastructure they depend on, the teams accountable. It answers questions that are startlingly hard in a big company — “who owns checkout?”, “what breaks if this API changes?”, “which services still run the vulnerable library?”

What lives in a catalog

Catalog entries are entities, and entities have relations. Backstage’s kinds are the ones most often referenced, and worth recognising on sight.

The most valuable field is ownership. A catalog whose entries have no real owner is a phone book with no numbers — and ownership is exactly what an incident responder, a security scanner and a cost report all need at 3am.

Descriptor files live beside the code

What keeps a catalog honest is storing each descriptor in the repository it describes, so it ships with the code and dies with it. In Backstage that file is catalog-info.yaml at the repo root, in an envelope any Kubernetes reader recognises.

# catalog-info.yaml — at the root of the checkout service repo
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: checkout
  description: Takes the money and creates the order.
  annotations:
    github.com/project-slug: acme/checkout
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: group:default/payments-team    # the ownership edge
  system: payments
  providesApis: [ checkout-rest ]
  dependsOn: [ resource:default/checkout-db ]

Relations such as ownedBy, partOf and dependsOn are derived from these fields — that is how a pile of YAML becomes a navigable graph. Full detail, including discovery providers that crawl a whole org, is on the Backstage page.

Why “API-driven” is the load-bearing phrase

The competency is not “service catalogs” but API-driven service catalogs, and that adjective carries the exam point. A catalog is API-driven when:

• Entries are ingested automatically from source control or cloud APIs, so the catalog cannot rot into a stale spreadsheet.
• The catalog exposes an API, so pipelines, policy checks and dashboards can query it: “list every production component owned by a team with no on-call rotation.”
• Entries are machine-readable and versioned, reviewed like code — and actions run through the API too, so creating a component from a template is a call, not only a button.

Two catalogs, two questions

Platforms carry two catalogs at once. The service catalog answers “what exists and who owns it?” The capability catalog answers “what can I ask for?” — on Kubernetes, literally the API types installed in the cluster: CRDs, Crossplane composite resource definitions, operators, and the templates wrapping them.

Developer Portals for Platform Adoption

☺ Like you’re 10: The portal is the shop window. It doesn’t make the goods — it makes people able to find them and want them.

A developer portal gathers the catalog, the golden paths, the docs and read-only views of everything else — deployments, dashboards, on-call, cost — into one place. Underline adoption: the portal makes an existing platform discoverable and attractive enough that people choose it.

Backstage and the portal landscape

Backstage is the reference implementation and the one CNPA material assumes. Donated to the CNCF by Spotify, it is a framework, not a finished product: you scaffold your own app, add plugins, and run it yourself. Memorise its three cores — Software Catalog, Software Templates (run by the scaffolder) and TechDocs — with plugins for Kubernetes, Argo CD, Grafana and on-call around them. Commercial portals exist too; the concepts transfer.

Software templates — the golden path made executable

A template is where the portal stops being a viewer and becomes a doer. Two halves: parameters is a JSON-Schema form the developer fills in, and steps is the ordered list of server-side actions run on submit.

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: go-service
  title: New Go service (with CI, docs and a database)
spec:
  type: service
  owner: group:default/platform-team
  parameters:                      # → rendered as a form
    - title: Tell us about your service
      required: [ name, owner ]
      properties:
        name:  { type: string, pattern: '^[a-z][a-z0-9-]+$' }
        owner: { type: string, "ui:field": OwnerPicker }
  steps:                           # → run server-side, in order
    - id: fetch
      action: fetch:template       # render the skeleton with ${{ values.* }}
      input: { url: ./skeleton, values: { name: '${{ parameters.name }}' } }
    - id: publish
      action: publish:github       # create the repo and push
      input: { repoUrl: 'github.com?owner=acme&repo=${{ parameters.name }}' }
    - id: register
      action: catalog:register     # add it to the catalog immediately
      input:
        repoContentsUrl: '${{ steps.publish.output.repoContentsUrl }}'
        catalogInfoPath: /catalog-info.yaml

Two exam-relevant consequences follow. First, the scaffolder writes to Git, not to a cluster — the same GitOps reconciler deploys it, so the audit trail stays intact. Second, the golden path is enforced by construction: no service can be born without CI, ownership or docs. Fix the template once and every later service inherits the fix.

The portal is a product, and adoption is its metric

Expect at least one question framed as a judgement call. The right instincts: treat the portal as a product with real users, seed it with useful content before launch, and never mandate usage as a substitute for making it good. An incomplete catalog and three broken buttons teach an organisation, in a week, to stop looking.

Measuring adoption and experience

Honest adoption signals are behavioural: what share of production services are catalogued with a real owner; how many new services came from a template rather than a copied repo; how many teams sit on the paved road. The dishonest one is a headcount of accounts created on launch day. For experience, the DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore service) give the system view, while developer surveys — SPACE is the usual reference — catch friction that never reaches a deploy. See Measuring your Platform and Developer Experience.

AI/ML in Platform Automation

☺ Like you’re 10: Two different things share this name — using clever software to help run the platform, and running clever software on the platform for other people.

This competency is new enough that candidates often over-think it. Split it in two and it becomes easy.

Direction one: AI for the platform

Here AI/ML is applied to platform operations to reduce toil. The defensible uses are assistive rather than autonomous:

Several of these are not new — predictive autoscaling and anomaly detection are ML techniques platforms have used for years. And ordinary automation still does the heavy lifting: KEDA and Karpenter are automation, not AI, so a question pitting “an AI decides when to add nodes” against “a controller reconciles desired state” usually wants the controller.

Direction two: the platform for AI/ML

The mirror image treats ML workloads as first-class platform customers. Their needs differ from a web service in testable ways: GPUs and other accelerators must be requested, scheduled and shared (node selectors, taints and tolerations, device plugins); training jobs are batch work with queues and long runtimes, not long-lived Deployments; datasets and models need versioned storage; inference needs autoscaling that survives cold starts. Kubeflow and KServe are the usual answers, and the same golden-path thinking applies. Deep dive: AI/ML Platforms.

Anti-patterns this domain likes to test

☺ Like you’re 10: Four ways to build a lovely counter that nobody wants to stand at.

Associate-level questions often describe a scenario and ask what went wrong; these four cover most of them.

• The portal with no platform. A beautiful UI whose buttons open tickets — nothing automated, nothing faster.
• The catalog nobody maintains. Typed by hand at launch, stale by autumn. Fix: ingest from the repos.
• The golden cage. One rigid abstraction, no escape hatch — so teams build a shadow platform you cannot secure.
• Platform-as-project. A launch, then no roadmap, owner or feedback loop. A platform is a product, staffed accordingly — see Team Topologies.

What you must be able to state on exam day

☺ Like you’re 10: Here’s the short list to know cold before you sit down.

Define an IDP and a portal in one sentence each, and say which contains which. Explain a golden path and why an escape hatch matters. Name the interfaces a platform exposes and why they resolve to one API. Recognise a workload spec (Score) and a claim as “intent, not implementation.” Say what a service catalog contains, why entries live beside the code, and what “API-driven” buys over a wiki. Name Backstage’s three cores and a template’s two halves, and know the scaffolder writes to Git. Distinguish AI for the platform from the platform for AI. And know that adoption, not architecture, judges this domain. The condensed must-know list for every domain is on Know Cold; sitting-day mechanics are on the Exam Guide.

CNPA is an associate-level, knowledge-based multiple-choice exam taken online with remote proctoring — it is not hands-on. That is the same shape as KCNA and KCSA, and the opposite of the performance-based, in-a-real-cluster exams: CKA, CKAD, CKS and the professional-level CNPE. Where each sits is mapped on Certifications.

On logistics, trust only the vendor. At the time of writing the Linux Foundation lists CNPA as a 120-minute exam with no prerequisites, priced around US$250 standalone, and the certification valid for two years; the pass mark is a single published figure — 75% or above, per the Multiple Choice Exam FAQ — while the question count is not published at all, so treat any count you read on a study site, including this one, as unconfirmed. Verify everything on the official page before you book: training.linuxfoundation.org · CNPA. Domain names and weights on this page come from the CNCF's published CNPA Exam Curriculum document. Other primary sources used here: the CNCF Platforms White Paper, the Backstage descriptor format, and score.dev.