CKA Services and Networking Practice Test 6 — 15 Questions

Question 1

Which kube-proxy mode supports connection-based load balancing using Linux IPVS?

Accepted Answer

ipvs. The IPVS (IP Virtual Server) mode in kube-proxy uses the Linux kernel's IPVS module to implement Layer 4 (transport layer) load balancing. IPVS supports multiple scheduling algorithms (e.g., round-robin, least connections) and provides connection-based load balancing by maintaining a connection tracking table, which allows it to forward packets belonging to the same TCP/UDP session to the same backend pod. This is more efficient than iptables for large-scale clusters due to its use of hash tables (O(1) lookup) rather than linear rule chains.

Answer

iptables

Answer

kernelspace

Answer

userspace

Question 2

An Ingress resource defines a TLS section with hosts: ["example.com"] and secretName: tls-secret. What must be true for TLS to work correctly?

Accepted Answer

The secret must be in the same namespace as the Ingress.. Kubernetes requires that the Secret referenced in an Ingress's TLS configuration must reside in the same namespace as the Ingress resource. The Ingress controller, when processing the TLS section, looks up the Secret by name within the Ingress's namespace to obtain the TLS certificate and private key. If the Secret is in a different namespace, the controller cannot access it, and TLS termination will fail.

Answer

The secret must contain keys named ca.crt and tls.crt.

Answer

The secret must be named tls-secret in the kube-system namespace.

Answer

The Ingress controller must be configured to enable TLS termination.

Question 3

A cluster uses Flannel as the CNI plugin. Which of the following best describes Flannel's networking model?

Accepted Answer

It assigns a /24 subnet to each node and uses VXLAN encapsulation.. Flannel's default networking model assigns a /24 subnet to each node and uses VXLAN encapsulation to create an overlay network. This allows pods on different nodes to communicate without requiring changes to the underlying physical network, as VXLAN tunnels traffic between nodes using UDP encapsulation.

Answer

It requires an external etcd to store network state.

Answer

It uses BGP to distribute routes across the cluster.

Answer

It provides network policies with full support for ingress and egress rules.

Question 4

You want to allow ingress traffic from pods with label 'app: frontend' in namespace 'web' to pods with label 'app: backend' in namespace 'api'. Which NetworkPolicy matches this requirement?

Accepted Answer

PodSelector: app: backend, Ingress rule with from: - namespaceSelector: matchLabels: name: web - podSelector: matchLabels: app: frontend. It defines a NetworkPolicy in the 'api' namespace that selects pods with label 'app: backend' and allows ingress traffic from pods with label 'app: frontend' in the 'web' namespace. The combination of namespaceSelector (matching namespace 'web') and podSelector (matching 'app: frontend') in the from rule ensures that only traffic originating from pods with the specified label in the specified namespace is permitted, exactly matching the requirement.

Answer

PodSelector: app: frontend, Egress rule with to: - namespaceSelector: matchLabels: name: api - podSelector: matchLabels: app: backend

Answer

PodSelector: {}, Ingress rule with from: - podSelector: matchLabels: app: frontend

Answer

PodSelector: app: backend, Ingress rule with from: - namespaceSelector: matchLabels: name: api - podSelector: matchLabels: app: frontend

Question 5

Which of the following is a core component of the Gateway API?

Accepted Answer

GatewayClass. The Gateway API is a Kubernetes SIG-Network project that defines a set of resources for configuring service networking. Its core components are GatewayClass, Gateway, and HTTPRoute (or TCPRoute, etc.). GatewayClass is analogous to IngressClass in the Ingress API, defining a class of gateways that a controller can implement, making it a foundational core component.

Answer

VirtualService

Answer

IngressController

Answer

ServiceEntry

Question 6

Which two of the following are valid methods for exposing a Service externally in Kubernetes? (Select TWO.)

Accepted Answer

LoadBalancer. LoadBalancer (Option C) is correct because it provisions an external load balancer (e.g., AWS ELB, GCP L7) that assigns a public IP to the Service, making it accessible from outside the cluster. NodePort (Option D) is correct because it opens a static port (30000-32767) on every node's IP, allowing external traffic to reach the Service via :.

Answer

Headless

Answer

ExternalName

Answer

ClusterIP

Question 7

Which three of the following are features of EndpointSlices compared to Endpoints? (Select THREE.)

Accepted Answer

Smaller slices with up to 100 endpoints per slice. EndpointSlices are designed to split large sets of endpoints into smaller, manageable slices, each containing up to 100 endpoints by default. This improves scalability and performance compared to the single monolithic Endpoints object, which could become a bottleneck in large clusters.

Answer

Direct support for NetworkPolicy

