Most KCNA study plans treat the Cloud Native Architecture domain as “autoscaling, serverless and a few CNCF project names.” That undersells it. The current KCNA curriculum lists Cloud Native Community and Collaboration and Cloud Native Ecosystem and Principles as explicit competencies inside that domain, and the exam asks about them directly: who decides what goes into Kubernetes, what a SIG is, what “beta” promises, how often Kubernetes releases, how long a version is supported, and how a vendor proves its distribution is “really Kubernetes.”
These are not trivia questions. They are the operating manual for anyone who will run, upgrade or contribute to Kubernetes, and they appear on the exam precisely because the KCNA is designed as an on-ramp into the community. This article covers the full set from a practitioner’s angle — with the current numbers, verified against the project’s own governance documents — and cross-links to the existing Cloud Native Architecture guide for the CNCF project maturity levels (Sandbox, Incubating, Graduated), which it already covers in detail and which are not retaught here.
Where This Sits in the Current KCNA Curriculum
The KCNA curriculum was refreshed in late 2025. The current domains and weights are:
| Domain | Weight | Competencies |
|---|---|---|
| Kubernetes Fundamentals | 44% | Core concepts, administration, scheduling, containerization |
| Container Orchestration | 28% | Networking, security, troubleshooting, storage |
| Cloud Native Application Delivery | 16% | Application delivery, debugging |
| Cloud Native Architecture | 12% | Observability, cloud native ecosystem and principles, cloud native community and collaboration |
Older study material (and some older guides on this site) quote the previous 46/22/16/8/8 split with five domains; if the numbers you have memorised look different, that is why. The community-and-collaboration material has not shrunk — it has been consolidated into the Architecture domain. Expect three to six of the exam’s 60 questions to come from this section, which is a cheap place to pick up marks because the facts are small, stable and highly memorable once organised.
How the Kubernetes Project Is Organised
Kubernetes is governed by the Kubernetes Steering Committee, a seven-member body elected by project contributors. Steering owns the project bylaws, the structure of the sub-organisations and project values. It deliberately does not make technical decisions about the code — that authority is delegated downward.
The project’s working units are:
| Group type | Purpose | Lifetime | Examples |
|---|---|---|---|
| Special Interest Group (SIG) | Owns a vertical, horizontal or project-support area; every repo, directory, API and test belongs to a SIG | Permanent (chartered) | SIG Node, SIG Network, SIG Storage, SIG Auth, SIG Scheduling, SIG Apps, SIG CLI, SIG API Machinery, SIG Architecture, SIG Release, SIG Docs, SIG Testing, SIG Security, SIG Cluster Lifecycle, SIG Contributor Experience |
| Subproject | A specific codebase or effort inside a SIG | As long as the code exists | kubeadm (SIG Cluster Lifecycle), kubectl (SIG CLI), Gateway API (SIG Network) |
| Working Group (WG) | Cross-SIG, time-bounded effort with a clear deliverable | Dissolves when done | WG Batch, WG Device Management, WG AI Gateway, WG Node Lifecycle |
| Committee | Sensitive or project-wide governance functions | Permanent | Steering, Code of Conduct, Security Response |
A few details the exam likes:
- SIGs come in three flavours in the governance document: vertical (Node, Network, Storage, Scheduling), horizontal (Architecture, Scalability) and project (Release, Docs, Testing, Contributor Experience).
- Each SIG has at least one, ideally two, chairs (organisers and facilitators) and typically tech leads; each must publish a charter defining scope, responsibilities and how decisions are made.
- SIGs must operate in the open: public mailing lists, recorded meetings, published notes. “Transparent and accessible” is one of the project’s stated principles alongside open, welcoming and merit-based.
- Working Groups do not own code; they coordinate SIGs that do.
The contributor ladder
The community membership document defines four roles, each granted through the OWNERS files that live in the repositories:
| Role | What it means | How you get it |
|---|---|---|
| Member | Active contributor in the Kubernetes GitHub org | Sponsored by two reviewers after multiple contributions |
| Reviewer | Reviews other members’ contributions in a subproject | Track record of authorship and review; reviewers entry in OWNERS |
| Approver | Can approve contributions for merge | Experienced reviewer; approvers entry in OWNERS |
| Subproject owner | Sets direction and priorities for a subproject | Demonstrated responsibility and judgement; listed in sigs.yaml |
Pull requests need both a /lgtm (from a reviewer) and /approved (from an approver) label before the merge bot takes them. This is why Kubernetes can accept thousands of contributors without a central gatekeeper: ownership is distributed down to directory level.
From Idea to Feature: The KEP Process
A Kubernetes Enhancement Proposal (KEP) is the design document and tracking record for any non-trivial change — new features, major changes to existing features, anything controversial or cross-cutting. The project modelled KEPs on IETF RFCs and Python PEPs. KEPs live in the kubernetes/enhancements repository, almost always under the owning SIG’s directory, and are named after their tracking issue number (for example, KEP-3015 is Traffic Distribution for Services).
The lifecycle you should recognise:
- Socialise the idea with a sponsoring SIG — mailing list or meeting agenda.
- Write the KEP from the template; status starts as
provisionalwhile the design is debated. - Approvers move it to
implementableonce the design is accepted. - Code lands across one or more releases, gated behind a feature gate, graduating alpha → beta → GA.
- The KEP becomes
implemented. Other terminal states aredeferred,rejected,withdrawnandreplaced.
Every KEP carries a kep.yaml with metadata — owning SIG, participating SIGs, stage, latest milestone, and the milestones at which alpha, beta and stable are targeted. Since Kubernetes 1.21 the Production Readiness Review (PRR) is also mandatory for graduation: a PRR approver checks that the feature can be enabled, disabled, monitored and rolled back safely.
Feature stages and what they promise
Features ship behind feature gates — --feature-gates=Name=true|false flags on each component. The stage determines the default and the guarantee:
| Stage | Default | Guarantee | Typical duration |
|---|---|---|---|
| Alpha | Disabled | May be buggy; may be dropped without notice; API may change incompatibly | One or more releases |
| Beta | Feature gate usually enabled; beta API groups disabled by default since v1.24 | Well tested; the feature will not be dropped, but details and schema may change | Limited — beta APIs are deprecated within 9 months or 3 releases |
| GA / Stable | Enabled and locked (cannot be turned off) | Appears in stable releases for many subsequent versions | Permanent within the major version |
The v1.24 change is a classic exam discriminator: a beta feature gate is normally on, but a new beta API version (for example something.k8s.io/v1beta1) is off until you enable it with --runtime-config. The two statements “beta is on by default” and “beta APIs are off by default” are both true and refer to different things.
Concrete examples from recent releases make this stick: the nftables kube-proxy mode went alpha in 1.29, beta in 1.31 and GA in 1.33; Linux user namespaces for Pods went beta in 1.30, on by default in 1.33 and GA in 1.36. When you read release notes, the pattern is always the same three steps.
The Release Cycle
Kubernetes ships three minor releases per year, each on a cycle of roughly fifteen weeks, run by a volunteer Release Team under SIG Release. (It was four releases a year until 2021.)
Inside one cycle:
| Phase | When | What happens |
|---|---|---|
| Enhancements definition | Weeks 1–4 | KEPs targeting the release must be implementable; Enhancements Freeze closes the list |
| Implementation | Weeks ~4–12 | Code merges on master with /sig, /kind, /lgtm, /approved labels |
| Code Freeze | Weeks ~12–14 | Only critical bug fixes merge; a /milestone label is required; enhancements not finished are pruned |
| Stabilisation & docs | Final ~2 weeks | Release notes and documentation finalised; release branch release-1.y cut at rc.0 |
| Post-release | Week 14+ | master reopens for the next cycle; fixes reach the release branch only via cherry picks approved by Release Managers |
Version numbers follow semantic versioning: 1.y.z where y is the minor release (new features) and z the patch (bug and security fixes only). Patch releases are cut roughly monthly, faster right after a new minor, with a cherry-pick deadline a couple of days before each one.
Support window
Since Kubernetes 1.19 each minor release receives about 12 months of standard patch support, followed by a 2-month maintenance mode in which only critical and security fixes may be cut — roughly 14 months in total before end of life. Earlier releases (1.18 and older) had only 9 months. At any moment the project maintains release branches for the three most recent minors.
As a worked example from the official release page at the time of writing: 1.37 (released August 2026) reaches end of life in October 2027; 1.36 in June 2027; 1.35 in February 2027; and 1.34 goes end of life this month, October 2026. If a question asks “how many Kubernetes minor versions are supported at once,” the answer is three; if it asks “how long is a release supported,” the answer is about a year of patches plus two months of maintenance.
Why practitioners care: a managed cluster that is two minors behind has months, not years, before it stops receiving security patches. Planning an upgrade every four months is not optional hygiene — it is the only way to stay inside the window. The CKA cluster upgrade guide shows the mechanics; this section is the why.
The Version Skew Policy
Because upgrades happen one component at a time, the project publishes exactly how far apart component versions may be. The rules below use 1.37 as the control-plane version:
| Component | Allowed versions relative to kube-apiserver | Example with apiserver at 1.37 |
|---|---|---|
| kube-apiserver (HA) | Newest and oldest instances within one minor | 1.37 and 1.36 |
| kubelet | Never newer; up to three minors older | 1.37, 1.36, 1.35, 1.34 |
| kube-proxy | Never newer than apiserver; up to three minors older; within three of its node’s kubelet | 1.37 → 1.34 |
| kube-controller-manager, kube-scheduler, cloud-controller-manager | Never newer; up to one minor older | 1.37, 1.36 |
| kubectl | Within one minor either way | 1.38, 1.37, 1.36 |
Two consequences follow directly. First, the upgrade order is fixed: kube-apiserver first (all instances), then controller-manager, scheduler and cloud-controller-manager, then kubelets and kube-proxy on the nodes, with kubectl at any point within one minor. Second, you cannot skip minor versions on the control plane — 1.35 to 1.37 means two upgrades — even though kubelets three minors behind are tolerated, which is what lets large node fleets lag behind during a rolling control-plane upgrade. The “three minors” allowance for kubelet dates from 1.28; before 1.25 it was two.
Exam phrasing to recognise: “A cluster runs kube-apiserver 1.37. Which kubelet version is not supported?” The answer is anything newer than 1.37 or older than 1.34.
The API Deprecation Policy
Governance also shows up as guarantees in the API itself. The deprecation policy (owned by SIG Architecture) gives operators predictable timelines:
- GA API versions may be marked deprecated but must not be removed within a major version — and there is no plan for a Kubernetes 2.0 that would remove them.
- Beta API versions are deprecated no later than 9 months or 3 minor releases after introduction (whichever is longer), and stop being served 9 months or 3 releases after deprecation.
- Alpha API versions may disappear in any release.
- An API may never be deprecated in favour of a less stable version, and objects must round-trip between served versions without data loss.
This is the policy behind every “API removed in 1.x” migration you have read about — extensions/v1beta1 Ingress, policy/v1beta1 PodSecurityPolicy, batch/v1beta1 CronJob. The API deprecations and versioning guide covers how to find and fix affected manifests with kubectl convert; for the KCNA you need the timelines and the reason they exist: operators can plan because the project promised them a schedule.
The CNCF Around Kubernetes
Kubernetes is the first project donated to, and the first to graduate from, the Cloud Native Computing Foundation (CNCF), itself part of the Linux Foundation. The Kubernetes project governs itself through Steering and the SIGs; the CNCF provides neutral ownership of the trademark and assets, funding, events and the ecosystem structure around it.
The bodies you should be able to name:
| Body | Role |
|---|---|
| Governing Board (GB) | Business and budget oversight; made up of member-company representatives |
| Technical Oversight Committee (TOC) | The technical governing body: defines the technical vision, admits, reviews, graduates and archives projects, and aligns interfaces across projects. Eleven voting members with two-year terms, appointed by the GB, the TOC itself, the end-user community and maintainers |
| End User Technical Advisory Board (TAB) | The voice of adopters (companies that use but do not sell cloud native technology) in TOC decisions |
| Technical Advisory Groups (TAGs) | Domain-expert groups that advise the TOC and support projects. Rebooted in 2025 into five: TAG Developer Experience, TAG Infrastructure, TAG Operational Resilience, TAG Security and Compliance, TAG Workloads Foundation |
The project lifecycle the TOC runs — Sandbox → Incubating → Graduated, with due diligence, adopter interviews and a TOC vote at each promotion — is covered with examples in the Cloud Native Architecture guide. Memorise that the TOC is who votes; the GB does not decide project maturity.
Open standards and interfaces
The CNCF’s technical vision emphasises interfaces before implementations, which is why so many cloud native building blocks are specifications with multiple implementations:
| Standard | Governs | Where it is covered |
|---|---|---|
| OCI (Open Container Initiative) image, runtime and distribution specs | What a container image is, how a runtime executes it, how registries serve it | Container runtimes guide |
| CRI (Container Runtime Interface) | How the kubelet talks to containerd or CRI-O | same guide |
| CNI (Container Network Interface) | How Pods get network connectivity | Services and networking guide |
| CSI (Container Storage Interface) | How storage drivers plug into Kubernetes | Container Orchestration storage material |
| CloudEvents, OpenTelemetry, OpenMetrics | Event, telemetry and metrics formats | Serverless guide, Architecture guide |
The exam framing is consistent: the interface is the standard; containerd, Cilium or a CSI driver is one implementation of it. Answer accordingly.
Conformance: proving a distribution is Kubernetes
The Certified Kubernetes Conformance Program lets vendors and open-source distributions prove they run upstream-compatible Kubernetes. The mechanics:
- The vendor runs the open-source conformance test suite (a defined subset of the Kubernetes e2e tests) with Sonobuoy and submits the results as a pull request to the CNCF conformance repository; a reviewer approves it.
- Certified products may use the Certified Kubernetes logo and the Kubernetes name. To stay certified, they must certify a current version at least yearly.
- Because the same test tool is open source, any end user can re-run it against their own cluster to confirm it is still conformant.
- Conformance guarantees API compatibility — a workload that runs on one certified distribution should run on another — which is the foundation of the “no vendor lock-in” claim.
Adjacent CNCF programs that appear in answer options: Kubernetes Certified Service Provider (KCSP), for consultancies with certified engineers, and Kubernetes Training Partner (KTP). These certify companies; the KCNA, CKA, CKAD, CKS and KCSA certify individuals. (Holding all five earns the Kubestronaut title.)
Roles and Personas in the Cloud Native Ecosystem
The curriculum also expects familiarity with the people who operate this ecosystem, because exam questions often describe a person’s responsibility and ask which role it belongs to:
| Persona | Focus | Typical Kubernetes concern |
|---|---|---|
| Application developer | Builds and ships code | Container images, Deployments, ConfigMaps, probes |
| DevOps engineer | Delivery pipelines and automation | CI/CD, GitOps, Helm, environments |
| Site Reliability Engineer (SRE) | Reliability, SLOs, incident response | Observability, autoscaling, capacity, error budgets |
| Platform engineer | Builds the internal platform other teams consume | Multi-tenancy, policy, golden paths, cluster lifecycle |
| Cloud architect | Designs the overall system | Service boundaries, multi-cluster and multi-cloud, cost |
| Security engineer | Reduces risk across the stack | Supply chain, RBAC, Pod Security, network policy |
| FinOps practitioner | Cost accountability | Requests/limits, rightsizing, showback — see the cost management guide |
The discriminator between SRE and platform engineer is the one most often tested: SREs own the reliability of running services (SLOs, on-call, postmortems); platform engineers own the platform other engineers build on. DevOps describes a culture and set of practices rather than a single job title, which is why “DevOps engineer” is frequently an answer that sounds right but is too broad.
How to Participate (and Why the Exam Cares)
The KCNA explicitly aims to situate candidates in the community, so a handful of practical facts are fair game:
- Communication channels: the Kubernetes Slack workspace, per-SIG Google Groups mailing lists, GitHub issues and PRs, and public SIG meetings on Zoom with recordings on YouTube. The
kubernetes-devlist carries project-wide announcements. - Events: KubeCon + CloudNativeCon, the CNCF’s flagship conference, runs in several regions each year, with co-located events such as Platform Engineering Day and the Kubernetes Contributor Summit.
- Getting started: the
kubernetes/communityrepository’s contributor guide,good first issueandhelp wantedlabels, and SIG Contributor Experience’s mentoring programmes. Non-code contributions — docs, triage, release team shadows — are first-class paths to membership. - Code of Conduct: adopted project-wide and enforced by the Code of Conduct Committee; contributors also sign the CNCF Contributor License Agreement (CLA) before their first PR can merge.
- Security: vulnerabilities go to the Security Response Committee privately, not to public issues; fixes are coordinated and announced on the
kubernetes-security-announcelist.
Even if you never open a PR, knowing where decisions are made tells you where to read when something changes — the KEP, the SIG meeting notes, the release notes — rather than relying on second-hand summaries.
Quick-Reference Table for Revision
| Fact | Answer |
|---|---|
| Project governing body | Kubernetes Steering Committee (7 elected members) |
| Who owns code areas | SIGs, via charters and OWNERS files |
| Cross-SIG, temporary effort | Working Group |
| Design/tracking document for a feature | KEP, in kubernetes/enhancements |
| Feature stages | Alpha (off) → Beta (on; beta APIs off since 1.24) → GA (locked on) |
| Minor releases per year | Three (~15-week cycles), since 2021 |
| Patch cadence | Roughly monthly |
| Support per minor | ~12 months + 2 months maintenance ≈ 14 months |
| Supported minors at once | Three |
| kubelet skew | Up to 3 minors older than apiserver, never newer |
| kubectl skew | ±1 minor of apiserver |
| Beta API lifetime | Deprecated ≤ 9 months/3 releases after intro; removed ≤ 9 months/3 releases after deprecation |
| GA API removal | Not within a major version |
| CNCF technical body | TOC (admits, graduates, archives projects) |
| CNCF TAGs (2025 reboot) | Developer Experience, Infrastructure, Operational Resilience, Security and Compliance, Workloads Foundation |
| Conformance tool | Sonobuoy; yearly recertification |
| First CNCF project to graduate | Kubernetes |
Common Mistakes
- Saying Steering decides technical direction. Steering governs the project; SIGs and SIG Architecture decide technical matters.
- Confusing the CNCF TOC with Kubernetes Steering. The TOC governs CNCF projects (admission and maturity); Steering governs the Kubernetes project internally.
- Treating beta as “safe to rely on forever.” Beta APIs have a nine-month/three-release clock.
- Assuming four releases a year. It has been three since 2021.
- Believing kubelet must match the apiserver exactly. It may lag by up to three minors.
- Thinking conformance tests performance or security. It tests API conformance only.
- Using the old 46/22/16/8/8 domain split in your time planning. The current curriculum is 44/28/16/12 with four domains.
Practise Until the Vocabulary Is Automatic
This section of the KCNA rewards recognition, not calculation. Make flashcards from the quick-reference table, then test yourself with scenario phrasing: “a cross-SIG effort with an end date” → Working Group; “the body that votes a project to Graduated” → TOC; “a flag that is on by default but may still change” → beta. The free KCNA practice questions and the free KCNA practice exam include community and governance items alongside the technical domains, so you can see how the exam actually words them.
When you want a full dress rehearsal across all four domains with the current weights, Sailor.sh’s Kubernetes and Cloud Native Associate (KCNA) Mock Exam Bundle provides five timed, 60-question mock exams with per-domain scoring and explanations, so a weak spot in Cloud Native Architecture shows up before exam day rather than on it. Combine it with the KCNA exam guide for logistics and the certification path guide if the KCNA is your first step toward the CKA.
Frequently Asked Questions
What is a Kubernetes SIG?
A Special Interest Group is a permanent, chartered team that owns a part of the project — a component area like Node or Network, a cross-cutting concern like Architecture, or a project function like Release or Docs. Every repository, directory and API in Kubernetes is owned by some SIG.
What is the difference between a SIG and a Working Group?
A SIG is permanent and owns code; a Working Group is a temporary, cross-SIG effort with a defined deliverable that dissolves when the work is done, without owning code itself.
What is a KEP?
A Kubernetes Enhancement Proposal: the design and tracking document required for most non-trivial changes. KEPs live in the kubernetes/enhancements repository, move through provisional → implementable → implemented, and record the alpha, beta and stable milestones for the feature.
What do alpha, beta and GA mean for a Kubernetes feature?
Alpha features are disabled by default, may be buggy and may be removed. Beta features are usually enabled by default and will not be dropped, though details may change; new beta API groups have been disabled by default since v1.24. GA (stable) features are always on and cannot be disabled.
How often does Kubernetes release and how long is a version supported?
Three minor releases a year, each supported for about 12 months of patches plus a 2-month maintenance mode — roughly 14 months. Patch releases ship about monthly. Three minor versions are supported at any time.
What is the Kubernetes version skew policy?
kube-apiserver instances must be within one minor of each other; kubelet and kube-proxy may be up to three minors older than the apiserver and never newer; controller-manager and scheduler may be one minor older; kubectl must be within one minor either way. The apiserver is always upgraded first.
What does the CNCF Technical Oversight Committee do?
The TOC is the CNCF’s technical governing body. It defines the technical vision, admits new projects, moves them between Sandbox, Incubating and Graduated, archives projects, and aligns interfaces across the portfolio.
What does “Certified Kubernetes” mean?
The distribution passed the CNCF conformance test suite (run with Sonobuoy) and submitted the results for review, proving it exposes the standard Kubernetes APIs. Certification must be renewed against a current version at least yearly, and anyone can re-run the same tests.
Is this topic really on the KCNA?
Yes. The current curriculum names “Cloud Native Community and Collaboration” and “Cloud Native Ecosystem and Principles” as competencies within the Cloud Native Architecture domain (12%), and questions about SIGs, release cadence, feature stages and CNCF structure are standard.
Conclusion & Next Steps
Kubernetes works at its scale because governance is distributed: Steering sets the rules, SIGs own the code, KEPs record the decisions, the Release Team ships three times a year on a published schedule, and the skew and deprecation policies turn all of that into promises operators can plan around. The CNCF wraps a neutral foundation, a TOC and a conformance program around the project so that “Kubernetes” means the same thing on every certified platform.
For the KCNA, learn the structure once and the questions become recognition exercises. For your career, the same knowledge tells you where to look when something changes and how to get involved when you want it to change differently. Pair this article with the Cloud Native Architecture guide for project maturity and autoscaling, the GitOps and application delivery guide for the delivery domain, and timed mock exams to confirm the vocabulary is automatic under the clock.