Certified Kubernetes Application Developer (CKAD) Exam Questions

A developer wants two containers in the same Pod to share the same network namespace (so they can reach each other over localhost) and the same set of mounted volumes. Which Kubernetes concept guarantees this?

✅ A. Containers in the same Pod always share the Pod’s network namespace and can share mounted volumes by default.
⬜ B. Each container in a Pod always gets its own isolated network namespace.
⬜ C. Containers must be in separate Pods to share localhost networking.
⬜ D. Sharing localhost networking requires a dedicated NetworkPolicy.

Explanation:
All containers within the same Pod share the Pod’s network namespace (so they can communicate via localhost) and can access any volumes defined in the Pod spec that they choose to mount — this is a fundamental property of the Pod as the shared execution environment.
Why other options are incorrect:
B: This is the opposite of how Pods work; containers in a Pod share, not isolate, the network namespace.
C: Containers do not need to be split into separate Pods to share localhost networking — that’s the default within one Pod.
D: NetworkPolicy configures traffic rules between Pods; it doesn’t create or require localhost sharing within a Pod, which is automatic.
Source: Pods

---

A developer wants a lightweight helper container to run continuously alongside the main application container for the life of the Pod (for example, to stream logs to a remote endpoint), rather than running once before the main container starts. Which container type is designed for this?

⬜ A. An init container
✅ B. A sidecar container
⬜ C. A Job
⬜ D. A DaemonSet

Explanation:
A sidecar container runs alongside the main application container for the Pod’s entire lifetime, extending or supporting it (for example, log shipping or a proxy) — unlike an init container, which runs once to completion before the main containers start.
Why other options are incorrect:
A: Init containers run to completion before app containers start; they don’t run continuously alongside them.
C: A Job manages Pods that run to completion; it is not a container pattern within a single Pod.
D: A DaemonSet is a workload controller for running Pods across nodes, not a within-Pod container pattern.
Source: Sidecar Containers

---

Which statement about Open Container Initiative (OCI) images is correct in the context of Kubernetes?

⬜ A. Kubernetes can only run images built specifically by Docker Desktop.
✅ B. Kubernetes runs containers based on OCI-compliant container images and uses an OCI-compatible container runtime (such as containerd or CRI-O) to run them.
⬜ C. Kubernetes builds container images internally and does not use any image format standard.
⬜ D. OCI images can only be pulled from Docker Hub.

Explanation:
Kubernetes relies on the OCI (Open Container Initiative) image and runtime specifications: it pulls and runs OCI-compliant container images through a Kubernetes-compatible, OCI-compatible container runtime such as containerd or CRI-O.
Why other options are incorrect:
A: Kubernetes is not tied to Docker Desktop; any OCI-compliant image and runtime works.
C: Kubernetes does not build images itself; that happens outside the cluster (e.g., a CI pipeline), and Kubernetes just runs the resulting OCI images.
D: OCI images can be pulled from any compliant registry, not only Docker Hub.
Source: Container Images

---

A developer wants to reduce a container image’s final size by excluding build-time tools and intermediate build artifacts from the image that actually gets deployed. Which Docker/OCI build technique is designed for this?

✅ A. A multi-stage build, where a builder stage compiles the application and only the necessary artifacts are copied into a smaller final stage.
⬜ B. Running docker pull twice.
⬜ C. Setting a higher CPU limit in the Pod spec.
⬜ D. Adding more init containers to the Pod.

Explanation:
A multi-stage build uses multiple FROM stages in a single Dockerfile: an early stage compiles/builds the application with all necessary build tools, and only the required output artifacts are copied into a final, minimal runtime stage — significantly reducing the deployed image’s size.
Why other options are incorrect:
B: Pulling an image twice has no effect on image size or build optimization.
C: CPU limits are a Kubernetes runtime resource control, unrelated to image build size.
D: Init containers are a Kubernetes Pod-level feature that runs before app containers start; they don’t affect how a Docker image itself is built or sized.
Source: Container Images

---

A Pod requires a specific container runtime feature and the cluster supports multiple container runtimes. Which Kubernetes interface standardizes how the kubelet communicates with any compliant container runtime (such as containerd or CRI-O)?

⬜ A. The Container Storage Interface (CSI)
✅ B. The Container Runtime Interface (CRI)
⬜ C. The Container Network Interface (CNI)
⬜ D. The Custom Resource Definition (CRD) interface

Explanation:
The Container Runtime Interface (CRI) is the standard API that lets the kubelet communicate with any compliant container runtime, allowing Kubernetes to support multiple interchangeable runtimes like containerd and CRI-O.
Why other options are incorrect:
A: CSI is the storage plugin interface, unrelated to container runtimes.
C: CNI is the networking plugin interface, unrelated to container runtimes.
D: CRD lets you define custom API object types; it has nothing to do with the runtime interface.
Source: Container Runtimes

---

A Pod has two containers: a main web server container and a helper container that must successfully fetch a TLS certificate before the web server starts. Which pattern correctly enforces this ordering?

⬜ A. Define the certificate-fetching container as a sidecar container.
✅ B. Define the certificate-fetching container as an init container, since init containers run to completion, in order, before app containers start.
⬜ C. Put both containers in the same container image.
⬜ D. Use a NetworkPolicy to delay the web server’s start.

Explanation:
Init containers are specifically designed to run to completion, in the order defined, before any application containers in the Pod start — which is exactly the guarantee needed to ensure the certificate is fetched before the web server container starts.
Why other options are incorrect:
A: A sidecar container runs concurrently with the main container rather than guaranteed to complete first.
C: Combining containers into a single image conflates two different concerns and loses the separation of responsibilities that containers provide.
D: NetworkPolicy governs network traffic rules, not container startup ordering.
Source: Init Containers

