SaveMyCert
Log in
5 of 5 free questions left today·for 10 a day
KCNA quick-recall

KCNA flashcards

Flip through 13 cards — one per KCNA topic — and self-test the key exam facts. Free, no account needed. These exams reward fast recognition, which is exactly what flashcards train.

1 / 13

Every KCNA flashcard, by exam domain

124 key facts across 4 domains — the full deck below, so you can scan it even without the interactive cards.

Kubernetes Fundamentals

44% of the exam
  • A Pod is the smallest deployable unit; its containers share one network namespace (one IP) and can share volumes such as an emptyDir.
  • The kube-apiserver is the front door: kubectl, the kubelet, and all controllers talk to the cluster only through it.
  • etcd is the cluster's key-value datastore and single source of truth; it needs a majority quorum to accept writes, and an etcd snapshot is the cluster backup.
  • The kube-scheduler only picks a node for each Pod; the kubelet on that node starts the containers via the runtime and sends the node heartbeat.
  • kube-controller-manager runs the provider-neutral controllers (including the node controller); cloud-controller-manager provisions cloud resources such as LoadBalancer Services.
  • A ReplicaSet keeps N Pods matching its selector alive; a Deployment owns ReplicaSets and adds rolling updates (maxSurge/maxUnavailable) and rollback via kubectl rollout undo, with no automatic rollback on failure.
  • A Service gives a stable virtual IP and DNS name to the ready Pods matching its selector; readiness failures remove a Pod from traffic, liveness failures restart it.
  • Namespaces scope names, access, and quotas; labels plus selectors are the glue that connects Services and controllers to Pods.
  • Kubernetes is declarative: controllers continuously reconcile observed state toward the desired state stored in etcd, so control plane outages freeze change and healing but leave running Pods running.
  • Every kubectl command is a request to the kube-apiserver; for logs and exec the API server relays to the kubelet on the Pod's node (port 10250), so a blocked path to one kubelet breaks only those commands.
  • kubectl config use-context rewrites current-context in the kubeconfig file and switches cluster, user, and namespace together.
  • kubectl apply is declarative and idempotent; an imperative scale or edit is reverted by the next apply of a manifest that sets that field.
  • Localise failures along the chain: no ReplicaSet or Pods means the controller manager, Pending Pods the scheduler, a ClusterIP failing on one node that node's kube-proxy.
  • etcd needs a majority (floor(n/2)+1): 3 and 4 members both tolerate one failure, 5 tolerate two - hence odd counts. Back up etcd to back up the cluster.
  • A Role grants permissions in one namespace; a ClusterRole via a ClusterRoleBinding reaches every namespace and cluster-scoped resources, but via RoleBindings never reaches cluster-scoped ones like Nodes.
  • RBAC is additive and allow-only: no deny rules, so excluding one namespace means replacing a ClusterRoleBinding with per-namespace RoleBindings.
  • Rules name API groups ("" is core; Deployments are in apps) and subresources separately: logs needs get on pods/log, exec needs create on pods/exec.
  • Test a ServiceAccount with --as=system:serviceaccount:<namespace>:<name>; a bare name impersonates a user instead.
  • A ResourceQuota caps a namespace's totals at admission and is not retroactive; a LimitRange sets per-container defaults, minimums, and maximums.
  • Namespaces scope names, access, and quotas, but not the network or the nodes; deleting one does not remove cluster-scoped objects such as ClusterRoleBindings that reference it.
  • The kube-scheduler filters out infeasible nodes, sums weighted plugin scores for the rest, and binds the Pod to the winner; setting spec.nodeName bypasses it entirely.
  • Requests drive scheduling and are compared with allocatable minus already-requested capacity; limits are enforced at runtime and play no part in placement.
  • A limit with no request (and no LimitRange default) makes the request equal to the limit, so it counts in full for scheduling.
  • A container over its CPU limit is throttled; one over its memory limit is OOMKilled and its restart policy applies.
  • nodeSelector labels are ANDed with no OR; node affinity adds operators like In, with expressions ANDed inside a term and terms ORed.
  • Required rules filter and can leave Pods Pending; preferred rules only score. Required zone anti-affinity allows at most one matching Pod per zone.
  • Topology spread constraints balance Pods within maxSkew: DoNotSchedule is a hard filter, ScheduleAnyway a scoring preference.
  • Taints repel, tolerations permit but never attract; dedicated nodes need a taint plus a toleration plus a nodeSelector or required affinity.
  • NoExecute evicts running Pods (after tolerationSeconds); NoSchedule and kubectl cordon only block new ones.
  • A higher-priority Pending Pod can preempt lower-priority Pods; preemptionPolicy: Never keeps its queue priority without evicting anything.
  • A DaemonSet runs one Pod on every eligible node; a nodeSelector narrows eligibility, tolerations widen it.
  • A Pod stays Pending when no single node passes filtering; kubectl describe pod shows a FailedScheduling event with the reason per node.
  • A container is an isolated process on a shared host kernel: namespaces control what it sees, cgroups control what it uses, seccomp and AppArmor control what it may do.
  • Containers virtualize the operating system; VMs virtualize the hardware. A base image supplies user-space files only, never a kernel.
  • Isolation is one-way: containers cannot see host processes, but the host sees every container process unless a VM-sandboxed runtime such as Kata is used.
  • Images are stacks of immutable read-only layers; tags are mutable pointers, digests are immutable content hashes. nginx expands to docker.io/library/nginx:latest.
  • Order Dockerfiles so dependency installs come before copying source; clean up temporary files in the same RUN or use a multi-stage build, because a later delete does not shrink the image.
  • The OCI publishes the image, runtime and distribution specs (runc is the reference runtime). The kubelet drives the runtime through the CRI; containerd defaults to runc, CRI-O to crun, and crictl is the CRI-level debugging tool.
  • A RuntimeClass maps a name to a runtime handler, letting Pods opt into sandboxed runtimes such as gVisor or Kata via runtimeClassName.
  • Kubernetes removed the Dockershim in 1.24; Docker-built images still run because they are OCI images, and cri-dockerd is the only way to keep Docker Engine as the node runtime.
  • Images tagged latest or untagged default to imagePullPolicy Always, other tags and digests to IfNotPresent; only a digest pins content, and private pulls need imagePullSecrets.
  • Podman is daemonless and rootless-friendly, runs pods locally and round-trips Kubernetes YAML with podman kube generate and podman kube play; skopeo copies images between registries without a daemon.

