CKAD Services and Networking Practice Test 9 — 15 Questions

Question 1

You have a Deployment with 3 replicas. You create a Service with 'clusterIP: None'. What is the effect on pod DNS?

Accepted Answer

DNS returns the IPs of all matching pods.. When a Service is created with `clusterIP: None`, it becomes a headless Service. For a headless Service, DNS is configured to return the IP addresses of all matching pods (the endpoints) rather than a single virtual IP. This allows client applications to discover and connect to individual pods directly, which is essential for stateful workloads like databases.

Answer

Each pod gets its own DNS record in the form ...svc.cluster.local

Answer

The Service name does not resolve to any IP; DNS fails.

Answer

The Service name resolves to a single virtual IP that load balances across pods.

Question 2

Which TWO statements about Ingress are correct? (Select 2)

Accepted Answer

Ingress can terminate TLS.. Ingress can terminate TLS by using a Secret that contains the TLS certificate and private key. When configured in the Ingress spec under `tls` and `secretName`, the Ingress controller decrypts HTTPS traffic before forwarding it to the backend Service, offloading TLS termination from the application pods.

Answer

Ingress provides a ClusterIP for internal access.

Answer

Ingress can load balance TCP traffic.

Answer

Ingress automatically assigns an external IP to the Service.

Question 3

Which THREE statements about NetworkPolicy are correct? (Select 3)

Accepted Answer

NetworkPolicy follows an allow-list model; if no policy matches, traffic is denied.. NetworkPolicy follows an allow-list model: by default, all traffic to and from pods is allowed. Once a NetworkPolicy selects a pod, that pod becomes isolated, and only traffic explicitly allowed by the policy's rules is permitted for the specified direction (ingress/egress). Any traffic not matching an allow rule is denied for that direction. Option A is correct because once a policy applies, the default behavior becomes deny for unmatched traffic. Option C is correct because namespaceSelector can select a namespace, allowing traffic from all pods in that namespace. Option E is correct because NetworkPolicy can restrict egress traffic via egress rules. Option B is incorrect because ipBlock can be used to allow or block IP ranges, but blocking specific external IPs is possible only if the CNI supports it (and it's not universally supported). Option D is incorrect because NetworkPolicy is namespaced, not cluster-scoped.

Answer

NetworkPolicy can block traffic to specific external IP addresses using ipBlock.

Answer

NetworkPolicy is a cluster-scoped resource.

Question 4

You have a Deployment named 'web-app' with 3 replicas. You want to expose the pods on port 80 internally within the cluster using a ClusterIP service. Which kubectl command should you use?

Accepted Answer

kubectl expose deployment web-app --port=80 --target-port=8080. `kubectl expose deployment web-app --port=80 --target-port=8080` creates a ClusterIP Service that maps port 80 on the Service to port 8080 on the Pods, allowing internal cluster traffic to reach the application. The `--port` flag defines the Service's listening port, while `--target-port` specifies the container port the traffic is forwarded to, which is essential when the container listens on a different port than the Service exposes.

Answer

kubectl create service clusterip web-app --tcp=80:8080

Answer

kubectl create service nodeport web-app --tcp=80:8080

Answer

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

Question 5

You have a headless Service for a StatefulSet. The DNS query for the service returns no A records. What is the most likely cause?

Accepted Answer

The Service selector does not match any pod labels. A headless Service (clusterIP: None) relies on DNS A records to return the IP addresses of the Pods selected by its selector. If the selector does not match any Pod labels, the Service has no endpoints, and the DNS lookup returns no A records. This is the most common cause for a headless Service returning empty DNS results.

Answer

The Service has clusterIP set to an IP address

Answer

The Service is of type ExternalName

Answer

The StatefulSet is using a volumeClaimTemplate

Question 6

You apply the following NetworkPolicy:

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

After applying, pods in the namespace cannot reach the kube-dns service. What is the most likely reason?

Accepted Answer

The policy blocks all egress traffic, including DNS. The NetworkPolicy explicitly includes `Egress` in `policyTypes` and uses an empty `podSelector: {}`, which selects all pods in the namespace. With no `egress` rules defined, the default behavior is to deny all egress traffic. DNS resolution for kube-dns typically uses UDP/TCP on port 53, and since all egress traffic is blocked, pods cannot reach the kube-dns service, causing DNS failures.

Answer

The policy does not have a namespaceSelector

Answer

The policy blocks all ingress traffic only

Answer

The kube-dns service is not running

Question 7

You have an Ingress resource with TLS configured. The certificate is stored in a Secret named 'my-tls'. Which field in the Ingress YAML specifies the Secret name?

Accepted Answer

.spec.tls[0].secretName. In Kubernetes Ingress resources, the TLS configuration is defined under `.spec.tls`, which is an array of TLS objects. Each object contains a `hosts` field and a `secretName` field that references the Kubernetes Secret holding the TLS certificate and private key. Option A correctly identifies `.spec.tls[0].secretName` as the field that specifies the Secret name.

Answer

.spec.tls[0].secret

Answer

.metadata.annotations['cert-manager.io/cluster-issuer']

Answer

.spec.tlsSecretName

Question 8

