Knowledge + Practice

Certified Kubernetes Application Developer CKAD (CKAD) — Questions 226–300

991 questions total · 14pages · All types, answers revealed

Take a mock exam Exam hub

Page 4 of 14

226

Multi-Selectmedium

Which TWO of the following are valid ways to create a ConfigMap from a file named 'app.properties'? (Select two.)

Select 2 answers

A.kubectl create configmap app-config --from-file=app.properties

B.kubectl create configmap app-config --from-literal=app.properties

C.kubectl create configmap app-config --from-env=app.properties

D.kubectl create configmap app-config --from-file=app.properties=app.properties

E.kubectl create configmap app-config --from-env-file=app.properties

AnswersA, E

--from-file uses the filename as the key and the file content as the value.

Why this answer

Option A is correct because `--from-file=app.properties` creates a ConfigMap with a single key-value pair, where the key defaults to the filename (app.properties) and the value is the entire file content. Option E is correct because `--from-env-file=app.properties` imports each line of the file as a separate key-value pair, treating the file as an environment variable definition file (key=value format).

Exam trap

CNCF often tests the confusion between `--from-file` (which creates a single key with the file content) and `--from-env-file` (which creates multiple keys from key=value lines), and candidates mistakenly think `--from-env` is a valid flag.

Full explanation →

227

MCQhard

You have a multi-stage Dockerfile with two stages: 'builder' and 'runtime'. You want to copy artifacts from the builder stage to the runtime stage. Which Dockerfile instruction achieves this?

A.EXPORT builder /app/artifact /app/

B.ADD --from=builder /app/artifact /app/

C.COPY ../builder/artifact /app/

D.COPY --from=builder /app/artifact /app/

AnswerD

--from specifies the source stage.

Why this answer

The COPY instruction with --from=stage-name copies files from a previous build stage.

Full explanation →

228

MCQeasy

Which service type is used to expose a service using an external DNS name, such as a database hosted outside Kubernetes?

A.ClusterIP

B.NodePort

C.LoadBalancer

D.ExternalName

AnswerD

Correct. Maps to an external DNS name.

Why this answer

ExternalName service maps to an external DNS name. It returns a CNAME record.

Full explanation →

229

MCQeasy

Which field in a Pod spec specifies which ServiceAccount the pod should use?

A.spec.serviceAccount

B.spec.accountName

C.spec.automountServiceAccountToken

D.spec.serviceAccountName

AnswerD

This is the correct field.

Why this answer

The correct field is `spec.serviceAccountName` in the Pod spec. This field explicitly specifies the name of the ServiceAccount that the Pod should use. If omitted, the Pod automatically uses the `default` ServiceAccount in its namespace.

This is defined in the Kubernetes API for PodSpec.

Exam trap

The trap here is that candidates may confuse the deprecated `spec.serviceAccount` field with the correct `spec.serviceAccountName`, or mistakenly think `spec.automountServiceAccountToken` selects the ServiceAccount, when it only controls token mounting.

How to eliminate wrong answers

Option A is wrong because `spec.serviceAccount` is a deprecated field that was replaced by `spec.serviceAccountName` in Kubernetes v1.9+; it is no longer supported in current API versions. Option B is wrong because `spec.accountName` is not a valid field in the PodSpec; Kubernetes does not recognize this field for ServiceAccount assignment. Option C is wrong because `spec.automountServiceAccountToken` is a boolean field that controls whether the ServiceAccount token is automatically mounted into the Pod, not which ServiceAccount to use.

Full explanation →

230

MCQmedium

You are performing a blue-green deployment. You have two Deployments: 'app-blue' and 'app-green', each with 5 replicas. Both are labeled with 'app: myapp'. The Service 'myapp-svc' selects pods with 'app: myapp' and 'version: blue'. After deploying the new version to 'app-green' and verifying it, what change is required to switch traffic to the green deployment?

A.Update the label on app-green pods to 'version: blue'

B.Update the Service selector to 'version: green'

C.Scale down app-blue to 0 replicas

D.Delete app-blue deployment

AnswerB

Changes the service to target green pods.

Why this answer

To switch traffic to green, update the Service's selector to 'version: green'. Option D is correct.

Full explanation →

231

MCQmedium

A developer created a Role named 'pod-reader' in namespace 'ns1' that allows 'get', 'list', and 'watch' on pods. They created a RoleBinding binding this Role to a ServiceAccount 'sa1' in the same namespace. However, a pod using 'sa1' cannot list pods in namespace 'ns2'. What is the most likely cause?

A.The Role is missing the apiGroup field

B.The Role does not include the 'list' verb for pods

C.Role and RoleBinding are namespace-scoped; they only grant permissions within their namespace

D.The RoleBinding is not bound to the correct ServiceAccount

AnswerC

Correct. Role and RoleBinding are scoped to a single namespace. To grant access across namespaces, you need ClusterRole and ClusterRoleBinding.

Why this answer

Role and RoleBinding are namespace-scoped resources in Kubernetes. A Role defined in 'ns1' grants permissions only within 'ns1', and a RoleBinding in 'ns1' binds that Role to a ServiceAccount only for operations inside 'ns1'. To list pods in 'ns2', the ServiceAccount needs a separate Role and RoleBinding (or a ClusterRole and ClusterRoleBinding) that explicitly grant permissions in 'ns2'.

Therefore, the pod using 'sa1' cannot list pods in 'ns2' because the Role and RoleBinding are confined to 'ns1'.

Exam trap

The trap here is that candidates often overlook the namespace-scoped nature of Role and RoleBinding, assuming that a RoleBinding can grant permissions across namespaces, when in fact it is strictly confined to the namespace of the RoleBinding itself.

How to eliminate wrong answers

Option A is wrong because the 'get', 'list', and 'watch' verbs on pods do not require an apiGroup field; pods are in the core API group (v1), which is the default and does not need explicit specification. Option B is wrong because the Role explicitly includes the 'list' verb for pods, as stated in the question. Option D is wrong because the RoleBinding is correctly bound to ServiceAccount 'sa1' in 'ns1', and the issue is not about binding to the wrong ServiceAccount but about namespace scope.

Full explanation →

232

MCQhard

Your Deployment is stuck during rollout, and you want to investigate. Which command pauses the rollout and allows you to check the current state?

A.kubectl rollout resume deployment my-deployment

B.kubectl rollout status deployment my-deployment

C.kubectl rollout pause deployment my-deployment

D.kubectl rollout stop deployment my-deployment

AnswerC

Pauses the rollout to investigate.

Why this answer

Option A pauses the rollout. Then you can run 'kubectl rollout status' to see the state. Option B resumes.

Option C is not a command. Option D is not for pausing.

Full explanation →

233

MCQeasy

You have a YAML file 'deploy.yaml' that defines a Deployment. Which command creates the Deployment if it does not exist, or updates it if it already exists?

A.kubectl replace -f deploy.yaml

B.kubectl patch -f deploy.yaml

C.kubectl create -f deploy.yaml

D.kubectl apply -f deploy.yaml

AnswerD

This creates the resource if it does not exist, or updates it if it does, using the declarative approach.

Why this answer

Option B is correct: 'kubectl apply' creates or updates resources declaratively. Option A ('create') fails if the resource exists. Option C ('replace') requires the resource to exist.

Option D ('patch') modifies an existing resource but is not idempotent like apply.

Full explanation →

234

MCQmedium

You have a Secret of type 'kubernetes.io/tls' named 'tls-secret'. What keys are required in the Secret data?

A.tls.crt and tls.key

B.username and password

C.tls.crt, tls.key, and ca.crt

D..dockerconfigjson

AnswerA

Required keys for a TLS secret: the certificate and private key.

Why this answer

A is correct because a Kubernetes TLS secret of type 'kubernetes.io/tls' requires exactly two data keys: 'tls.crt' (the TLS certificate) and 'tls.key' (the private key). These are mandatory for the TLS handshake to function, as defined by the Kubernetes API for TLS secrets.

Exam trap

The trap here is that candidates often assume 'ca.crt' is required because they think of full certificate chains, but the CKAD exam tests the exact mandatory keys per the Kubernetes API documentation for 'kubernetes.io/tls'.

How to eliminate wrong answers

Option B is wrong because 'username and password' are used for basic authentication secrets (type 'kubernetes.io/basic-auth'), not for TLS secrets. Option C is wrong because while 'ca.crt' (the CA certificate) is optional and can be included for chain validation, it is not required; only 'tls.crt' and 'tls.key' are mandatory. Option D is wrong because '.dockerconfigjson' is the key for a Docker registry secret (type 'kubernetes.io/dockerconfigjson'), not for a TLS secret.

Full explanation →

235

MCQmedium

A developer wants to ensure that a pod runs with a non-root user and cannot gain root privileges. Which SecurityContext settings should be used?

A.securityContext: allowPrivilegeEscalation: false

B.securityContext: runAsNonRoot: true

C.securityContext: runAsNonRoot: true allowPrivilegeEscalation: false

D.securityContext: runAsNonRoot: true allowPrivilegeEscalation: true

AnswerC

Correct. runAsNonRoot ensures non-root; allowPrivilegeEscalation: false prevents privilege escalation.

Why this answer

Option C is correct because setting `runAsNonRoot: true` enforces that the container's user ID is non-zero (non-root), and `allowPrivilegeEscalation: false` prevents the container from gaining additional privileges beyond its initial set, such as through setuid binaries or kernel capabilities. Together, they ensure the pod runs as a non-root user and cannot escalate to root, satisfying the developer's requirement.