---

Which of these is a valid, commonly used multi-container Pod design pattern for adding functionality to a main application container without modifying its code?

✅ A. The ‘ambassador’ pattern, where a helper container proxies network connections on behalf of the main container.
⬜ B. Running the same image twice with identical names in the same Pod.
⬜ C. Deploying two unrelated applications randomly into one Pod for convenience.
⬜ D. Disabling all containers except one at runtime.

Explanation:
The ambassador pattern is a well-known multi-container Pod design pattern (alongside sidecar and adapter patterns) where a helper container proxies or simplifies network connections on behalf of the main application container, without requiring changes to the application’s own code.
Why other options are incorrect:
B: Containers within a Pod must have unique names; running duplicate-named containers isn’t a valid pattern.
C: Randomly grouping unrelated applications into one Pod isn’t a recognized design pattern and undermines Pod-level lifecycle management.
D: Disabling containers at runtime isn’t a multi-container design pattern; it’s just turning functionality off.
Source: How Pods manage multiple containers

---

A developer building a container image wants to follow best practice by NOT running the application process as the root user inside the container. Where is this enforced at the Kubernetes Pod/container level?

✅ A. In the Pod or container securityContext, using fields like runAsNonRoot and runAsUser.
⬜ B. In the container image’s file system permissions only, with no Kubernetes-level control.
⬜ C. In a NetworkPolicy.
⬜ D. In a StorageClass.

Explanation:
Kubernetes lets you enforce non-root execution declaratively through the Pod or container securityContext, using fields such as runAsNonRoot: true and runAsUser, which Kubernetes enforces when starting the container — independent of what the image itself might attempt to do.
Why other options are incorrect:
B: While the image can also be built to run as a non-root user, Kubernetes provides its own enforceable, cluster-level control via securityContext, which is the CKAD-relevant answer.
C: NetworkPolicy governs network traffic, not user/process privilege.
D: StorageClass configures storage provisioning, unrelated to container user privileges.
Source: Configure a Security Context for a Pod or Container

---

A developer wants their application Pod to automatically restart failed containers, following the Pod’s restart policy. Which field controls this at the Pod level?

✅ A. spec.restartPolicy
⬜ B. metadata.labels
⬜ C. spec.nodeName
⬜ D. spec.serviceAccountName

Explanation:
spec.restartPolicy on a Pod (values: Always, OnFailure, Never) controls whether and when the kubelet restarts containers in that Pod after they exit, which is fundamental to how workload controllers like Deployments keep applications running.
Why other options are incorrect:
B: Labels are metadata used for selection/grouping; they don’t control restart behavior.
C: nodeName pins a Pod to a specific node; it has no effect on restart behavior.
D: serviceAccountName sets the Pod’s identity for API access; it is unrelated to container restart behavior.
Source: Pod Lifecycle

---

A development team wants to store their application container images in a private registry and have Kubernetes authenticate to pull them. Which Kubernetes object is used to hold registry credentials referenced by a Pod’s imagePullSecrets?

⬜ A. A ConfigMap
✅ B. A Secret of type kubernetes.io/dockerconfigjson
⬜ C. A ResourceQuota
⬜ D. A PodDisruptionBudget

Explanation:
A Secret of type kubernetes.io/dockerconfigjson stores container registry credentials, and a Pod (or its ServiceAccount) references it via imagePullSecrets so the kubelet can authenticate when pulling images from a private registry.
Why other options are incorrect:
A: A ConfigMap is meant for non-sensitive configuration, not credentials.
C: A ResourceQuota limits resource consumption in a namespace, unrelated to image pull authentication.
D: A PodDisruptionBudget limits voluntary disruptions to Pods; it has nothing to do with registry credentials.
Source: Secrets

---

A developer needs to deploy a stateless REST API with 5 replicas and wants Kubernetes to automatically replace any replica that crashes, while supporting rolling updates. Which object should they create?

⬜ A. A bare Pod, repeated 5 times manually.
✅ B. A Deployment with replicas: 5.
⬜ C. A StatefulSet with replicas: 5.
⬜ D. A Job with completions: 5.

Explanation:
A Deployment is the standard way to run a specified number of stateless replicas, with the underlying ReplicaSet automatically replacing crashed Pods, and native support for rolling updates and rollbacks.
Why other options are incorrect:
A: Manually creating 5 individual Pods provides no automatic replacement on failure or built-in rolling update support.
C: A StatefulSet is designed for stateful workloads needing stable identity/storage, which isn’t required for a stateless REST API.
D: A Job runs Pods to completion for finite tasks; it isn’t designed for a continuously running service.
Source: Deployments

---

A team is deploying a clustered database where each replica needs a stable, unique network identity (e.g., db-0, db-1, db-2) and its own dedicated persistent storage that survives Pod rescheduling. Which object should they use?

⬜ A. Deployment
⬜ B. DaemonSet
✅ C. StatefulSet
⬜ D. ReplicaSet

Explanation:
A StatefulSet is specifically designed for stateful applications that need stable, unique network identities and stable, per-replica persistent storage that survives rescheduling — exactly the requirements of a clustered database.
Why other options are incorrect:
A: A Deployment’s replicas are interchangeable and don’t provide stable per-replica identity or storage.
B: A DaemonSet runs one Pod per node; it doesn’t provide the ordered identity/storage guarantees a clustered database needs.
D: A ReplicaSet, like a Deployment, manages interchangeable replicas without stable identity or per-replica storage.
Source: StatefulSets

---

A developer updates a Deployment’s container image to a new version, and Kubernetes gradually replaces old Pods with new ones while keeping the application available throughout. Which Deployment strategy is being used by default?

