CKA Services and Networking Practice Questions

Free CKA Services and Networking practice test questions

8 questions from this domain with answers and explanations - different from the samples on the main CKA page. A free account includes a fixed set of 20 questions for this exam; paid access unlocks the full bank.

1. Question 1Services and Networking

   Which Service type exposes the Service on each node's IP at a static port?

   • AClusterIP
   • BLoadBalancer
   • CExternalName
   • DNodePortCorrect
   ✓ Correct answer: D

   A NodePort Service allocates a port from the node port range (30000-32767 by default), and every node proxies that same port into the Service, so traffic sent to <NodeIP>:<NodePort> reaches the backend pods. A NodePort Service also gets a cluster IP, so NodePort builds on top of ClusterIP. This makes the application reachable from outside the cluster through any node's IP address without a cloud load balancer.

   Why the other options are wrong

   • AClusterIP creates an internal virtual IP that is only reachable within the cluster; it does not expose the Service on node IPs or open any port on the node's network interface.
   • BLoadBalancer provisions an external load balancer through the cloud provider integration; by default it also allocates node ports for the load balancer to target, but that can be turned off with spec.allocateLoadBalancerNodePorts: false, and the type is defined by the external load balancer, not by a static port on each node.
   • CExternalName maps the Service to an external DNS name via a CNAME record; it does not expose any port on the nodes and is used to give cluster-internal DNS aliases to external services.
2. Question 2Services and Networking

   Nexus Cloud Corp has deployed an Nginx Ingress controller and created an Ingress resource, but external traffic is not reaching the backend pods. The Ingress controller's Service is of type LoadBalancer and has an external IP. What should the administrator check first?

   • ARestart every pod in the cluster to reset the routing state
   • BVerify the Ingress resource's ingressClassName matches the controller's classCorrect
   • CDelete and recreate the Ingress controller deployment entirely
   • DChange the Ingress controller Service from LoadBalancer to ClusterIP
   ✓ Correct answer: B

   When an Ingress resource is not processed by any controller, the most common cause is a mismatch between the ingressClassName field in the Ingress spec (or the legacy 'kubernetes.io/ingress.class' annotation) and the class name that the running Ingress controller is configured to watch. If these values do not match, the controller silently ignores the Ingress object and no routing rules are configured. Checking the IngressClass resource or the controller's startup flags to confirm the expected class name is the first targeted diagnostic step.

   Why the other options are wrong

   • ARestarting all pods is disruptive and does not address an ingressClassName mismatch as the likely cause.
   • CRecreating the controller is premature before confirming the Ingress resource references its class.
   • DSwitching the controller Service to ClusterIP would remove its external IP and stop external traffic entirely.
3. Question 3Services and NetworkingSelect all that apply

   Which two are required components for Ingress to function? (Choose two.)

   • AAn Ingress controller deployed in the clusterCorrect
   • BAn Ingress resource defining routing rulesCorrect
   • CA LoadBalancer Service for every backend
   • DA dedicated etcd instance for Ingress
   ✓ Correct answer: A, B

   Ingress in Kubernetes requires two distinct components working together. The Ingress resource is a declarative API object where operators define HTTP routing rules (host names, URL paths, and backend Services). The Ingress controller is a running software component (such as NGINX Ingress Controller, Traefik, or HAProxy) that watches Ingress resources and configures the underlying proxy accordingly. Without both pieces, no HTTP routing occurs.

   Why the other options are wrong

   • CA LoadBalancer Service for every backend is not required for Ingress; backend Services for Ingress rules typically use ClusterIP, and the Ingress controller itself may optionally be fronted by a LoadBalancer Service, but backends do not need to be LoadBalancer type.
   • DA dedicated etcd instance for Ingress does not exist as a concept in Kubernetes; Ingress resources are stored in the cluster's single etcd instance alongside all other API objects, and no separate etcd is required.
4. Question 4Services and Networking

   Which field in a NodePort service spec lets you request a specific node port number?

   • Aspec.ports[].externalPort
   • Bspec.ports[].nodePortCorrect
   • Cspec.nodePort
   • Dspec.ports[].hostPort
   ✓ Correct answer: B

   In a NodePort service, each port entry in spec.ports can include a nodePort field to pin the service to a specific port in the allowed NodePort range (default 30000-32767). If nodePort is omitted, Kubernetes allocates a random port from that range. Specifying it explicitly is useful when external firewall rules or load balancers need a predictable, stable port number.

   Why the other options are wrong

   • Aspec.ports[].externalPort is not a valid field in the Kubernetes Service API. There is no externalPort field; the correct field is nodePort within a port entry.
   • Cspec.nodePort is not a valid path in the Service spec. The nodePort configuration belongs inside the ports array at spec.ports[].nodePort, not at the top-level spec.
   • Dspec.ports[].hostPort is a pod-level container port field used to bind a container port directly to the host, not a Service spec field. It is unrelated to NodePort service configuration.
