KCNA quick review

Memory hook: The API receives, etcd remembers, controllers reconcile, the scheduler places, the kubelet runs.

Must remember

• Kubernetes orchestrates containerised applications. You declare the desired state; control loops repeatedly compare it with the observed state and act on the difference. This supports recovery without a person restarting every failed application.
• A cluster combines a control plane with worker nodes. A node can be a virtual or physical machine. Highly available control planes avoid making one machine the only route to cluster management.
• kube-apiserver exposes the Kubernetes API and is the entry point for clients and components. etcd stores cluster configuration and state. Backing up etcd protects Kubernetes object data; it does not automatically back up files inside application volumes.
• kube-controller-manager runs reconciliation controllers, such as the controller that maintains a requested replica count. kube-scheduler selects a suitable node for an unscheduled Pod. It does not start that Pod's containers itself.
• kubelet runs on each node and works with a container runtime to keep assigned Pods running. kube-proxy, or a networking implementation that replaces its role, supplies Service traffic forwarding. A cloud controller integrates supported cloud infrastructure.
• A Pod is the smallest deployable Kubernetes unit: one or more closely coupled containers with a shared network identity and declared volumes. Containers in one Pod reach each other through localhost; separate Pods have separate identities.
• An object manifest normally has apiVersion, kind, metadata and spec. spec expresses intent; status reports observed conditions. YAML is a representation of API objects, not a different control plane.
• Labels identify and group objects; selectors find matching groups. Annotations carry extra descriptive metadata. Namespaces organise namespaced objects; nodes and PersistentVolumes are examples of cluster-scoped objects.

Read the story behind a Deployment: submit its manifest → controllers create the required child objects → scheduler assigns Pods → kubelets start containers → readiness determines whether application endpoints should receive traffic. A controller may replace a failed Pod with a new identity rather than repair the old Pod in place.

Choose under exam pressure

Traps

• Kubernetes does not provide a complete application database, source repository or build pipeline just because it runs containers.
• A namespace is a scope for organisation and policy, not an automatic network isolation boundary.
• Pod IPs and container writable layers are poor places to keep an application's durable identity or only copy of data.
• Losing API availability affects management and reconciliation; it does not mean every already running container instantly stops.

Practise this topic

Memory hook: Build an image, store it in a registry, run it as a container, group it in a Pod.

Must remember

• An image packages application files, dependencies and startup metadata. A container is a running instance with a writable layer and runtime isolation. A registry stores and distributes image artifacts; it does not schedule applications.
• Containers ordinarily share the host kernel. Virtual machines have a guest operating system and kernel. Containers are lightweight process isolation, not a guarantee of the same isolation boundary as separate VMs.
• Linux namespaces give processes isolated views of resources such as process IDs and networking. Control groups, or cgroups, account for and constrain resource use. Linux namespaces and Kubernetes namespaces are different concepts.
• Image layers enable reuse and caching. A tag such as stable can point to a different image later; a digest identifies specific content. Pin digests when an exact, reproducible artifact matters.
• A Dockerfile describes an image build. A multi-stage build separates compilation tools from the final runtime image. Smaller images can reduce download time and attack surface; they still need patching and vulnerability review.
• The Open Container Initiative, OCI, defines interoperable image, runtime and distribution specifications. Kubernetes' Container Runtime Interface, CRI, lets the kubelet talk to runtimes such as containerd and CRI-O. Image-building tools and node runtimes serve different purposes.
• Kubernetes also uses CNI for container networking integrations and CSI for storage integrations. Remember: CRI runs; CNI connects; CSI stores. These interfaces make implementations replaceable without making their capabilities identical.
• Treat container filesystems as replaceable. Put runtime settings in configuration, keep credentials out of image layers, run as a non-root user where possible, drop unneeded privileges and rebuild patched images instead of manually editing every running container.
• An ordinary init container completes setup before the main application starts. A sidecar supports the application while it runs, for example with a proxy or telemetry agent. Use separate Pods when components need independent scaling or lifecycles.

Choose under exam pressure

Traps

• An image built with Docker can run through a compatible runtime without Docker Engine being the Kubernetes runtime.
• Deleting a secret in a later image layer does not reliably remove it from earlier layers or build history.
• latest is a tag, not a promise that an already running Pod continuously updates itself.
• A container image must support the target operating system and CPU architecture; packaging does not eliminate platform compatibility requirements.

Practise this topic

Memory hook: Context selects the destination; authentication proves identity; authorisation grants actions; admission checks the change.

Must remember