⬜ A. Recreate strategy
✅ B. RollingUpdate strategy
⬜ C. Blue-green deployment, natively built into Deployment objects
⬜ D. Canary deployment, natively built into Deployment objects

Explanation:
RollingUpdate is the default Deployment strategy: it incrementally replaces old ReplicaSet Pods with new ones (controlled by maxUnavailable/maxSurge), keeping the application available throughout the rollout.
Why other options are incorrect:
A: The Recreate strategy terminates all old Pods before creating new ones, causing downtime — it must be explicitly configured, and is not the default.
C and D: Blue-green and canary are deployment patterns often built using multiple Deployments/Services or additional tooling (like a service mesh or Argo Rollouts); they are not a native, built-in Deployment strategy type themselves.
Source: Rolling Update Deployment

---

After rolling out a new Deployment revision, the application starts failing. Which command lets the developer revert the Deployment to its previous working revision?

✅ A. kubectl rollout undo deployment/
⬜ B. kubectl delete deployment/
⬜ C. kubectl scale deployment/ –replicas=0
⬜ D. kubectl cordon deployment/

Explanation:
kubectl rollout undo deployment/<name> rolls a Deployment back to its previous revision (or a specific revision with --to-revision), which is the standard way to recover from a bad rollout.
Why other options are incorrect:
B: Deleting the Deployment removes it entirely rather than reverting to a known-good version.
C: Scaling to zero replicas just stops the application; it doesn’t restore the previous working version.
D: kubectl cordon applies to nodes, not Deployments, and has no rollback effect.
Source: Rolling Back a Deployment

---

A team wants a monitoring agent Pod to run on every node in the cluster (including future nodes added later), rather than a fixed replica count. Which object is the correct choice?

⬜ A. Deployment
✅ B. DaemonSet
⬜ C. Job
⬜ D. CronJob

Explanation:
A DaemonSet ensures a copy of the Pod runs on all (or matching) nodes automatically, including newly added nodes, which is exactly the requirement for a per-node monitoring agent.
Why other options are incorrect:
A: A Deployment manages a specified replica count, not a guarantee of one Pod per node.
C: A Job runs to completion once and isn’t designed for a continuously running per-node agent.
D: A CronJob runs Jobs on a schedule, not a continuously running per-node process.
Source: DaemonSet

---

A batch report-generation script needs to run to completion once a day at midnight, and Kubernetes should retry it if it fails. Which object combination is correct?

⬜ A. A Deployment with replicas: 1
✅ B. A CronJob, which creates a Job on the defined schedule
⬜ C. A DaemonSet with a schedule field
⬜ D. A bare Pod with restartPolicy: Always

Explanation:
A CronJob creates Jobs on a recurring cron-based schedule, and the underlying Job handles retrying failed Pods according to its retry policy — the correct combination for a scheduled, run-to-completion batch task.
Why other options are incorrect:
A: A Deployment is meant for continuously running replicas, not a scheduled, run-to-completion task.
C: DaemonSet has no schedule field; scheduling is a CronJob feature.
D: A bare Pod with restartPolicy: Always would keep restarting indefinitely rather than running once on a schedule.
Source: CronJob

---

A developer wants to control how many Pods can be unavailable at once during a Deployment’s rolling update, to balance rollout speed against maintaining capacity. Which Deployment fields control this?

⬜ A. replicas and selector
✅ B. maxUnavailable and maxSurge under the RollingUpdate strategy
⬜ C. readinessProbe and livenessProbe
⬜ D. resources.requests and resources.limits

Explanation:
maxUnavailable and maxSurge, configured under a Deployment’s strategy.rollingUpdate, control how many Pods can be unavailable and how many extra Pods can be created above the desired count during a rolling update, letting teams balance rollout speed against availability.
Why other options are incorrect:
A: replicas sets the desired Pod count and selector matches Pods to the Deployment; neither controls rollout pacing.
C: Probes affect Pod readiness/health detection but don’t directly set rollout unavailability limits.
D: Resource requests/limits control compute allocation, not rollout pacing.
Source: Rolling Update Deployment

---

Which command correctly updates only the container image of an existing Deployment named web, triggering a new rollout, without editing the full YAML manifest?

✅ A. kubectl set image deployment/web web-container=myapp:v2
⬜ B. kubectl get deployment web
⬜ C. kubectl label deployment web app=web
⬜ D. kubectl top deployment web

Explanation:
kubectl set image deployment/web web-container=myapp:v2 updates the specified container’s image within the Deployment, which triggers a new rollout using the Deployment’s configured update strategy, all without needing to hand-edit the manifest.
Why other options are incorrect:
B: kubectl get only retrieves Deployment information; it doesn’t change anything.
C: kubectl label adds/updates labels on the object; it doesn’t change the container image.
D: kubectl top shows resource usage metrics, unrelated to updating an image.
Source: Deployments

---

A developer wants to temporarily pause an in-progress Deployment rollout to make several changes without triggering multiple separate rollouts, then resume it as a single rollout. Which commands support this workflow?

✅ A. kubectl rollout pause deployment/ … kubectl rollout resume deployment/
⬜ B. kubectl delete deployment/ then kubectl apply -f
⬜ C. kubectl cordon deployment/
⬜ D. kubectl drain deployment/

Explanation:
kubectl rollout pause stops the rollout controller from acting on further changes to the Deployment, letting a developer batch multiple edits together, and kubectl rollout resume then triggers a single rollout reflecting all the accumulated changes.
Why other options are incorrect:
B: Deleting and reapplying the Deployment is disruptive and isn’t the supported pause/resume workflow.
C and D: cordon and drain operate on nodes, not Deployments, and have no relevance to rollout pausing.
Source: Deployments

---