Exam trap

The trap here is that candidates often think `runAsNonRoot: true` alone is sufficient to prevent privilege escalation, but it only restricts the initial user ID, not the ability to escalate later, which requires `allowPrivilegeEscalation: false`.

How to eliminate wrong answers

Option A is wrong because `allowPrivilegeEscalation: false` alone does not enforce that the container runs as a non-root user; it only prevents privilege escalation, so a root user could still be used initially. Option B is wrong because `runAsNonRoot: true` alone ensures the container runs as a non-root user but does not prevent privilege escalation, meaning the container could still gain root privileges via setuid binaries or other mechanisms. Option D is wrong because `allowPrivilegeEscalation: true` explicitly permits privilege escalation, which directly contradicts the requirement to 'cannot gain root privileges'.

Full explanation →

236

MCQmedium

You need to collect metrics from an application running in a pod. The application exposes metrics on port 8080 at /metrics in Prometheus format. Which resource should you configure to allow Prometheus to scrape these metrics?

A.Create an Ingress resource that exposes the /metrics endpoint externally.

B.Create a ConfigMap with the Prometheus scrape configuration and mount it into the Prometheus pod.

C.Create a Service with annotation 'prometheus.io/scrape: "true"' and 'prometheus.io/port: "8080"'.

D.Add a PrometheusRule resource that defines the scrape target.

AnswerC

Standard Prometheus operator configuration for scraping.

Why this answer

Option C is correct because Prometheus uses a pull-based model to scrape metrics from targets. By adding the `prometheus.io/scrape: "true"` and `prometheus.io/port: "8080"` annotations to a Service that selects the pod, you enable Prometheus's built-in service discovery to automatically detect and scrape the `/metrics` endpoint on port 8080 without manual configuration.

Exam trap

The trap here is that candidates confuse Prometheus's pull-based scraping with push-based or external access patterns, leading them to choose Ingress (external exposure) or PrometheusRule (alerting) instead of the service annotation that enables automatic internal discovery.

How to eliminate wrong answers

Option A is wrong because an Ingress resource exposes HTTP/HTTPS routes externally for client access, not for Prometheus scraping; Prometheus scrapes internally and does not use Ingress for target discovery. Option B is wrong because while a ConfigMap can hold Prometheus scrape configuration, mounting it into the Prometheus pod is a manual configuration step, not the resource that enables automatic scraping of an application pod; the question asks which resource to configure on the application side to allow scraping. Option D is wrong because a PrometheusRule resource defines alerting and recording rules, not scrape targets; scrape targets are defined via ServiceMonitor, PodMonitor, or service annotations.

Full explanation →

237

Multi-Selectmedium

Which TWO of the following are valid methods to create a Service in Kubernetes? (Select 2)

Select 2 answers

A.kubectl create service clusterip my-svc --tcp=80:80

B.kubectl apply -f service.yaml

C.kubectl create deployment my-svc --image=nginx

D.kubectl run my-svc --image=nginx --port=80

E.kubectl expose deployment my-deploy --port=80

AnswersA, E

Creates a ClusterIP service via kubectl create service.

Why this answer

You can create a Service via kubectl expose or by writing a YAML manifest.

Full explanation →

238

MCQeasy

Which kubectl command creates a ConfigMap named 'app-config' with key 'color' and value 'blue'?

A.kubectl create configmap app-config --from-literal=color=blue

B.kubectl create configmap app-config --from-file=color=blue

C.kubectl create configmap app-config --from-env-file=color=blue

D.kubectl run configmap app-config --data color=blue

AnswerA

Correct syntax using --from-literal.

Why this answer

Option A is correct because `kubectl create configmap app-config --from-literal=color=blue` directly creates a ConfigMap with a key-value pair. The `--from-literal` flag specifies a literal key=value string, which is the standard way to inject a single key-value pair into a ConfigMap without referencing an external file.

Exam trap

The trap here is confusing `--from-literal` with `--from-file` or `--from-env-file`, as candidates often misremember which flag accepts a literal key=value string versus a file path.

How to eliminate wrong answers

Option B is wrong because `--from-file` expects a file path (e.g., `--from-file=color.txt`), not a literal key=value pair; using `--from-file=color=blue` would attempt to read a file named 'color=blue', which does not exist. Option C is wrong because `--from-env-file` expects a file containing environment variable definitions in KEY=VALUE format (e.g., `--from-env-file=env.txt`), not a literal key=value pair. Option D is wrong because `kubectl run` is used to create a Pod, not a ConfigMap; the `--data` flag is invalid for `kubectl run` and does not create ConfigMaps.

Full explanation →

239

MCQhard

You have a Deployment that uses an httpGet liveness probe on port 8080 with path /healthz. The probe fails after the container starts, but you can successfully curl http://localhost:8080/healthz from within the container. What is the most likely cause?

A.The liveness probe port is incorrect

B.The container is not running

C.The liveness probe path is incorrect

D.The container is listening on localhost (127.0.0.1) instead of 0.0.0.0

AnswerD

The liveness probe runs from the node and cannot reach localhost inside the container. The container must listen on all interfaces (0.0.0.0) for the probe to succeed.

Why this answer

The liveness probe is executed by the kubelet from the node's network namespace, not from within the container. If the application binds only to 127.0.0.1 (localhost), it will only accept connections from within the container itself. The kubelet's HTTP GET request to the pod's IP on port 8080 will be refused because the socket is not listening on 0.0.0.0, causing the probe to fail even though a local curl succeeds.

Exam trap

The trap here is that candidates see a successful curl from inside the container and assume the probe should work, failing to realize that the kubelet probes from outside the container's network namespace and cannot reach a service bound only to 127.0.0.1.

How to eliminate wrong answers

Option A is wrong because the probe is configured to use port 8080, and the curl test confirms the application is indeed listening on port 8080 inside the container, so the port is correct. Option B is wrong because the container is clearly running — the user can successfully execute curl inside it, which requires a running container. Option C is wrong because the curl test uses the exact same path /healthz and succeeds, proving the path is correct and the endpoint is reachable from within the container.

Full explanation →

240

Multi-Selectmedium

Which TWO statements about Ingress are correct? (Select 2)

Select 2 answers

A.Ingress can terminate TLS.

B.Ingress provides a ClusterIP for internal access.

C.Ingress can route traffic based on the host header.

D.Ingress can load balance TCP traffic.

E.Ingress automatically assigns an external IP to the Service.

AnswersA, C

Ingress can terminate TLS using secrets.

Why this answer

Options A and D are correct. Ingress can provide host-based routing and TLS termination. Option B is false because Ingress is not for TCP/UDP.

Option C is false because Ingress does not provide a default ClusterIP. Option E is false because Ingress does not directly assign external IPs.

Full explanation →

241

MCQhard

An Ingress resource routes traffic to a Service 'web' on port 80. The Service has multiple endpoints but all return 503. What should be checked first?

A.Ensure that the Service type is ClusterIP

B.Check the readiness probe of the Pods

C.Verify that the Service port matches the Pod's container port

D.Check the Ingress controller logs

AnswerB

503 often indicates Pods are not ready; readiness probe failing causes removal from endpoints.

Why this answer

A 503 Service Unavailable error from the Ingress indicates the upstream Service is not ready to serve traffic. The most common cause is Pods failing their readiness probes, which removes them from the Service's endpoint list. Checking the readiness probe status directly addresses why the Service has endpoints but returns 503.

Exam trap

CNCF often tests the distinction between readiness and liveness probes, where candidates mistakenly check liveness or assume a port mismatch, but readiness directly controls traffic routing via Services.

How to eliminate wrong answers

Option A is wrong because ClusterIP is the default Service type and does not cause 503 errors; changing it would not fix the issue. Option C is wrong because if the Service port mismatched the container port, the Service would have no endpoints at all, not endpoints returning 503. Option D is wrong because Ingress controller logs would show routing errors or backend unavailability, but the first diagnostic step should be checking the Pods' readiness, not logs.

Full explanation →

242

Multi-Selecthard

You want to apply a Pod Security Admission (PSA) policy that enforces the 'restricted' profile in the 'dev' namespace, but only for Pods that are not exempt. Which TWO steps are required? (Select TWO)

Select 2 answers

A.Set the label 'pod-security.kubernetes.io/enforce=restricted' on the namespace

B.Add a 'securityContext' field to the Pod template with 'runAsUser: 1000'

C.Set the label 'pod-security.kubernetes.io/enforce=baseline' on the namespace

D.Set the label 'pod-security.kubernetes.io/warn=restricted' on the namespace

E.Configure Pods to meet the restricted profile requirements, such as setting runAsNonRoot and seccompProfile

AnswersA, E

This label enforces the restricted profile for all pods in the namespace.

Why this answer

Option A is correct because setting the label 'pod-security.kubernetes.io/enforce=restricted' on the namespace instructs the Pod Security Admission controller to reject any Pod that does not meet the restricted profile, unless the Pod is exempt (e.g., system-critical Pods or those with specific exemptions). This label directly enforces the policy at admission time, ensuring only compliant Pods are created in the 'dev' namespace.

Exam trap

The trap here is confusing the 'warn' mode with 'enforce' mode, as candidates often think a warning label is sufficient to block non-compliant Pods, but only the 'enforce' label actually rejects them at admission time.

