Simplified Access to Platform Capabilities: CNPA practice questions

Simplified access is about the front door of the platform: how a developer finds a capability, requests it and starts using it without needing to understand everything behind it. The CNCF Platforms White Paper treats this as a defining attribute. Capabilities should be self-service, meaning users can request and receive them autonomously and automatically, and its example is concrete: a user should be able to request a database and receive its locator and credentials by running a command-line tool or filling out a form in a web portal. The platform should also encapsulate details that would only add cognitive load, such as which cloud provider delivers a service, while still letting users configure and observe what they need.

The same paper stresses meeting users where they are. A deployment capability might be used from an IDE by developers, from a command-line tool by testers and from a GUI-based web portal by a product owner. Portals, APIs, CLIs and templates are therefore not competing choices but different interfaces onto the same capabilities, and they should behave consistently.

The Platform Engineering Maturity Model shows how access tends to evolve. At the Provisional level each capability has its own custom, often manual process, and knowledge of how to request things is passed from person to person. At the Operationalized level, standard tooling and documented golden paths exist but often still require deep domain expertise and support from maintainers. At the Scalable level, solutions are self-service, sometimes one click, and need little support, although day-two management may still be rough. At the Optimizing level, capabilities are integrated into the tools teams already use and some, such as observability or identity for a new service, are provisioned automatically, while users can still customize beyond the defaults.

DORA's platform engineering guidance adds two practical rules. Shift complexity down into the platform instead of expecting developers to become experts in Kubernetes, cloud networking or security policies, and give clear feedback on the outcome of every task so users can troubleshoot on their own when something fails. Golden paths are the main vehicle: a template, its pipeline and its documentation that together make the recommended way the easiest way.

Misconceptions include equating simplified access with a ticket queue that someone else works through, which DORA calls the ticket-ops trap; assuming a portal simplifies anything when the processes behind it are still manual; and building what DORA calls a golden cage with no way off the path. The white paper says platforms should be optional and composable, so teams with unusual needs can step outside the paved road without leaving the platform entirely.

At associate level, expect scenario questions asking which interface or change best reduces friction, what makes a capability truly self-service, and how golden paths balance standardization with flexibility.