You need to forward a local port to port 8080 on a pod named 'my-pod' in the 'default' namespace. Which kubectl command should you use?

Accepted Answer

kubectl port-forward pod/my-pod 8080:8080. The `kubectl port-forward` command requires the resource type (pod/) and the correct port mapping syntax. The question specifies forwarding a local port to port 8080 on the pod, so the local port is 8080 and the pod port is 8080, making `8080:8080` the correct mapping. The full command `kubectl port-forward pod/my-pod 8080:8080` establishes a tunnel from localhost:8080 to the pod's port 8080.

Answer

kubectl port-forward pod/my-pod 8080:80

Answer

kubectl forward pod/my-pod 8080:8080

Answer

kubectl port-forward my-pod 8080

Question 9

You have a Service named 'my-svc' in the 'prod' namespace. What is the fully qualified DNS name for this Service?

Accepted Answer

my-svc.prod.svc.cluster.local. The fully qualified DNS name for a Service in Kubernetes follows the pattern `..svc.cluster.local`. For 'my-svc' in the 'prod' namespace, this resolves to 'my-svc.prod.svc.cluster.local'. This is the standard DNS naming convention used by CoreDNS (or kube-dns) for Service discovery within a cluster.

Answer

my-svc.svc.cluster.local

Answer

prod.my-svc.svc.cluster.local

Answer

my-svc.prod.cluster.local

Question 10

You want to block all ingress traffic to pods labeled 'app=api' except from pods labeled 'app=frontend'. Which NetworkPolicy rule is correct?

Accepted Answer

ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend. A NetworkPolicy with an ingress rule using a podSelector with matchLabels: app: frontend allows traffic only from pods that have that label. By default, when no NetworkPolicy selects the pods, all ingress traffic is allowed; once a policy selects them, only explicitly allowed traffic is permitted. This rule therefore blocks all ingress except from pods labeled app=frontend.

Answer

ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          app: frontend

Answer

ingress:
  - ports:
    - port: 80

Answer

ingress:
  - from:
    - ipBlock:
        cidr: 10.0.0.0/8

Question 11

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 12

You want to expose a Deployment named 'nginx' on port 80 using a LoadBalancer service. Which YAML snippet is correct?

Accepted Answer

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx. Option C is correct because it defines a Service of type LoadBalancer, exposing the 'nginx' Deployment on port 80. The apiVersion v1 is appropriate for a Service, and the selector matches the Deployment's labels. Option B includes an unnecessary explicit targetPort: 80, making it less preferred for the CKAD exam, which expects the most concise correct YAML. Option A uses NodePort instead of LoadBalancer, and Option D uses an incorrect apiVersion.

Answer

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

Answer

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  targetPort: 80
  selector:
    app: nginx

Answer

apiVersion: apps/v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Question 13

You have an Ingress that should route requests to 'api.example.com' to a service named 'api-svc' on port 80, and requests to 'www.example.com' to 'web-svc' on port 80. Which host-based routing rule is correct?

Accepted Answer

spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - backend:
          service:
            name: api-svc
            port:
              number: 80
  - host: www.example.com
    http:
      paths:
      - backend:
          service:
            name: web-svc
            port:
              number: 80. It follows the Kubernetes Ingress v1 API specification: each rule in `spec.rules` is an object with a `host` field and an `http` field, and within `http`, a `paths` array containing backend references. This structure correctly routes requests for `api.example.com` to `api-svc:80` and `www.example.com` to `web-svc:80`.

Answer

spec:
  rules:
  - http:
      paths:
      - host: api.example.com
        backend:
          service:
            name: api-svc
            port:
              number: 80
      - host: www.example.com
        backend:
          service:
            name: web-svc
            port:
              number: 80

Answer

spec:
  rules:
  - host: api.example.com
    - backend:
        service:
          name: api-svc
          port:
            number: 80
  - host: www.example.com
    - backend:
        service:
          name: web-svc
          port:
            number: 80

Answer

spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - backend:
          serviceName: api-svc
          servicePort: 80
  - host: www.example.com
    http:
      paths:
      - backend:
          serviceName: web-svc
          servicePort: 80

Question 14

You have a Service named 'myservice' in namespace 'default'. A pod in the same cluster but different namespace 'other' wants to resolve the service's IP. What DNS name should it use?

Accepted Answer

myservice.default.svc.cluster.local. Kubernetes DNS resolves services using the format `..svc.cluster.local`. Since the service 'myservice' is in the 'default' namespace, a pod in the 'other' namespace must include the namespace in the DNS name to reach it. This fully qualified domain name (FQDN) ensures the DNS query resolves to the service's cluster IP, regardless of the pod's namespace.

Answer

default.myservice.svc.cluster.local

Answer

myservice.svc.cluster.local

Answer

myservice.other.svc.cluster.local

Question 15

Which of the following are valid Service types in Kubernetes? (Select all that apply)

Accepted Answer

ExternalName. ExternalName, ClusterIP, and NodePort are all valid Service types in Kubernetes. Headless (clusterIP=None) is not a distinct type, and Ingress is a separate resource for HTTP routing.

Answer

Headless

Answer

Ingress