DevOps Practices in Platform Engineering: CNPA practice questions

Platform engineering did not replace DevOps. The CNCF white paper and maturity model both describe it as an explicit form of the cross-functional cooperation that DevOps promised. DevOps asked development and operations to share responsibility for delivering and running software, and over time that sharing pushed more and more infrastructure work onto product teams. A platform keeps the DevOps outcome, teams that can build, ship and run their own services, while moving the repetitive parts of the toolchain into shared, self-service capabilities.

Many of the practices a platform encodes come from DORA's research. Its capability catalog includes continuous integration, trunk-based development, deployment automation, test automation, version control, monitoring and observability, and pervasive security, all practices DORA links to better software delivery performance. A platform turns them into defaults: a pipeline template that builds and tests every commit, a deployment path that is the same for every environment, security scanning that runs without each team wiring it up. DORA's metrics guide names reducing the batch size of changes as a common way to improve, because smaller changes are easier to reason about, move through delivery faster and are easier to recover from when something fails.

Culture is part of DevOps, not an add-on. DORA's capability on generative organizational culture builds on Ron Westrum's typology of pathological, bureaucratic and generative organizations and reports that a high-trust culture which emphasizes information flow predicts software delivery and organizational performance. In a generative culture messengers are trained rather than punished, risks are shared and failure leads to inquiry; DORA's practical advice includes holding blameless postmortems. For a platform team this shapes how it handles an outage in a shared capability and how it treats users who report friction.

Ownership is another DevOps idea a platform must preserve. The white paper says users should not have to operate the services the platform offers, but also that platforms should be optional and let teams run their own capabilities when needed. DORA's metrics guide warns against siloed ownership and recommends sharing all of the delivery metrics across development, operations and release teams. A platform that becomes a gate every change must queue behind recreates the old wall between development and operations; DORA calls this the ticket-ops trap.

Common misconceptions include equating DevOps with a job title or with a separate team that runs everyone's pipelines, assuming speed and stability trade off against each other (DORA's research repeatedly finds that they do not), and believing tooling alone delivers DevOps outcomes without changes to how teams work.

At associate level, expect questions that connect a practice to its purpose: why small batches, automated tests, shared metrics or blameless reviews help, and how a platform supports those practices without taking ownership of the product away from the team that builds it.