CKA Services and Networking Practice Test 11 — 15 Questions

Question 1

Which of the following is NOT a valid Service type in Kubernetes?

Accepted Answer

Headless. Headless is not a valid Service type in Kubernetes; it is a configuration of a ClusterIP service where the cluster IP is set to 'None' to return individual pod DNS records instead of a single virtual IP. The valid Service types are ClusterIP, NodePort, LoadBalancer, and ExternalName.

Answer

ExternalName

Answer

NodePort

Answer

ClusterIP

Question 2

You need to expose a Service externally using an Ingress. The Ingress controller requires a specific IngressClass. How do you specify the IngressClass in the Ingress resource?

Accepted Answer

Set spec.ingressClassName: nginx. The `spec.ingressClassName` field is the standard way to specify the IngressClass for an Ingress resource in Kubernetes v1.18+ (GA in v1.22). This field references the name of an IngressClass resource, which defines the controller (e.g., nginx, haproxy) and its configuration. Using this field ensures the Ingress controller selects the correct implementation.

Answer

Set spec.class: nginx

Answer

Add an annotation: kubernetes.io/ingress.class: nginx

Answer

Create an IngressClass resource and reference it via spec.ingressClassRef

Question 3

You have a Service 'my-svc' with ClusterIP None (headless). You create a StatefulSet with 3 replicas and a headless Service. How do you reach individual pods?

Accepted Answer

Use the pod DNS name: .my-svc..svc.cluster.local. In a headless Service (ClusterIP: None), Kubernetes creates DNS A/AAAA records for each pod in a StatefulSet using the pattern ...svc.cluster.local. This allows direct, stable network identity for each pod, which is essential for stateful applications like databases that require consistent hostnames.

Answer

Use the Service name 'my-svc' which will round-robin between pods

Answer

Use the Service's ClusterIP (None) to reach all pods

Answer

You cannot reach individual pods directly; you must use the Service name

Question 4

Which THREE of the following are true about NetworkPolicy in Kubernetes? (Select 3)

Accepted Answer

NetworkPolicy supports both ingress and egress rules. Option B is correct because a NetworkPolicy spec can include both an ingress array and an egress array, allowing you to control inbound and outbound traffic for the selected pods (with policyTypes declaring which directions are enforced). Option C is correct because the podSelector within an ingress/egress rule can be combined with a namespaceSelector, and when both are used in the same peer element they match pods in the namespaces selected by namespaceSelector, enabling cross-namespace pod selection. Option E is correct because Kubernetes NetworkPolicy is additive and default-allow: if no NetworkPolicy selects a given pod, that pod is not isolated and all ingress and egress traffic is permitted. Option A is not correct because NetworkPolicy peers are defined by ipBlock CIDRs, podSelector, and namespaceSelector — not by DNS names. Option D is not correct because NetworkPolicy is a namespaced resource (it lives in a namespace and selects pods within that namespace, though rules can reference other namespaces).

Answer

NetworkPolicy can define rules based on DNS names

Answer

NetworkPolicy is a cluster-scoped resource

Question 5

You need to expose a Deployment named 'web' on port 80 inside the cluster. Which kubectl command creates a ClusterIP service?

Accepted Answer

kubectl expose deployment web --port=80. The `kubectl expose deployment web --port=80` command creates a ClusterIP service by default, which exposes the deployment on port 80 within the cluster. The `expose` command without specifying `--type` defaults to ClusterIP, making it the appropriate choice for internal cluster access.

Answer

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

Answer

kubectl create service clusterip web --tcp=80

Answer

kubectl port-forward deployment/web 80:80

Question 6

You apply the following NetworkPolicy:

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

What effect does this policy have?

Accepted Answer

All ingress traffic to any pod in the namespace is denied.. This NetworkPolicy uses a `podSelector: {}` which selects all pods in the namespace, and specifies `policyTypes: [Ingress]` with no ingress rules. According to Kubernetes NetworkPolicy semantics, when no ingress rules are defined, all ingress traffic is denied. This effectively creates a default-deny ingress policy for all pods in the namespace, making option D correct.