Answer

Automatic scaling based on the number of endpoints

Question 8

Which two of the following are valid Ingress path types in networking.k8s.io/v1? (Select TWO.)

Accepted Answer

Exact. In networking.k8s.io/v1, the Ingress spec allows two path types: 'Exact' and 'Prefix'. 'Exact' matches the URL path exactly, case-sensitive, and is used when you need a precise route without any wildcard or trailing segment matching. This is defined in the Kubernetes Ingress API documentation.

Answer

Glob

Answer

Regex

Answer

Wildcard

Question 9

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 10

Which command creates a temporary pod and forwards port 8080 from your local machine to port 80 of an existing pod named 'web-pod'?

Accepted Answer

kubectl port-forward pod/web-pod 8080:80. The command `kubectl port-forward pod/web-pod 8080:80` forwards traffic from port 8080 on your local machine to port 80 of the existing pod named 'web-pod'. It runs entirely as a local client-side process and does not spin up any temporary pods in the Kubernetes cluster.

Answer

kubectl exec -it web-pod -- nc -l -p 8080

Answer

kubectl proxy --port=8080

Answer

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

Question 11

You have a NetworkPolicy that selects pods with label 'app: db'. The policy has an ingress rule allowing traffic from pods with label 'app: frontend'. A pod with label 'app: frontend' is in a different namespace. No namespaceSelector is specified in the ingress rule. Will traffic from that pod be allowed?

Accepted Answer

No, because the frontend pod is in a different namespace and no namespaceSelector is specified. A NetworkPolicy's ingress rule without a namespaceSelector only applies to pods within the same namespace as the policy. Since the frontend pod is in a different namespace and no namespaceSelector is specified, the rule does not match it, and traffic is denied by default (as NetworkPolicy enforces default-deny for selected pods).

Answer

Yes, because podSelector selects pods across all namespaces

Answer

No, because NetworkPolicy only works within the same namespace

Answer

Yes, because all ingress traffic is allowed by default

Question 12

You run 'kubectl run nginx --image=nginx --expose --port=80'. What resources are created?

Accepted Answer

A Deployment named nginx and a Service named nginx. The `kubectl run nginx --image=nginx --expose --port=80` command creates a Deployment named `nginx` (which manages a ReplicaSet and Pods) and a Service named `nginx` that exposes port 80. The `--expose` flag triggers automatic Service creation, and `kubectl run` without `--restart=Never` defaults to creating a Deployment, not a standalone Pod.

Answer

A Pod named nginx and a Service named nginx

Answer

A Pod named nginx and an Endpoints resource named nginx

Answer

A ReplicaSet named nginx and a Service named nginx

Question 13

Which Service type exposes a Service on each Node's IP at a static port in the range 30000-32767?

Accepted Answer

NodePort. A NodePort Service exposes the Service on each Node's IP at a static port in the range 30000-32767. When you create a NodePort Service, Kubernetes allocates a port from that range (or you can specify one) and opens that port on every node in the cluster, forwarding traffic to the Service's ClusterIP and then to the selected Pods.

Answer

ExternalName

Answer

ClusterIP

Answer

LoadBalancer

Question 14

In a Kubernetes cluster using CoreDNS, what is the DNS name for a Service named 'api' in namespace 'backend'?

Accepted Answer

api.backend.svc.cluster.local. In Kubernetes, CoreDNS resolves Service DNS names using the format `..svc.cluster.local`. For a Service named 'api' in namespace 'backend', the fully qualified DNS name is `api.backend.svc.cluster.local`. This allows Pods to discover the Service via DNS, with CoreDNS serving as the cluster DNS provider.

Answer

backend.api.svc.cluster.local

Answer

api.backend.cluster.local

Answer

api.svc.backend.cluster.local

Question 15

You have an Ingress resource with a TLS section specifying a secret named 'tls-secret'. The certificate in 'tls-secret' is expired. What happens when a client connects via HTTPS to the Ingress host?

Accepted Answer

TLS handshake succeeds but the client receives a warning about the expired certificate. When a client connects via HTTPS to an Ingress host with an expired TLS certificate, the Ingress controller (e.g., NGINX) still terminates the TLS handshake successfully because TLS termination does not validate certificate expiration at the server side. The expired certificate is presented to the client, and the client's browser or tool (e.g., curl) will show a warning about the expired certificate but the connection proceeds unless the client is configured to reject expired certificates. The Ingress controller does not enforce certificate validity; it only serves the configured secret.

Answer

The Ingress controller returns an error and refuses to terminate TLS

Answer

The Ingress controller automatically renews the certificate

Answer

The secret is ignored and HTTP is used instead