• kubectl is a client of the Kubernetes API. A kubeconfig context combines a cluster, credentials and a default namespace. Check the context before acting; an accurate command aimed at the wrong cluster is still wrong.
• get lists objects, describe adds object details and events, and explain describes API fields. -n team-a chooses a namespace; -A lists across namespaces when authorised. -o yaml or -o json exposes object structure.
• Imperative commands describe an immediate operation, such as creating an object. Declarative management records the desired configuration in manifests and applies it repeatedly. kubectl apply -f file.yaml submits desired configuration; it does not establish a continuously running GitOps controller.
• A ConfigMap carries non-confidential settings. A Secret carries sensitive values and can be mounted or injected into a Pod. Base64 in a Secret manifest is encoding, not encryption; encryption at rest, restricted access and safe handling are separate controls.
• Mounted configuration can update over time, but an application must notice and reload it. Values injected as environment variables do not automatically change in an existing process; replacing Pods is often the intended rollout mechanism.
• Authentication determines who makes an API request. Authorisation, commonly RBAC, determines whether that identity may perform the requested verb on the resource. Admission can validate or mutate an authorised object-creation or modification request before persistence.
• Role and RoleBinding usually express permissions within a namespace. ClusterRole defines reusable or cluster-scoped permissions. A RoleBinding can reference a ClusterRole but grants applicable permissions only in the binding's namespace; a ClusterRoleBinding grants across the cluster.
• ServiceAccounts are workload identities. Prefer short-lived, scoped credentials and omit API token mounting when an application does not need Kubernetes API access. Grant least privilege; a namespace does not justify giving every application cluster-admin.
• Pod Security Standards offer Privileged, Baseline and Restricted profiles. Pod Security Admission can enforce, warn or audit at namespace scope. Application identity, network policy and container hardening protect different layers.

Read-only command recognition:

kubectl config current-context
kubectl get pods -n team-a -o wide
kubectl describe pod app -n team-a
kubectl explain deployment.spec
kubectl auth can-i get secrets -n team-a

Choose under exam pressure

Traps

• Possessing a valid identity does not imply permission to perform every action.
• A Secret object is not automatically encrypted merely because its YAML looks unreadable.
• Listing or watching Secrets can expose secret data; “read-only” is not necessarily harmless.
• ConfigMap or Secret changes do not rebuild an image or automatically restart every consumer.

Practise this topic

Memory hook: Deployment repeats; StatefulSet identifies; DaemonSet covers nodes; Job finishes; CronJob schedules runs.

Must remember

• A ReplicaSet maintains the requested replica count; a Deployment adds rollout management. A StatefulSet does not make database replication, backups or application consistency automatic.
• The scheduler filters and scores nodes against a Pod's requirements. Requests express resources needed for scheduling. Limits constrain runtime usage. For CPU, 500m is half a CPU; memory units such as Mi and Gi are binary quantities.
• CPU over a limit is normally throttled. Exceeding available or permitted memory can lead to an out-of-memory kill. A large request can keep a Pod Pending even while actual node usage appears low.
• nodeSelector matches node labels. Node affinity supports richer required or preferred placement rules. Pod affinity/anti-affinity considers other Pods. Topology spread constraints help distribute replicas across failure domains.
• A taint discourages or prevents placement on a node. A matching toleration allows a Pod to tolerate that taint; it does not guarantee the Pod will be scheduled there. Other resource and placement checks still apply.
• Horizontal Pod Autoscaler, HPA, adjusts replica count from observed metrics. Vertical Pod Autoscaler, VPA, adjusts resource requests according to its configuration. Node autoscaling changes the available node capacity. None of these replaces a functioning application design.
• ResourceQuota limits aggregate resource use in a namespace. LimitRange can set per-object defaults and bounds. They do not grant permissions to users.
• Multiple replicas improve availability only when placement, capacity, readiness and dependent services support it. A PodDisruptionBudget limits certain voluntary disruptions; it does not prevent every hardware failure or guarantee recovery capacity.

Choose under exam pressure

Traps

• A toleration removes a placement obstacle; it does not attract or reserve a node for the Pod.
• Requests influence scheduling even when current measured usage is low.
• A Deployment needs usable labels and selectors to manage the intended Pod set.
• Increasing replicas does not fix a broken image, incorrect configuration or an unavailable external database.

Practise this topic

Memory hook: Pod IPs change; Services give a stable destination; DNS gives a name; policy controls the path.

Must remember

• Each Pod has a network identity. Containers inside one Pod share its network namespace and port space, so they can communicate through localhost but cannot both bind the same address and port.
• A network implementation provides Pod connectivity, commonly through CNI plugins. CoreDNS commonly provides cluster DNS. The mechanism routing Service traffic may be kube-proxy or another implementation.
• A Service describes a stable way to reach a changing set of backends. Label selectors usually identify its Pods, and EndpointSlices record backend addresses and readiness information. A Service does not create those application Pods.

