CKAD Services and Networking — 10 Questions

Question 1

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

Accepted Answer

Regular Service (ClusterIP). When Pods use hostNetwork: true, they share the node's network namespace, so their endpoint IP is the node IP. A regular ClusterIP Service still creates stable DNS records (via CoreDNS) that resolve to the Service's virtual IP. kube-proxy will still set up iptables rules to forward traffic from the ClusterIP to the endpoint (node IP), so ClusterIP connectivity is not lost. A Service object is still necessary for stable DNS names. Note: A headless Service also provides a stable DNS name, but it resolves to the individual pod/node IPs instead of a single virtual IP.

Answer

Headless Service

Answer

Endpoints resource

Answer

Ingress

Question 2

You have deployed a microservices application in a Kubernetes cluster. One of the services, 'payment-service', needs to be accessed by other services within the cluster via a stable DNS name. You create a Service of type ClusterIP named 'payment' with selector app=payment. However, when you try to curl http://payment from another Pod, the connection times out. You verify that the Pods backing 'payment-service' are running and ready, and the Endpoints object lists the correct Pod IPs. You also confirm that the Pods are listening on port 8080, and the Service defines targetPort: 8080. The cluster uses a standard CNI plugin (Calico) and DNS is provided by CoreDNS. What is the most likely cause of the timeout?

Accepted Answer

The Pods are listening on 127.0.0.1 only, not on 0.0.0.0. The most likely cause is that the Pods are listening only on 127.0.0.1 (localhost), so they only accept connections from within the same Pod. When the Service sends traffic to the Pod via its cluster IP, the connection arrives on the Pod's network interface (e.g., eth0), not on loopback. Since the application is not bound to 0.0.0.0, the kernel rejects the SYN with a TCP RST, and the client typically sees 'connection refused'. (A timeout could occur if a network policy is silently dropping packets, but the localhost bind is the most common and direct issue.)

Answer

The Service name 'payment' is not resolvable by DNS

Answer

The targetPort in the Service does not match the containerPort in the Pod spec

Answer

The Service type should be NodePort instead of ClusterIP

Question 3

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. 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 4

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'. 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 5

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 that maps port 80 to targetPort 8080 and uses the selector `app: web-app` to match the Pods. Option D is incorrect because it uses the selector `name: web-app`, which does not match the Pods labeled with `app: web-app`. Option B is incorrect because it adds `type: NodePort`, which is unnecessary for internal cluster access and may expose the service externally. Option C incorrectly swaps `port` and `targetPort`, sending traffic to the wrong container port.

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:
    name: web-app

Question 6

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. 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 7

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

Accepted Answer

replicas: Number of desired Pod replicas. A Deployment manifest uses replicas for pod count, selector for label matching, template for pod spec, and strategy for update behavior. Common confusions include misattributing replicas to ReplicaSet only or confusing selector with image specification.

Answer

replicas: Defines the number of Pods in a ReplicaSet

Answer

selector: Defines the container image to use

Question 8

Match each Kubernetes term to its description.

Accepted Answer

Init Container: Runs before main containers to perform setup tasks.. In Kubernetes, special container patterns serve distinct purposes: Init containers run to completion before the main app starts (setup), Sidecar containers run alongside to provide additional services, Ambassador containers proxy external traffic, and Adapter containers transform outputs. Common confusions involve mixing Init and Sidecar roles.

Answer

Init Container: Runs alongside main container to add functionality.

Answer

Sidecar Container: Runs before main containers to perform setup tasks.

Question 9

You have an Ingress resource that routes traffic to two services: 'app1' and 'app2'. The requirement is that traffic for 'app.example.com' goes to app1, and traffic for any other host goes to app2. Which Ingress specification correctly achieves this?

Accepted Answer

spec:
  defaultBackend:
    service:
      name: app2
      port:
        number: 80
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app1
            port:
              number: 80. A rule without a host acts as a catch-all for all hosts. The defaultBackend also handles requests that do not match any rule, including unmatched hosts. Therefore, both B (using defaultBackend for app2) and D (using a hostless rule for app2) correctly route traffic: app.example.com to app1 and all other hosts to app2.

Answer

spec:
  rules:
  - host: "*"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app2
            port:
              number: 80
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app1
            port:
              number: 80

Answer

spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app2
            port:
              number: 80
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app1
            port:
              number: 80

Question 10

A developer creates a Service named 'backend' in namespace 'default'. The service targets pods with label 'app: backend'. From within a pod in the same namespace, which DNS name resolves to the service's ClusterIP?

Accepted Answer

backend. Kubernetes DNS resolves a Service name to its ClusterIP when queried from within the same namespace. The DNS record for a Service is simply `<service-name>` in the same namespace, so 'backend' resolves directly to the ClusterIP of the backend Service.

Answer

backend.default.svc.cluster.local

Answer

backend.svc.cluster.local

Answer

backend.default.cluster.local