CKAD Services and Networking Practice Test 5 — 15 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The headless Service must have the 'publishNotReadyAddresses: true' field to include not-ready Pods.. A headless Service (clusterIP: None) creates DNS A/AAAA records only for Pods that are in the Ready state. If the backend Pod is running but not ready (e.g., due to a failing readiness probe or other conditions), the Service excludes it from DNS. Setting publishNotReadyAddresses: true on the Service would include all matching Pods regardless of readiness, allowing the frontend to discover the backend IPs. Since the frontend cannot resolve any IPs, the most likely cause is that the Service is not configured to serve not-ready Pods.

Answer

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

Answer

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

Answer

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

Question 2

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

Accepted Answer

View the deployment revision history, then choose the revision to rollback to, then perform the rollback using kubectl rollout undo, then wait for the rollout to complete, then verify the deployment status. View history, choose revision, undo to that revision, wait for completion, then verify.

Answer

Choose the revision to rollback to, then view the deployment revision history, then perform the rollback, then wait for the rollout to complete, then verify

Answer

View the history, choose the revision, perform the rollback, then verify, then wait for completion

Answer

Perform the rollback, then view the history, then choose the revision, then wait, then verify

Question 3

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

Accepted Answer

Define Pod YAML with container specs and emptyDir volume, mount volume in each container, apply with kubectl, then test.. Define Pod with containers, add shared emptyDir volume, mount in each container, apply, then test.

Answer

Define Pod YAML with container specs and volume mounts (but no volume definition), apply, then add emptyDir volume definition and re-apply.

Answer

Define Pod YAML with container specs and emptyDir volume, apply, then edit the running Pod to mount the volume in each container.

Answer

Define Pod YAML with container specs, mount volume in each container, then add emptyDir volume definition, then apply.

Question 4

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

Accepted Answer

NodePort. NodePort is the correct answer because it exposes a pod on a static port (in the range 30000-32767) on every node's IP address. When a Service of type NodePort is created, Kubernetes opens that port on all nodes in the cluster, forwarding traffic to the target pods. This allows external access to the pod via any node's IP and the assigned static port.

Answer

LoadBalancer

Answer

ExternalName

Answer

ClusterIP

Question 5

You have a Service named 'web' in namespace 'default'. Which DNS name resolves to the Service's ClusterIP?

Accepted Answer

web.default.svc.cluster.local. In Kubernetes, the DNS name for a Service follows the pattern `..svc.cluster.local`. For a Service named 'web' in the 'default' namespace, the correct FQDN is `web.default.svc.cluster.local`. This resolves to the Service's ClusterIP, allowing pods to reach the service via a stable DNS name.

Answer

web.default.cluster.local

Answer

web.svc.cluster.local

Answer

web.default.pod.cluster.local

Question 6

You need to create a NetworkPolicy that denies all ingress traffic to pods with label 'app: db' in namespace 'prod'. Which YAML snippet correctly implements this?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-db
  namespace: prod
spec:
  podSelector:
    matchLabels:
      app: db
  policyTypes:
  - Ingress
  ingress: []. It defines a NetworkPolicy that selects pods with label 'app: db' in namespace 'prod', specifies 'policyTypes: [Ingress]', and sets 'ingress: []'. An empty ingress rule list means no ingress traffic is allowed, effectively denying all ingress to the selected pods. This is the standard Kubernetes pattern for creating a deny-all ingress policy for a specific set of pods.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-db
  namespace: prod
spec:
  podSelector:
    matchLabels:
      app: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: prod
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from: []

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []

Question 7

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?

Accepted Answer

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  clusterIP: None
  selector:
    app: mysql
  ports:
  - port: 3306. Setting `clusterIP: None` creates a headless Service, which is required for StatefulSets to provide stable network identities and unique DNS entries for each pod. A headless Service does not load-balance traffic; instead, it returns the pod IPs directly, enabling DNS resolution to individual pod hostnames like `mysql-0.mysql.default.svc.cluster.local`.

Answer

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

Answer

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

Answer

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

Question 8

Which command creates a Service named 'my-svc' that exposes a deployment named 'my-deploy' on port 80?

Accepted Answer

kubectl expose deployment my-deploy --name=my-svc --port=80. The `kubectl expose` command is specifically designed to create a Service from an existing resource like a Deployment. By specifying `deployment my-deploy`, `--name=my-svc`, and `--port=80`, it generates a ClusterIP Service that routes traffic to the pods selected by the deployment's labels on port 80.

Answer

kubectl create service my-svc --port=80 --target-port=80

