CKAD Services and Networking Practice Test 2 — 15 Questions

Question 1

A DevOps engineer notices that traffic to a Service named 'api' is not being forwarded to newly created pods. The Service selects pods with label 'app: api'. The pods are running and have the correct label. However, the Service's endpoints list does not include the new pods. What is the most likely cause?

Accepted Answer

The Service's targetPort does not match the container's port. Option B is correct because the Service's `targetPort` must match the `containerPort` defined in the pod's container spec. If they differ, the Service will not route traffic to the pod, and the pod will not appear in the Endpoints object, even if the label selector matches. Kubernetes validates the endpoint population by checking that the pod's readiness probe passes and that the target port is reachable on the pod's IP.

Answer

The pods are in a different namespace

Answer

The Service type is NodePort instead of ClusterIP

Answer

The pods have a different label than 'app: api'

Question 2

A user creates a Deployment with 3 replicas and a Service of type ClusterIP. The Service selects pods with label 'app: web'. The user wants external clients to access the application via a stable IP address. Which additional resource is required?

Accepted Answer

An Ingress resource. A ClusterIP Service is only reachable within the cluster. To expose a Deployment to external clients via a stable IP, an Ingress resource is required because it provides HTTP/HTTPS routing from outside the cluster to the Service, typically using a load balancer or a reverse proxy like NGINX. Ingress also offers a stable external IP (or hostname) and can manage TLS termination, making it the correct choice for external access with a stable endpoint.

Answer

A second Service of type NodePort

Answer

A NetworkPolicy

Answer

A ConfigMap

Question 3

During a security audit, it is discovered that a pod running a database is accessible from any other pod in the cluster. The database should only be accessible by pods with label 'role: backend'. Which resource should be applied to enforce this restriction?

Accepted Answer

A NetworkPolicy with an ingress rule selecting pods with label 'role: backend'. Option C is correct because a NetworkPolicy with an ingress rule that selects pods with label 'role: backend' explicitly restricts inbound traffic to the database pod to only those pods that match that label. NetworkPolicies are Kubernetes-native resources that enforce firewall rules at the IP address or port level (OSI layer 3 or 4) using the pod's labels as selectors, and they are the standard mechanism for controlling pod-to-pod traffic within a cluster.

Answer

An Ingress resource with TLS

Answer

A Service of type ClusterIP with a firewall rule

Answer

A PodSecurityPolicy

Question 4

A developer creates a headless Service named 'db' to discover all database pod IPs. The Service selects pods with label 'app: db'. The pods are assigned IPs 10.0.0.1, 10.0.0.2, and 10.0.0.3. When a client performs a DNS lookup for 'db', what will it receive?

Accepted Answer

All three pod IPs as separate A records. A headless Service (clusterIP: None) does not have a cluster IP. Instead, DNS queries for the Service name return A records for all pods matching the selector. Since the Service selects pods with label 'app: db', the DNS lookup for 'db' returns the three pod IPs (10.0.0.1, 10.0.0.2, 10.0.0.3) as separate A records, allowing direct pod-to-pod communication.

Answer

The IP of the first pod only

Answer

The cluster IP of the Service

Answer

A round-robin list of pod IPs

Question 5

Which TWO statements about Kubernetes Services are correct? (Choose two.)

Accepted Answer

A Service provides a stable endpoint for a set of pods.. Option B is correct because a Kubernetes Service provides a stable virtual IP and DNS name that remains constant even as the underlying pods are created, destroyed, or rescheduled. This decouples clients from the ephemeral nature of pod IPs, ensuring reliable connectivity to the pod group.

Answer

Services can only route traffic based on named ports.

Answer

Services can only route traffic to pods in the same namespace.

Answer

Every Service must have a cluster IP assigned.

Question 6

Which THREE components are required for a basic Ingress to route HTTP traffic to a Service? (Choose three.)

Accepted Answer

A Service of type ClusterIP or NodePort. A Service of type ClusterIP or NodePort is required because the Ingress resource routes external HTTP traffic to a Service, which then forwards it to the Pods. ClusterIP is the default and most common type for internal cluster routing, while NodePort can also be used but is less typical. Without a Service, the Ingress has no endpoint to direct traffic to.

Answer

A Deployment of the application

Answer

A NetworkPolicy allowing traffic from the Ingress controller

Question 7

Refer to the exhibit. A user has created the Service shown. The application pods listen on port 8080. Which port should an external client use to access the application from outside the cluster?

Accepted Answer

30007. Option C is correct because the Service is of type NodePort, which exposes the application on a static port (30007) on each node's IP address. External clients can access the application by hitting any cluster node's IP on port 30007, which forwards traffic to the Service's ClusterIP on port 80, then to the pods on port 8080.

Answer

8080

Answer

80

Answer

30000

Question 8

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?

Accepted Answer

The backend Pod does not have a readiness probe defined, so it is not considered ready and not added to DNS records.. 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.

Answer

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

Answer

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

Answer

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

Question 9

A developer deploys a web application as a Deployment named 'web-app' with 3 replicas. The application listens on port 8080 and should be accessible from within the cluster via the service name 'web-svc' on port 80. Which Service YAML correctly exposes the application?

Accepted Answer

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: web-app. Option A is correct because it defines a ClusterIP Service (default type) named 'web-svc' that maps port 80 (the service port) to targetPort 8080 (the container port), and uses the selector `app: web-app` to match the Pods created by the Deployment. This allows internal cluster traffic to reach the application on port 80 via the service name, while the application container listens on port 8080.

Answer

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: web-app

Answer

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  ports:
  - port: 8080
    targetPort: 80
  selector:
    app: web-app

Answer

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: web-app

Question 10

A DevOps engineer is setting up network policies in a Kubernetes cluster. The goal is to allow traffic from pods with label 'role=frontend' to pods with label 'role=backend' on TCP port 8080, and deny all other ingress to backend pods. Which two components are necessary to implement this? (Choose two.)

Accepted Answer

A NetworkPolicy with an ingress rule selecting pods with role=backend. Option A is correct because a NetworkPolicy with an ingress rule selecting pods with label 'role=backend' defines the target pods for the policy. This is the foundational component that scopes the policy to backend pods, allowing you to then specify which sources (frontend pods) and ports (TCP 8080) are permitted.

Answer

A Service of type LoadBalancer to expose backend pods

Answer

A pod anti-affinity rule to ensure frontend pods are not scheduled on the same nodes as backend pods

Answer

A CNI plugin that supports NetworkPolicy enforcement, such as Calico

Question 11

Order the steps to perform a rolling rollback of a Deployment to a previous revision.

Question 12

Arrange the steps to create a multi-container Pod with a shared volume.

Question 13

Match each YAML key in a Deployment manifest to its purpose.

Question 14

Match each Kubernetes term to its description.

Question 15

Which of the following Service types exposes a pod on a static port on each node's IP address?

Accepted Answer

NodePort. NodePort Service exposes the Service on each Node's IP at a static port (the NodePort). A NodePort Service is accessible from outside the cluster by requesting :.

Answer

LoadBalancer

Answer

ExternalName

Answer

ClusterIP