• A headless Service uses clusterIP: None and allows discovery of endpoint addresses rather than providing the normal virtual ClusterIP. It is useful when clients need individual backend identities.
• service.namespace.svc.<cluster-domain> is the normal fully qualified Service name pattern. The cluster domain is often cluster.local, but it is configurable. port is the Service-facing port; targetPort is the backend application port.
• Ingress expresses HTTP/HTTPS routing such as host and path rules. It requires a controller. Gateway API provides more expressive, role-oriented networking APIs and also needs an implementation. Neither an API manifest nor a Service type guarantees external infrastructure exists.
• A NetworkPolicy selects Pods and permits particular ingress or egress traffic. Enforcement requires a supporting network plugin. Policies are additive allow rules: when both ends are isolated, the source egress and destination ingress rules must permit the connection.
• Without applicable isolation policies, standard Kubernetes network policy behaviour is permissive. Namespace separation alone does not block packets. A default-deny policy often needs explicit allowances for DNS and application dependencies.
• A service mesh adds application traffic features such as identity-based mutual TLS, traffic management and telemetry. It can use proxies such as Envoy. It complements basic networking; it does not make RBAC or application authorisation unnecessary.

Choose under exam pressure

Traps

• A ClusterIP Service is not automatically reachable from the public internet.
• A Service with the wrong selector can exist while having no usable application endpoints.
• NetworkPolicy controls connectivity; it does not by itself encrypt packets or decide Kubernetes API permissions.
• A NetworkPolicy object has no useful enforcement effect if the installed network implementation does not support it.

Practise this topic

Memory hook: A volume is mounted, a claim asks, a PV supplies, a StorageClass provisions.

Must remember

• The writable layer of a container is disposable. A volume exposes storage to containers in a Pod. Containers share the volume only when each mounts it; their independent root filesystems are not automatically shared.
• emptyDir starts empty when a Pod is assigned to a node. It survives individual container restarts within that Pod but is removed when the Pod is removed from the node. Use it for scratch data or cooperation between containers, not the only copy of important records.
• A PersistentVolume, PV, represents a storage resource in the cluster. A PersistentVolumeClaim, PVC, is a namespaced request for storage with requirements such as capacity and access mode. A Pod mounts a claim; the claim binds to suitable storage.
• Static provisioning supplies an existing PV. Dynamic provisioning uses a StorageClass and provisioner to create backing storage for a suitable claim. CSI provides an integration standard between Kubernetes and storage systems.
• A PV is cluster-scoped; a PVC is namespaced. The workload and its claim normally belong to the same namespace. Persistent storage has a lifecycle separate from an individual Pod, but its survival still depends on deletion and reclaim settings.

• Access modes depend on driver and backend capabilities. Choosing RWX in YAML does not turn a single-node block disk into a distributed shared filesystem.
• A Retain reclaim policy keeps released storage for deliberate recovery or cleanup. Delete removes the associated storage through its supported provisioner when reclamation occurs. Know which data may disappear before deleting a claim.
• Storage topology matters: a disk can be restricted to a zone or node. A StorageClass with WaitForFirstConsumer delays binding or provisioning until scheduling information is available, helping avoid incompatible placement.
• Block storage provides devices, file storage provides filesystem access, and object storage exposes objects through an API. A cloud object bucket is not automatically a normal POSIX filesystem volume.
• Persistence is not a backup strategy. Protect against application corruption, accidental deletion and infrastructure loss with appropriate backup, restore testing and storage durability choices.

Choose under exam pressure

Traps

• RWO means one node, not necessarily one Pod.
• Deleting a Pod and deleting its PVC are different operations with different data consequences.
• A Pending PVC can indicate missing capacity, an incompatible class or access mode, or delayed binding; it is not always a broken application image.
• A persistent disk can preserve corrupted data just as persistently as correct data.

Practise this topic

Memory hook: Find the failing layer: placement, image, process, readiness, Service, network or dependency.

Must remember

