CKAD Services and Networking Practice Test 13 — 15 Questions

Question 1

To create a service that will be accessible from outside the cluster using a cloud provider's load balancer, what type should be used?

Accepted Answer

LoadBalancer. The LoadBalancer service type (D) provisions an external load balancer from the cloud provider (e.g., AWS ELB, GCP TCP/UDP Load Balancer) and assigns a public IP or DNS name, making the service accessible from outside the cluster. This is the correct choice when the requirement explicitly states using a cloud provider's load balancer for external access.

Answer

NodePort

Answer

ClusterIP

Answer

ExternalName

Question 2

A developer creates a headless Service with 'clusterIP: None' for a StatefulSet. What is the primary purpose of using a headless Service?

Accepted Answer

To provide stable network identities and DNS records for each pod in the StatefulSet. A headless Service (with `clusterIP: None`) is used with StatefulSets to provide stable, unique network identities (DNS records) for each pod. Instead of a single virtual IP and round-robin load balancing, the headless Service returns A/AAAA records for each pod's individual IP address, enabling direct pod-to-pod communication based on stable hostnames like `pod-name.service-name.namespace.svc.cluster.local`.

Answer

To prevent DNS resolution of the service

Answer

To enable TLS termination at the service level

Answer

To provide load balancing across the pods

Question 3

You apply the following Ingress manifest:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

The Ingress controller logs show a 404 error when accessing 'http://example.com/api'. The service 'api-service' exists and is reachable via ClusterIP. What is the most likely cause?

Accepted Answer

The IngressClass 'nginx' is not installed or configured. The Ingress controller logs a 404 error because the Ingress resource references `ingressClassName: nginx`, but the NGINX Ingress Controller is not installed or its IngressClass resource is not configured in the cluster. Without a matching IngressClass, the controller ignores this Ingress, so no routing rules are applied, and the default backend (if any) or the controller itself returns a 404. The service exists and is reachable, but the Ingress controller never processes the rules.

Answer

The service 'api-service' is in a different namespace

Answer

The service port (80) does not match the container port

Answer

The path '/api' should be pathType: Exact

Question 4

Which Service type is used to expose a service externally on a static port on each worker node?

Accepted Answer

NodePort. A NodePort service exposes the application on a static port (in the range 30000-32767) on every worker node's IP address. This allows external traffic to reach the service by targeting any node's IP and the assigned NodePort, making it the correct choice for exposing a service externally on a static port per node.

Answer

ExternalName

Answer

ClusterIP

Answer

LoadBalancer

Question 5

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 6

You have an Ingress with TLS configured. The Ingress controller returns a certificate error when accessing via HTTPS. The secret 'my-tls' exists in the same namespace. Which of the following is the most likely cause?

Accepted Answer

The secret name in the TLS section of the Ingress does not match the actual secret name. The most likely cause is that the secret name specified in the TLS section of the Ingress resource does not match the actual name of the Secret object. When TLS is configured, the Ingress controller reads the `secretName` field to fetch the certificate and key; a mismatch causes the controller to fail to load the TLS material, resulting in a certificate error. Since the secret exists in the same namespace, the only plausible issue is a naming mismatch.

Answer

The Ingress controller does not support TLS

Answer

The secret is in a different namespace than the Ingress

Answer

The certificate is not signed by a trusted CA

Question 7

You need to allow ingress traffic to pods in namespace 'api' only from pods in namespace 'frontend' that have label 'role: proxy'. Which NetworkPolicy ingress rule correctly implements this?

Accepted Answer

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        name: frontend
    podSelector:
      matchLabels:
        role: proxy. It combines a namespaceSelector (to match the 'frontend' namespace) with a podSelector (to match pods with label 'role: proxy') in the same ingress rule. This ensures that only traffic from pods in the 'frontend' namespace that also have the label 'role: proxy' is allowed, fulfilling the requirement precisely.

Answer

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        name: frontend

Answer

ingress:
- from:
  - ipBlock:
      cidr: 0.0.0.0/0
  - podSelector:
      matchLabels:
        role: proxy

Answer

ingress:
- from:
  - podSelector:
      matchLabels:
        role: proxy

Question 8

Which Service type is used to expose a Service on a static port on each node's IP address, allowing external traffic to reach the Service?

Accepted Answer

NodePort. NodePort is the correct Service type because it exposes the Service on a static port (in the range 30000-32767) on each node's IP address. This allows external traffic to reach the Service by sending requests to any node's IP at that port, which then forwards traffic to the appropriate Pods via the ClusterIP and kube-proxy rules.