Full explanation →

243

MCQhard

You are designing a Pod that must run a diagnostic tool to collect network logs before the main application starts. The diagnostic tool should run to completion, then the main application starts. Which approach should you use?

A.Add the diagnostic tool as an init container in the Pod

B.Add the diagnostic tool as a sidecar container in the same Pod

C.Add the diagnostic tool as a sidecar container with a postStart hook

D.Create a separate Job that runs before the Pod

AnswerA

Init containers run sequentially before any app containers start. They must complete successfully before app containers launch.

Why this answer

Option B is correct. Init containers run sequentially to completion before app containers start. Option A is incorrect because sidecars run concurrently with the main container.

Option C is incorrect because a Job is a separate resource, not part of the same Pod. Option D is incorrect because the diagnostic tool is not a sidecar.

Full explanation →

244

MCQeasy

What annotation is required on an Ingress resource to use a specific IngressClass (e.g., 'nginx')?

A.kubernetes.io/ingress-type: nginx

B.kubernetes.io/ingress.class: nginx

C.ingress.kubernetes.io/class: nginx

D.kubernetes.io/class: nginx

AnswerB

Correct annotation to specify the IngressClass.

Why this answer

The annotation 'kubernetes.io/ingress.class' is used to specify the IngressClass. Alternatively, you can use spec.ingressClassName, but the annotation is the traditional way.

Full explanation →

245

MCQmedium

A pod named 'app' is stuck in 'Pending' state. You run 'kubectl describe pod app' and see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the most likely cause?

A.The pod's CPU request is higher than the available CPU on any node

B.The container image is not found

C.The pod is in CrashLoopBackOff

D.The pod has been evicted due to memory pressure

AnswerA

The scheduling failure is due to insufficient CPU resources on all nodes.

Why this answer

The event '0/3 nodes are available: 3 Insufficient cpu' indicates that the pod's CPU resource request exceeds the allocatable CPU capacity on every node in the cluster. Kubernetes schedules pods based on resource requests, not limits, so if the sum of CPU requests across all pods on a node would exceed the node's capacity, the pod remains Pending. This is the most likely cause because the error message directly points to insufficient CPU resources.

Exam trap

The trap here is that candidates confuse resource requests with resource limits, or assume that the pod is failing at runtime (like CrashLoopBackOff) when the error is purely a scheduling issue indicated by the Pending state and the specific 'Insufficient cpu' event.

How to eliminate wrong answers

Option B is wrong because a missing container image would produce an 'ImagePullBackOff' or 'ErrImagePull' event, not an 'Insufficient cpu' scheduling error. Option C is wrong because CrashLoopBackOff is a pod status that occurs after the pod has been scheduled and started, not while it is still Pending. Option D is wrong because eviction due to memory pressure results in a 'Evicted' status, not a Pending state, and the event would mention memory, not CPU.

Full explanation →

246

MCQhard

A ClusterRole named 'secret-reader' grants get, list, watch on secrets in all namespaces. A RoleBinding in namespace 'app' binds this ClusterRole to a ServiceAccount 'app-sa'. Which of the following is true about the effective permissions of 'app-sa'?

A.The ServiceAccount can read secrets in all namespaces

B.The RoleBinding is invalid because ClusterRole cannot be used with RoleBinding

C.The ServiceAccount can read secrets only in namespace 'app'

D.The ServiceAccount can read secrets only in the default namespace

AnswerC

Correct. A RoleBinding scopes the ClusterRole's permissions to the RoleBinding's namespace.

Why this answer

A RoleBinding can only grant permissions within its own namespace, even when it references a ClusterRole. Since the RoleBinding is in namespace 'app', the ServiceAccount 'app-sa' receives the permissions defined in the 'secret-reader' ClusterRole, but scoped only to namespace 'app'. Therefore, it can read secrets only in namespace 'app', not in all namespaces.

Exam trap

The trap here is that candidates often assume a ClusterRole always grants cluster-wide permissions when bound via any binding, forgetting that a RoleBinding restricts the scope to its own namespace.

How to eliminate wrong answers

Option A is wrong because a RoleBinding scopes the ClusterRole's permissions to the RoleBinding's namespace ('app'), not to all namespaces; to grant cluster-wide access, a ClusterRoleBinding must be used. Option B is wrong because a RoleBinding can legally reference a ClusterRole; this is a standard Kubernetes pattern to reuse cluster-scoped roles within a specific namespace. Option D is wrong because the RoleBinding is in namespace 'app', not 'default', so the permissions apply to namespace 'app' only.

Full explanation →

247

MCQeasy

You want to scale a Deployment named 'frontend' to 5 replicas. Which command should you use?

A.kubectl set replicas deployment frontend=5

B.kubectl update deployment frontend --replicas=5

C.kubectl scale deployment frontend --replicas=5

D.kubectl scale --replicas=5 frontend

AnswerC

Correct.

Why this answer

'kubectl scale deployment frontend --replicas=5' is the correct imperative command.

Full explanation →

248

MCQhard

A pod is stuck in Pending state. You run 'kubectl describe pod mypod' and see the event: '0/3 nodes are available: 1 Insufficient memory, 2 Insufficient cpu'. The pod has resource requests defined. Which action would allow the pod to be scheduled?

A.Increase the resource requests for the container

B.Delete the pod and recreate it with the same spec

C.Decrease the memory and CPU requests to fit within available node resources

D.Decrease the CPU request but keep the memory request the same

AnswerC

This would make the pod schedulable on the existing nodes.

Why this answer

The pod is unschedulable because the cluster's three nodes collectively lack sufficient CPU and memory to satisfy the pod's resource requests. Decreasing the memory and CPU requests to fit within the available node resources (option C) directly resolves the scheduling failure by making the pod's resource demands compatible with the remaining capacity on at least one node.

Exam trap

CNCF often tests the misconception that simply recreating the pod or adjusting only one resource dimension will fix scheduling issues, when in fact the scheduler evaluates all resource requests simultaneously against each node's allocatable capacity.

How to eliminate wrong answers

Option A is wrong because increasing resource requests would make the pod even more demanding, worsening the scheduling failure. Option B is wrong because deleting and recreating the pod with the same spec does not change the resource requests or node availability, so it will remain stuck in Pending. Option D is wrong because decreasing only the CPU request while keeping the memory request unchanged would still leave the memory request unmet (the event shows 1 node has insufficient memory), so the pod would still be unschedulable.

Full explanation →

249

MCQmedium

You want to see the IP address and the node on which each pod in the 'default' namespace is running. Which command provides this information?

A.kubectl describe pods

B.kubectl get pods -o wide

C.kubectl get pods --show-labels

D.kubectl get pods -o yaml

AnswerB

The -o wide flag shows additional columns including IP and Node.

Why this answer

Option B is correct because `kubectl get pods -o wide` outputs additional columns including the pod's IP address and the node it is scheduled on, which directly answers the question. The `-o wide` flag extends the default output format to show these fields without requiring a full resource description or YAML output.

Exam trap

The trap here is that candidates may choose `kubectl describe pods` (Option A) because it shows IP and node information, but they overlook that `-o wide` provides a cleaner, tabular view for multiple pods, which is the intended use case in the question.

How to eliminate wrong answers

Option A is wrong because `kubectl describe pods` shows detailed information about pods, including IP and node, but it is not a concise command to 'see' this data for all pods at once; it requires scrolling through verbose output per pod. Option C is wrong because `--show-labels` only adds label columns to the default pod list, not IP or node information. Option D is wrong because `-o yaml` outputs the full YAML representation of pod objects, which includes IP and node fields but is overly verbose and not the standard way to quickly view this tabular data.

Full explanation →

250

Multi-Selectmedium

Which TWO methods can be used to expose a Secret's data as environment variables inside a container? (Select 2)

Select 2 answers

A.Using 'args' in container spec

B.Using 'env.valueFrom.secretKeyRef'

C.Using 'env.valueFrom.configMapKeyRef'

D.Using 'volumeMounts' with a secret volume

E.Using 'envFrom.secretRef'

AnswersB, E

Exposes a single key as a named env var.

Why this answer

Option B is correct because `env.valueFrom.secretKeyRef` allows you to inject a specific key from a Kubernetes Secret as an environment variable into a container. This is a standard method for exposing sensitive data like passwords or tokens directly into the container's environment without hardcoding them in the Pod spec.

Exam trap

CNCF often tests the distinction between `env.valueFrom.secretKeyRef` (for a single key) and `envFrom.secretRef` (for all keys), and the trap is that candidates confuse `secretKeyRef` with `configMapKeyRef` or think `args` can be used for environment injection.

Full explanation →

251

MCQmedium

A company wants to ensure zero-downtime deployments for a stateless web application running in Kubernetes. They have a single Deployment with 3 replicas and a Service of type LoadBalancer. Which strategy should they use to achieve this?

A.Use Recreate strategy

B.Use RollingUpdate with maxSurge=100% and maxUnavailable=100%

C.Use RollingUpdate with maxSurge=25% and maxUnavailable=0

D.Use RollingUpdate with maxSurge=0 and maxUnavailable=25%

AnswerC

RollingUpdate with maxUnavailable=0 ensures no pods are taken down before new ones are ready, providing zero-downtime.

Why this answer

