Certified Kubernetes Administrator (CKA) — All Questions
5 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.Headless
- d.NodePort✓
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.svc.db.prod.cluster.local
- d.db.cluster.local.prod.svc
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.Pods can only talk to Pods on the same node
- b.Traffic must be routed through the API server
- c.All cross-node Pod traffic is blocked until a Service is created
- d.Every Pod can reach every other Pod directly, because the network model is flat and non-isolated by default✓
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 headless Service
- c.A NetworkPolicy
- 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.The policy has no effect until a matching egress policy exists
- b.Egress traffic from the Pods is also blocked
- c.All other ingress traffic to the selected Pods is denied✓
- d.All ingress traffic is still allowed because policies are additive only
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.