A StatefulSet named db with 3 replicas is being scaled down. In which order does Kubernetes terminate the Pods by default?

⬜ A. In random order, to maximize speed.
✅ B. In reverse ordinal order — the highest-numbered Pod (e.g., db-2) is terminated first.
⬜ C. All Pods are terminated simultaneously regardless of ordinal.
⬜ D. In alphabetical order of the node names they’re running on.

Explanation:
By default, a StatefulSet scales down in reverse ordinal order, terminating the Pod with the highest ordinal index first (for example, db-2 before db-1 before db-0), preserving the stable identity and ordering guarantees StatefulSets are designed to provide.
Why other options are incorrect:
A, C, and D: These would break the ordered, predictable scaling guarantees that are the defining characteristic of a StatefulSet.
Source: StatefulSets

---

A container in a Pod is running but the application inside has deadlocked and stopped responding, though the process itself hasn’t exited. Which probe should be configured so Kubernetes detects this and restarts the container?

⬜ A. A startup probe only
✅ B. A liveness probe
⬜ C. A readiness probe only, with no liveness probe
⬜ D. No probe is needed; Kubernetes detects deadlocks automatically

Explanation:
A liveness probe periodically checks whether the application is actually functioning (not just that the process exists); if it fails repeatedly, Kubernetes restarts the container — exactly the mechanism needed to recover from an application-level deadlock.
Why other options are incorrect:
A: A startup probe only gates when the other probes begin checking a slow-starting container; it doesn’t itself trigger restarts for a later deadlock.
C: A readiness probe controls whether a Pod receives traffic via a Service, but does not restart the container.
D: Kubernetes has no automatic deadlock detection; a correctly configured liveness probe is required.
Source: Configure Liveness, Readiness and Startup Probes

---

A Pod’s container is fully running but the application takes 30 seconds to warm up before it can serve traffic. Without any additional configuration, a naive liveness probe with a short timeout might kill the container before it finishes starting. Which probe type is specifically designed to solve this?

⬜ A. A readiness probe only
✅ B. A startup probe, which disables liveness and readiness checks until it succeeds
⬜ C. A NetworkPolicy
⬜ D. A ResourceQuota

Explanation:
A startup probe is specifically designed for slow-starting containers: while it hasn’t yet succeeded, Kubernetes disables the liveness and readiness probes, preventing a container from being killed for ‘failing’ a liveness check while it’s still legitimately starting up.
Why other options are incorrect:
A: A readiness probe controls traffic routing, but by itself doesn’t stop a liveness probe from prematurely killing a slow-starting container.
C: NetworkPolicy is unrelated to probe/startup timing.
D: ResourceQuota limits aggregate namespace resource consumption, unrelated to startup timing.
Source: Configure Liveness, Readiness and Startup Probes

---

A Pod is Running, but a Service is not sending it any traffic. kubectl describe pod shows the container is not passing a certain probe. Which probe type, when failing, causes a Pod to be removed from a Service’s list of active endpoints without restarting the container?

⬜ A. Liveness probe
✅ B. Readiness probe
⬜ C. Startup probe
⬜ D. Exec probe (as a category, unrelated to readiness)

Explanation:
A readiness probe determines whether a Pod is ready to serve traffic; if it fails, the Pod is removed from the Service’s Endpoints/EndpointSlices (so it stops receiving traffic) without the container being restarted, unlike a failing liveness probe.
Why other options are incorrect:
A: A failing liveness probe causes the container to be restarted, not just removed from Service traffic.
C: A startup probe gates when the other probes start being evaluated; it isn’t itself the traffic-routing signal.
D: ‘Exec probe’ describes a probe mechanism (running a command), not a probe purpose category like readiness.
Source: Configure Liveness, Readiness and Startup Probes

---

A developer needs to see the last 50 lines of a currently running container’s logs, and then continue streaming new log lines as they’re generated. Which kubectl command accomplishes this?

✅ A. kubectl logs –tail=50 -f
⬜ B. kubectl describe pod
⬜ C. kubectl top pod
⬜ D. kubectl get pod -o wide

Explanation:
kubectl logs <pod-name> --tail=50 -f shows the last 50 lines of the container’s logs and then follows (-f) the log stream, printing new lines as they appear — exactly the behavior described.
Why other options are incorrect:
B: kubectl describe pod shows Pod metadata and events, not log content.
C: kubectl top pod shows resource usage, not log output.
D: kubectl get pod -o wide shows extended Pod status fields, not log content.
Source: Debug Running Pods

---

A Pod has two containers, app and sidecar. Which command retrieves the logs specifically from the sidecar container?

✅ A. kubectl logs -c sidecar
⬜ B. kubectl logs
⬜ C. kubectl exec – logs sidecar
⬜ D. kubectl describe pod -c sidecar

Explanation:
When a Pod has multiple containers, kubectl logs <pod-name> -c <container-name> (here, -c sidecar) is required to specify which container’s logs to retrieve; without -c, kubectl logs fails or defaults ambiguously when there’s more than one container.
Why other options are incorrect:
B: Without specifying -c on a multi-container Pod, kubectl logs will error asking you to specify a container.
C: There is no kubectl exec ... -- logs construct for retrieving container logs this way.
D: kubectl describe pod doesn’t take a -c flag to filter to one container’s logs; it shows Pod-level info and events.
Source: Debug Running Pods

---

Which command displays real-time CPU and memory usage for all Pods in the current namespace, assuming the Metrics Server is installed?

⬜ A. kubectl get events
✅ B. kubectl top pods
⬜ C. kubectl describe namespace
⬜ D. kubectl get componentstatuses

