CKAD Services and Networking — 40 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

Question 11

A NetworkPolicy allows ingress traffic from pods with label 'role: frontend' in the same namespace. Which podSelector is correct?

Accepted Answer

ingress:
  - from:
    - podSelector:
        matchExpressions:
          - key: role
            operator: In
            values:
            - frontend. In Kubernetes NetworkPolicy, podSelector is a LabelSelector which supports both matchLabels and matchExpressions. Option A uses matchExpressions with operator In and values [frontend], which is equivalent to matchLabels role=frontend. Therefore A is also correct. The question must be revised to only accept matchLabels or to allow multiple correct options.

Answer

ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          role: frontend

Answer

ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0

Question 12

A developer wants to test a service locally using kubectl. Which command forwards local port 8080 to the service's port 80?

Accepted Answer

kubectl port-forward service/myservice 8080:80. `kubectl port-forward` requires the resource type (e.g., `service/`) to be specified when targeting a Service. The syntax `kubectl port-forward service/myservice 8080:80` forwards local port 8080 to the Service's port 80, allowing local traffic to reach the Service's cluster IP.

Answer

kubectl port-forward pod/myservice 8080:80

Answer

kubectl port-forward myservice 8080:80

Answer

kubectl port-forward service/myservice 80:8080

Question 13

Which TWO are valid ways to create a Service in Kubernetes?

Accepted Answer

Using kubectl apply -f service.yaml. Option A is correct because `kubectl apply -f service.yaml` is the standard declarative method for creating a Service from a manifest file whose `kind` is `Service`, letting the API server create or update the resource. Option E is correct because `kubectl expose deployment mydeploy --port=80` imperatively creates a Service that targets the pods of the existing `mydeploy` Deployment, using the Deployment's selector and exposing the specified port. Option B is not a valid Service creation command because `kubectl create service clusterip` requires a `--tcp` value in the form `:` but the syntax shown (`--tcp=80:80`) is actually accepted only when the service name and port mapping are valid; however, the canonical valid form is `kubectl create service clusterip myservice --tcp=80:80`, so this option is technically valid but is not marked correct here. Option C is invalid because `kubectl create deployment` does not support an `--expose` flag; you would need `kubectl expose` afterward. Option D is invalid because `kubectl run` no longer supports `--expose` in current Kubernetes versions; it was removed, and `kubectl expose` should be used instead.

Answer

Using kubectl create service clusterip myservice --tcp=80:80

Answer

Using kubectl create deployment mydeploy --image=nginx --expose

Answer

Using kubectl run mypod --image=nginx --expose

Question 14

Which kubectl command creates a Service of type ClusterIP named 'my-service' that exposes port 80 on a set of pods selected by label 'app: web'?

Accepted Answer

kubectl expose deployment my-deployment --port=80 --target-port=80 --type=ClusterIP --name=my-service. `kubectl expose deployment my-deployment --port=80 --target-port=80 --type=ClusterIP --name=my-service` creates a ClusterIP Service that maps port 80 on the Service to port 80 on pods selected by the deployment's label selector. If the deployment has selector `app: web`, this satisfies the requirement. Option C is wrong because `kubectl create service clusterip` automatically generates a selector of `app=my-service` (based on the Service name), not `app=web`. Therefore, it would not select the desired pods.

Answer

kubectl run my-service --image=nginx --port=80 --expose

Answer

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

Answer

kubectl expose pod my-pod --port=80 --target-port=80 --type=NodePort --name=my-service

Question 15

You create a Service named 'backend' in namespace 'prod'. A pod in namespace 'dev' tries to reach the service using the DNS name 'backend.prod.svc.cluster.local'. The pod cannot resolve the name. What is the most likely cause?

Accepted Answer

The cluster DNS service is not running. The pod in the 'dev' namespace is correctly using the full DNS name 'backend.prod.svc.cluster.local' to reach the service in the 'prod' namespace. This is the proper way to resolve a service across namespaces. If the pod cannot resolve this name, the most likely cause is that the cluster DNS service (CoreDNS) is not running or is unhealthy, leading to DNS resolution failures.

Answer

CoreDNS is configured to reject cross-namespace queries

Answer

The 'prod' namespace does not exist

Answer

The pod is using the short name 'backend' without the namespace suffix

Question 16

You are tasked with creating a NetworkPolicy that denies all ingress traffic to pods in the 'db' namespace by default. Which YAML snippet correctly implements this?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: db
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []. Options A and B are both correct because they define a NetworkPolicy that selects all pods in the namespace with `podSelector: {}`, specify `policyTypes: [Ingress]`, and have either an empty `ingress` array (A) or omit the `ingress` field entirely (B). In Kubernetes, both patterns result in a default-deny ingress policy, blocking all inbound traffic to the selected pods. Option C allows all ingress traffic with an empty rule `{}`, and option D only denies egress.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: db
spec:
  podSelector: {}
  ingress:
  - {}

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: db
spec:
  podSelector: {}
  policyTypes:
  - Egress

