CKAD Practice Test 48 — 15 Questions

Question 1

Which Service type is used to expose a Service on a static port on each node in the cluster?

Accepted Answer

NodePort. NodePort is the correct Service type because it exposes the Service on a static port (in the range 30000-32767) on every node's IP address in the cluster. Traffic sent to any node's IP on that port is forwarded to the Service's ClusterIP and then to the selected Pods, enabling external access without a cloud load balancer.

Answer

ClusterIP

Answer

ExternalName

Answer

LoadBalancer

Question 2

A Deployment named 'app' has the following strategy: type: RollingUpdate with maxSurge=1 and maxUnavailable=0. You have 5 replicas. During a rolling update, how many pods will be running at any given time?

Accepted Answer

Between 5 and 6. With maxSurge=1 and maxUnavailable=0 on a 5-replica Deployment, Kubernetes must keep all 5 original pods available at all times while it may temporarily add 1 extra pod above the desired count. Therefore the total number of running pods ranges from 5 (when no surge pod exists yet) up to 6 (when one surge pod is created before an old one is terminated). The rollout proceeds by creating one new pod, waiting for it to become Ready, then terminating one old pod, keeping the count between 5 and 6.

Answer

Between 4 and 5

Answer

Between 5 and 10

Answer

Exactly 5

Question 3

Which THREE of the following are valid types of probes in Kubernetes? (Select 3)

Accepted Answer

Liveness probe. Liveness, Readiness, and Startup probes are all valid probe types in Kubernetes. Liveness probes check if a container is still running and can restart it if needed. Readiness probes determine if a container is ready to serve traffic. Startup probes delay liveness and readiness checks until the container has started successfully. Options B (Survival) and D (Health) are not valid Kubernetes probe types.

Answer

Survival probe

Answer

Health probe

Question 4

A pod with an init container and a main container has 'restartPolicy: Always'. The init container exits with code 0. What happens next?

Accepted Answer

The main container starts; if it fails, it will be restarted. When an init container exits with code 0, it indicates successful completion. With `restartPolicy: Always`, the pod's main container then starts. If the main container fails, Kubernetes restarts it according to the `restartPolicy`, which is `Always` in this case, so the main container will be restarted indefinitely.

Answer

The pod enters CrashLoopBackOff because the init container should not exit

Answer

The pod is considered complete and enters Succeeded phase

Answer

The init container restarts and runs again

Question 5

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?

Accepted Answer

Role and RoleBinding are namespace-scoped; they only grant permissions within their namespace. 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'.

Answer

The Role is missing the apiGroup field

Answer

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

Answer

The RoleBinding is not bound to the correct ServiceAccount

Question 6

You need to allow ingress traffic to pods in namespace 'api' only from pods in namespace 'frontend' that have label 'role: proxy'. Which NetworkPolicy ingress rule correctly implements this?

Accepted Answer

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        name: frontend
    podSelector:
      matchLabels:
        role: proxy. It combines a namespaceSelector (to match the 'frontend' namespace) with a podSelector (to match pods with label 'role: proxy') in the same ingress rule. This ensures that only traffic from pods in the 'frontend' namespace that also have the label 'role: proxy' is allowed, fulfilling the requirement precisely.

Answer

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        name: frontend

Answer

ingress:
- from:
  - ipBlock:
      cidr: 0.0.0.0/0
  - podSelector:
      matchLabels:
        role: proxy

Answer

ingress:
- from:
  - podSelector:
      matchLabels:
        role: proxy

Question 7

What is the purpose of the `IngressClass` resource in Kubernetes?

Accepted Answer

To specify which Ingress controller should implement the Ingress.. The `IngressClass` resource decouples the Ingress definition from the specific Ingress controller implementation. It allows you to specify which controller (e.g., NGINX, HAProxy, Traefik) should process the Ingress by referencing the `spec.controller` field, enabling multi-controller clusters and dynamic routing decisions.

Answer

To enable path-based routing.

Answer

To define the TLS certificate for an Ingress.

Answer

To set the default backend for an Ingress.

Question 8

A headless service is created with 'clusterIP: None'. What is the primary use case for such a service?

Accepted Answer

To allow direct pod-to-pod DNS resolution for StatefulSets.. A headless service (clusterIP: None) is primarily used with StatefulSets to enable direct pod-to-pod DNS resolution. Instead of a single virtual IP, the DNS returns the individual pod IPs (A/AAAA records) or SRV records, allowing each pod to be addressed by its stable network identity (e.g., pod-name.service-name.namespace.svc.cluster.local). This is essential for stateful applications like databases that require stable peer discovery.

Answer

To provide a stable IP address for the service.

Answer

To expose the service externally without a load balancer.

