CKA Practice Test 4 — 25 Questions

Question 1

You have a NetworkPolicy that selects pods with label 'role: db' in the 'default' namespace. The policy has no ingress rules defined. What is the effect on traffic to the selected pods?

Accepted Answer

All ingress traffic is denied. A NetworkPolicy with no ingress rules defaults to denying all ingress traffic to the selected pods. This is because Kubernetes NetworkPolicies are whitelist-based: if no ingress rules are specified, the policy implicitly denies all incoming traffic, even if other policies allow it. The selected pods with label 'role: db' will therefore receive no ingress traffic.

Answer

Only traffic from pods with label 'role: frontend' is allowed

Answer

Both ingress and egress traffic are denied

Answer

All ingress traffic is allowed

Question 2

A pod is stuck in Pending state. You run 'kubectl describe pod my-pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {gpu: true} that the pod didn't tolerate, 3 node(s) had resource pressure.'. What is the most likely cause?

Accepted Answer

The pod needs a toleration for the gpu taint, and nodes have resource constraints.. The event message explicitly states that 1 node has a taint (gpu: true) that the pod does not tolerate, and 3 nodes have resource pressure (e.g., memory, disk, or PID exhaustion). A pod remains in Pending state when no node can satisfy its scheduling requirements; adding a toleration for the gpu taint would allow scheduling on that node, but the resource pressure on the other nodes must also be resolved (e.g., by freeing resources or increasing capacity).

Answer

The pod has a nodeSelector that doesn't match any node.

Answer

The pod is using a deprecated API version.

Answer

The pod's image pull secret is missing.

Question 3

A developer runs 'kubectl port-forward service/my-service 8080:80'. What does this command do?

Accepted Answer

It forwards incoming traffic on local port 8080 to port 80 on the service's ClusterIP.. `kubectl port-forward` creates a tunnel from a local port on the client machine to a specified port on a Kubernetes resource, in this case a Service. It forwards traffic received on localhost:8080 to the Service's ClusterIP on port 80, allowing the developer to access the service without exposing it externally.

Answer

It creates a proxy that routes traffic from the service's ClusterIP to the local machine on port 8080.

Answer

It exposes the service as a NodePort on port 8080.

Answer

It creates a new service of type LoadBalancer on port 8080.

Question 4

A NetworkPolicy named 'deny-all' is applied to a namespace with podSelector: {}. The policy has no ingress rules. What is the effect?

Accepted Answer

All ingress traffic to pods in the namespace is denied, but egress traffic is allowed.. A NetworkPolicy with `podSelector: {}` selects all pods in the namespace. With no ingress rules defined, the policy defaults to denying all ingress traffic to those pods, while egress traffic remains unrestricted unless explicitly denied by another policy. This is because Kubernetes NetworkPolicy is additive for ingress: if any policy selects a pod, the default allow for ingress is overridden, and only explicitly allowed ingress traffic is permitted.

Answer

All traffic to and from pods in the namespace is denied.

Answer

Only traffic from pods in the same namespace is allowed.

Answer

All traffic is allowed because podSelector: {} matches nothing.

Question 5

You create a Service of type LoadBalancer in a Kubernetes cluster that does not have an external load balancer provider (e.g., bare-metal). What will be the state of the EXTERNAL-IP field when you run 'kubectl get svc'?

Accepted Answer

. When a Service of type LoadBalancer is created in a Kubernetes cluster without an external load balancer provider (e.g., bare-metal or on-premises), the cloud-controller-manager component responsible for provisioning the external load balancer is absent or non-functional. As a result, the external IP address remains unassigned, and `kubectl get svc` displays `` for the EXTERNAL-IP field until a controller sets it. This state persists indefinitely unless an external tool like MetalLB is deployed to fulfill the LoadBalancer request.

Answer

The ClusterIP

Answer

The node's IP address

Answer

<none>

Question 6

You run 'kubectl get svc my-service -o yaml' and see 'type: ClusterIP'. The service has no endpoints. What is the most likely cause?

Accepted Answer

No pods with labels matching the service selector are running and ready.. A Kubernetes Service of type ClusterIP relies on a label selector to identify target Pods. If no Pods match the selector and are in the Ready state, the Service will have no endpoints, causing traffic to be dropped. The absence of endpoints directly indicates a mismatch or absence of matching, ready Pods.

