ckad exam questions Advanced Practice Exam: Hard Questions 2025

Your team is containerizing a legacy web app that writes user uploads to a local filesystem path (/var/www/uploads). In production, uploads must survive Pod restarts and be shareable across multiple replicas. The cluster has dynamic provisioning and supports ReadWriteMany volumes. You want the most Kubernetes-native solution that minimizes application changes and works with a Deployment scaled to 3 replicas. What should you implement?

You are designing a batch processing Pod that must run a one-time database migration before the main container starts. If the migration fails, the Pod should fail fast and not start the main container. The migration needs access to the same image and configuration as the main app. Which approach best fits Kubernetes patterns?

A Deployment with 8 replicas serves HTTP traffic. You must ensure zero downtime during updates, and you must prevent routing traffic to Pods until they have loaded a large in-memory cache (takes ~40 seconds). During rollouts, you also want Kubernetes to wait long enough before declaring the rollout failed. What is the best combination of settings?

A Job processes items from a queue and must be resilient to transient failures. However, the external system occasionally causes long hangs where the process makes no progress but does not exit. You need Kubernetes to kill and retry the Pod when it hangs, while avoiding restarts during normal long processing. What is the best approach?

A Pod is repeatedly restarting. `kubectl describe pod` shows `CrashLoopBackOff` and the last termination reason is `OOMKilled`. The application has occasional spikes but you want to prevent node-wide memory pressure and avoid repeated OOM kills. Which change best addresses this in a way aligned with Kubernetes scheduling and QoS behavior?

You are troubleshooting a Service that should route to Pods, but `kubectl get endpoints` shows none. The Pods are Running and Ready. The Service selector is `app=payments, tier=api`. The Pods have labels `app=payments` and `tier=API` (uppercase). You cannot restart the Service due to change control but can patch resources. What is the fastest safe fix?

A Pod needs a configuration file that changes per environment, plus a secret token used by the app. The app watches the config file for changes and can reload without restart, but it must never log the secret. You want to follow best practices and minimize risk of secret exposure. Which design is best?

A namespace has a default-deny NetworkPolicy (no ingress/egress allowed unless explicitly permitted). A frontend Pod must call a backend Service on TCP 8080, and the backend must call an external database by DNS name. After enabling policies, backend can no longer resolve DNS. What is the most likely missing rule you must add?

A Pod must access the Kubernetes API to list Pods in its namespace. You want the minimum permissions necessary and must avoid granting cluster-wide rights. Which approach is best?

You run a gRPC service (HTTP/2) behind a Kubernetes Service. Clients inside the cluster connect via the Service DNS name, but connections intermittently fail during rollouts with errors suggesting broken long-lived streams. You want to reduce connection disruption without changing client code. Which Service/load-balancing approach is most appropriate?