Answer

To enable DNS round-robin across all pods.

Question 9

A Deployment is configured with 'resources.requests.memory: 256Mi' and 'resources.limits.memory: 512Mi'. The node runs out of memory. Which pods will be the first to be evicted?

Accepted Answer

BestEffort pods first, then this Burstable pod, then Guaranteed pods last. C is correct because Kubernetes evicts pods based on their Quality of Service (QoS) class when a node runs out of memory. BestEffort pods (no requests/limits) are evicted first, followed by Burstable pods (requests < limits, as in this case), and Guaranteed pods (requests == limits) are evicted last. This ensures that pods with stricter resource guarantees are more protected during memory pressure.

Answer

The node will not evict pods if limits are set

Answer

This pod will be evicted first because it has a memory limit

Answer

All pods are evicted simultaneously

Question 10

Which Service type exposes a Service externally via each Node's IP on a static port?

Accepted Answer

NodePort. A NodePort Service exposes the Service on each Node's IP address at a static port (in the range 30000-32767 by default). This allows external traffic to reach the Service by sending requests to any Node's IP and the specified NodePort, which then forwards traffic to the corresponding ClusterIP Service and ultimately to the Pods.

Answer

ClusterIP

Answer

LoadBalancer

Answer

ExternalName

Question 11

Which TWO commands can be used to update the image of a Deployment? (Select two)

Accepted Answer

kubectl set image deployment/myapp app=nginx:1.21. Options A and D are correct because `kubectl set image` directly updates the container image, and `kubectl patch` modifies the Deployment manifest using a JSON patch. Option B is incorrect because `kubectl edit` only opens the manifest in an editor, requiring manual changes; it does not directly update the image. Option C is incorrect because `kubectl update` is not a valid command. Option E is incorrect because `kubectl replace` requires a full manifest file, not just an image flag.

Answer

kubectl edit deployment myapp

Answer

kubectl update deployment myapp --image=nginx:1.21

Answer

kubectl replace deployment myapp --image=nginx:1.21

Question 12

Which of the following is a valid YAML snippet for a container that sets the seccomp profile to 'RuntimeDefault' in a PodSecurityContext?

Accepted Answer

securityContext: seccompProfile: type: RuntimeDefault. In a PodSecurityContext, the seccomp profile is configured under the `seccompProfile` field with a `type` key set to `RuntimeDefault`. This tells the container runtime (e.g., containerd) to use the default seccomp profile provided by the runtime, which blocks a set of syscalls that are not typically needed by containers.

Answer

securityContext: seccompProfile: profile: RuntimeDefault

Answer

securityContext: seccomp: RuntimeDefault

Answer

securityContext: seccomp: type: RuntimeDefault

Question 13

A pod has 'automountServiceAccountToken: false' in its spec. What is the effect?

Accepted Answer

The service account token is not mounted into the pod. Setting `automountServiceAccountToken: false` in a Pod spec explicitly prevents the automatic mounting of the service account token into the Pod's containers. By default, Kubernetes mounts a token at `/var/run/secrets/kubernetes.io/serviceaccount/token` for API authentication; disabling it means the token is not present in the container filesystem, so the Pod cannot authenticate to the Kubernetes API using that default mechanism.

Answer

The pod uses the default service account token from the namespace

Answer

The service account token is mounted but not updated

Answer

The pod cannot communicate with the Kubernetes API

Question 14

You create a headless service with 'clusterIP: None' for a StatefulSet. How does a client discover the individual pod IPs?

Accepted Answer

DNS returns multiple A records for the service name, each pointing to a pod IP. A is correct because a headless service (clusterIP: None) does not provide a virtual IP or load balancing. Instead, DNS is configured to return multiple A records directly for the service name, each pointing to the IP address of a pod in the StatefulSet. This allows clients to discover and connect to individual pod IPs, which is essential for stateful applications where each pod has a unique identity.

Answer

The service returns the pod's hostname from the StatefulSet

Answer

An Ingress controller must be configured to expose each pod

Answer

The service provides a virtual IP that load balances among pods

Question 15

A developer wants to tag a local image 'myapp:latest' with the tag 'v1.0.0' for pushing to a registry. Which command does this?

Accepted Answer

docker tag myapp:latest myapp:v1.0.0. The `docker tag` command is used to tag an existing local image with a new tag. After tagging, the image can be pushed to a registry using `docker push`. There is no `kubectl tag` command; Kubectl does not manage local image tagging. `kubectl set image` is used to update the image of a deployment, not to tag a local image.

Answer

docker push myapp:v1.0.0

Answer

kubectl tag myapp:latest myapp:v1.0.0

Answer

kubectl set image myapp:v1.0.0