Option C is correct because a RollingUpdate strategy with maxSurge=25% and maxUnavailable=0 ensures that during a deployment, the desired number of replicas is always available (no downtime). maxUnavailable=0 means no old Pods are terminated until new ones are ready, and maxSurge=25% allows one extra Pod (25% of 3 replicas = 0.75, rounded up to 1) to be created before terminating old ones, maintaining capacity for zero-downtime updates.

Exam trap

The trap here is that candidates often confuse maxSurge and maxUnavailable, thinking that allowing some unavailability (e.g., maxUnavailable=25%) is acceptable for zero-downtime, but in Kubernetes, zero-downtime strictly requires maxUnavailable=0 to ensure no Pods are terminated before replacements are ready.

How to eliminate wrong answers

Option A is wrong because the Recreate strategy terminates all existing Pods before creating new ones, causing downtime during the update. Option B is wrong because maxSurge=100% and maxUnavailable=100% allows all Pods to be replaced simultaneously, which can cause a temporary loss of service if readiness probes fail or new Pods take time to become ready, violating zero-downtime requirements. Option D is wrong because maxSurge=0 and maxUnavailable=25% means no new Pods are created until old ones are terminated, reducing available capacity by 25% (1 Pod) during the update, which can cause downtime if traffic exceeds remaining capacity.

Full explanation →

252

Multi-Selecthard

A pod is running but not serving traffic. You suspect the readiness probe is failing. Which THREE commands or actions would help you diagnose the readiness probe issue?

Select 3 answers

A.Examine the container logs for errors during readiness probe checks.

B.Run 'kubectl top pod <pod-name>' to check CPU/memory usage.

C.Run 'kubectl get nodes' to see node conditions.

D.Run 'kubectl describe pod <pod-name>' to check the events section for probe failures.

E.Exec into the container and manually curl the readiness endpoint to test it.

AnswersA, D, E

Logs may reveal why the probe is failing.

Why this answer

Option A is correct because container logs often contain detailed error messages from the readiness probe itself, such as HTTP 4xx/5xx responses or connection timeouts. By examining the logs, you can directly see why the probe is failing, e.g., the application's health endpoint returning a non-2xx status or the probe timing out.

Exam trap

CNCF often tests the distinction between resource monitoring commands and probe-specific diagnostics, so candidates may mistakenly choose 'kubectl top pod' or 'kubectl get nodes' thinking they reveal probe failures, when in fact only describe, logs, and direct endpoint testing are relevant.

Full explanation →

253

MCQeasy

Which command forwards port 8080 on the local machine to port 80 on a pod named 'web-pod'?

A.kubectl expose pod web-pod --port=8080 --target-port=80

B.kubectl proxy --port=8080 --target=pod/web-pod:80

C.kubectl port-forward pod/web-pod 8080:80

D.kubectl exec web-pod -- curl http://localhost:8080

AnswerC

Correct syntax for port-forward.

Why this answer

The kubectl port-forward command is used for this. The syntax is: kubectl port-forward pod/web-pod 8080:80

Full explanation →

254

MCQeasy

Which of the following commands creates a Job that runs a single pod executing the command 'sleep 30'?

A.kubectl run myjob --image=busybox --restart=OnFailure -- sleep 30

B.kubectl create job myjob --image=busybox -- sleep 30

C.kubectl create job myjob --image=busybox --command -- sleep 30

D.kubectl create job myjob --image=busybox sleep 30

AnswerB

Correct syntax: 'kubectl create job <name> --image=<image> -- <command>'.

Why this answer

Option C is correct. The 'kubectl create job' command with the '--image' and '--' syntax is the correct way to create a Job from the command line. Option A uses 'run' which creates a Deployment, not a Job.

Option B creates a Job but the syntax '-- sleep 30' is missing the '--' separator. Option D is a correct command but not the only correct one; however, since the question asks for the single best answer and C is more concise, it is correct.

Full explanation →

255

MCQmedium

You need to scale a Deployment named 'api' to 10 replicas. Which command works?

A.kubectl set replicas deployment/api 10

B.kubectl scale --replicas=10 deployment/api

C.kubectl scale deployment api --replicas=10

D.kubectl edit deployment api --replicas=10

AnswerC

Correct command.

Why this answer

kubectl scale can scale a deployment. Option A is correct.

Full explanation →

256

MCQmedium

A Deployment is configured with strategy type 'Recreate'. Which statement about this strategy is true?

A.It creates a new ReplicaSet but does not scale down the old one.

B.It updates Pods by gradually terminating old Pods and creating new ones.

C.It terminates all existing Pods before creating new Pods.

D.It first creates new Pods and then terminates old Pods.

AnswerC

Correct. All old Pods are killed before new ones are created.

Why this answer

Recreate terminates all existing Pods before creating new ones, causing downtime.

Full explanation →

257

MCQeasy

Which kubectl command is used to view the rollout status of a Deployment named 'web-app'?

A.kubectl rollout history deployment web-app

B.kubectl describe deployment web-app

C.kubectl status deployment web-app

D.kubectl rollout status deployment web-app

AnswerD

This is the correct command to view rollout status.

Why this answer

The command 'kubectl rollout status deployment web-app' displays the current status of the rollout, including whether it is complete or progressing.

Full explanation →

258

MCQeasy

You need to create a ConfigMap named 'app-config' with key 'APP_COLOR' and value 'blue'. Which command creates this ConfigMap?

A.kubectl create configmap app-config --from-env-file=APP_COLOR=blue

B.kubectl create configmap app-config --from-literal=APP_COLOR=blue

C.kubectl create configmap app-config --from-literal=APP_COLOR:blue

D.kubectl create configmap app-config --from-file=APP_COLOR=blue

AnswerB

Correct. --from-literal is used for inline key-value pairs.

Why this answer

Option B is correct because `kubectl create configmap app-config --from-literal=APP_COLOR=blue` uses the `--from-literal` flag, which directly creates a ConfigMap entry from a key-value pair specified in the command line. The syntax `key=value` is required for literal data, and this command correctly maps the key 'APP_COLOR' to the value 'blue'.

Exam trap

The trap here is confusing the `--from-literal` syntax (which requires `=`) with the colon-based syntax used in YAML or environment files, leading candidates to incorrectly choose Option C.

How to eliminate wrong answers

Option A is wrong because `--from-env-file` expects a path to a file containing environment variables in `key=value` format, not a literal key-value pair; using `--from-env-file=APP_COLOR=blue` would attempt to read a file named 'APP_COLOR=blue', which does not exist. Option C is wrong because `--from-literal` requires the `=` sign to separate key and value, not a colon (`:`); using a colon would be interpreted as part of the key name, resulting in a key like 'APP_COLOR:blue' with an empty value. Option D is wrong because `--from-file` expects a file path or a file with a key specified as `key=filepath`, not a literal value; `--from-file=APP_COLOR=blue` would try to read a file named 'blue' and assign its contents to the key 'APP_COLOR', which is not the intended behavior.

Full explanation →

259

MCQhard

A pod's container has securityContext with runAsNonRoot: true but no runAsUser set. The container image has a user 'appuser' with UID 1001. Will the pod run successfully?

A.No, because runAsNonRoot requires an explicit runAsUser

B.No, because the container image user is unknown

C.Yes, because runAsNonRoot is ignored if runAsUser is not set

D.Yes, because the container image user is non-root

AnswerD

runAsNonRoot: true requires that the container does not run as root. The image's default user is non-root (1001), so it's allowed.

Why this answer

Option D is correct because when `runAsNonRoot: true` is set in the pod's security context without an explicit `runAsUser`, Kubernetes checks the container image's user (as defined in the Dockerfile `USER` directive). If that user is non-root (UID 1001 in this case), the container runs as that user, satisfying the non-root requirement. The pod will start successfully because the image user is non-root, and no explicit `runAsUser` is required.

Exam trap

CNCF often tests the misconception that `runAsNonRoot` requires an explicit `runAsUser` field, but the correct behavior is that Kubernetes falls back to the container image's user if no `runAsUser` is set.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot` does not require an explicit `runAsUser`; it can rely on the container image's user if it is non-root. Option B is wrong because the container image user is known (UID 1001) and is non-root, so the pod will run successfully. Option C is wrong because `runAsNonRoot` is not ignored when `runAsUser` is not set; it validates the container image's user instead.

Full explanation →

260

MCQhard

A pod is failing to start with error 'container has runAsNonRoot and image will run as root'. The container image runs as root. Which change allows the pod to run?

A.Remove runAsNonRoot: true from securityContext

B.Add fsGroup: 1000

C.Set allowPrivilegeEscalation: false

D.Set runAsUser to a non-zero UID, e.g., 1000

AnswerD

This overrides the image's user to a non-root user, satisfying runAsNonRoot.

Why this answer

Option B is correct: set runAsUser to a non-zero ID to run as non-root, satisfying runAsNonRoot. Option A removes the check but may be insecure. Option C does not change user.

Option D is not valid.

Full explanation →

261

Multi-Selectmedium

Which of the following are valid methods to perform a blue-green deployment? (Choose TWO)

Select 2 answers

A.Create two Deployments for blue and green, and update the Service selector to point to the new version

B.Create a single Deployment and update the pod labels to match the Service selector

C.Use a single Deployment and change the container image, then perform a rolling update

D.Use an Ingress resource to route traffic to different Services, each backing a different version

E.Delete the old Deployment and create a new one

AnswersA, D

Classic blue-green with Service selector.

Why this answer

