Use this guide to connect Kubernetes resource definitions with application behavior. Each concept explains a practical distinction, resolves an original example, and identifies a specific mistake. Work through the foundations first, then apply them to deploying, exposing, and diagnosing applications.
Application design and build
1. Resource definitions and desired state
A Kubernetes manifest identifies a resource through apiVersion, kind, and metadata, then describes its desired configuration. Controllers reconcile managed resources toward that configuration asynchronously. API acceptance establishes that a request was accepted; status, conditions, and dependent objects show whether the intended application state was reached.
Worked example: A Deployment requesting three replicas is accepted, but only two Pods become ready. The definition exists successfully; the application has not yet reached its requested availability.
Mistake to avoid: Treating successful creation of a resource as proof that its application is healthy.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education; Certified Kubernetes Application Developer (CKAD) | CNCF
2. The Pod as a shared execution boundary
Containers in one Pod share a network namespace, including the Pod IP and port space. Their image filesystems remain separate, although explicitly mounted volumes can share files. Group containers when they require close coordination and a common lifecycle, rather than merely because they belong to the same application.
Worked example: An application listens on port 8080. Its companion container reaches it through localhost:8080, but needs a shared volume to read files the application writes.
Mistake to avoid: Assuming colocated containers automatically share their entire filesystem or can bind the same port.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
3. Labels and selector logic
Labels identify object attributes that selectors can match. Annotations carry supplementary metadata and are not ordinary label-selector targets. Multiple requirements within a label selector must all match. Stable application labels help controllers and Services find their intended objects without depending on changing Pod names.
Worked example: A selector requiring app=ledger and tier=api matches a Pod carrying both labels. A Pod labeled only app=ledger does not match.
Mistake to avoid: Placing routing metadata in annotations and expecting a Service selector to find it.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education; Certified Kubernetes Application Developer (CKAD) | CNCF
4. Container image construction
An OCI-compatible image packages application files and execution configuration. A build stage can compile software while a separate runtime stage contains only the artifacts needed to execute it. Rebuilding an image creates a new artifact; editing a running container does not update the image used for future Pods.
Worked example: A compiler stage produces a reporting binary. Copying that binary into a smaller runtime stage avoids shipping the compiler while preserving the executable.
Mistake to avoid: Embedding credentials in image layers, where removing the file later may leave recoverable data.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education; Certified Kubernetes Application Developer (CKAD) | CNCF
5. Commands, arguments, and shell expansion
A container's command and args can override its image's default startup configuration. Kubernetes does not automatically run those values through a shell. Shell features such as pipelines and redirection require an explicit shell invocation, and that shell must exist in the image.
Worked example: To run a pipeline, an image containing a shell can use command ["/bin/sh", "-c"] with the pipeline as one argument. Passing a pipe symbol directly to an executable creates a literal argument.
Mistake to avoid: Assuming every image contains a shell or automatically interprets shell syntax.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
6. Choosing a workload resource
Choose a controller according to workload lifecycle and identity. Deployments manage interchangeable replicas; StatefulSets provide stable replica identity and storage associations; DaemonSets run Pods on eligible nodes. Jobs manage finite work, while CronJobs schedule it. Controller behavior does not supply application-level replication or data consistency.
Worked example: An interchangeable HTTP frontend fits a Deployment. A node-local log collector fits a DaemonSet because its placement follows eligible nodes rather than a fixed replica count.
Mistake to avoid: Choosing a StatefulSet solely because an application writes files, without requiring stable replica identity.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
7. Jobs and successful completion
A Job manages Pods that should finish successfully. Completions describes the required successful work, while parallelism controls how many Pods may run concurrently. Retries can repeat application effects, so the program should handle duplicate attempts or partially completed operations.
Worked example: A Job with completions=6 and parallelism=2 needs six successful completions while running at most two Pods concurrently under normal controller operation. Processing must tolerate retried work.
Mistake to avoid: Interpreting parallelism as the number of successful completions required, or assuming execution happens exactly once.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
8. CronJobs and overlapping runs
A CronJob creates Jobs according to a schedule. Its concurrency policy governs overlap among Jobs belonging to that CronJob. Forbid skips a scheduled run when an earlier Job remains active; it does not queue every missed execution or prevent unrelated workloads from running.
Worked example: A report is scheduled every ten minutes but takes fifteen minutes. With Forbid, the next scheduled execution is skipped while the previous report Job remains active.
Mistake to avoid: Assuming a schedule or concurrency policy guarantees exactly one execution for each intended business operation.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
9. Ordinary init containers
Ordinary init containers run sequentially and must complete successfully before application containers start. They suit finite preparation tasks, such as generating configuration in a shared volume. Their images and mounts are defined separately from those of application containers.
Worked example: An init container writes a generated configuration file into a shared volume and exits successfully. The application mounts that volume and starts with the prepared file.
Mistake to avoid: Putting a permanently running helper into an ordinary init container, preventing application startup.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
10. Sidecars and shared application support
A sidecar is a supporting container that runs alongside the primary application, such as a local proxy or file-processing helper. Coordinate shared ports, volumes, readiness, and termination behavior. A sidecar pattern describes an architectural relationship; lifecycle details depend on how the container is declared.
Worked example: A web application writes files to a shared volume, and a helper processes them continuously. Both containers mount the volume, while only the application receives public traffic.
Mistake to avoid: Assuming placing a helper beside an application automatically provides startup ordering or coordinated shutdown.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
11. Ephemeral storage lifetime
A container's writable layer and a Pod's emptyDir have different lifetimes. An emptyDir survives container restarts within the same Pod, but its data disappears when that Pod is removed. Use it for scratch files or sharing data between colocated containers when persistence beyond the Pod is unnecessary.
Worked example: A worker restarts inside its existing Pod and can still read cached files from emptyDir. A replacement Pod starts with a new, empty volume.
Mistake to avoid: Using emptyDir for records that must survive Pod replacement.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
12. PersistentVolumeClaims and application storage
A PersistentVolumeClaim requests storage with specified capacity, access modes, and other requirements. A Pod references a claim in its namespace. Binding associates the claim with storage, but attachment, mounting, and filesystem access must still succeed. Storage persistence also depends on the backing implementation and reclaim behavior.
Worked example: A claim requesting 4Gi can bind to a compatible 6Gi volume because requested capacity is a minimum. The application still needs an appropriate mount path and file permissions.
Mistake to avoid: Reading ReadWriteOnce as a guarantee that only one Pod can access the volume.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
Application environment, configuration, and security
13. Namespaces and resource identity
Namespaced objects are identified by resource type, name, and namespace. The same name can exist in different namespaces. Other resources, including Nodes and PersistentVolumes, are cluster-scoped. A namespace organizes resources; separate authorization and network controls determine access and isolation.
Worked example: A ConfigMap named settings in namespace billing is different from settings in namespace support. A billing Pod's ordinary ConfigMap reference uses the billing object.
Mistake to avoid: Looking in the default namespace and concluding that a resource in another namespace does not exist.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education; Certified Kubernetes Application Developer (CKAD) | CNCF
14. ConfigMap consumption
ConfigMaps hold ordinary configuration separately from container images. A container can consume selected keys as environment variables or mount values as files. Choose the form that the application actually reads. Explicit key references make configuration dependencies easier to inspect than importing every key indiscriminately.
Worked example: A ConfigMap contains MODE=preview. A container environment variable using configMapKeyRef supplies that value when the container starts, allowing one image to serve different environments.
Mistake to avoid: Creating a ConfigMap without connecting it to the container's environment, arguments, or mounted files.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
15. Configuration changes and running processes
Changing a ConfigMap does not update environment variables already loaded by a process. Ordinary projected volume files can update eventually, but the application must reread them. A ConfigMap file mounted through subPath does not receive those automatic updates. Decide whether configuration changes require application reload or Pod replacement.
Worked example: A process reads MODE from its environment at startup. Updating the ConfigMap leaves the existing process unchanged; replacing its Pod lets the new process receive the updated value.
Mistake to avoid: Assuming every ConfigMap change immediately alters application behavior.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
16. Secret encoding and confidentiality
Secrets represent sensitive configuration and require restricted access. Base64 in a Secret's data field is an encoding, not encryption. stringData accepts ordinary strings for conversion into stored data. Protection depends on access controls, cluster storage safeguards, and careful handling outside Kubernetes.
Worked example: A password encoded in base64 can be decoded by anyone who obtains the encoded value. Moving it from a ConfigMap to a Secret does not justify printing it in logs.
Mistake to avoid: Treating base64 representation as a confidentiality mechanism.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
17. Consuming application and registry Secrets
Applications can consume Secret keys through environment variables or mounted files. Private image retrieval uses imagePullSecrets instead, with credentials appropriate to the registry. These mechanisms solve different problems. References must identify suitable Secrets in the Pod's namespace.
Worked example: A Pod uses registry credentials through imagePullSecrets to retrieve its image, then mounts a separate database credential Secret for the application to read.
Mistake to avoid: Expecting credentials in an application environment variable to authenticate the node's image pull.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
18. ServiceAccounts as workload identities
A ServiceAccount supplies a Kubernetes API identity for a workload. The Pod selects it through serviceAccountName, while authorization grants determine its permissions. An application that does not call the API may not need automatically mounted API credentials. This identity is separate from the container's operating-system user.
Worked example: A report generator uses a dedicated ServiceAccount permitted to read one relevant resource type. A static frontend disables automatic credential mounting because it makes no API calls.
Mistake to avoid: Assuming a named ServiceAccount automatically receives the permissions its application needs.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
19. Authentication, authorization, and admission
Authentication establishes the caller's identity. Authorization determines whether that identity may perform the requested operation. Admission can then validate or modify an otherwise authorized request. These stages explain different failures: permission to create Pods does not guarantee that every proposed Pod satisfies admission requirements.
Worked example: A user is authenticated and authorized to create Pods, but admission rejects a Pod that violates required security settings. Adding broader RBAC permissions would not resolve that rejection.
Mistake to avoid: Treating all API rejections as missing authorization.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
20. RBAC rules and permission reach
RBAC rules grant verbs on resources in particular API groups. A RoleBinding grants permissions within its namespace, including when it references a ClusterRole. A ClusterRoleBinding grants the referenced permissions across the cluster. Applicable grants are additive, and access to subresources can require distinct permissions.
Worked example: Granting get on pods does not also grant get on pods/log. A logging tool needs the relevant log subresource permission in the intended namespace.
Mistake to avoid: Using a ClusterRoleBinding when the application only needs access in one namespace.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
21. Resource requests and scheduling
Requests contribute to the scheduler's accounting of needed capacity. CPU is commonly expressed in millicores, with 1000m equal to one CPU. Memory requests use quantities such as Mi. Compare requested resources with allocatable capacity and existing reservations, rather than relying solely on low observed usage.
Worked example: A container requests 250m CPU, or one quarter of a CPU. Four such requests total 1000m before accounting for any other containers or scheduling constraints.
Mistake to avoid: Expecting a Pod to schedule because a node appears idle despite insufficient unreserved requested capacity.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
22. Resource limits and runtime behavior
Limits constrain runtime consumption rather than reserving scheduling capacity. CPU limits can cause throttling; memory-limit violations can lead to container termination. Requests and limits therefore answer different questions. Interpret application latency and termination evidence before deciding which resource setting needs adjustment.
Worked example: A container requests 200m CPU and has a 500m limit. The request contributes 200m to scheduling accounting, while sustained CPU demand beyond the limit can be throttled.
Mistake to avoid: Assuming a memory limit behaves like a CPU limit by merely slowing the process.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
23. Accounting for all Pod containers
Resource requirements belong to containers, and colocated containers contribute to Pod demand. Sum ordinary application-container requests when assessing their combined requirements. Init containers, restartable sidecars, Pod overhead, and any Pod-level resource configuration can affect effective accounting, so inspect the complete admitted specification.
Worked example: Two ordinary application containers request 300m and 150m CPU, plus 128Mi and 64Mi memory. Their combined requests are 450m CPU and 192Mi memory.
Mistake to avoid: Calculating Pod requirements from only the primary application container.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
24. ResourceQuota and LimitRange
ResourceQuota limits aggregate resource consumption or object counts within a namespace. LimitRange can impose per-object constraints and default resource values. Defaults may change the resource requirements of the admitted Pod. A quota rejection differs from a Pod accepted successfully but left pending by the scheduler.
Worked example: A namespace quota permits 2 CPU of requests, with 1500m already used. A new 600m request exceeds the remaining 500m and can be rejected during admission.
Mistake to avoid: Investigating node capacity before checking an explicit namespace quota rejection.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
25. Execution identity and filesystem permissions
Security contexts can configure a container's execution user and related filesystem settings. Non-root execution reduces privileges but must remain compatible with the image and mounted data. Settings such as a read-only root filesystem also require writable locations for files the application legitimately creates.
Worked example: An application running as UID 1001 cannot write a root-owned, non-writable directory. Providing a suitably permitted mounted directory resolves the need without changing to root.
Mistake to avoid: Assuming runAsNonRoot automatically fixes image ownership or mounted-file permissions.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
26. Capabilities and privilege escalation
Linux capabilities divide privileged operating-system actions into narrower permissions. Dropping unnecessary capabilities and preventing privilege escalation can reduce a container's authority. These settings govern process execution, while RBAC governs Kubernetes API access. Each control must match the application's actual requirements.
Worked example: A worker needs ordinary filesystem and network operations but no special host privileges. It can drop unnecessary capabilities and disable privilege escalation while retaining only the permissions needed to run.
Mistake to avoid: Granting privileged mode to solve an ordinary file-permission problem.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
27. Custom resources and Operators
A CustomResourceDefinition adds an API resource type with a schema and scope. A controller supplies the behavior associated with those objects; an Operator typically uses controllers to encode application operations. Discovering a resource type and verifying its controller are separate checks.
Worked example: A BackupPlan custom resource is accepted, but no backup occurs. The definition exists; inspect the responsible controller and the resource's status to determine why reconciliation is absent.
Mistake to avoid: Assuming installing a CustomResourceDefinition alone implements its promised behavior.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
Application deployment
28. Deployment templates and ownership
A Deployment manages ReplicaSets, which manage Pods created from a Pod template. Change application settings in the managing template so replacements inherit them. Deployment selectors must agree with template labels, and their immutability makes deliberate label design important.
Worked example: A managed Pod has the wrong environment variable. Updating the Deployment's Pod template produces replacement Pods with the corrected value; editing one Pod would not establish the desired configuration.
Mistake to avoid: Deleting a managed Pod and expecting its replacement to have different settings.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
29. Rollout progress and application verification
A Deployment rollout replaces Pods after a relevant template change. rollout status reports controller progress, but application verification must also check readiness and intended behavior. Inspect updated, ready, and available replicas to understand whether the desired revision has become usable.
Worked example: A new image starts successfully but fails readiness checks. New Pods exist, yet the rollout does not establish the expected available replicas; inspect probe results and application logs.
Mistake to avoid: Declaring deployment success merely because the new image appears in the template.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
30. Rolling-update capacity budgets
maxSurge permits extra replicas during a rolling update, while maxUnavailable permits fewer available replicas than desired. These values guide replacement behavior and require sufficient capacity for any surge. They do not guarantee availability through unrelated failures, and terminating Pods can affect observed counts.
Worked example: With four desired replicas, maxSurge=1 and maxUnavailable=0, the controller can add a replacement before removing an available old replica, targeting at least four available replicas during replacement.
Mistake to avoid: Setting zero unavailability while overlooking the capacity needed to start replacement Pods.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
31. Deployment rollback boundaries
Deployment revision history records Pod-template changes that can support rollback. Undoing a rollout restores a retained template revision, rather than every dependency the application uses. External configuration, persistent data, and database migrations need separate compatibility consideration.
Worked example: An earlier image revision is restored, but its referenced ConfigMap name is unchanged and that ConfigMap now contains new values. The rollback does not restore the old configuration data.
Mistake to avoid: Assuming rollback reverses database changes or every configuration edit.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
32. Blue-green deployment selection
Blue-green deployment maintains distinguishable old and new application versions, then switches the traffic selection when the new version is ready. A Service selector can implement that switch. Both versions need adequate capacity and compatible dependencies, and existing connections may not move immediately.
Worked example: A Service initially selects app=search, release=blue. After verifying green Pods, changing release to green directs new Service traffic to the green population.
Mistake to avoid: Leaving the Service selector broad enough to include both colors unintentionally.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
33. Canary deployment and traffic assumptions
A canary exposes a limited population to a new version while the established version remains available. Separate Deployments can share a Service selection. Replica ratios alone do not guarantee exact traffic percentages because connection reuse, request patterns, and forwarding behavior influence distribution.
Worked example: Nine stable replicas and one canary replica provide a small canary backend population. They do not prove that exactly ten percent of requests reach the canary.
Mistake to avoid: Treating a Pod-count ratio as a precise traffic-weight configuration.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
34. Image references and pull behavior
An image tag is a named reference whose registry content can change; a digest identifies specific image content. imagePullPolicy affects retrieval behavior when a container starts. Updating a Deployment's image reference and verifying resulting Pods is more reliable than assuming a reused tag automatically triggers replacement.
Worked example: A registry tag changes from one build to another, but the Deployment template remains identical. That registry change alone does not initiate a new Deployment rollout.
Mistake to avoid: Using a moving tag as proof that every running replica contains the same build.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
35. Helm charts and releases
A Helm chart packages templates and defaults; a release is an installation of a chart. Chart version and application image version describe different artifacts. Release names, target namespaces, and supplied values determine the intended installation and must agree with the application's deployment requirements.
Worked example: The same chart is installed as releases orders-preview and orders-live with different values. They are separate installations, although both originate from the same package.
Mistake to avoid: Assuming a chart version number directly identifies the container image version.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
36. Helm values and rendered manifests
Values customize a chart only through keys its templates actually use. Rendering manifests makes the resulting images, labels, ports, permissions, and storage visible before installation. Valid YAML in a values file does not prove that the chart recognizes the requested customization.
Worked example: A chart expects replicaCount, but a values file supplies replicas. Rendering shows the default count unchanged, revealing the incorrect key before deployment.
Mistake to avoid: Assuming every chart uses the same value names or structure.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
37. Helm upgrades and rollback
A Helm upgrade changes an existing release using chart content and effective values. Inspect release history and generated resources when diagnosing an upgrade. Helm rollback targets an earlier release revision, but application data, external services, and irreversible migration effects still need separate treatment.
Worked example: An upgrade changes a frontend image and Service configuration. Rolling back the release can restore its earlier managed definitions, but it does not erase records written to an external database.
Mistake to avoid: Treating package rollback as a complete recovery mechanism for application state.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
38. Kustomize bases and overlays
Kustomize composes Kubernetes manifests through reusable bases and environment-specific overlays. It transforms existing resource definitions rather than using Helm-style template expressions. An overlay can adjust replicas, labels, images, and other settings while preserving a shared foundation.
Worked example: A base defines a two-replica frontend. A preview overlay changes it to one replica and selects a preview image, producing environment-specific manifests from the shared resources.
Mistake to avoid: Editing the shared base for a change intended only for one environment.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
39. Kustomize patches and generated configuration
Patches should target the intended resource and modify the intended field. Configuration generators can produce names with content-derived suffixes, allowing recognized references to follow generated objects. Always inspect the rendered output, especially when custom resources or unusual reference fields are involved.
Worked example: An overlay generates a ConfigMap and patches a Deployment's replica count. Rendering verifies both the new count and the Deployment's reference to the generated ConfigMap name.
Mistake to avoid: Assuming every custom string field receives automatic reference rewriting.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
Services and networking
40. Service selection and EndpointSlices
A selector-based Service discovers matching Pods in its own namespace. EndpointSlices represent backend addresses and conditions as Pods change. Normal Service traffic depends on suitable endpoint readiness, so a correct Service definition still requires matching, usable backends.
Worked example: A Service selects app=invoice, but its Pods carry app=invoices. No matching backends appear. Correcting the label relationship resolves selection before investigating external routing.
Mistake to avoid: Assuming a Service can select Pods in another namespace through ordinary Pod labels.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
41. Service port and targetPort
The Service port is the port clients use; targetPort is the backend destination port. A named targetPort resolves through matching named Pod ports. Declaring containerPort does not start a listener, and the chosen protocol must match the application.
Worked example: A Service exposes port 80 and forwards to targetPort 8081. Clients use port 80, while the application must actually listen on 8081 inside its Pod.
Mistake to avoid: Changing containerPort alone and expecting the application's listening socket to change.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
42. Choosing a Service type
ClusterIP provides an internal Service address. NodePort exposes a port through configured node access paths. LoadBalancer requests an external load-balancing implementation, whose availability depends on the environment. Select the type according to the required client path and verify the supporting network integration.
Worked example: An internal worker calling an internal API can use ClusterIP. Creating a LoadBalancer Service in an environment without a supporting implementation does not establish an external endpoint.
Mistake to avoid: Treating the Service type as proof that external networking has been provisioned successfully.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
43. Service DNS and namespace qualification
Service DNS names let applications discover stable service identities. A short name commonly resolves within the querying Pod's namespace. Cross-namespace access needs qualification, such as service.namespace. Fully qualified names also depend on the configured cluster domain, which should not be assumed universally.
Worked example: A Pod in checkout calls pricing.catalog to reach the pricing Service in namespace catalog. Using pricing alone would normally search for a Service in checkout.
Mistake to avoid: Diagnosing a missing Service when the client is resolving the name in the wrong namespace.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
44. Headless Services and endpoint discovery
A headless Service sets clusterIP to None and does not receive the ordinary virtual Service IP. With a selector, DNS can expose backend addresses directly. Clients must handle endpoint discovery and selection appropriately; readiness and publishing settings also influence which addresses are discoverable.
Worked example: A client discovers individual cache replica addresses through a headless Service and chooses the required replica itself, rather than connecting through one virtual Service address.
Mistake to avoid: Expecting a headless Service to provide ordinary virtual-IP load balancing.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
45. Ingress resources and controllers
Ingress describes HTTP or HTTPS routing intent, while an Ingress controller implements it. The selected IngressClass and controller configuration determine which implementation handles the resource. Creating an Ingress without a suitable controller does not establish an external access path.
Worked example: An Ingress references a valid Service, but no controller handles its class. Backend health can be correct while the intended external route remains unavailable.
Mistake to avoid: Treating Ingress as a Service type or assuming every cluster has a working controller.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
46. Ingress host and path matching
Ingress rules match request hosts and paths before selecting a backend Service. Exact paths require an exact match; Prefix paths use path-element matching. ImplementationSpecific delegates interpretation to the controller. The backend port refers to a Service port, rather than directly choosing a Pod port.
Worked example: A Prefix rule for /shop matches /shop/cart but does not match /shopping. A request must also satisfy any host requirement in that rule.
Mistake to avoid: Assuming Prefix means any arbitrary string beginning with the same characters.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
47. Ingress TLS and backend transport
Ingress TLS configuration associates hosts with a certificate Secret, subject to controller support and configuration. Certificate identity must match the requested hostname. TLS termination at the controller does not automatically establish encrypted transport from that controller to the backend application.
Worked example: A browser requests portal.example.test. The certificate must cover that hostname; a certificate for reports.example.test does not satisfy the identity check merely because both routes share an address.
Mistake to avoid: Assuming client-facing HTTPS proves that every downstream connection is also encrypted.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
48. NetworkPolicy isolation and additive allowances
NetworkPolicy selects Pods and controls ingress, egress, or both when the network implementation enforces it. Isolation applies separately to each direction. Allowed traffic is the union of applicable rules. A connection between isolated workloads must satisfy both source egress and destination ingress restrictions.
Worked example: A database allows ingress from an API, but the API's egress policy allows only DNS. The database connection remains blocked until source egress also permits it.
Mistake to avoid: Reading policies as ordered firewall rules where the final rule overrides earlier allowances.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
49. NetworkPolicy peer selector combinations
Within one peer entry, namespaceSelector and podSelector jointly select Pods satisfying both conditions. Separate peer entries describe alternatives. A podSelector alone selects peers in the policy's namespace. YAML structure therefore changes the population permitted to connect.
Worked example: One peer combining namespace label team=payments and Pod label role=api permits payment-team API Pods. Splitting those selectors into separate peers permits a broader union.
Mistake to avoid: Separating selectors into different list entries when both conditions must hold.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
50. Egress policies and DNS dependencies
Restricting egress requires accounting for the application's actual dependencies, including name resolution. DNS may use UDP and TCP, and its destination depends on cluster configuration. Permit the required resolver path deliberately rather than opening unrelated outbound access when names stop resolving.
Worked example: An isolated client can reach an approved API by address but cannot resolve its name. Allowing the configured DNS destination and required DNS transports repairs discovery without broadening API access.
Mistake to avoid: Permitting only application traffic while overlooking DNS, or assuming every cluster uses identical DNS labels and addresses.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
51. Tracing the application traffic path
Diagnose connectivity in stages: name resolution, destination selection, Service port mapping, backend readiness, network policy, and application response. Test equivalent protocols and request assumptions at each boundary. A successful backend test narrows the fault but does not prove Service or external routing works.
Worked example: A ready Pod responds directly on 8080, but its Service forwards to 9090. Correcting targetPort repairs the Service path without changing the application.
Mistake to avoid: Comparing tests with different host headers or paths and attributing the difference solely to networking.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
Application observability and maintenance
52. API discovery and deprecation
A manifest's apiVersion must identify an API served by the target cluster. Deprecated APIs may remain available temporarily, while removed APIs cannot accept requests. Use API discovery and field documentation to inspect supported resources, then review migration requirements rather than merely replacing a version string.
Worked example: A manifest fails because its API version is not served. kubectl api-resources identifies the available resource, and kubectl explain helps inspect the supported definition before migration.
Mistake to avoid: Assuming an API version change never requires changes to fields or behavior.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
53. Readiness and traffic eligibility
Readiness checks whether a container is prepared to serve traffic. Failure makes it unready without restarting it solely for that reason. Service endpoint eligibility normally reflects readiness. A useful check tests the application's ability to handle its intended requests rather than only whether a process exists.
Worked example: An API temporarily cannot obtain required configuration. Its readiness check fails, removing normal Service traffic eligibility while leaving the process running to recover.
Mistake to avoid: Using readiness failure as evidence that Kubernetes must restart the container.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
54. Liveness and restart decisions
Liveness checks whether a running container needs recovery through restart. Repeated failures reaching the configured threshold can cause a restart. Choose checks for failures that restarting can plausibly repair. Depending on a remote service for liveness can turn an external outage into unnecessary local restart loops.
Worked example: A process deadlocks and its local health endpoint stops responding. A suitable liveness check detects the failure and triggers a restart under the container's restart policy.
Mistake to avoid: Making liveness fail whenever an unrelated downstream service is unavailable.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
55. Startup probes for slow initialization
A startup probe protects initialization by withholding liveness and readiness probing until startup succeeds. Its configured failure allowance should accommodate expected initialization without concealing indefinite failure. After success, ordinary health checks take over; startup success does not permanently establish application readiness.
Worked example: An application needs about forty seconds to initialize. A startup probe with a ten-second period and failureThreshold=6 provides roughly sixty seconds of startup allowance before repeated failures trigger recovery.
Mistake to avoid: Giving every container an extremely long liveness delay to accommodate one slow startup.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
56. Pod status, conditions, and events
Pod phase is a broad lifecycle summary; container states, readiness conditions, and events provide more precise diagnostic evidence. A Running Pod can still contain an unready or repeatedly failing container. kubectl get and describe reveal different levels of detail, while usage metrics require a functioning metrics source.
Worked example: A Pod is Pending with no assigned node, and scheduler events report insufficient requested memory. That evidence points to scheduling capacity rather than application startup.
Mistake to avoid: Diagnosing the cause from one displayed status label without inspecting conditions and events.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
57. Selecting container logs and execution instances
Logs must correspond to the correct Pod, container, and execution instance. Select the container explicitly in multi-container Pods, and use previous logs when investigating an earlier terminated instance. Standard container logs expose logging streams; files written elsewhere require a suitable separate inspection method.
Worked example: The current worker instance has empty logs after restarting. kubectl logs with the worker container selected and --previous reveals the configuration error from the failed instance.
Mistake to avoid: Inspecting a healthy sidecar's logs while diagnosing the primary container's failure.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
58. In-container inspection and debug environments
kubectl exec runs an available command inside a running container; it cannot provide tools absent from the image. A permitted debug container can supply diagnostic tools without modifying the production image. Its filesystem and visibility are not automatically identical to those of the application container.
Worked example: A minimal image has no shell, so shell-based exec fails. An authorized debug environment can test Pod-network connectivity while application logs provide process-level evidence.
Mistake to avoid: Interpreting a missing diagnostic executable as proof that the application itself is broken.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
59. Image retrieval failure diagnosis
Image retrieval failures happen before the application process starts. Events distinguish invalid references, denied registry access, unavailable registries, and connectivity problems. Check the exact image name, referenced pull credentials, namespace, and affected nodes. Pull backoff describes retry delay rather than the underlying cause.
Worked example: Events report registry authorization failure. The referenced pull Secret exists only in another namespace; supplying suitable credentials in the Pod's namespace addresses the identified failure.
Mistake to avoid: Changing application probes or reading application logs before the image has been retrieved.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
60. Crash loops and resource-related termination
CrashLoopBackOff signals delayed restart attempts after repeated failures. Diagnose the previous termination reason, exit code, logs, and events. Separate process errors, probe-triggered restarts, container memory-limit termination, and Pod eviction under node pressure. Each failure path calls for a different corrective decision.
Worked example: A worker repeatedly terminates with OOMKilled near its memory limit. Inspect its workload and memory settings; changing the Service selector would not address that termination.
Mistake to avoid: Raising memory limits automatically without examining demand, requests, and available node capacity.
Source reference: Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
Sources
Exam identity and scope verified:
- Certified Kubernetes Application Developer (CKAD) - Linux Foundation - Education
- Certified Kubernetes Application Developer (CKAD) | CNCF