Answer

kubectl run my-svc --expose --port=80 --image=my-image

Answer

kubectl create svc clusterip my-svc --tcp=80:80

Question 9

A pod is unable to resolve the DNS name of a Service in the same namespace. The pod's /etc/resolv.conf shows 'nameserver 10.96.0.10'. What is the most likely cause?

Accepted Answer

The kube-dns Service is not running. The pod's /etc/resolv.conf shows nameserver 10.96.0.10, which is the default ClusterIP of the kube-dns Service. If the kube-dns Service is not running, the DNS resolver will fail to respond to queries, causing the pod to be unable to resolve the DNS name of any Service, including one in the same namespace. This is the most direct cause because the pod relies entirely on that nameserver for DNS resolution.

Answer

The pod is using dnsPolicy: Default

Answer

The Service is of type ExternalName

Answer

The pod's /etc/hosts file is misconfigured

Question 10

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

Accepted Answer

A Service of type LoadBalancer automatically creates a NodePort Service.. When a Service of type LoadBalancer is created, Kubernetes automatically creates a corresponding NodePort Service (and a ClusterIP Service) as part of its implementation. The cloud load balancer routes external traffic to the NodePort on each node, which then forwards to the ClusterIP. This is defined in the Kubernetes Service specification and is a core behavior of the LoadBalancer type.

Answer

A Service of type ClusterIP is accessible from outside the cluster.

Answer

A Service of type ExternalName requires a selector to route traffic.

Answer

A headless Service has clusterIP set to "0.0.0.0".

Question 11

You want to restrict ingress traffic to pods with label 'app: web' in namespace 'frontend' to only come from pods in namespace 'backend'. Which NetworkPolicy YAML is correct?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: backend. It defines a NetworkPolicy in the 'frontend' namespace that selects pods with label 'app: web' and allows ingress traffic only from pods in the 'backend' namespace. The key is the `namespaceSelector` with `kubernetes.io/metadata.name: backend`, which matches the namespace named 'backend' (this label is automatically added by Kubernetes to every namespace). The `policyTypes: [Ingress]` explicitly enables ingress rules, and the `from` rule restricts traffic to only those originating from the 'backend' namespace.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

Question 12

You need to debug a Service that is not routing traffic to its endpoints. Which command shows the current endpoints of a Service?

Accepted Answer

kubectl get endpoints my-service. `kubectl get endpoints my-service` directly retrieves the Endpoints object associated with the Service, which lists the IP addresses and ports of the Pods that are currently receiving traffic. This is the most precise way to verify whether the Service has any active endpoints, as the Endpoints object is updated by the kube-controller-manager based on Pod readiness and label selectors.

Answer

kubectl describe service my-service

Answer

kubectl get svc my-service -o wide

Answer

kubectl get pods -l app=my-app

Question 13

An Ingress resource has the following spec. What is the effect?

spec:
  tls:
  - hosts:
    - myapp.example.com
    secretName: myapp-tls
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp
            port:
              number: 80

Accepted Answer

Ingress terminates TLS using the secret and routes to the service.. The Ingress spec defines TLS termination at the ingress controller using the secret `myapp-tls` for the host `myapp.example.com`. The `tls` block configures the ingress to decrypt HTTPS traffic using the certificate and key stored in that secret, and then forward the decrypted HTTP traffic to the backend service `myapp` on port 80. This is the standard behavior for securing traffic with TLS in Kubernetes Ingress.

Answer

Ingress uses the secret for client authentication.

Answer

Ingress redirects HTTP to HTTPS automatically.

Answer

Ingress passes the TLS connection through to the service.

Question 14

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

Accepted Answer

kubectl port-forward pod/web-pod 8080:80. `kubectl port-forward` creates a direct tunnel from a local port to a port on a specific pod. The syntax `kubectl port-forward pod/web-pod 8080:80` forwards local port 8080 to port 80 on the pod named 'web-pod', enabling local access to the pod's service without requiring a Service object.

Answer

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

Answer

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

Answer

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

Question 15

Which THREE statements about Ingress are correct? (Choose three.)

Accepted Answer

Ingress can terminate TLS connections.. Ingress can terminate TLS connections by referencing a Secret that contains the TLS certificate and private key. When a TLS section is defined in the Ingress spec, the Ingress controller terminates the HTTPS connection at the edge and forwards plain HTTP traffic to the backend services. This is a core feature for securing ingress traffic in Kubernetes.

Answer

Ingress can route traffic based on source IP.

Answer

Ingress can route traffic based on destination port.