Options A and D are valid blue-green strategies. Option A uses two Deployments and a Service selector switch. Option D uses a single Deployment with label update but that requires careful orchestration; it's not typical blue-green.

Actually, typical blue-green uses two separate Deployments. Option A and D? Let me correct: Option A is correct. Option C is using an Ingress, which can also be used for blue-green.

But standard is A and C? The question expects two correct. Let me set: Option A and Option D are correct? I'll adjust. Actually, a common blue-green is with two Deployments and changing Service selector (A) or using an Ingress to route (C).

Option D is not standard. I'll fix the response.

Full explanation →

262

MCQhard

You have a Deployment with multiple replicas. You want to expose it via a Service that has a stable IP address and is accessible from outside the cluster on a static port on each node. Which Service type should you use?

A.NodePort

B.LoadBalancer

C.ClusterIP

D.ExternalName

AnswerA

Correct. NodePort exposes the service on a static port on each node's IP.

Why this answer

NodePort exposes the Service on a static port on each node's IP, allowing external access. ClusterIP is only internal. LoadBalancer builds on NodePort but requires cloud provider support.

ExternalName maps to an external DNS name. Option B is correct.

Full explanation →

263

MCQmedium

You have a headless Service for a StatefulSet. The DNS query for the service returns no A records. What is the most likely cause?

A.The Service selector does not match any pod labels

B.The Service has clusterIP set to an IP address

C.The Service is of type ExternalName

D.The StatefulSet is using a volumeClaimTemplate

AnswerA

If the selector doesn't match pod labels, the Service has no endpoints, and DNS returns no A records.

Why this answer

A headless Service (clusterIP: None) returns DNS A records for each ready pod endpoint. If no pod is ready, no A records are returned.

Full explanation →

264

Multi-Selectmedium

Which TWO are valid Service types? (Choose two.)

Select 2 answers

A.NodePort

B.Headless

C.Ingress

D.ClusterIP

E.Pod

AnswersA, D

Valid type.

Why this answer

Valid types are ClusterIP, NodePort, LoadBalancer, ExternalName. ClusterIP and NodePort are two of them.

Full explanation →

265

MCQmedium

You need to configure a container to shut down gracefully when it receives a SIGTERM signal, with a timeout of 30 seconds before force kill. Which field in the Pod spec should you set?

A.activeDeadlineSeconds

B.livenessProbe.periodSeconds

C.restartPolicy

D.terminationGracePeriodSeconds

AnswerD

Correct. This field specifies the grace period in seconds.

Why this answer

terminationGracePeriodSeconds sets the time Kubernetes waits for a pod to shut down gracefully after sending SIGTERM.

Full explanation →

266

Multi-Selectmedium

Which TWO of the following are valid patterns for sidecar containers in a multi-container pod?

Select 2 answers

A.Adapter

B.Sidecar

C.Ambassador

D.Init container

E.Proxy

AnswersA, B

An adapter standardizes interfaces.

Why this answer

The sidecar, adapter, and ambassador are common patterns. Init container is not a sidecar pattern.

Full explanation →

267

Multi-Selecteasy

Which TWO of the following are required to create a Role and RoleBinding that grants read access to Pods in the 'development' namespace? (Choose two.)

Select 2 answers

A.A NetworkPolicy that allows traffic to Pods

B.A ClusterRole with the same rules

C.A RoleBinding that binds the Role to a subject (User or ServiceAccount)

D.A ClusterRoleBinding that binds the Role to a subject

E.A Role with apiGroups: [""], resources: ["pods"], verbs: ["get", "list", "watch"]

AnswersC, E

Correct.

Why this answer

Option C is correct because a RoleBinding is the Kubernetes resource that binds a Role (which defines permissions) to a specific subject (User, Group, or ServiceAccount) within a namespace. Without a RoleBinding, the permissions defined in the Role are not granted to any identity, making it a required component for granting access.

Exam trap

The trap here is that candidates often confuse RoleBindings with ClusterRoleBindings, thinking a ClusterRoleBinding is needed for a Role, or they mistakenly believe a NetworkPolicy is part of RBAC, when it is a separate network security mechanism.

Full explanation →

268

MCQeasy

A Deployment has 3 replicas. You run 'kubectl scale deployment mydeploy --replicas=5'. What happens?

A.The command fails because you must edit the YAML directly.

B.A new Deployment is created with 5 replicas.

C.The Deployment is updated to have 5 replicas, and the ReplicaSet creates 2 additional pods.

D.The current ReplicaSet is deleted and a new one is created with 5 replicas.

AnswerC

The scale command changes the desired replicas field. The existing ReplicaSet will create new pods to match the desired count.

Why this answer

Option A is correct: the command scales the Deployment to 5 replicas. Option B is incorrect because the command is valid. Option C is incorrect because ReplicaSet is managed by Deployment.

Option D is incorrect; no new Deployment is created.

Full explanation →

269

Multi-Selectmedium

Which TWO of the following are valid fields in a CronJob spec? (Select 2)

Select 2 answers

A.restartPolicy

B.concurrencyPolicy

C.completions

D.schedule

E.parallelism

AnswersB, D

Correct: concurrencyPolicy controls how concurrent runs are handled (Allow, Forbid, Replace).

Why this answer

B is correct because `concurrencyPolicy` is a valid field in a CronJob spec that controls how concurrent executions of the job are handled. It can be set to `Allow`, `Forbid`, or `Replace`, which determines whether a new job can start while a previous one is still running.

Exam trap

CNCF often tests the distinction between CronJob spec fields and Job spec fields, trapping candidates who confuse `completions` and `parallelism` (Job-level) with CronJob-level fields like `schedule` and `concurrencyPolicy`.

Full explanation →

270

MCQeasy

Which Service type is used to expose a Service externally using a cloud provider's load balancer?

A.NodePort

B.LoadBalancer

C.ExternalName

D.ClusterIP

AnswerB

LoadBalancer integrates with cloud providers to expose the Service externally.

Why this answer

Option B is correct. LoadBalancer Service provisions an external load balancer (if supported by the cloud provider) to expose the Service.

Full explanation →

271

MCQmedium

You run 'kubectl port-forward pod/my-pod 8080:80' and try to access 'http://localhost:8080', but the connection is refused. The pod is running and port 80 is open. What is the most likely issue?

A.The container is listening on port 8080 instead of 80

B.Local port 8080 is already in use by another process

C.The service must exist for port-forwarding to work

D.The pod is in a different namespace and the namespace flag is missing

AnswerB

If local port 8080 is occupied, the port-forward will fail or the connection will be refused.

Why this answer

kubectl port-forward forwards from a local port to a port on the pod. If the local port 8080 is already in use, the command will fail or the forwarding won't work. Option C is correct.

Option A is incorrect because the command forwards to the pod, not through a service. Option B is incorrect because port 80 on the pod is open. Option D is incorrect because kubectl port-forward works even if no services exist.

Full explanation →

272

MCQhard

A StatefulSet named 'mysql' is deployed with 3 replicas. The administrator wants to create a headless Service so that each pod gets a unique DNS entry. Which Service specification should be used?

A.apiVersion: v1 kind: Service metadata: name: mysql spec: type: NodePort selector: app: mysql ports: - port: 3306

B.apiVersion: v1 kind: Service metadata: name: mysql spec: clusterIP: None selector: app: mysql ports: - port: 3306

C.apiVersion: v1 kind: Service metadata: name: mysql spec: type: ClusterIP selector: app: mysql ports: - port: 3306

D.apiVersion: v1 kind: Service metadata: name: mysql spec: clusterIP: "" selector: app: mysql ports: - port: 3306

AnswerB

Setting clusterIP: None creates a headless Service.

Why this answer

A headless Service is created by setting clusterIP: None. This allows DNS to return the pod IPs directly, and for StatefulSets, each pod gets a DNS name like <pod>.<service>.<namespace>.svc.cluster.local.

Full explanation →

273

MCQmedium

You want to view the resource usage of all pods running on a node named 'node01'. Which command should you use?

A.kubectl top nodes node01

B.kubectl get pods -o wide --all-namespaces --field-selector spec.nodeName=node01

C.kubectl top pods --all-namespaces --field-selector spec.nodeName=node01

D.kubectl describe node node01 | grep -A 10 'Non-terminated Pods'

AnswerC

This command shows pod resource usage for all pods scheduled on node01.

Why this answer

Option C is correct because `kubectl top pods` retrieves real-time CPU and memory usage metrics for pods, and the `--field-selector spec.nodeName=node01` filter restricts the output to only pods scheduled on the specified node. This directly answers the requirement to view resource usage of all pods on 'node01'.

Exam trap

The trap here is confusing `kubectl top pods` (which shows live resource usage) with `kubectl get pods` (which shows static pod metadata) or `kubectl describe node` (which shows node-level resource allocation, not per-pod usage).

How to eliminate wrong answers

Option A is wrong because `kubectl top nodes` shows resource usage at the node level (aggregate CPU/memory for the entire node), not per-pod usage. Option B is wrong because `kubectl get pods -o wide` lists pod details (like IP and node) but does not include resource usage metrics; it only shows static pod information. Option D is wrong because `kubectl describe node` shows node-level resource allocation (requests/limits) and pod counts, not real-time resource usage of individual pods.

Full explanation →

274

Multi-Selectmedium

Which THREE statements about NetworkPolicy are correct?

Select 3 answers