Question 17

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?

Accepted Answer

The pod is in a different namespace and the namespace flag is missing. kubectl port-forward creates a local listener on the specified local port. If the pod is in a different namespace and --namespace is not provided, kubectl fails to find the pod, prints an error, and does not create the local listener. As a result, connecting to localhost:8080 is refused. A local port conflict would instead cause kubectl to fail with 'address already in use', but another process would already be listening on that port, so connection refused would not occur.

Answer

The container is listening on port 8080 instead of 80

Answer

Local port 8080 is already in use by another process

Answer

The service must exist for port-forwarding to work

Question 18

You have a NetworkPolicy that allows ingress from pods with label 'app: frontend' in any namespace, and also allows ingress from the IP range '10.0.0.0/8'. The policy is not working as expected. Which YAML snippet correctly implements both requirements?

Accepted Answer

ingress:
- from:
  - namespaceSelector: {}
    podSelector:
      matchLabels:
        app: frontend
- from:
  - ipBlock:
      cidr: 10.0.0.0/8. It uses two separate `from` entries in the ingress rule. The first `from` combines a `namespaceSelector: {}` (selects all namespaces) with a `podSelector` for `app: frontend`, meaning pods with that label in any namespace are allowed. The second `from` uses an `ipBlock` to allow traffic from the 10.0.0.0/8 CIDR range. In Kubernetes NetworkPolicy, multiple `from` entries are ORed together, so traffic matching either rule is permitted.

Answer

ingress:
- from:
  - namespaceSelector: {}
  - podSelector:
      matchLabels:
        app: frontend
  - ipBlock:
      cidr: 10.0.0.0/8

Answer

ingress:
- from:
  - podSelector:
      matchLabels:
        app: frontend
  - ipBlock:
      cidr: 10.0.0.0/8

Answer

ingress:
- from:
  - namespaceSelector: {}
    podSelector:
      matchLabels:
        app: frontend
  - ipBlock:
      cidr: 10.0.0.0/8

Question 19

Which command creates a Service named 'web' of type ClusterIP that selects pods with label 'tier: frontend' and exposes port 80?

Accepted Answer

kubectl expose deployment frontend --port=80 --target-port=80 --type=ClusterIP --name=web. kubectl expose deployment frontend --port=80 --target-port=80 --type=ClusterIP --name=web creates a ClusterIP Service named 'web' with port 80. The Service's selector is automatically set to match the deployment's pod selector. Therefore, to satisfy the requirement that the Service selects pods with label tier=frontend, the deployment 'frontend' must have a matching selector. Since the stem does not provide this context, the answer is conditionally correct. In a CKAD exam, this is often implied, but strictly speaking, the command does not guarantee the required selector.

Answer

kubectl create service clusterip web --tcp=80

Answer

kubectl expose deployment web --port=80 --type=NodePort

Answer

kubectl run web --image=nginx --port=80 --expose

Question 20

Which TWO of the following are valid rules for a NetworkPolicy that allows egress traffic from pods with label 'app: worker' to the external IP range '192.168.0.0/16' on port 53 UDP? (Select 2)

Accepted Answer

egress:
- ports:
  - port: 53
    protocol: UDP
  to:
  - ipBlock:
      cidr: 192.168.0.0/16. Option A is correct because it defines an egress rule with the destination specified via ipBlock cidr 192.168.0.0/16 and the allowed port 53/UDP, which is exactly the required traffic pattern; the ordering of 'ports' and 'to' keys within a NetworkPolicy egress rule is irrelevant in YAML. Option C is correct because it contains the same valid egress rule structure — a 'to' peer using ipBlock cidr 192.168.0.0/16 and a 'ports' entry with port 53 and protocol UDP — matching the scenario's requirement to allow egress to that external IP range on UDP port 53. Option B is not correct because it adds a second 'to' peer with podSelector: {} that would allow egress to all pods, which is not part of the requested rule. Option D is not correct because it lacks the 'to' peer entirely, so it would allow egress on port 53/UDP to any destination rather than restricting it to 192.168.0.0/16. Option E is not correct because it uses 'from' instead of 'to', which is invalid for an egress rule and would not select the intended destination.

Answer

egress:
- to:
  - ipBlock:
      cidr: 192.168.0.0/16
  ports:
  - port: 53
    protocol: UDP
- to:
  - podSelector: {}

Answer

egress:
- to:
  - ipBlock:
      cidr: 192.168.0.0/16
  ports:
  - port: 53
    protocol: UDP

Answer

egress:
- from:
  - ipBlock:
      cidr: 192.168.0.0/16
  ports:
  - port: 53
    protocol: UDP