• Start with scope and evidence: current context, namespace, affected objects, recent changes and the intended outcome. kubectl get gives the overview; describe and events explain lifecycle failures; logs explain application behaviour.
• A Pending Pod has not completed setup. Events may reveal insufficient resources, incompatible node selection, a missing volume or other scheduling/setup problems. Do not assume that an application exception causes every Pending state.
• ImagePullBackOff points to repeated image-pull failures: check the image name/tag/digest, registry access, credentials and connectivity. CrashLoopBackOff means a container repeatedly exits or fails and restart attempts are backing off; it describes a symptom, not a unique root cause.
• For crashes, inspect the current and previous container logs, exit reason, command, configuration, Secrets and resource limits. OOMKilled makes memory behaviour a priority. In multi-container Pods, select the correct container with -c.
• Readiness asks whether a container should receive application traffic. Liveness asks whether a running container needs restarting. Startup gives a slow-starting application time to initialise before liveness and readiness checks take over.
• A Pod can be Running without being Ready. A failed readiness check can remove its endpoint from normal Service traffic without restarting the container. Repeated liveness or startup failures can trigger container restart according to the configured behaviour.
• For connectivity, trace name resolution → Service → EndpointSlices → Pod readiness → target port → process listener → policy and dependencies. A mismatched Service selector or wrong target port can look like an application outage.
• For node-level issues, check node readiness, pressure conditions, resource availability and the kubelet/runtime/networking layer. A central application log alone cannot explain every infrastructure failure.
• kubectl exec runs a command in an existing container; kubectl debug can introduce a diagnostic environment when supported and authorised. Minimal images may lack shells or debugging tools. Debug actions require appropriate permissions and can change or expose a workload.
• Change one plausible cause at a time, observe the result and verify user-facing recovery. Repeatedly deleting Pods can erase useful evidence while a controller reproduces the same broken specification.

Read-only command recognition, using example names:

kubectl get pods -n demo -o wide
kubectl describe pod web -n demo
kubectl logs web -n demo -c app --previous
kubectl get events -n demo --sort-by=.metadata.creationTimestamp
kubectl get endpointslices -n demo -l kubernetes.io/service-name=web

Choose under exam pressure

Traps

• A readiness failure is not the same action as a liveness failure.
• Exit status and events are evidence; status labels alone do not establish a root cause.
• The relevant error may be in a previous container instance or another container in the Pod.
• A liveness check that fails whenever an external dependency is temporarily unavailable can create unnecessary restart storms.

Practise this topic

Memory hook: CI proves the change; delivery prepares it; deployment releases it; GitOps keeps reality aligned.

Must remember

• Continuous integration, CI, merges and validates changes frequently through automated builds and tests. Continuous delivery keeps a validated release ready, often with a human approval before production. Continuous deployment automatically releases qualifying changes to production.
• A typical path is commit → build → test/scan → immutable artifact → deploy → verify. Build once and promote the reviewed artifact when possible. Rebuilding separately for every environment risks deploying content different from what was tested.
• GitOps uses declarative desired state kept in version control, with agents pulling that state and continuously reconciling the live system. Git history supports review and traceability; the reconciler detects and corrects drift.
• Argo CD and Flux are recognisable GitOps delivery projects. A CI script that runs kubectl apply is automation, but it does not by itself provide continuous pull-based reconciliation.
• Helm packages applications as charts with templates and values, and tracks installed releases. Kustomize composes and patches Kubernetes manifests using bases and overlays without requiring a general template language. Either can supply desired manifests to a delivery process.

• Kubernetes Deployments support rolling updates and recreates. A meaningful canary requires a deliberate way to control exposure and judge results; simply creating a new Pod is not a complete release strategy.
• maxSurge controls temporary extra replicas during a rolling update; maxUnavailable controls permitted unavailability. Readiness helps prevent premature traffic to new Pods. Resource headroom matters when old and new replicas overlap.
• Rollback restores a prior application configuration or artifact. It does not automatically reverse database schema migrations, external messages or user-visible data changes. Design compatibility and recovery before releasing.
• Secure the supply chain with reviewed dependencies, trusted registries, image scanning, provenance/signature checks and least-privilege pipeline credentials. SBOMs describe software components; they are not proof that a release has no vulnerabilities.
• Deployment success needs observation: healthy Pods are necessary but do not alone prove acceptable latency, error rate or business behaviour.

Choose under exam pressure

Traps

• Continuous delivery does not necessarily mean automatic production deployment.
• Git is not a secret manager; plain credentials in repository history remain exposed even after a later deletion.
• An automatic rollback cannot safely undo every stateful business operation.
• An image scan and a successful deployment are different checks; neither replaces runtime monitoring.

Practise this topic

Memory hook: Metrics show the trend, logs explain events, traces follow the journey.

Must remember

