Platform Architecture and Capabilities: CNPA practice questions

Architecturally, the CNCF Platforms White Paper describes a platform as a bridge. On one side are capability providers: other internal teams, cloud providers and managed services that actually run databases, networks or identity systems. On the other side are the platform's users, such as application developers and data scientists. The platform sits in between and offers those capabilities through consistent interfaces while it implements the organization's practices for security, performance, cost governance and user experience. This is why a platform team can own a portal and an API for workload identity while the identity service itself is a cloud product.

The white paper lists capability domains a cloud-native platform may offer, and they make a useful mental map: web portals for observing and provisioning capabilities; APIs and CLIs for automated provisioning; golden path templates and documentation; automation for building and testing; automation for delivering and verifying; development environments; observability of functionality, performance and cost; infrastructure services for compute, networking and storage; data services such as databases, caches and object stores; messaging and event services; identity and secret management; security services for static analysis, runtime analysis and policy enforcement; and artifact storage for images, packages and source code. The paper relates each domain to example CNCF or CDF projects, for instance Backstage for portals, Kubernetes and Crossplane for provisioning APIs, Argo and Flux for delivery, OpenTelemetry and Prometheus for observability, SPIFFE/SPIRE and cert-manager for identity, and OPA, Kyverno and Falco for security.

Two attributes shape the architecture more than any single tool. The platform should be optional and composable: teams can use only the parts they need and can run a capability the platform does not offer, the white paper's example being a graph database. And it should be secure by default, with compliance checks built in rather than added by each team. Capabilities can also be combined into higher-level offerings. The maturity model's most advanced interface level describes building blocks assembled into automatic compositions, such as observability agents injected into every workload or a pipeline space and a namespace created for every new project, while super users can still decompose them.

DORA adds an extensibility principle: a central team cannot and should not build everything, so the platform needs clear APIs and a contribution model that lets other teams add tools and services in a standard way.

A common misconception is that the capability list is a checklist to implement in full. The white paper says the opposite: a good platform reflects its users' needs, so capabilities are chosen and prioritized together with users, and frequently needed, undifferentiated ones such as pipelines, databases and observability are suggested as a good place to start. Another is that the platform equals Kubernetes. Kubernetes appears in several domains as a foundation, but the platform is the curated layer of interfaces, templates and policies on top of it.

Questions at this level usually describe a need and ask which capability domain or example project fits it, or ask what the platform layer is responsible for compared with the providers underneath.