Container Orchestration

28% of the exam
  • Every Pod gets its own IP address, and Pods reach each other across nodes without NAT and without a Service; that flat model is implemented by the CNI plugin, and kubeadm leaves nodes NotReady until you install one.
  • A Service provides a stable virtual IP and DNS name in front of ephemeral Pods; any running Pod whose labels match becomes an endpoint, whichever controller created it, and a Pod without a readiness probe counts as ready once running.
  • kube-proxy runs on every node and programs iptables (default), nftables or IPVS (deprecated) rules that turn Service IPs into Pod endpoints; it never handles traffic sent directly to a Pod IP.
  • ClusterIP is internal-only and the default; NodePort opens a high port (30000-32767) on every node; LoadBalancer provisions a cloud load balancer that by default targets those node ports.
  • A headless Service (clusterIP: None) returns Pod IPs directly in DNS and gives StatefulSet Pods names like db-0.db.shop.svc.cluster.local; ExternalName returns a CNAME to an outside hostname.
  • CoreDNS resolves names like api.shop.svc.cluster.local; short names work within the same namespace.
  • Ingress defines layer 7 host and path routing but needs a controller (ingress-nginx is retired); the Gateway API splits a platform-owned Gateway from team-owned HTTPRoutes and supports weighted backends as standard.
  • Pods are default-allow until a NetworkPolicy selects them; a bare podSelector matches only the policy's own namespace, cross-namespace peers need a namespaceSelector, and default-deny egress must explicitly allow DNS on port 53.
  • The 4Cs are Cloud, Cluster, Container, Code, outermost to innermost: nested layers of defense in depth where a weakness in an outer layer undermines the inner ones.
  • RBAC is additive and allow-only; a RoleBinding can reference a Role in its own namespace or a ClusterRole, granting its rules only in that namespace, while a ClusterRoleBinding grants cluster-wide.
  • A ServiceAccount is a Pod's API identity; give workloads dedicated minimal ServiceAccounts and set automountServiceAccountToken: false when the API is not needed.
  • Secrets are base64-encoded in the API (an encoding, not protection) and unencrypted in etcd by upstream default; RBAC guards API access, and an EncryptionConfiguration with a real provider before identity guards etcd data.
  • PodSecurityPolicy was deprecated in 1.21 and removed in 1.25; Pod Security Admission applies Privileged, Baseline, or Restricted per namespace label in enforce (reject), audit (record only) or warn (message only) mode, and modes can use different levels.
  • runAsNonRoot is a start-time check by the kubelet and does not choose a user (runAsUser does); allowPrivilegeEscalation: false blocks later escalation such as setuid.
  • Admission runs after authorization: mutating admission first, then validating admission on the mutated object, with webhooks to engines like OPA Gatekeeper and Kyverno.
  • Supply chain security means scanning for CVEs, signing images and verifying signatures at admission, keeping SBOMs and using minimal base images; pull secrets and digests do not prove provenance.
  • NetworkPolicies turn default-allow networking into allow-lists that block lateral movement, but only when the CNI plugin enforces them.
  • The five Pod phases are Pending, Running, Succeeded, Failed, and Unknown; containers have their own states (Waiting, Running, Terminated), and kubectl shows a Succeeded Pod as Completed.
  • Images are pulled by the kubelet only after the Pod is bound to a node; imagePullPolicy Always contacts the registry on every container start, IfNotPresent uses a cached copy, and Never fails with ErrImageNeverPull when the image is absent.
  • ImagePullBackOff means the image cannot be pulled; CreateContainerConfigError means an env reference to a ConfigMap or Secret (or key) is missing; CrashLoopBackOff means the container ran and keeps exiting.
  • A missing ConfigMap or Secret mounted as a volume gives FailedMount and ContainerCreating; an unbound PVC gives FailedScheduling and Pending.
  • OOMKilled is per container and can happen on a node with free memory; a CPU limit only throttles; node-pressure eviction (memory, disk, PIDs) ends a Pod as Failed with reason Evicted.
  • kubectl logs --previous reads the crashed instance; --since and --tail only filter the instance being read; -c picks a container, --all-containers reads them all, -l selects Pods by label.
  • A failing liveness probe restarts the container; a failing readiness probe only removes the Pod from Service endpoints; a startup probe holds both off - init containers and postStart hooks do not.
  • A Service with no endpoints means its selector matches no Pods or they are not ready; a wrong targetPort leaves ready endpoints that refuse connections, and containerPort is informational.
  • kubectl top shows live usage from metrics-server; kubectl describe shows configured requests and limits.
  • kubectl describe ends with the Events section - FailedScheduling, FailedMount, BackOff and Unhealthy name the cause; events expire after about an hour by default.
  • A NotReady node means its kubelet stopped reporting healthy; kubectl describe node shows the conditions (Ready, MemoryPressure, DiskPressure, PIDPressure).
  • A Volume is declared once in spec.volumes and is visible only to containers that mount it via their own volumeMounts; emptyDir survives container restarts but not Pod deletion.
  • Secrets are the object for sensitive values (own RBAC, optional encryption at rest, tmpfs-backed volumes), but their data is only base64-encoded by default; ConfigMap and Secret keys can also be consumed as environment variables.
  • PersistentVolumes are the cluster-scoped supply of storage; PersistentVolumeClaims are namespaced requests that bind to them one-to-one (receiving the whole PV), and a Pod references a claim in its own namespace, never the PV.
  • The four access modes are ReadWriteOnce (RWO), ReadOnlyMany (ROX), ReadWriteMany (RWX), and ReadWriteOncePod (RWOP) - the abbreviations kubectl prints.
  • ReadWriteOnce limits the volume to one node, not one Pod - a Pod on a second node hits a Multi-Attach error; only ReadWriteOncePod guarantees a single Pod, and it requires CSI.
  • Reclaim policy Retain keeps the PV and its data (status Released, manual cleanup); Delete removes the PV and the underlying storage, and is the default when a StorageClass sets no reclaimPolicy.
  • A StorageClass defines a provisioner and parameters; a PVC referencing it (or the default class) triggers dynamic provisioning, and WaitForFirstConsumer delays it until a Pod is scheduled so zonal disks land in the right zone.
  • CSI is the standard interface storage vendors implement, alongside CRI for runtimes and CNI for networking; it replaced in-tree volume plugins.
  • StatefulSet volumeClaimTemplates create one PVC per replica (like data-db-0); the default retention policy (Retain on scale-down and delete) keeps them, so a recreated replica reattaches its own claim.