Answer

Ingress traffic from pods with label 'app: allowed' is allowed.

Answer

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

Answer

The policy has no effect because no rules are specified.

Question 7

Which Service type is used to expose a service externally with a cloud provider's load balancer?

Accepted Answer

LoadBalancer. The LoadBalancer service type provisions an external load balancer from the underlying cloud provider (e.g., AWS ELB, GCP TCP/UDP Load Balancer, Azure Load Balancer) and assigns a public IP or DNS name to route external traffic to the Kubernetes service. It is the only built-in service type that directly integrates with a cloud provider's infrastructure to expose a service externally with a managed load balancer.

Answer

NodePort

Answer

ClusterIP

Answer

ExternalName

Question 8

A pod in namespace 'ns1' cannot resolve the DNS name 'svc.ns2.svc.cluster.local'. What is the most likely cause?

Accepted Answer

The service 'svc' does not exist in namespace 'ns2'.. In Kubernetes, CoreDNS dynamically creates DNS records for Services using the format '..svc.'. If a pod attempts to resolve the fully qualified domain name (FQDN) 'svc.ns2.svc.cluster.local' and fails, the most likely cause is that the Service named 'svc' does not exist in the namespace 'ns2', meaning no DNS record exists for it.

Answer

The pod's DNS policy is set to None.

Answer

The pod is trying to resolve using only the short service name 'svc' without the namespace.

Answer

The pod's DNS policy is set to Default.

Question 9

You have a NodePort service. Which kube-proxy mode allows for better performance and more sophisticated load balancing algorithms like 'least connection'?

Accepted Answer

ipvs. (ipvs) is correct because kube-proxy in IPVS mode uses the Linux kernel's IP Virtual Server (IPVS) to implement Layer 4 load balancing, which supports sophisticated scheduling algorithms such as 'least connection' (lc), round-robin, and others. IPVS operates in kernel space with a hash table structure, providing better performance and scalability compared to iptables, especially in clusters with thousands of services.

Answer

iptables

Answer

kernelnet

Answer

userspace

Question 10

Which TWO statements about Ingress in Kubernetes are correct?

Accepted Answer

Ingress can terminate TLS connections for backend Services.. Option B is correct because an Ingress resource can reference a TLS Secret via spec.tls, allowing the Ingress controller to terminate TLS connections and forward decrypted HTTP traffic to the backend Services. Option E is correct because Ingress rules use the host field to match the HTTP Host header and route requests to different backend Services accordingly. Option A is wrong because spec.ingressClassName selects which Ingress controller should handle the resource; it does not disable the default controller. Option C is wrong because gRPC support is not native to Ingress and typically requires controller-specific annotations or a Gateway API/HTTPRoute setup. Option D is wrong because Ingress operates at Layer 7 (HTTP/HTTPS), while Layer 4 TCP/UDP load balancing requires a Service of type LoadBalancer or a Gateway API TCPRoute.

Answer

Setting spec.ingressClassName to 'nginx' disables the default Ingress controller.

Answer

Ingress natively supports gRPC services without any additional configuration.

Answer

Ingress can provide Layer 4 (TCP/UDP) load balancing.

Question 11

Which THREE statements about NetworkPolicy are correct?

Accepted Answer

To allow traffic from a specific namespace, you can use a namespaceSelector in the ingress rule.. Option A is correct because an ingress rule's 'from' clause can include a namespaceSelector that matches namespaces by their labels, thereby permitting traffic originating from pods in those namespaces. Option C is correct because an empty podSelector (podSelector: {}) matches every pod in the NetworkPolicy's own namespace, effectively applying the policy to all pods there. Option D is correct because podSelector uses a LabelSelector whose matchLabels field selects pods by exact key/value label pairs. Option B is wrong because the absence of any NetworkPolicy means all ingress and egress traffic is allowed by default; traffic is only denied once a policy selects the pod. Option E is wrong because NetworkPolicy is a namespaced resource, not cluster-scoped, and only affects pods within its own namespace.