Answer

The service type is ClusterIP, which does not support endpoints.

Answer

The service's port does not match the container port.

Answer

The service is misconfigured and needs to be deleted and recreated.

Question 7

Which of the following CNI plugins typically uses BGP to distribute routing information across nodes?

Accepted Answer

Calico. Calico uses BGP (Border Gateway Protocol) to exchange routing information between nodes, enabling direct pod-to-pod communication without overlays. Each node runs a BGP client that advertises the pod CIDRs assigned to that node, allowing the underlying network infrastructure to route traffic at Layer 3.

Answer

Flannel

Answer

Weave

Answer

Cilium

Question 8

An Ingress resource uses 'networking.k8s.io/v1' API. Which field specifies the hostname and path rules for routing traffic?

Accepted Answer

spec.rules. In the 'networking.k8s.io/v1' Ingress API, the 'spec.rules' field is where you define an array of routing rules, each containing a 'host' field for the hostname and an 'http' subfield with 'paths' that specify path-based routing to backend services. This is the primary mechanism for directing traffic based on hostname and path.

Answer

spec.ingress

Answer

spec.tls

Answer

spec.backend

Question 9

You create a ClusterIP service named 'my-svc' in the 'default' namespace. A pod in the same namespace tries to reach the service using the DNS name 'my-svc'. Which fully qualified domain name (FQDN) should the pod use to resolve the service?

Accepted Answer

my-svc.default.svc.cluster.local. The standard FQDN for a Kubernetes service in the default namespace is `..svc.cluster.local`. This is the DNS record created by CoreDNS (or kube-dns) for ClusterIP services, allowing pods to resolve the service by its fully qualified domain name. The pod can also use the shorter form `my-svc` because the DNS search path includes the service's namespace and the `svc.cluster.local` suffix, but the FQDN ensures unambiguous resolution.

Answer

my-svc.default.svc.cluster

Answer

my-svc.default.cluster.local

Answer

my-svc.svc.cluster.local

Question 10

Which of the following Service types does NOT assign a ClusterIP to the Service?

Accepted Answer

Headless. A Headless Service is created by setting the `clusterIP` field to `None` in the Service specification. This tells Kubernetes not to allocate a ClusterIP, making the Service headless. Instead of a virtual IP, DNS queries for the Service name return the IP addresses of all matching Pods directly, enabling stateful workloads like databases to discover individual Pod endpoints.

Answer

LoadBalancer

Answer

ClusterIP

Answer

NodePort

Question 11

Which of the following Service types exposes a Service on a static port on each node's IP?

Accepted Answer

NodePort. NodePort is the correct answer because it exposes a Service on a static port (in the range 30000–32767) on every node's IP address. Traffic sent to any node's IP on that port is forwarded to the Service's ClusterIP and then to the backing pods. This is defined in the Service's `spec.ports[].nodePort` field.

Answer

ExternalName

Answer

ClusterIP

Answer

LoadBalancer

Question 12

Which of the following is the default DNS name for a Service named 'my-svc' in namespace 'my-ns'?

Accepted Answer

my-svc.my-ns.svc.cluster.local. A is correct because Kubernetes uses a built-in DNS system (CoreDNS) that automatically creates DNS records for Services. The fully qualified domain name (FQDN) for a Service follows the pattern `..svc.cluster.local`, where `svc` is a fixed label indicating it's a Service record, and `cluster.local` is the default cluster domain. This allows pods to resolve the Service by name within the cluster.

Answer

my-svc.my-ns.cluster.local

Answer

my-svc.my-ns.svc

Answer

my-svc.my-ns.pod.cluster.local

Question 13

An ingress resource is defined with the following snippet:
```yaml
spec:
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 80
```
The secret 'app-tls' exists and contains a valid certificate. However, accessing https://app.example.com returns a certificate warning in the browser. What is the most likely cause?

Accepted Answer

The TLS secret is in a different namespace than the ingress resource. The TLS secret must reside in the same namespace as the Ingress resource because the Ingress controller reads the secret from the Ingress's namespace. If the secret is in a different namespace, the controller cannot access it, causing it to fall back to its default (untrusted) certificate or fail to serve the correct certificate, which results in a browser certificate warning.

Answer

The ingress controller does not support TLS termination

Answer