Explanation:
kubectl top pods displays live CPU and memory usage per Pod, sourced from the Metrics Server (or a compatible metrics pipeline) running in the cluster.
Why other options are incorrect:
A: kubectl get events lists cluster events, not resource usage metrics.
C: kubectl describe namespace shows namespace-level quotas/limits, not live per-Pod usage.
D: kubectl get componentstatuses reports control-plane component health, not Pod resource usage.
Source: Resource metrics pipeline

---

A developer wants their application to expose custom metrics (like request count or queue depth) in a format that a Prometheus-compatible monitoring stack can scrape. What is the standard approach?

✅ A. Expose the metrics on an HTTP endpoint (commonly /metrics) in the Prometheus text exposition format, using a client library, so a Prometheus server can scrape it.
⬜ B. Write metrics directly into etcd from the application.
⬜ C. Metrics must be emailed to the monitoring team manually.
⬜ D. Use a NetworkPolicy to broadcast metrics to all Pods.

Explanation:
The standard, widely used pattern for exposing custom application metrics to a Prometheus-compatible monitoring stack is to instrument the application (often with a Prometheus client library) to expose an HTTP endpoint — typically /metrics — in the Prometheus text exposition format, which Prometheus then scrapes on an interval.
Why other options are incorrect:
B: Applications should never write directly into the cluster’s etcd store; that’s reserved for the Kubernetes API server itself.
C: Manual, non-automated metric reporting defeats the purpose of a monitoring/observability pipeline.
D: NetworkPolicy governs traffic rules; it isn’t a mechanism for exposing or broadcasting metrics.
Source: Resource metrics pipeline

---

A Pod keeps restarting and kubectl get pods shows CrashLoopBackOff. Which command shows the logs from the PREVIOUS (already-terminated) instance of the container, which is often essential for diagnosing the crash?

✅ A. kubectl logs –previous
⬜ B. kubectl logs –since=1h
⬜ C. kubectl get pod -o yaml
⬜ D. kubectl rollout status deployment/

Explanation:
kubectl logs <pod-name> --previous retrieves the logs from the last terminated instance of the container, which is essential when diagnosing a CrashLoopBackOff, since the currently running instance may not have produced the crash-causing output yet (or has already been replaced).
Why other options are incorrect:
B: --since=1h filters by time from the CURRENT container instance’s logs, not the previous, already-terminated one.
C: The Pod’s YAML shows its spec/status, not the crashed container’s log output.
D: kubectl rollout status reports on a Deployment’s rollout progress, not container log content.
Source: Debug Running Pods

---

A developer wants to inject a non-sensitive configuration value (such as a feature flag) into a container as an environment variable, sourced from a Kubernetes object that can be updated independently of the container image. Which object should they use?

⬜ A. A Secret
✅ B. A ConfigMap
⬜ C. A PersistentVolumeClaim
⬜ D. A ResourceQuota

Explanation:
A ConfigMap is designed to hold non-sensitive configuration data (like feature flags or settings) that can be injected into Pods as environment variables or mounted files, and updated independently of the container image.
Why other options are incorrect:
A: A Secret is intended for sensitive values (passwords, tokens); using it for a non-sensitive feature flag isn’t the appropriate object, though it would technically also work mechanically.
C: A PersistentVolumeClaim requests durable storage; it isn’t designed for small configuration values.
D: A ResourceQuota limits resource consumption in a namespace; it has no role in application configuration.
Source: ConfigMaps

---

A developer needs to inject a database password into a container as an environment variable, but must avoid storing it in plain text within the Pod spec’s YAML or the container image. Which approach correctly meets this requirement?

⬜ A. Hardcode the password directly in the Deployment YAML’s env field.
✅ B. Store the password in a Secret, and reference it in the container’s env using valueFrom.secretKeyRef.
⬜ C. Store the password in a public ConfigMap.
⬜ D. Bake the password into the container image at build time.

Explanation:
Storing the password in a Secret and referencing it via valueFrom.secretKeyRef in the container’s environment variable definition keeps the sensitive value out of the plain Pod spec text and out of the container image, which is the standard, correct approach.
Why other options are incorrect:
A: Hardcoding the password directly in YAML exposes it in plain text wherever that manifest is stored or viewed.
C: A ConfigMap is meant for non-sensitive data and does not provide the access controls/handling appropriate for secrets.
D: Baking secrets into a container image is a serious anti-pattern — anyone with access to the image can extract the value.
Source: Secrets

---

A developer wants an entire ConfigMap’s key-value pairs to appear as individual files inside a container, where each key becomes a filename and its value becomes the file’s content. Which approach achieves this?

✅ A. Mount the ConfigMap as a volume in the Pod spec.
⬜ B. Reference the ConfigMap only via envFrom.
⬜ C. This is not possible; ConfigMaps can only be used as environment variables.
⬜ D. Use a StorageClass referencing the ConfigMap.

Explanation:
Mounting a ConfigMap as a volume causes each key in the ConfigMap to appear as a separate file within the mount path inside the container, with the file’s content set to that key’s value — the standard way to expose configuration as files rather than environment variables.
Why other options are incorrect:
B: envFrom injects ConfigMap keys as environment variables, not as individual files.
C: ConfigMaps support both environment variable injection and volume mounting; volume mounting as files is a well-supported, common pattern.
D: A StorageClass configures dynamic volume provisioning and has nothing to do with exposing ConfigMap data as files.
Source: ConfigMaps

---

A Pod needs to make authenticated calls to the Kubernetes API server itself (for example, to list Pods in its own namespace) using an identity Kubernetes manages, rather than a human user’s credentials. Which object provides this identity?

✅ A. A ServiceAccount
⬜ B. A ConfigMap
⬜ C. A NetworkPolicy
⬜ D. A PersistentVolume