Cloud Native Application Delivery

16% of the exam
  • RollingUpdate is the default Deployment strategy; no RollingUpdate setting guarantees old and new versions never overlap, so only Recreate does - at the cost of downtime
  • maxSurge sets the ceiling (replicas + surge, percentages round up) and maxUnavailable the floor (replicas - unavailable, percentages round down); both cannot be 0, and on a full cluster use maxSurge 0
  • kubectl rollout status blocks and exits non-zero when progressDeadlineSeconds passes, making it a pipeline gate; kubectl rollout undo returns to the previous revision
  • Blue-green switches a Service selector between full environments; without a mesh, a canary's traffic share follows its Pod ratio
  • Pin images by a unique version tag or digest - latest and per-environment tags like prod move, and imagePullPolicy only changes when the kubelet pulls
  • The four OpenGitOps principles: declarative, versioned and immutable, pulled automatically, continuously reconciled; deploys are merged pull requests and rollback is git revert
  • Drift is reverted only when the controller is set to do so (Argo CD automated sync with selfHeal; Flux Kustomizations reapply each interval, while HelmRelease drift correction is opt-in) - an imperative rollback on a GitOps-managed object is itself drift
  • Helm: chart (package), chart archive (.tgz), values, release (installed instance), revision; helm rollback records a new revision
  • Kustomize keeps every file valid YAML: kubectl kustomize renders, kubectl diff -k previews, kubectl apply -k applies
  • Cloud Native Buildpacks build images without a Dockerfile; Harbor stores, scans and signs them; Tekton runs CI pipelines, Argo CD and Flux do GitOps
  • A rolling update only progresses as new Pods become available; a bad release stalls while the old ReplicaSet keeps serving
  • maxSurge and maxUnavailable default to 25% (surge rounds up, unavailable rounds down), so a broken 4-replica rollout freezes at 3 old + 2 new Pods
  • Deployment conditions: Available, Progressing and, when Pod creation is rejected, ReplicaFailure; ProgressDeadlineExceeded is a reason on Progressing
  • progressDeadlineSeconds (default 600) counts from the last progress, and exceeding it triggers no automatic rollback
  • ImagePullBackOff = bad image; Running 0/1 with no restarts = readiness failing; climbing RESTARTS = liveness failing; Pending = unschedulable; FailedCreate on the ReplicaSet = quota rejection
  • kubectl rollout history --revision=N only shows a revision; rollout undo --to-revision=N restores it, within revisionHistoryLimit (default 10); CHANGE-CAUSE reads kubernetes.io/change-cause
  • Match the remedy to the diagnosis: rollback cannot add capacity, and restarting Pods reuses the same broken template
  • Helm 4 renamed --atomic to --rollback-on-failure (a failed install is uninstalled) and --wait now takes a strategy; the default hookOnly does not wait for resource readiness
  • Alerts notify and HPAs scale; only a metric-gated rollout such as Argo Rollouts analysis aborts a bad release automatically

