KCNA · Domain 4: Cloud Native Architecture · 12% of the exam
Task 4.3: Cloud Native Community and Collaboration
How the community works: CNCF and its maturity levels, the Technical Oversight Committee, Kubernetes SIGs and enhancement proposals, the release cycle, conformance, and open governance.
Study it
CNCF, maturity levels, SIGs, KEPs, releases and conformance
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the CNCF documentation page that proves it.
Question 1 · choose 1
A bank's platform team may adopt only CNCF projects that the foundation considers stable, widely adopted and production ready. Which CNCF maturity level should it look for?
AIncubating
BSandbox
CGraduated
DArchived
Show the answer and why
AIncubating
Incorrect
Incubating projects are used successfully in production by a small number of users; wide adoption is what graduation recognizes.
BSandbox
Incorrect
The Sandbox is the entry point for early-stage, experimental projects.
CGraduated
Correct
CNCF describes graduated projects as stable, widely adopted and production ready.
DArchived
Incorrect
Archived projects have become less active and no longer receive full CNCF services.
CNCF projects move from Sandbox to Incubating to Graduated as they mature; graduation signals stability and broad production adoption.
A company wants its clusters to stay on Kubernetes minor versions that still receive patch releases from the upstream project. Which plan matches the project's support policy?
AStay on one minor version for five years, as each minor release is a long-term line
BUpgrade about yearly; the three newest minor releases get roughly a year of patches
CTrack the newest minor release closely, since older minor versions get no patches
DUpgrade rarely, since fixes are backported to older minor versions for several years
Show the answer and why
AStay on one minor version for five years, as each minor release is a long-term line
Incorrect
The upstream project does not run five-year support lines; a minor version leaves support after about a year.
BUpgrade about yearly; the three newest minor releases get roughly a year of patches
Correct
The project maintains release branches for the most recent three minor releases, and each gets approximately one year of patch support.
CTrack the newest minor release closely, since older minor versions get no patches
Incorrect
The three most recent minor releases are patched, not just the newest.
DUpgrade rarely, since fixes are backported to older minor versions for several years
Incorrect
Older minor versions fall out of support; fixes are not backported to them.
With three maintained minor releases and about a year of patches each, staying supported means planning regular upgrades.
Late in a Kubernetes release cycle, a contributor's non-critical fix is not merged into the release branch. Which phase of the release cycle explains this?
ACode Freeze, when only critical bug fixes merge
BNormal development, which is reserved for feature work
CPost-release, when the next cycle has not started
DThe beta period of the feature gate
Show the answer and why
ACode Freeze, when only critical bug fixes merge
Correct
During Code Freeze only critical bug fixes go into the release.
BNormal development, which is reserved for feature work
Incorrect
Normal development accepts bug fixes as well as features, through the usual review.
CPost-release, when the next cycle has not started
Incorrect
The fix would target the next release then, not be blocked for this one.
DThe beta period of the feature gate
Incorrect
Feature stages are about features, not merge rules for a release branch.
The release cycle runs from normal development through Code Freeze to the release, tightening what may merge as the date nears.