Explanation:
A ServiceAccount provides an identity that Pods can use to authenticate to the Kubernetes API server; a token associated with the ServiceAccount is automatically mounted into the Pod (or can be requested), and RBAC then determines what that identity is authorized to do.
Why other options are incorrect:
B: A ConfigMap stores configuration data; it does not provide an API identity.
C: A NetworkPolicy controls network traffic; it doesn’t provide an authentication identity.
D: A PersistentVolume provides storage; it is unrelated to API authentication.
Source: Service Accounts

---

A Pod’s ServiceAccount needs permission to list and get Secrets, but only within its own namespace, following least privilege. Which combination of objects correctly grants this?

⬜ A. A ClusterRole and ClusterRoleBinding scoped to the whole cluster.
✅ B. A Role (scoped to the namespace) bound to the ServiceAccount via a RoleBinding.
⬜ C. No RBAC object is needed; ServiceAccounts have full access by default.
⬜ D. A NetworkPolicy allowing traffic to the Secrets API.

Explanation:
A namespace-scoped Role granting get/list on Secrets, bound to the ServiceAccount via a RoleBinding in that same namespace, is the least-privilege way to grant this access — limited to exactly the namespace and verbs required.
Why other options are incorrect:
A: A ClusterRole/ClusterRoleBinding would grant access more broadly than the single namespace required, violating least privilege.
C: ServiceAccounts have no permissions by default; access must be explicitly granted through RBAC.
D: NetworkPolicy governs network traffic, not API authorization for reading Secrets.
Source: Using RBAC Authorization

---

A security team wants to enforce that containers in a certain namespace cannot run as the root user and cannot escalate privileges, using a cluster-wide, built-in policy mechanism (rather than a third-party admission controller). Which Kubernetes-native feature should they use?

✅ A. Pod Security Standards, enforced via Pod Security Admission at the namespace level.
⬜ B. A ConfigMap labeled security=enforced.
⬜ C. A ResourceQuota with a CPU limit.
⬜ D. A headless Service.

Explanation:
Pod Security Standards define built-in policy levels (Privileged, Baseline, Restricted), and Pod Security Admission is the built-in Kubernetes admission controller that enforces these standards at the namespace level using namespace labels — a native way to restrict things like running as root or privilege escalation.
Why other options are incorrect:
B: A ConfigMap label has no enforcement mechanism attached to it; it’s just metadata unless something else acts on it.
C: A ResourceQuota limits resource consumption, not security posture like root access.
D: A headless Service affects DNS/Service behavior, unrelated to Pod security enforcement.
Source: Pod Security Standards

---

Which securityContext field, when set to true, prevents a container’s root filesystem from being written to, reducing the impact of certain container escape or tampering attempts?

⬜ A. runAsNonRoot
✅ B. readOnlyRootFilesystem
⬜ C. allowPrivilegeEscalation
⬜ D. privileged

Explanation:
Setting readOnlyRootFilesystem: true in a container’s securityContext mounts the container’s root filesystem as read-only, which is a hardening measure that limits what an attacker or compromised process can modify at runtime.
Why other options are incorrect:
A: runAsNonRoot ensures the container doesn’t run as the root user, which is a different (though related) hardening control from filesystem writability.
C: allowPrivilegeEscalation controls whether a process can gain more privileges than its parent; it doesn’t affect filesystem writability.
D: privileged (when true) actually grants extensive host access, the opposite of a hardening measure.
Source: Configure a Security Context for a Pod or Container

---

A namespace administrator wants to cap the total amount of CPU and memory that can be requested across ALL Pods in a namespace, to prevent one team from consuming the entire cluster’s capacity. Which object should they create?

⬜ A. A LimitRange
✅ B. A ResourceQuota
⬜ C. A NetworkPolicy
⬜ D. A PodDisruptionBudget

Explanation:
A ResourceQuota sets hard limits on the total amount of resources (such as aggregate CPU/memory requests and limits, or object counts) that can be consumed across all objects within a namespace, which is exactly the cross-team, namespace-wide capping described.
Why other options are incorrect:
A: A LimitRange sets default/min/max resource constraints for individual Pods/containers within a namespace, but doesn’t cap the aggregate total across the whole namespace the way a ResourceQuota does.
C: NetworkPolicy manages traffic rules, not resource consumption limits.
D: A PodDisruptionBudget limits voluntary disruptions during maintenance events, unrelated to resource capping.
Source: Resource Quotas

---

A security team wants to restrict a group of Pods labeled tier=backend so they can only receive traffic from Pods labeled tier=frontend, denying all other ingress traffic. Which object correctly enforces this?

✅ A. A NetworkPolicy with an ingress rule that selects podSelector: {tier: backend} and allows from Pods matching tier: frontend.
⬜ B. A ResourceQuota restricting Pod count.
⬜ C. A ConfigMap labeled tier=backend.
⬜ D. A ServiceAccount bound to the backend Pods.

Explanation:
A NetworkPolicy that targets Pods with podSelector: {tier: backend} and specifies an ingress rule allowing traffic only from Pods matching tier: frontend is exactly the mechanism designed to restrict which Pods can send traffic to a given set of Pods.
Why other options are incorrect:
B: A ResourceQuota limits resource consumption, not network traffic sources.
C: A ConfigMap label is just metadata on a ConfigMap object and has no traffic-filtering effect.
D: A ServiceAccount provides an API identity, not network traffic filtering.
Source: Network Policies

---

A developer wants a Pod’s container to automatically pick up environment variables named after EVERY key in a ConfigMap, without listing each key individually. Which field should they use in the container spec?

⬜ A. env, listing each key one at a time
✅ B. envFrom, referencing the ConfigMap
⬜ C. volumeMounts, with no ConfigMap reference
⬜ D. resources.requests