Cloud Native Architecture

12% of the exam
  • Metrics measure trends over time, logs record discrete events, traces follow one request across services; Kubernetes Events record what the cluster did to objects and expire after about an hour.
  • Prometheus pulls metrics by scraping HTTP endpoints, keeps 15 days of local history by default, and is queried with PromQL; short-lived batch jobs push to a Pushgateway that Prometheus scrapes.
  • Alertmanager, not Prometheus itself, deduplicates, groups, silences, and routes alerts; a rule's for: duration only delays firing.
  • metrics-server powers kubectl top and the HPA with current CPU and memory only; it keeps no history, has no PromQL, and kubectl logs does not depend on it.
  • Containers log to stdout and stderr; a DaemonSet agent like Fluent Bit ships every container's logs without changing Pod specs, while a sidecar needs a change to each Pod.
  • OpenTelemetry instruments code and propagates trace context vendor-neutrally; Jaeger stores and visualizes traces. Missing context propagation splits one request into several traces.
  • Prometheus, Fluentd, and Jaeger are CNCF graduated projects; exporters adapt third-party systems to Prometheus without changing them.
  • Requests compared with observed usage is the evidence for right-sizing; saturation, read from Prometheus history, tests a resource-bottleneck theory.
  • The CNCF definition names five techniques: containers, service meshes, microservices, immutable infrastructure, and declarative APIs. GitOps and serverless are popular practices, not among the five.
  • Cloud native systems aim to be loosely coupled, resilient, manageable, and observable, with change driven by automation.
  • Microservices trade operational complexity for independent scaling, deployment, and team autonomy; monoliths are simpler to run and debug.
  • A service mesh handles east-west service-to-service traffic (mTLS, retries, traffic shifting) without code changes; API gateways and Ingress handle north-south traffic entering the application.
  • Immutable infrastructure means replace, not patch: ship a new container image instead of modifying a running instance.
  • Declarative APIs plus reconciliation loops produce self-healing: after a node failure, Pods are evicted after the default 300-second toleration and the ReplicaSet controller creates replacements, which the scheduler places on healthy nodes.
  • HPA scales Pod replicas (minimum one by default; zero only on object or external metrics), VPA right-sizes Pod requests, Cluster Autoscaler changes node count, and KEDA scales on events down to zero.
  • Diagnose by symptom: Pending Pods for lack of CPU need nodes (Cluster Autoscaler); OOMKills need a bigger memory limit, not more replicas. Do not let HPA and VPA act on the same metric.
  • Serverless means no server management and scale-to-zero; Knative brings request-driven and event-driven serverless to Kubernetes.
  • OPA is a general-purpose policy engine (Rego); Falco detects runtime threats; Alertmanager routes Prometheus alerts; the OpenTelemetry Collector moves telemetry.
  • The CNCF is a project of the Linux Foundation and a vendor-neutral home for cloud native open source; Kubernetes was its first hosted project and first to graduate.
  • CNCF projects climb three maturity levels in order: Sandbox, Incubating, Graduated. Archived is a status for inactive projects, not a fourth level.
  • Incubating needs independent adopters (dev/test use is enough) and a healthy contributor base; Graduated adds production use, maintainers from at least two organizations and a third-party security review.
  • The TOC accepts projects and votes on maturity moves and archiving by a two-thirds supermajority; the Governing Board handles budget, marketing and business oversight.
  • Archived projects lose CNCF support services and cannot advertise their former level, but the CNCF and Linux Foundation keep their trademarks and domains.
  • Kubernetes SIGs own areas of the code long-term; working groups are temporary, cross-SIG and own no code; the Steering Committee governs Kubernetes as a whole.
  • Maintainers are nominated and approved by existing maintainers under each project's governance, not appointed by the TOC, CNCF staff or employers.
  • End users run the technology, vendors sell around it, ambassadors advocate for it, and Kubestronauts hold all the Kubernetes certifications.

Keep studying KCNA

KCNA flashcards: your questions

Yes — the whole KCNA deck is free and needs no account, as is every KCNA revision lesson. Create a free account to save progress and drill practice questions; full-length mock exams are a one-time unlock per certification.

Source

Exam structure, domain weights and scoring on this page come from the official KCNA exam guide.