The path type is Prefix but should be Exact

Answer

The secret name does not match the TLS section host

Question 14

Which resource type is used to configure HTTP/HTTPS routing to Services?

Accepted Answer

Ingress. Ingress is the Kubernetes resource that provides HTTP and HTTPS routing from outside the cluster to Services within the cluster. It defines rules for host-based and path-based routing, TLS termination, and load balancing, making it the correct choice for configuring external HTTP/HTTPS access.

Answer

EndpointSlice

Answer

NetworkPolicy

Answer

Service

Question 15

You have a Service with endpoints for pods in different zones. You want kube-proxy to use a mode that provides better performance for large clusters and supports scheduling algorithms like least-connection. Which mode should you use?

Accepted Answer

ipvs mode. IPVS (IP Virtual Server) mode is correct because it uses the LVS (Linux Virtual Server) kernel module to provide a transport-layer load balancer that supports multiple scheduling algorithms, including least-connection (lc), round-robin (rr), and source hashing (sh). Unlike iptables, IPVS uses a hash table as the underlying data structure, which scales linearly with the number of services and endpoints, making it far more performant in large clusters with thousands of services.

Answer

userspace mode

Answer

iptables mode

Answer

kernelspace mode

Question 16

Which of the following is a valid use case for a Headless Service?

Accepted Answer

To enable DNS-based service discovery for stateful applications like StatefulSets. A Headless Service (with clusterIP: None) is used to enable DNS-based service discovery, returning the IP addresses of all backing pods rather than a single virtual IP. This is essential for stateful applications like StatefulSets, where each pod requires a stable network identity and direct pod-to-pod communication without load balancing.

Answer

To provide a stable IP address for a deployment

Answer

To load balance traffic across pods using iptables

Answer

To allow external traffic to reach pods without a load balancer

Question 17

Which kube-proxy mode uses IP Virtual Server (IPVS) for load balancing and supports more algorithms than the default mode?

Accepted Answer

ipvs. The IP Virtual Server (IPVS) mode in kube-proxy leverages the Linux kernel's IPVS module, which is built on the Netfilter framework and operates in the kernel space. Unlike the default iptables mode, IPVS supports a variety of load-balancing algorithms (e.g., round-robin, least-connection, source-hashing) and provides better scalability and performance for large clusters by using a hash table for service-to-endpoint mapping.

Answer

userspace

Answer

iptables

Answer

kube-proxy

Question 18

You want to temporarily access a pod's HTTP endpoint on port 8080 from your local machine on port 9090. Which command should you use?

Accepted Answer

kubectl port-forward pod/my-pod 9090:8080. `kubectl port-forward` creates a direct tunnel from a local port (9090) to a pod's port (8080) over the Kubernetes API server, enabling temporary access to a pod's HTTP endpoint without exposing a service. This is the standard method for debugging or testing a pod's network endpoint from a local machine.

Answer

kubectl exec -it my-pod -- /bin/bash

Answer

kubectl proxy --port=9090

Answer

kubectl expose pod my-pod --port=9090 --target-port=8080

Question 19

What is the purpose of a headless Service (clusterIP: None)?

Accepted Answer

To allow direct DNS resolution to pod IPs. A headless Service (clusterIP: None) disables the virtual IP and load balancing, causing DNS queries to return the IP addresses of the backing pods directly. This allows clients to perform DNS-based service discovery and connect to specific pod IPs, which is essential for stateful applications like databases that require direct pod-to-pod communication.

Answer

To expose the Service externally via a cloud load balancer

Answer

To provide load balancing across pods

Answer

To map the Service to an external DNS name

Question 20

A developer runs `kubectl run nginx --image=nginx --port=80` and then `kubectl expose pod nginx --port=80 --target-port=80 --type=NodePort`. What is the name of the created Service?

Accepted Answer

nginx. The `kubectl expose pod nginx --port=80 --target-port=80 --type=NodePort` command creates a Service that inherits its name from the resource being exposed, which is the pod named 'nginx'. By default, `kubectl expose` uses the name of the referenced resource (in this case, the pod) as the Service name, resulting in a Service named 'nginx'. This is consistent with Kubernetes behavior where the Service name is derived from the resource name unless overridden with the `--name` flag.

Answer

expose-nginx

Answer

nginx-service

Answer

nginx-pod