Answer

ClusterIP

Answer

ExternalName

Answer

LoadBalancer

Question 9

Which TWO of the following are valid methods to create a Service in Kubernetes? (Select 2)

Accepted Answer

kubectl apply -f service.yaml. `kubectl apply -f service.yaml` declaratively creates a Service from a YAML manifest. Option B is correct because `kubectl expose deployment my-deploy --port=80` imperatively creates a Service that exposes the deployment's pods. Option E is not considered a standard method for creating a Service in the context of this exam; the commonly taught imperative commands are `kubectl apply -f` and `kubectl expose`. Options C and D are incorrect: `kubectl port-forward` does not create a Service, and `kubectl run` creates a Pod or Deployment, not a Service.

Answer

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

Answer

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

Answer

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

Question 10

An Ingress resource is defined as:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
  tls:
  - hosts:
    - example.com
    secretName: tls-secret
What must exist in the cluster for TLS termination to work?

Accepted Answer

A Secret named tls-secret of type kubernetes.io/tls in the same namespace. C is correct because TLS termination requires the actual TLS certificate and key to be stored in a Kubernetes Secret of type `kubernetes.io/tls`. The Ingress controller reads this Secret to terminate HTTPS connections, decrypting traffic before forwarding it to the backend service. Without this Secret, the Ingress controller cannot present a valid certificate to clients.

Answer

An IngressClass annotation specifying the ingress controller

Answer

A ServiceAccount named tls-secret

Answer

A ConfigMap named tls-secret with certificate data

Question 11

You want to expose a Deployment 'app' externally on port 30080 on each node. What service type should you use?

Accepted Answer

NodePort. A NodePort service exposes the Deployment on a static port (30080) on each node's IP address, making it accessible externally via <NodeIP>:30080. This is the correct choice because the requirement explicitly asks to expose the app on port 30080 on each node, which matches the NodePort service type's behavior of opening a specific port on every node in the cluster.

Answer

LoadBalancer

Answer

ExternalName

Answer

ClusterIP

Question 12

An Ingress resource is created with the following YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80

Which of the following requests will be routed to the api-svc Service? (Select all that apply.)

Accepted Answer

GET http://example.com/api/. Based on the Ingress YAML, the host must be 'example.com' and the path must match the prefix '/api' according to pathType: Prefix, which matches based on URL path elements split by '/'. /api/ and /api/users are valid matches because the first path element 'api' matches and then the prefix ends. /apix does not match because 'apix' is not an element-wise prefix of 'api'. Option A fails due to path '/other'. Option C fails due to host 'example.org'. Therefore, only options B and E are correct.

Answer

GET http://example.com/other

Answer

GET http://example.org/api

Answer

GET http://example.com/apix

Question 13

You have a Deployment with multiple replicas. You want to expose it via a Service that has a stable IP address and is accessible from outside the cluster on a static port on each node. Which Service type should you use?

Accepted Answer

NodePort. A NodePort Service type exposes the application on a static port (in the range 30000-32767) on every node's IP address, making it accessible from outside the cluster. This satisfies the requirement for a stable IP (the node's IP) and a static port on each node, while also providing a stable ClusterIP for internal use.

Answer

LoadBalancer

Answer

ClusterIP

Answer

ExternalName

Question 14

Which TWO are valid Service types? (Choose two.)

Accepted Answer

NodePort. A is correct because NodePort is a standard Kubernetes Service type that exposes a Service on a static port (30000-32767) on each Node's IP address, allowing external traffic to reach the Service. It works by opening that port on every node and routing traffic to the ClusterIP Service, which then forwards to the Pods.

Answer

Headless

Answer

Ingress

Answer

Pod

Question 15

A NetworkPolicy named 'deny-all' is applied in a namespace. Which YAML snippet correctly implements a default-deny-all ingress policy?

Accepted Answer

spec:
  podSelector: {}
  policyTypes:
  - Ingress. A NetworkPolicy with an empty `podSelector: {}` selects all pods in the namespace, and specifying `policyTypes: [Ingress]` without any `ingress` rules creates a default-deny-all ingress policy, blocking all incoming traffic. Options B and C include `ingress` rules (with empty `from`), which is not the standard approach for a strict deny-all; the canonical method is to omit the `ingress` field entirely when using `policyTypes: [Ingress]`.

Answer

spec:
  podSelector: {}
  ingress:
  - from: []

Answer

spec:
  podSelector:
    matchLabels: {}
  ingress:
  - from: []

Answer

spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Ingress