A.NetworkPolicy uses labels to select pods and namespaces

B.By default, if no NetworkPolicy selects a pod, all traffic to that pod is allowed

C.NetworkPolicy resources are cluster-scoped

D.ipBlock can only be used in ingress rules

E.An empty podSelector in spec selects all pods in the namespace

AnswersA, B, E

podSelector and namespaceSelector use label selectors.

Why this answer

NetworkPolicy is namespaced, can use podSelector and namespaceSelector, and default is allow all if no policy selects the pod. Empty podSelector selects all pods in the namespace. ipBlock can be used in both ingress and egress rules.

Full explanation →

275

MCQhard

You are a platform engineer managing a Kubernetes cluster version 1.28. A development team has deployed a microservice application called 'order-processor' in the 'prod' namespace. The application consists of a frontend Pod 'frontend' and a backend Pod 'backend', each with a single container. The frontend needs to communicate with the backend using a headless Service named 'backend-svc' that selects Pods with label 'app:backend'. The backend Pods are expected to scale horizontally, and the frontend uses a DNS lookup to discover all backend Pod IPs for client-side load balancing. However, after deploying, the frontend is unable to resolve 'backend-svc' to any IP addresses. The backend Pod is running and has the correct label 'app:backend'. The Service 'backend-svc' is defined as a ClusterIP with clusterIP: None. The frontend container has the 'default' DNS policy. What is the most likely cause of the failure?

A.The headless Service must have the 'publishNotReadyAddresses: true' field to include not-ready Pods.

B.The Service and frontend are in different namespaces; the DNS name must be fully qualified.

C.The backend Pod does not have a readiness probe defined, so it is not considered ready and not added to DNS records.

D.The frontend Pod's DNS policy is set to 'None' which disables DNS resolution.

AnswerC

Default behavior: only ready Pods are published in headless Service DNS records.

Why this answer

Option C is correct because a headless Service (clusterIP: None) creates DNS A/AAAA records only for Pods that are in the Ready state. Without a readiness probe defined on the backend Pod, Kubernetes considers the Pod not ready, so it is excluded from the DNS records. The frontend's DNS lookup of 'backend-svc' therefore returns no IP addresses, causing the resolution failure.

Exam trap

The trap here is that candidates assume a headless Service always returns all matching Pod IPs regardless of readiness, but Kubernetes only publishes ready Pods to DNS unless explicitly configured otherwise.

How to eliminate wrong answers

Option A is wrong because 'publishNotReadyAddresses: true' is a legacy field (deprecated in 1.25) that forces inclusion of not-ready Pods in DNS; it is not required for headless Services and is not the default cause of the issue. Option B is wrong because the question states both the frontend and backend are in the 'prod' namespace, so no cross-namespace DNS qualification is needed; a simple service name resolves within the same namespace. Option D is wrong because the frontend container has the 'default' DNS policy (not 'None'), so DNS resolution is enabled and not disabled.

Full explanation →

276

MCQhard

You have a Helm chart that deploys a web application. You want to conditionally include a ConfigMap in the release based on a value 'config.enabled'. Which template syntax correctly implements this?

A.{% if .Values.config.enabled %} (ConfigMap YAML) {% endif %}

B.{{- if .Values.config.enabled }} (ConfigMap YAML) {{- end }}

C.{{- when .Values.config.enabled }} (ConfigMap YAML) {{- end }}

D.{{- if .Values.config.enabled }} (ConfigMap YAML) {{- end }}

AnswerB

Correct Helm syntax.

Why this answer

Option D uses the correct Helm template syntax: '{{- if .Values.config.enabled }}' to conditionally include content. Option A uses Python-style syntax. Option B is close but missing the if statement.

Option C uses an invalid 'when' statement.

Full explanation →

277

MCQhard

A pod is running with a service account that has been granted a Role to get pods. The pod's code uses the Kubernetes API from within the container. However, the API call fails with a 403 Forbidden error. Which file should the pod read to obtain the authentication token?

A./var/run/secrets/kubernetes.io/serviceaccount/token

B./etc/kubernetes/admin.conf

C./var/run/secrets/kubernetes.io/serviceaccount/namespace

D./var/run/secrets/kubernetes.io/serviceaccount/ca.crt

AnswerA

Correct. The token file is mounted at that path.

Why this answer

The pod's service account token is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. This token is a signed JWT that the pod uses to authenticate to the Kubernetes API server. Without reading this file, the pod cannot present valid credentials, resulting in a 403 Forbidden error.

Exam trap

CNCF often tests the distinction between the token file, the CA certificate, and the namespace file — candidates confuse the token with the CA cert or think the admin kubeconfig is accessible inside the pod.

How to eliminate wrong answers

Option B is wrong because /etc/kubernetes/admin.conf is the kubeconfig file for the cluster administrator, not for a pod's service account; it contains admin-level credentials and is not mounted inside pods. Option C is wrong because /var/run/secrets/kubernetes.io/serviceaccount/namespace contains only the namespace name, not an authentication token. Option D is wrong because /var/run/secrets/kubernetes.io/serviceaccount/ca.crt is the CA certificate used to verify the API server's TLS certificate, not an authentication token.

Full explanation →

278

MCQhard

A canary deployment is being implemented using two Deployments (stable and canary) and a Service. The Service's label selector has two entries: 'app: myapp' and 'version: stable'. Initially, the canary Deployment's pods have label 'version: canary'. To route a small percentage of traffic to the canary, what should you do?

A.Update the Service's selector to include both 'version: stable' and 'version: canary'

B.Change the canary Deployment's pod template labels to also include 'version: stable' so that the Service selects them

C.Use a NetworkPolicy to allow traffic to the canary

D.Create a new Service that points to both Deployments

AnswerB

By adding the label 'version: stable' to the canary pods, they will be selected by the Service. Since the canary has fewer replicas, it will receive a proportionally smaller amount of traffic.

Why this answer

The Service currently selects only pods with 'version: stable'. To route some traffic to canary, you need the canary pods to also be selected by the Service. You can change the canary pods' 'version' label to 'stable' (or add an additional label), or modify the Service selector to include both versions.

However, the simplest approach is to update the canary Deployment's pod template labels to include 'version: stable' so that both Deployments have the same label, but the canary has a smaller number of replicas. Alternatively, you can use a Service Mesh like Istio for fine-grained traffic splitting. But among the options, updating the canary pod labels to match the Service selector is a common technique.

Full explanation →

279

MCQmedium

A pod with the following security context is in CrashLoopBackOff. The container image runs as user 1000. securityContext: runAsUser: 2000 runAsGroup: 3000 fsGroup: 4000 What is the most likely cause?

A.runAsUser is set to 2000, but the container expects to run as user 1000

B.runAsGroup is set to 3000, but the container expects group 1000

C.The pod does not have enough CPU resources

D.fsGroup is set to 4000, causing volume mount permission issues

AnswerA

This mismatch causes permission errors because the container's file permissions or processes require user 1000.

Why this answer

The container image is built to run as user 1000, but the Pod's securityContext overrides this with runAsUser: 2000. When the container starts, it attempts to access files or resources that require user 1000 permissions, causing it to fail and enter CrashLoopBackOff. The mismatch between the image's default user and the securityContext's runAsUser is the most direct cause of the crash.

Exam trap

CNCF often tests the nuance that runAsUser overrides the container image's default user, and candidates may incorrectly attribute the crash to group or volume issues without checking the actual user mismatch.

How to eliminate wrong answers

Option B is wrong because runAsGroup: 3000 does not conflict with the container expecting group 1000; the container image specifies a user (UID 1000), not a group, and group mismatches typically cause permission errors on files, not immediate crashes. Option C is wrong because insufficient CPU resources would manifest as a different error (e.g., OOMKilled or container pending), not a CrashLoopBackOff with a security context mismatch. Option D is wrong because fsGroup: 4000 affects volume mount permissions, but the question does not mention any volumes; without volumes, fsGroup has no effect, and even with volumes, it would cause permission errors on mounted files, not a crash on startup.

Full explanation →

280

Multi-Selecteasy

Which TWO of the following are valid service types in Kubernetes?

Select 2 answers

A.NodePort

B.Headless

C.Ingress

D.Gateway

E.ClusterIP

AnswersA, E

Valid service type.

Why this answer

ClusterIP and NodePort are standard service types. LoadBalancer and ExternalName are also valid, but the question asks for TWO; these are the most basic. Headless is not a type; it's a variation of ClusterIP.

Full explanation →

281

MCQeasy

To create a service that will be accessible from outside the cluster using a cloud provider's load balancer, what type should be used?

A.NodePort

B.ClusterIP

C.ExternalName

D.LoadBalancer

AnswerD

Correct. LoadBalancer provisions a cloud load balancer and assigns an external IP.

Why this answer

LoadBalancer provisions an external load balancer in cloud environments. NodePort also exposes externally but on a static port on each node, not via a cloud LB.

Full explanation →

282

MCQeasy

Which command shows resource usage (CPU/memory) of pods in the default namespace?

A.kubectl get pods -o wide

B.kubectl logs pod

C.kubectl top pod

D.kubectl describe pod

AnswerC

kubectl top pod displays CPU and memory usage for pods.

Why this answer

Option C is correct because `kubectl top pod` is the Kubernetes command that displays real-time CPU and memory usage metrics for pods, leveraging the metrics server to collect resource utilization data. This command is essential for monitoring pod performance and is part of the Application Observability and Maintenance domain.

