Certified Kubernetes Administrator (CKA) — All Questions

Which Service type exposes an application on a static port on every node's IP so external traffic can reach it without a cloud load balancer?

• a.ClusterIP
• b.ExternalName
• c.NodePort✓
• d.Headless

A NodePort Service opens the same port on every node and forwards traffic to the Service's Pods, making the app reachable via <NodeIP>:<NodePort>. ClusterIP is internal-only, ExternalName maps to a DNS name, and a headless Service returns Pod IPs directly with no proxying.

In-cluster DNS lets Pods resolve a Service by name. What is the fully qualified DNS name for a Service named db in the namespace prod using the default cluster domain?

• a.db.prod.svc.cluster.local✓
• b.prod.db.cluster.local.svc
• c.db.cluster.local.prod.svc
• d.svc.db.prod.cluster.local

Kubernetes Service DNS follows the pattern <service>.<namespace>.svc.<cluster-domain>, so db in prod resolves to db.prod.svc.cluster.local. Pods in the same namespace can use the short name db. Understanding this pattern is essential for troubleshooting cross-namespace connectivity.

By default, how do Pods in a Kubernetes cluster communicate with each other across nodes before any NetworkPolicy is applied?

• a.All cross-node Pod traffic is blocked until a Service is created
• b.Every Pod can reach every other Pod directly, because the network model is flat and non-isolated by default✓
• c.Pods can only talk to Pods on the same node
• d.Traffic must be routed through the API server

Kubernetes assumes a flat network where every Pod can reach every other Pod across nodes without NAT, and all Pods are non-isolated until a NetworkPolicy selects them. NetworkPolicies (enforced by a supporting CNI plugin) are what restrict traffic. The API server is not in the data path for Pod-to-Pod traffic.

You want to route external HTTP traffic to different Services based on the URL path (for example /api and /web). Which resource is designed for this Layer 7 routing?

• a.A NodePort Service
• b.A NetworkPolicy
• c.A headless Service
• d.An Ingress with an Ingress controller✓

An Ingress defines HTTP and HTTPS routing rules, including host- and path-based routing, and is realized by an Ingress controller running in the cluster. NodePort Services expose a single port with no path awareness, NetworkPolicies control access rather than routing, and headless Services do not proxy traffic.

A NetworkPolicy is applied that selects a set of Pods and defines only an ingress rule allowing traffic from one label-selected source. What is the effect on other incoming traffic to those Pods?

• a.All other ingress traffic to the selected Pods is denied✓
• b.All ingress traffic is still allowed because policies are additive only
• c.Egress traffic from the Pods is also blocked
• d.The policy has no effect until a matching egress policy exists

Once a NetworkPolicy with an ingress section selects a Pod, that Pod becomes isolated for ingress and only the explicitly allowed sources can reach it; everything else is denied. Defining ingress rules does not restrict egress. This default-deny-once-selected behavior is a common exam point.