Answer

If no NetworkPolicy exists, all traffic is denied by default.

Answer

NetworkPolicy is a cluster-scoped resource.

Question 12

Which THREE of the following are valid methods for service discovery in Kubernetes?

Accepted Answer

Environment variables (e.g., SERVICE_NAME_SERVICE_HOST). Environment variables (B) are a valid service-discovery mechanism because kubelet injects variables such as SERVICE_NAME_SERVICE_HOST and SERVICE_NAME_SERVICE_PORT for each Service into Pods at creation time, letting containers locate dependencies without an external registry. DNS lookups using CoreDNS (D) are the canonical discovery method: CoreDNS serves records like ..svc.cluster.local and SRV records for named ports, resolving Service ClusterIPs and headless endpoints. Kubernetes API queries (E) are valid because clients can list/watch Service and Endpoints/EndpointSlice objects via kubectl or direct API calls to discover backends dynamically. kubectl port-forward (A) merely tunnels a local port to a Pod or Service for debugging and does not provide in-cluster discovery, while Ingress rules (C) only expose HTTP/HTTPS routes from outside the cluster and are not a discovery mechanism for workloads.

Answer

kubectl port-forward

Answer

Ingress rules

Question 13

Which THREE components are part of the Gateway API?

Accepted Answer

Gateway. The Gateway API is a Kubernetes SIG-Network set of role-oriented, portable, and expressive routing resources, and its core object model consists of GatewayClass, Gateway, and route resources such as HTTPRoute. Option A, Gateway, is correct because it represents a deployed instance of a gateway (a data-plane load balancer/proxy) that listeners and routes attach to. Option D, HTTPRoute, is correct because it is one of the standard route types that defines HTTP/HTTPS routing rules and binds to a Gateway listener. Option E, GatewayClass, is correct because it is the cluster-scoped template that defines the controller implementation and configuration for Gateways, analogous to IngressClass. Option B, Service, is not part of the Gateway API itself; it is a core Kubernetes resource used for exposing pods and may be referenced as a backend, but it is not a Gateway API component. Option C, Ingress, is not part of the Gateway API; it is the older, separate Kubernetes Ingress resource that the Gateway API is intended to supersede.

Answer

Service

Answer

Ingress

Question 14

Which TWO statements about EndpointSlices are correct?

Accepted Answer

EndpointSlices improve scalability compared to Endpoints.. Option A is correct because EndpointSlices improve scalability over the legacy Endpoints object: instead of one large Endpoints resource per Service, the EndpointSlice controller splits endpoints across multiple EndpointSlice objects (default up to 100 endpoints per slice), reducing the size of updates propagated to kube-proxy and other watchers. Option B is correct because each EndpointSlice endpoint includes topology information such as the node's zone and hostname (under the topology field, e.g., kubernetes.io/hostname and topology.kubernetes.io/zone), which enables topology-aware routing and traffic distribution. Option C is incorrect because EndpointSlices are normally created and managed automatically by the EndpointSlice controller (and mirrored by kube-proxy), not manually by users. Option D is incorrect because a single EndpointSlice can hold many endpoints (up to 100 by default), not just one. Option E is incorrect because EndpointSlices back all Service types that have endpoints, including ClusterIP, NodePort, LoadBalancer, and headless Services, not only ClusterIP.

Answer

EndpointSlices are created manually by the user.

Answer

Each EndpointSlice can contain only one endpoint.

Answer

EndpointSlices are only used with ClusterIP services.

Question 15

Which THREE of the following are CNI plugins?

Accepted Answer

Flannel. Flannel is a CNI plugin that provides a simple overlay network for Kubernetes clusters, typically using VXLAN or host-gw to encapsulate and route pod traffic across nodes. It implements the Container Network Interface (CNI) specification by installing a binary and configuration file on each node, enabling pod-to-pod communication without requiring a separate network daemon.

Answer

kube-proxy

Answer

CoreDNS