Exam trap

The trap here is that candidates often confuse `kubectl get pods -o wide` or `kubectl describe pod` with resource monitoring commands, but neither provides live CPU/memory metrics, which only `kubectl top pod` (with the Metrics Server) can deliver.

How to eliminate wrong answers

Option A is wrong because `kubectl get pods -o wide` shows pod details like node IP and pod IP, but does not include CPU or memory usage metrics. Option B is wrong because `kubectl logs pod` retrieves container logs, not resource usage statistics. Option D is wrong because `kubectl describe pod` provides detailed configuration and status information, but does not display live CPU or memory consumption data.

Full explanation →

283

Multi-Selectmedium

Which TWO of the following are valid ways to expose application metrics for scraping by Prometheus in a Kubernetes environment?

Select 2 answers

A.Add annotations 'prometheus.io/scrape: "true"' to the pod template

B.Create an Ingress with the metrics path

C.Create a ServiceMonitor custom resource in the same namespace

D.Add annotations 'prometheus.io/scrape: "true"' to the Deployment

E.Store metrics in a ConfigMap and mount it to Prometheus

AnswersA, C

Prometheus auto-discovers pods with these annotations.

Why this answer

Option A is correct because Prometheus supports automatic service discovery in Kubernetes via pod annotations. Adding 'prometheus.io/scrape: "true"' to the pod template tells Prometheus to scrape metrics from that pod, provided Prometheus is configured to use the Kubernetes service discovery mechanism. This is a standard, widely adopted pattern for exposing application metrics.

Exam trap

CNCF often tests the distinction between pod-level annotations (which Prometheus discovers) versus higher-level resource annotations (like Deployment) that are ignored by Prometheus's service discovery.

Full explanation →

284

Multi-Selecthard

Which THREE of the following are valid fields in a PodSecurityContext that affect container security? (Select 3)

Select 3 answers

A.capabilities

B.runAsUser

C.runAsGroup

D.privileged

E.fsGroup

AnswersB, C, E

Valid field in PodSecurityContext.

Why this answer

Option B (runAsUser) is correct because it is a valid field in a PodSecurityContext that specifies the user ID (UID) under which all containers in the pod run. This field directly affects container security by controlling privilege levels and access to host resources, overriding the container's default user.

Exam trap

The trap here is that candidates often confuse PodSecurityContext fields (which affect all containers in the pod) with container-level SecurityContext fields (which affect only a single container), leading them to incorrectly select 'capabilities' or 'privileged' as pod-level options.

Full explanation →

285

MCQhard

A ClusterIP service named 'svc' has no endpoints. Which command can you use to debug why the service is not routing traffic?

A.kubectl get endpoints svc

B.kubectl describe service svc

C.kubectl logs svc

D.kubectl exec -it svc -- /bin/sh

AnswerA

Shows the endpoints of the service, which are missing.

Why this answer

Run 'kubectl get endpoints svc' to see if the service has any endpoints. If none, check that the pod selector matches the labels of the pods and that the pods are running.

Full explanation →

286

MCQhard

A pod 'app' has an init container that fails. The pod status is Init:Error. What is the first step to diagnose?

A.kubectl describe pod app

B.kubectl logs app -c <init-container-name>

C.kubectl exec -it app -- /bin/sh

D.kubectl logs app

AnswerB

Specifies the init container to get its logs.

Why this answer

Use 'kubectl logs app -c <init-container-name>' to see the logs of the specific init container that failed. The pod logs do not include init containers by default.

Full explanation →

287

MCQeasy

A pod needs to run as a non-root user. Which securityContext field should be set to enforce this?

A.runAsGroup: 3000

B.runAsUser: 1000

C.readOnlyRootFilesystem: true

D.runAsNonRoot: true

AnswerD

This enforces that the container cannot run as root.

Why this answer

Option D is correct because setting `runAsNonRoot: true` in the pod's securityContext explicitly enforces that the container must not run as the root user (UID 0). If the container image attempts to run as root, the Pod will fail to start, ensuring compliance with non-root security policies.

Exam trap

The trap here is that candidates often confuse `runAsUser: 1000` with enforcing non-root execution, but it only sets a user ID and does not prevent the container from running as root if the image's entrypoint ignores the UID setting.

How to eliminate wrong answers

Option A is wrong because `runAsGroup: 3000` only sets the primary group ID for the container's processes, not the user ID, so it does not prevent running as root. Option B is wrong because `runAsUser: 1000` sets a specific user ID (1000) but does not enforce that the container cannot run as root; if the image runs as root, this field is ignored unless the image respects the user ID override. Option C is wrong because `readOnlyRootFilesystem: true` makes the root filesystem read-only but does not restrict the user ID, so the container could still run as root.

Full explanation →

288

MCQhard

A Kubernetes Job with parallelism=3 and completions=6 is created. How many pods will run concurrently at most?

A.3

B.9

C.6

D.1

AnswerA

'parallelism' defines the maximum number of pods that can run concurrently. Here it is set to 3.

Why this answer

Option B is correct. The 'parallelism' field specifies the maximum number of pods that can run concurrently. 'completions' is the total number of successful pods needed for the Job to complete. So at most 3 pods will run concurrently.

Option A (6) is the total completions, not concurrency. Option C (1) is the default but not the configured value. Option D (9) is incorrect.

Full explanation →

289

MCQhard

A deployment 'api-deploy' has resource limits set but is frequently being OOMKilled. The team suspects the memory limit is too low. Which approach should be taken to confirm this without causing downtime?

A.Create a new pod with a higher memory limit and delete the old pods manually.

B.Set the memory limit to unlimited by removing the limit section and restart the pod.

C.Use 'kubectl set resources' to increase the limit on the running pod dynamically.

D.Increase the memory limit in the deployment spec and apply the change; the rollout will automatically restart pods.

AnswerD

Rolling update applies changes without downtime.

Why this answer

Option D is correct because updating the deployment spec triggers a rolling update, which replaces pods with new ones having the increased memory limit without downtime. This approach leverages Kubernetes' deployment controller to manage the rollout automatically, ensuring service continuity while adjusting resource limits.

Exam trap

The trap here is that candidates confuse 'kubectl set resources' with a dynamic in-place update, not realizing it modifies the deployment spec and requires a rollout to take effect, similar to editing the YAML directly.

How to eliminate wrong answers

Option A is wrong because manually creating and deleting pods bypasses the deployment's desired state management, risking configuration drift and potential downtime if not coordinated properly. Option B is wrong because removing the memory limit entirely can lead to resource starvation for other pods and violates Kubernetes best practices; it also requires restarting the pod, causing downtime. Option C is wrong because 'kubectl set resources' modifies the deployment spec, not the running pod directly; the pod must be recreated to apply the new limits, and the command triggers a rollout, not a dynamic in-place update.

Full explanation →

290

MCQmedium

You want to set environment variable 'DB_URL' in a pod from the key 'url' in ConfigMap 'db-config'. Which YAML snippet is correct?

A.envFrom: - configMapRef: name: db-config

B.env: - name: DB_URL valueFrom: configMapKeyRef: name: db-config key: url

C.env: - name: DB_URL valueFrom: secretKeyRef: name: db-config key: url

D.env: - name: DB_URL valueFrom: configMap: name: db-config key: url

AnswerB

Correct: configMapKeyRef references the ConfigMap key.

Why this answer

Option B is correct because it uses the `configMapKeyRef` field under `valueFrom` to inject a specific key ('url') from a ConfigMap ('db-config') into the environment variable 'DB_URL'. This is the precise syntax required to reference a single key from a ConfigMap in a pod's environment variable definition.

Exam trap

CNCF often tests the distinction between `envFrom` (inject all keys) and `env` with `configMapKeyRef` (inject a single key), and the trap here is that candidates confuse `configMapKeyRef` with the invalid `configMap` or mistakenly use `secretKeyRef` for ConfigMap data.

How to eliminate wrong answers

Option A is wrong because `envFrom` with `configMapRef` injects all key-value pairs from the ConfigMap as environment variables, not a single specific key into a named variable. Option C is wrong because `secretKeyRef` is used to reference keys from a Secret, not a ConfigMap; using it here would cause a runtime error or fail to resolve the value. Option D is wrong because `configMap` is not a valid field under `valueFrom`; the correct field is `configMapKeyRef`.

Full explanation →

291

MCQeasy

Which of the following is a valid Pod Security Admission standard?

A.Privileged, Default

B.Default

C.Restricted

D.Secure

AnswerC

Restricted is one of the three standards (privileged, baseline, restricted).

Why this answer

The Pod Security Admission (PSA) standard defines three levels: Privileged, Baseline, and Restricted. Option C is correct because 'Restricted' is one of the three valid standards, designed to enforce the most restrictive pod security policies.

Exam trap

The trap here is that candidates may confuse 'Default' with the 'Baseline' standard, or assume 'Secure' is a valid level, when in fact only Privileged, Baseline, and Restricted are defined in the Kubernetes documentation.

How to eliminate wrong answers

Option A is wrong because 'Default' is not a valid Pod Security Admission standard; the three standards are Privileged, Baseline, and Restricted. Option B is wrong because 'Default' alone is not a valid standard; the valid standards are Privileged, Baseline, and Restricted. Option D is wrong because 'Secure' is not a valid Pod Security Admission standard; the valid standards are Privileged, Baseline, and Restricted.

