CKAD Services and Networking Practice Test 6 — 15 Questions

Question 1

A Service named 'api' has no endpoints. 'kubectl describe svc api' shows the selector 'app: api', but no pods have that label. What is the most likely reason for missing endpoints?

Accepted Answer

No pods match the Service's selector. The most likely reason for missing endpoints is that no pods match the Service's selector. A Kubernetes Service routes traffic to pods that have labels matching its `spec.selector`. If `kubectl describe svc api` shows `Selector: app=api` but no pods carry the label `app: api`, the Service's endpoint controller will not populate any endpoints, resulting in an empty `Endpoints` object. This is the direct cause of the missing endpoints.

Answer

The Service is in a different namespace than the pods

Answer

The Service port is incorrect

Answer

The Service type is ExternalName

Question 2

Which TWO are valid ways to create a Service from a deployment named 'frontend'? (Choose two.)

Accepted Answer

Write a YAML manifest with apiVersion: v1, kind: Service, metadata.name, spec.selector matching deployment labels, and run kubectl apply -f manifest.yaml. It describes the standard method of creating a Kubernetes Service by writing a YAML manifest with the correct apiVersion (v1), kind (Service), metadata.name, and spec.selector that matches the labels of the target Pods (e.g., from the 'frontend' deployment). Running 'kubectl apply -f manifest.yaml' then creates the Service, which routes traffic to Pods with matching labels.

Answer

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

Answer

kubectl autoscale deployment frontend --min=1 --max=5

Answer

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

Question 3

Which command exposes a deployment named 'web' as a ClusterIP service on port 80?

Accepted Answer

kubectl expose deployment web --port=80. `kubectl expose deployment web --port=80` creates a ClusterIP service by default, which exposes the deployment on port 80 within the cluster. The `expose` command automatically selects the deployment's pod labels and creates a service that maps port 80 to the target port (defaulting to the same port).

Answer

kubectl create service clusterip web --port=80

Answer

kubectl run web --expose --port=80

Answer

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

Question 4

An ingress resource is created with the following spec. Which request will be routed to the 'green' service?

```yaml
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: blue
            port:
              number: 80
      - path: /api/v1
        pathType: Exact
        backend:
          service:
            name: green
            port:
              number: 80
```

Accepted Answer

http://example.com/api/v1. The request to http://example.com/api/v1 matches the Exact path /api/v1, which routes to the green service. In Kubernetes ingress, Exact pathType requires the request path to be identical to the specified path, and /api/v1 matches exactly.

Answer

http://example.com/api/v1/

Answer

http://example.com/api

Answer

http://example.com/

Question 5

A NetworkPolicy named 'default-deny-ingress' is applied to a namespace but contains no rules. What is the effect on pods in that namespace?

Accepted Answer

All ingress traffic is denied.. A NetworkPolicy with no rules defaults to denying all ingress traffic because Kubernetes NetworkPolicies are additive: any pod selected by a NetworkPolicy is isolated, and only traffic explicitly allowed by rules is permitted. Since this policy has no rules, no ingress traffic is allowed, effectively creating a deny-all ingress policy for pods in the namespace.

Answer

Only traffic from pods with label 'allow: true' is allowed.

Answer

All ingress traffic is allowed.

Answer

Only traffic from pods in the same namespace is allowed.

Question 6

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 7

A pod in namespace 'default' cannot resolve the service name 'db' in namespace 'data'. Which DNS name should the pod use to reach the service?

Accepted Answer

db.data.svc.cluster.local. Kubernetes DNS resolves a service in another namespace using the format ..svc.cluster.local. Since the service is named 'db' in namespace 'data', the fully qualified domain name (FQDN) is db.data.svc.cluster.local. This allows cross-namespace service discovery without needing to modify the pod's DNS configuration.

Answer

db.default.svc.cluster.local

Answer

data.db.svc.cluster.local

Answer

db.svc.data.cluster.local

Question 8

Which service type is used to expose a service using an external DNS name, such as a database hosted outside Kubernetes?

Accepted Answer

ExternalName. ExternalName is the correct service type because it maps a Kubernetes service to an external DNS name (e.g., a database hosted outside the cluster) by returning a CNAME record with that external name. This allows pods to access the external resource using the service's DNS name without needing to know the external endpoint's IP address.

Answer

ClusterIP

Answer

NodePort

Answer

LoadBalancer

Question 9

A headless service is created with 'clusterIP: None'. What is the primary use case for such a service?

Accepted Answer

To allow direct pod-to-pod DNS resolution for StatefulSets.. A headless service (clusterIP: None) is primarily used with StatefulSets to enable direct pod-to-pod DNS resolution. Instead of a single virtual IP, the DNS returns the individual pod IPs (A/AAAA records) or SRV records, allowing each pod to be addressed by its stable network identity (e.g., pod-name.service-name.namespace.svc.cluster.local). This is essential for stateful applications like databases that require stable peer discovery.

Answer

To provide a stable IP address for the service.

Answer

To expose the service externally without a load balancer.

Answer

To enable DNS round-robin across all pods.

Question 10

An Ingress resource uses the annotation 'kubernetes.io/ingress.class: nginx'. However, traffic is not being routed. The cluster has multiple ingress controllers. What is the most likely cause?

Accepted Answer

The annotation is deprecated; use spec.ingressClassName instead.. The annotation `kubernetes.io/ingress.class` is deprecated in Kubernetes 1.18+ and removed in 1.25+. The correct approach is to use `spec.ingressClassName` in the Ingress spec, which references an `IngressClass` resource. Since the cluster has multiple ingress controllers, the deprecated annotation may be ignored or not processed by the intended controller, causing traffic not to be routed.

Answer

The ingress controller is not installed.

Answer

The service backend doesn't exist.

Answer

TLS certificate is invalid.

Question 11

A NetworkPolicy allows egress traffic to pods with label 'db: mysql' in the same namespace. Which egress rule is correct?

Accepted Answer

egress:
  - to:
    - podSelector:
        matchLabels:
          db: mysql. A NetworkPolicy egress rule uses the `to` field to specify destination pods, and a `podSelector` within the same namespace selects pods with the label `db: mysql`. This allows outbound traffic from any pod in the namespace to pods matching that label, which directly satisfies the requirement.

Answer

egress:
  - to:
    - namespaceSelector:
        matchLabels:
          db: mysql

Answer

egress:
  - from:
    - podSelector:
        matchLabels:
          db: mysql

Answer

egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/8

Question 12

Which TWO statements about Kubernetes Services are correct?

Accepted Answer

A Service provides a stable IP address and DNS name for a set of pods.. A Kubernetes Service provides a stable virtual IP address and a DNS name (via CoreDNS) that remains constant even as the underlying pods are created, destroyed, or scaled. This abstraction decouples clients from the ephemeral nature of pod IPs, ensuring reliable service discovery within the cluster.

Answer

A ClusterIP service is accessible from outside the cluster.

Answer

A Service can load balance traffic across multiple clusters.

Answer

A headless service assigns a ClusterIP to the service.

Question 13

Which THREE components are typically involved when using Ingress to expose a service?

Accepted Answer

Ingress resource. An Ingress resource defines the routing rules for external HTTP/HTTPS traffic to services within the cluster. It specifies hostnames, paths, and the backend service to forward requests to, but it is only a configuration object. The actual traffic handling requires an Ingress controller (e.g., NGINX, Traefik) to process the Ingress resource and implement the rules, and a Service of type ClusterIP or NodePort to expose the target pods internally.

Answer

External load balancer

Answer

NetworkPolicy

Question 14

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 15

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