• Observability is the ability to understand internal system behaviour using emitted evidence. Monitoring detects conditions you have chosen to watch; useful telemetry also helps investigate unexpected problems.
• Metrics are numeric measurements over time, suited to rates, resource use and service health. Logs record events with context. Distributed traces connect spans across services to show where a request spent time or failed. Correlation identifiers help connect the signals.
• Prometheus collects and queries time-series metrics. A common model is to scrape HTTP metrics endpoints using service discovery. An exporter exposes metrics for a component that does not provide them directly. PromQL is the query language.
• Alertmanager groups, deduplicates and routes alerts, and supports silencing/inhibition. A dashboard displays evidence; it is not a substitute for an actionable alert with ownership and a response plan.

• Use a counter's rate over an interval for requests per second, rather than treating its cumulative total as a current rate. Avoid unbounded labels such as user IDs or raw request IDs; high cardinality increases storage and processing work.
• OpenTelemetry supplies vendor-neutral instrumentation, telemetry APIs/SDKs and collection/export components. Its Collector can receive, process and export signals. It is not itself the complete long-term storage and dashboard backend.
• Jaeger is associated with distributed tracing. Fluentd and Fluent Bit collect and forward logs or telemetry. Recognise the tool's job before matching it to a scenario.
• Latency, traffic, errors and saturation are useful service health signals. Latency percentiles reveal slow-tail behaviour that an average can hide. Measuring only CPU can miss a user-visible failure caused by another service.
• An SLI is a measured indicator; an SLO is the target for it; an SLA is a commitment with contractual implications. An error budget expresses tolerated unreliability against an SLO over its chosen window. A 99.9% request-success SLO permits 0.1% unsuccessful eligible requests under that definition.
• Kubernetes resource metrics, such as those often exposed through Metrics Server for kubectl top and autoscaling, do not constitute a complete historical observability platform. Cost visibility also needs resource attribution, requests versus usage, retention and billing awareness.

Choose under exam pressure

Traps

• Collecting more logs is not automatically better; noisy or sensitive logs create cost and security problems.
• Average latency can hide a poor experience for the slowest requests.
• A trace is not necessarily a record of every request; sampling affects what is retained.
• Prometheus metrics are not a substitute for a complete, exact per-request financial ledger.

Practise this topic

Memory hook: Design for change and failure; choose a tool by its job; contribute through an open process.

Must remember

• Cloud native describes ways to build and operate applications that adapt to dynamic environments through automation, resilience and manageable change. It is not limited to one public cloud: cloud native systems can run on premises, at the edge or across cloud providers.
• Microservices split an application into independently deployable services around clear responsibilities. They can improve independent scaling and ownership but add distributed communication, data-consistency and operational complexity. A monolith can still use containers and modern delivery practices.
• Loose coupling limits how much components must know about each other. APIs, events and queues can reduce direct dependencies, but contracts, retries and failure handling remain necessary. Repeated retries need backoff and safe/idempotent behaviour to avoid amplifying failures.
• Immutable infrastructure favours replacing a versioned component over manually patching it in place. Declarative configuration records intended state. Automation and reconciliation make repeatable changes possible; neither prevents a bad specification from being applied consistently.
• Resilience plans for partial failure using replicas, health checks, distribution, timeouts, recovery and tested dependencies. Elasticity adjusts capacity with demand. Scalability is the ability to handle growth; it does not require that every scaling decision be automatic.
• Serverless moves more provisioning and scaling responsibility to a platform and often uses event-triggered execution. Servers still exist; users retain responsibility for code, permissions, data and service limits. Knative is an ecosystem example for serverless workloads on Kubernetes.

• CNCF is a vendor-neutral home for open source cloud native projects within the Linux Foundation. Its landscape groups projects by purpose; inclusion is not a statement that every project solves every problem or has identical maturity.
• CNCF maturity levels include Sandbox, Incubating and Graduated. Graduation reflects evidence of project maturity, governance and adoption under CNCF criteria; it does not certify that a particular deployment is secure or guaranteed to fit your requirements. Archived status is different from active graduation.
• Open source communities collaborate through public repositories, issues, pull requests, design proposals, reviews and meetings. SIGs, working groups, maintainers and contributors organise work. Read a project's contribution guide, governance and code of conduct before submitting changes.
• Useful contributions include documentation, translations, reproducible bug reports, testing, accessibility, triage and code. Follow the project's licence and contribution requirements, such as DCO sign-off or a CLA when requested. Open source does not mean “no licence conditions.”

Choose under exam pressure

Traps

• Running an unchanged application in a public cloud does not automatically give it resilient cloud native behaviour.
• Microservices, Kubernetes and a service mesh are architectural choices, not compulsory ingredients for every application.
• A Graduated project can still be misconfigured, compromised or unsuitable for a particular requirement.
• Open source permits use under its licence; it does not eliminate ownership, attribution or redistribution obligations.

Practise this topic