Full explanation →

292

Multi-Selectmedium

Which TWO statements about Kustomize are true?

Select 2 answers

A.Kustomize can be used to perform canary deployments.

B.Kustomize supports overlays that allow different configurations for different environments.

C.Kustomize requires Helm to manage dependencies.

D.Kustomize uses a file named kustomization.yaml to define resources and customizations.

E.Kustomize can only be used with kubectl apply -k.

AnswersB, D

Correct. Overlays modify base configurations for different contexts.

Why this answer

Kustomize supports overlays, which are layered patches applied on top of a base configuration. This allows you to define a common base set of Kubernetes resources and then use different overlay directories (e.g., dev, staging, prod) to customize settings like replicas, image tags, or namespaces for each environment without duplicating the entire manifest.

Exam trap

CNCF often tests the misconception that Kustomize is a deployment strategy tool (like for canaries) rather than a configuration customization tool, and that it is tightly coupled to kubectl or Helm, when in fact it is a standalone declarative customization engine.

Full explanation →

293

MCQeasy

Which kubectl command can be used to see the rollout status of a Deployment named 'web-app'?

A.kubectl rollout history deployment web-app

B.kubectl describe deployment web-app

C.kubectl status deployment web-app

D.kubectl rollout status deployment web-app

AnswerD

Correct command to view rollout status.

Why this answer

The correct command is 'kubectl rollout status deployment web-app'. This shows the status of the rollout.

Full explanation →

294

Multi-Selectmedium

Which TWO statements about kubectl apply vs kubectl create are correct? (Select two)

Select 2 answers

A.kubectl create can update existing resources if the --force flag is used

B.kubectl apply only works with Deployments

C.kubectl apply can update existing resources; kubectl create will error if resource exists

D.kubectl create can be used to update resources by providing the full YAML

E.kubectl apply maintains a last-applied-configuration annotation; kubectl create does not

AnswersC, E

Correct.

Why this answer

kubectl apply can be used to update resources (declarative), while kubectl create is imperative and will error if resource exists. Option A and E are correct.

Full explanation →

295

MCQeasy

An application requires Pods to communicate using hostNetwork: true. Which Kubernetes resource is still necessary for stable DNS names?

A.Headless Service

B.Endpoints resource

C.Regular Service (ClusterIP)

D.Ingress

AnswerC

Regular Service provides stable DNS and IP; works with hostNetwork.

Why this answer

When Pods use hostNetwork: true, they share the node's network namespace and bypass the Pod network, so kube-proxy does not set up iptables rules for ClusterIP Services. However, a regular ClusterIP Service still creates stable DNS records (via CoreDNS) that resolve to the Service's virtual IP, which can then be used for stable DNS names even though direct ClusterIP connectivity is lost. This ensures that other components can discover the Pods via DNS without relying on Pod IPs that may change.

Exam trap

The trap here is that candidates assume hostNetwork: true eliminates the need for any Service, but DNS resolution still depends on the Service object existing in the cluster, even if the ClusterIP is unreachable.

How to eliminate wrong answers

Option A is wrong because a Headless Service (ClusterIP = None) does not provide a stable ClusterIP or load-balanced DNS; it returns Pod IPs directly via DNS A/AAAA records, which are not stable when Pods restart or are rescheduled. Option B is wrong because an Endpoints resource is an internal data structure that tracks Pod IPs for a Service; it is not a standalone resource for stable DNS names and is automatically managed by the Service. Option D is wrong because an Ingress is an HTTP/HTTPS layer-7 routing resource that relies on a Service to function; it does not provide DNS names itself and is not necessary for stable DNS within the cluster.

Full explanation →

296

Drag & Dropmedium

Sequence the steps to troubleshoot a Pod stuck in CrashLoopBackOff state.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

Start by checking status, then inspect logs and events to diagnose. Fix the issue, then restart the Pod.

Full explanation →

297

MCQeasy

Which kubectl command creates a ConfigMap named 'app-config' from a file 'config.properties'?

A.kubectl create configmap app-config --from-file=config.properties

B.kubectl create configmap app-config --file config.properties

C.kubectl create configmap app-config --from-env-file config.properties

D.kubectl create configmap app-config --from-literal config.properties

AnswerA

This is the correct syntax to create a ConfigMap from a file.

Why this answer

Option A is correct because `kubectl create configmap` with the `--from-file` flag creates a ConfigMap from a file, using the filename as the key and the file content as the value. This is the standard Kubernetes method to import configuration data from a local file into a ConfigMap resource.

Exam trap

The trap here is confusing `--from-file` (which stores the entire file as a single entry) with `--from-env-file` (which parses key-value pairs), leading candidates to choose option C when they need to preserve the file's original format.

How to eliminate wrong answers

Option B is wrong because `--file` is not a valid flag for `kubectl create configmap`; the correct flag is `--from-file`. Option C is wrong because `--from-env-file` imports the file as environment variables (key=value pairs per line), not as a single key-value entry, which changes the data structure. Option D is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to reference a file.

Full explanation →

298

MCQeasy

You are a Kubernetes administrator responsible for a production cluster. A development team has deployed a Pod named 'app-pod' that runs a container with a PostgreSQL database. The team reports that the Pod is failing to start with an error: 'Error: container has runAsNonRoot and image will run as root (runtime error)'. The Pod YAML is as follows: ```yaml apiVersion: v1 kind: Pod metadata: name: app-pod spec: containers: - name: db image: postgres:latest securityContext: runAsNonRoot: true ``` The team wants to ensure the container runs securely without running as root. What is the BEST course of action?

A.Add `runAsUser: 999` to the container's securityContext to run the container as the postgres user.

B.Remove `runAsNonRoot: true` from the securityContext to allow the container to run as root.

C.Increase the Pod's resource limits because the error is due to insufficient memory.

D.Create a PodSecurityPolicy that allows running as root.

AnswerA

This explicitly sets the user to a non-root user, satisfying runAsNonRoot.

Why this answer

Option A is correct because the PostgreSQL official image runs as the 'postgres' user with UID 999 by default. Adding `runAsUser: 999` to the container's securityContext overrides the user to a non-root UID, satisfying the `runAsNonRoot: true` constraint and allowing the container to start without the runtime error.

Exam trap

The trap here is that candidates may think removing `runAsNonRoot` is the simplest fix, but the question explicitly requires the container to run securely without root, so the correct action is to specify a non-root user ID rather than disabling the security constraint.

How to eliminate wrong answers

Option B is wrong because removing `runAsNonRoot: true` would allow the container to run as root, which violates the security requirement to run securely without running as root. Option C is wrong because the error message explicitly states a security context violation (runAsNonRoot vs. root image), not a resource constraint; increasing resource limits would not resolve a security context error. Option D is wrong because a PodSecurityPolicy (PSP) is a cluster-level admission controller that can enforce policies, but it does not change the container's user ID; the immediate fix is to set a non-root user in the Pod spec, and PSPs are deprecated in Kubernetes 1.21+ and removed in 1.25.

Full explanation →

299

MCQeasy

Which command creates a ConfigMap named 'app-config' with two keys: 'key1=value1' and 'key2=value2'?

A.kubectl create configmap app-config --from-literal key1=value1 --from-literal key2=value2

B.kubectl create configmap app-config --from-literal=key1=value1,key2=value2

C.kubectl create configmap app-config --from-file key1=value1 --from-file key2=value2

D.kubectl create configmap app-config --from-env-file=key1=value1 --from-env-file=key2=value2

AnswerA

Correct: uses two --from-literal flags.

Why this answer

Option A is correct because `kubectl create configmap` with the `--from-literal` flag allows you to specify key-value pairs directly on the command line. Each `--from-literal` flag creates one entry in the ConfigMap, so using two separate flags correctly creates a ConfigMap named 'app-config' with keys 'key1' and 'key2' mapped to 'value1' and 'value2' respectively.

Exam trap

The trap here is that candidates confuse `--from-literal` with `--from-file` or `--from-env-file`, or incorrectly assume that `--from-literal` accepts comma-separated syntax, leading them to choose options that either attempt to read nonexistent files or create a single malformed key.

How to eliminate wrong answers

Option B is wrong because `--from-literal` does not accept comma-separated key-value pairs; it expects a single key=value argument per flag, and using a comma would create a single key named 'key1=value1,key2=value2' instead of two separate keys. Option C is wrong because `--from-file` is used to load data from files on disk, not to specify literal key-value pairs; using it with 'key1=value1' would attempt to read a file named 'key1=value1' which does not exist. Option D is wrong because `--from-env-file` is used to load multiple key-value pairs from a file formatted as environment variables (e.g., a .env file), not to specify individual literals on the command line.

Full explanation →

300

MCQmedium

A Kubernetes pod has two containers: a main application container and a sidecar container running a logging agent. The sidecar container is expected to start before the main container because it needs to initialize a shared log directory. What Kubernetes feature ensures this ordering?

A.Lifecycle hooks

B.Readiness probe on the sidecar

C.Init containers

D.Resource limits

AnswerC

Init containers run sequentially and complete before app containers start.

Why this answer

Init containers run to completion before app containers start, ensuring order.

Full explanation →

Page 4 of 14

All pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Practice CKAD by domain

Target a specific domain to shore up weak areas.

Application Design and Build Application Deployment Application Environment, Configuration and Security Application Observability and Maintenance Services and Networking

See all domains with question counts →