Explanation:
envFrom lets a container automatically import all key-value pairs from a referenced ConfigMap (or Secret) as environment variables, without needing to enumerate each key individually under env.
Why other options are incorrect:
A: Listing each key individually under env works but requires explicitly naming every key, which is the opposite of the ‘without listing each key’ requirement.
C: volumeMounts mounts data as files, not as environment variables, and still needs a ConfigMap volume reference to do anything.
D: resources.requests configures compute resource requests, unrelated to environment variable injection.
Source: ConfigMaps

---

Which of these is generally considered a best practice regarding Secrets in Kubernetes?

⬜ A. Store Secrets in plain-text ConfigMaps to simplify management.
✅ B. Limit which ServiceAccounts, Roles, and namespaces can access a given Secret using RBAC, and avoid printing Secret values into logs.
⬜ C. Commit raw Secret manifests containing plain-text sensitive values directly into a public source-code repository.
⬜ D. Grant every ServiceAccount in the cluster access to every Secret by default.

Explanation:
Restricting access to Secrets through RBAC (least privilege) and being careful not to expose Secret values in logs or other visible outputs are core best practices for handling sensitive data safely in Kubernetes.
Why other options are incorrect:
A: Storing sensitive data in a plain-text ConfigMap defeats the purpose of using a Secret object and its intended handling.
C: Committing plain-text secrets to any repository, especially a public one, is a serious security anti-pattern.
D: Granting universal access to all Secrets violates the principle of least privilege and increases blast radius if any component is compromised.
Source: Secrets

---

A developer wants to prevent a container from being able to escalate its privileges beyond its parent process, as an additional hardening measure alongside running as a non-root user. Which securityContext field controls this directly?

✅ A. allowPrivilegeEscalation, set to false
⬜ B. readOnlyRootFilesystem, set to true
⬜ C. runAsUser, set to 0
⬜ D. hostNetwork, set to true

Explanation:
Setting allowPrivilegeEscalation: false in a container’s securityContext explicitly prevents a process from gaining more privileges than its parent process, which is a specific, direct hardening control against privilege-escalation techniques.
Why other options are incorrect:
B: readOnlyRootFilesystem controls filesystem writability, a related but distinct hardening control from privilege escalation.
C: Setting runAsUser to 0 would explicitly run the container AS root, which is the opposite of a hardening measure.
D: hostNetwork: true gives the Pod access to the host’s network namespace, which increases the attack surface rather than reducing it.
Source: Configure a Security Context for a Pod or Container

---

A developer has a Deployment of backend Pods and wants other Pods in the same cluster to reach them at a stable internal address, without exposing them outside the cluster. Which Service type is appropriate?

✅ A. ClusterIP
⬜ B. NodePort
⬜ C. LoadBalancer
⬜ D. ExternalName

Explanation:
ClusterIP, the default Service type, provides a stable, cluster-internal virtual IP and DNS name for reaching a set of Pods from within the cluster, with no external exposure — matching this requirement exactly.
Why other options are incorrect:
B: NodePort exposes the Service externally via a port on every node, more than is needed here.
C: LoadBalancer provisions external cloud load-balancer access, again more than required.
D: ExternalName maps a Service name to an external DNS name outside the cluster, which doesn’t apply to routing to internal backend Pods.
Source: Service

---

A developer wants a single external HTTP entry point that routes /api requests to one backend Service and /web requests to a different backend Service, based on URL path. Which object should they configure?

⬜ A. A ClusterIP Service
✅ B. An Ingress resource with path-based routing rules
⬜ C. A headless Service
⬜ D. A PersistentVolumeClaim

Explanation:
An Ingress resource is designed to define HTTP(S) routing rules — including path-based routing like /api vs. /web — directing external traffic through a single entry point to different backend Services, managed by an Ingress controller.
Why other options are incorrect:
A: A ClusterIP Service alone provides a single internal address for one backend, not path-based routing across multiple Services.
C: A headless Service returns individual Pod IPs via DNS; it doesn’t perform HTTP path-based routing.
D: A PersistentVolumeClaim requests storage and has nothing to do with HTTP routing.
Source: Ingress

---

A developer’s Pod tries to reach another Service by its short name (e.g., payments) instead of the fully qualified domain name, and it works correctly when calling from within the same namespace. What makes this possible?

✅ A. Kubernetes cluster DNS automatically appends the Pod’s own namespace and cluster domain suffix through its configured search domains, resolving the short name.
⬜ B. Kubernetes requires the fully qualified name always; short names never work.
⬜ C. The Pod must have a hard-coded IP address for every Service it calls.
⬜ D. Short names only work if NetworkPolicy explicitly allows DNS.

Explanation:
A Pod’s /etc/resolv.conf is automatically configured with search domains that include its own namespace, so a short Service name like payments (in the same namespace) resolves correctly without needing the fully qualified payments.<namespace>.svc.cluster.local form.
Why other options are incorrect:
B: Short names do work within the same namespace precisely because of the automatically configured DNS search domains.
C: Kubernetes doesn’t require hard-coded IPs; DNS-based service discovery is the whole point of cluster DNS.
D: DNS resolution isn’t gated by NetworkPolicy by default; NetworkPolicy controls IP traffic, and DNS resolution itself typically still needs to reach the DNS Service/Pods, but short-name resolution isn’t inherently blocked without a policy.
Source: DNS for Services and Pods

---

A developer wants to test connectivity to a Service directly from their local machine during development, without modifying the Service type or deploying an Ingress. Which kubectl command temporarily forwards a local port to a Service or Pod?

✅ A. kubectl port-forward svc/ 8080:80
⬜ B. kubectl expose service
⬜ C. kubectl cordon svc/
⬜ D. kubectl taint svc/