5. Question 5Services and Networking

   How do you create a default deny-all ingress Network Policy for the entire namespace "prod"?

   • Aapply an annotation deny-all-ingress: true to the prod namespace object
   • Bcreate a NetworkPolicy with podSelector: {} and policyTypes: ["Ingress"] with no ingress rules in namespace prodCorrect
   • Cset networkPolicy.defaultDeny: true in the prod namespace specification
   • Dcreate a NetworkPolicy with podSelector: {} and policyTypes: ["Egress"] with no egress rules in prod
   ✓ Correct answer: B

   An empty podSelector {} in a NetworkPolicy matches every pod in the namespace. When policyTypes includes Ingress but the ingress rules list is absent or empty, the policy defines zero allowed ingress sources, resulting in all ingress traffic being denied for every pod in the namespace. This is the official Kubernetes-documented pattern for creating a default deny-all ingress policy and is enforced by any CNI plugin that supports Network Policies.

   Why the other options are wrong

   • ANamespace annotations do not enforce network isolation; a NetworkPolicy object is required to deny ingress.
   • CThere is no defaultDeny field on a namespace spec; default deny is achieved with an empty NetworkPolicy.
   • DpolicyTypes Egress with no egress rules denies outbound traffic, not the ingress the requirement asks for.
6. Question 6Services and Networking

   Which Weave Net feature distinguishes it from basic Flannel?

   • AWeave Net supports Network Policies and provides optional encryptionCorrect
   • BWeave Net relies exclusively on BGP routing for connectivity
   • CWeave Net requires a dedicated external etcd cluster to run
   • DWeave Net supports only IPv6 pod networking
   ✓ Correct answer: A

   Weave Net is a CNI plugin that implements the Kubernetes NetworkPolicy API, allowing administrators to enforce ingress and egress traffic rules between pods. It also supports optional encryption of the data plane traffic between nodes using sleeve or fast datapath modes with NaCl encryption. Basic Flannel, by contrast, provides only simple overlay networking and does not implement NetworkPolicy enforcement or built-in encryption.

   Why the other options are wrong

   • BWeave Net uses its own mesh overlay, not exclusively BGP; BGP-only routing is more typical of Calico.
   • CWeave Net stores state in its own gossip protocol and does not require a separate etcd cluster.
   • DWeave Net supports IPv4 pod networking, not an IPv6-only mode.
7. Question 7Services and Networking

   You created a ClusterIP service but pods in another namespace cannot resolve the bare service name. They can resolve the FQDN. What is happening?

   • AThe service must be type LoadBalancer before its bare name will resolve from other namespaces
   • BClusterIP services are namespace-restricted and can only be reached from within their own namespace
   • CDNS short names only resolve within the same namespaceCorrect
   • DThe CoreDNS server is misconfigured and is silently dropping all short-name lookups
   ✓ Correct answer: C

   Kubernetes injects a DNS search list into each pod's /etc/resolv.conf that includes the pod's own namespace (for example, search default.svc.cluster.local svc.cluster.local cluster.local). When a pod uses a bare service name like my-svc, the resolver appends the search domains in order. Because the target service is in a different namespace, the bare name fails - the resolver never appends the target namespace. Using the form <service>.<namespace> or the full FQDN <service>.<namespace>.svc.cluster.local bypasses the search-domain limitation and resolves correctly from any namespace.

   Why the other options are wrong

   • AService type affects external exposure, not internal DNS resolution behavior for names across namespaces.
   • BClusterIP Services are reachable cluster-wide; only the bare short name is namespace-scoped in DNS.
   • DCoreDNS is working correctly since the FQDN resolves; the issue is the search-domain scope of short names.
8. Question 8Services and Networking

   Which NetworkPolicy spec in namespace data denies all ingress traffic to Pods labeled app=db, while leaving every other Pod in the namespace unaffected?

   • ApodSelector matching app=db, policyTypes: ["Ingress"], and no ingress fieldCorrect
   • BpodSelector: {}, policyTypes: ["Ingress"], and ingress: []
   • CpodSelector matching app=db, policyTypes: ["Egress"], and egress: []
   • DpodSelector matching app=db, policyTypes: ["Ingress"], and ingress: [{ from: [{ podSelector: {} }] }]
   ✓ Correct answer: A

   A NetworkPolicy that selects a Pod and lists Ingress in policyTypes isolates that Pod for ingress, so the only connections allowed in are those from the Pod's own node and those an ingress rule allows. With no ingress rules, whether the field is left out or set to an empty list, no other traffic is allowed. Selecting app=db keeps the effect on those Pods only.

   Why the other options are wrong

   • BAn empty podSelector selects every Pod in the namespace, so this denies ingress to all of them, not just the app=db Pods.
   • CpolicyTypes lists only Egress, so this isolates the app=db Pods for outbound traffic and leaves their inbound traffic open.
   • DAn empty podSelector inside from allows traffic from every Pod in the namespace, so this rule opens ingress instead of denying it.

How Services and Networking is tested

This domain holds 152 of the 793 questions in the CKA bank, about 19%. The mix is 190 single-answer multiple choice and 10 multiple-response, so it is worth practising the formats as well as the content.

Once you have a few attempts recorded, CertGrid scores every domain separately and points you at the weakest one, so you can drill Services and Networking on its own rather than re-running full-length mocks.

Other CKA exam domains

• Cluster Architecture Installation and Configuration167 questions
• Workloads and Scheduling173 questions
• Storage145 questions
• Troubleshooting156 questions
• All CKA practice questions793 total
• Services and Networking study notesKey concepts
• Cloud Native practice examsAll Cloud Native

CKA Services and Networking FAQ