Explanation:
kubectl port-forward svc/<service-name> 8080:80 creates a temporary tunnel from a local port (8080) to the Service’s port (80), letting a developer test connectivity directly from their machine without changing the Service type or setting up Ingress.
Why other options are incorrect:
B: kubectl expose creates a new Service from an existing resource; it doesn’t create a local port-forward tunnel.
C and D: cordon and taint are node-level operations and don’t apply to Services at all.
Source: Service

---

Which statement about Kubernetes NetworkPolicy behavior is correct when NO NetworkPolicy selects a given Pod?

⬜ A. All traffic to and from that Pod is denied by default.
✅ B. All traffic to and from that Pod is allowed by default (Kubernetes networking is permissive unless a NetworkPolicy restricts it).
⬜ C. Only traffic from the same namespace is allowed.
⬜ D. Only traffic on port 80 is allowed.

Explanation:
If no NetworkPolicy selects a given Pod, that Pod’s traffic is unrestricted (allowed) by default, consistent with Kubernetes’ default permissive networking model; restrictions only apply once a NetworkPolicy explicitly selects that Pod.
Why other options are incorrect:
A: This describes default-deny behavior, which only applies once at least one NetworkPolicy selects the Pod, not as the baseline default.
C and D: Kubernetes doesn’t apply an implicit same-namespace-only or single-port restriction without an explicit NetworkPolicy.
Source: Network Policies

---

A developer needs their application Pod to discover the individual Pod IPs backing a StatefulSet (for peer discovery in a clustered application) rather than a single load-balanced address. Which Service configuration is designed for this?

⬜ A. A LoadBalancer Service
✅ B. A Headless Service (clusterIP: None)
⬜ C. A NodePort Service
⬜ D. An Ingress resource

Explanation:
A Headless Service, created by setting clusterIP: None, causes DNS lookups to return the individual Pod IPs directly rather than a single virtual IP — the standard pattern used with StatefulSets for peer discovery in clustered applications.
Why other options are incorrect:
A and C: LoadBalancer and NodePort still front the Service with a single address/port abstraction rather than exposing individual Pod IPs via DNS.
D: Ingress handles HTTP(S) routing to Services; it does not provide direct per-Pod DNS discovery.
Source: Service

---

A Service’s selector is app: cart, but no existing Pods currently carry the label app: cart. What happens to the Service’s Endpoints/EndpointSlices?

⬜ A. The Service automatically creates new Pods matching the selector.
✅ B. The Service exists but has no active Endpoints, so it will not route traffic to any Pod until matching Pods appear.
⬜ C. The Service throws a validation error and cannot be created.
⬜ D. The Service falls back to routing traffic to any random Pod in the namespace.

Explanation:
A Service’s Endpoints/EndpointSlices are populated dynamically based on which existing Pods match its label selector. If no Pods currently match, the Service simply has no active endpoints and traffic sent to it will fail to reach any backend, until matching Pods are created.
Why other options are incorrect:
A: A Service does not create Pods itself; that’s the role of a controller like a Deployment.
C: Kubernetes allows creating a Service with a selector that currently matches zero Pods; it is not a validation error.
D: A Service never falls back to routing to unrelated, non-matching Pods.
Source: EndpointSlices

---

Which Service type builds on NodePort and additionally provisions an external load balancer (typically from a cloud provider) to distribute traffic to the Service?

⬜ A. ClusterIP
⬜ B. NodePort
✅ C. LoadBalancer
⬜ D. ExternalName

Explanation:
A LoadBalancer Service builds on NodePort functionality and additionally requests an external load balancer (commonly from a cloud provider’s integration) to distribute incoming traffic to the Service across nodes.
Why other options are incorrect:
A: ClusterIP is internal-only and does not provision any external load balancer.
B: NodePort alone exposes a static port on every node but does not itself provision an external load balancer.
D: ExternalName maps to an external DNS name and does not provision a load balancer for internal Pods.
Source: Service

---

A developer wants an Ingress resource to route based on the incoming request’s hostname (e.g., api.example.com vs. shop.example.com) to two different backend Services. Which Ingress feature supports this?

⬜ A. Path-based routing only, with no support for hostnames.
✅ B. Host-based (name-based virtual hosting) routing rules within the Ingress spec.
⬜ C. A separate LoadBalancer Service per hostname is strictly required instead.
⬜ D. NetworkPolicy hostname matching.

Explanation:
Ingress resources support host-based routing rules, allowing different backend Services to be selected based on the incoming request’s hostname (name-based virtual hosting), in addition to or instead of path-based rules.
Why other options are incorrect:
A: Ingress explicitly supports host-based rules in addition to path-based ones; this option incorrectly excludes that.
C: A single Ingress with host-based rules can serve multiple hostnames without needing a separate LoadBalancer Service for each.
D: NetworkPolicy operates on IP/port-level traffic rules, not HTTP hostname-based routing.
Source: Ingress

---

A developer’s application needs to reach a Service in a DIFFERENT namespace (billing) named invoices. Which is the correct fully qualified DNS name to use from a Pod in another namespace?

⬜ A. invoices.svc.cluster.local
✅ B. invoices.billing.svc.cluster.local
⬜ C. billing.invoices.svc.cluster.local
⬜ D. invoices://billing

Explanation:
The standard Kubernetes Service DNS format is <service-name>.<namespace>.svc.cluster.local, so reaching the invoices Service in the billing namespace from another namespace requires invoices.billing.svc.cluster.local.
Why other options are incorrect:
A: This omits the namespace entirely, which is required when calling across namespaces.
C: This reverses the correct name/namespace order.
D: This is not a valid Kubernetes Service DNS or URL format.
Source: DNS for Services and Pods