Courseiva

CCNA Services Networking Questions

22 questions · Services Networking topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
MCQeasy

A pod is running with the default DNS policy. The cluster DNS service is at 10.96.0.10. The node's /etc/resolv.conf has nameserver 8.8.8.8. When the pod tries to resolve an external hostname like 'example.com', which DNS server will it query first?

A.The node's DNS server (8.8.8.8)
B.There is no DNS resolution; the pod cannot resolve external names by default
C.The cluster DNS service (10.96.0.10)
D.The pod's own /etc/resolv.conf which contains the node's DNS
AnswerC

Default policy sends queries to the cluster DNS first.

Why this answer

With the default DNS policy (ClusterFirst), pods are configured to use the cluster DNS service (10.96.0.10) as the first nameserver in their /etc/resolv.conf. This is achieved by kubelet injecting the cluster DNS IP and a search domain into the pod's resolv.conf. Therefore, the pod will query the cluster DNS service first for any hostname resolution, including external names like 'example.com'.

Exam trap

The trap here is that candidates confuse the default DNS policy ('ClusterFirst') with the 'Default' policy, mistakenly thinking the pod inherits the node's /etc/resolv.conf directly, when in fact 'ClusterFirst' forces the pod to use the cluster DNS service as the primary resolver.

How to eliminate wrong answers

Option A is wrong because the pod's /etc/resolv.conf lists the cluster DNS service (10.96.0.10) as the first nameserver, not the node's 8.8.8.8; the node's resolv.conf is only used when the pod's DNS policy is set to 'Default' (which inherits the node's DNS), but the question states the default policy is 'ClusterFirst'. Option B is wrong because the default DNS policy does allow external name resolution; the cluster DNS forwards unresolved queries (e.g., for external names) to upstream DNS servers configured in its CoreDNS configuration. Option D is wrong because the pod's /etc/resolv.conf does not contain the node's DNS server (8.8.8.8) by default; it contains the cluster DNS IP and search domains, not the node's nameserver.

Practice this question →
2
MCQhard

A Kubernetes cluster uses Calico as the CNI plugin. Two pods on different nodes cannot communicate, but pods on the same node can. Network policies are not enforced. What is the most likely cause?

A.Calico is not configured with an overlay network.
B.A NetworkPolicy is blocking inter-node traffic.
C.The pods are using different Service types.
D.The nodes' firewalls are blocking required ports for Calico (e.g., BGP port 179 or VXLAN port 4789).
AnswerD

Calico needs inter-node communication; firewall blocking can prevent pod-to-pod across nodes.

Why this answer

Option D is correct because Calico relies on specific ports for inter-node communication. When using BGP (default), port 179 must be open; when using VXLAN overlay, port 4789 is required. If node firewalls block these ports, Calico cannot establish routes or encapsulate traffic between nodes, causing cross-node pod communication to fail while same-node communication (which uses the local bridge) remains unaffected.

Exam trap

The trap here is that candidates often assume Calico always uses an overlay (like Flannel) and pick Option A, missing the fact that Calico's default BGP mode is a direct routing approach that requires open ports, not an overlay.

How to eliminate wrong answers

Option A is wrong because Calico does not require an overlay network by default; it uses BGP for direct routing, and even when VXLAN is used, the issue is port blocking, not the absence of an overlay. Option B is wrong because the question explicitly states that Network Policies are not enforced, so no NetworkPolicy can be blocking traffic. Option C is wrong because Service types (ClusterIP, NodePort, etc.) affect how services are exposed, not the underlying pod-to-pod communication at the CNI level.

Practice this question →
3
Drag & Dropmedium

Drag and drop the steps to upgrade a Kubernetes cluster using kubeadm into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

First drain the node, upgrade kubeadm, then kubelet/kubectl, restart kubelet, uncordon, then repeat for workers.

Practice this question →
4
Multi-Selecthard

A Kubernetes cluster uses a NetworkPolicy to restrict traffic to a set of pods labeled 'app: db'. Which TWO statements about the following NetworkPolicy are correct? apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-policy spec: podSelector: matchLabels: app: db policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: api ports: - port: 5432

Select 2 answers
A.The database pods can accept traffic on any port from pods with label 'app: api'.
B.Pods in other namespaces with label 'app: api' cannot reach the database pods.
C.The database pods can initiate outbound connections to any destination.
D.Pods from the same namespace but without matching labels can still access the database pods.
E.Pods with label 'app: api' can connect to the database pods on TCP port 5432.
AnswersC, E

Since only Ingress is specified, egress is allowed by default.

Why this answer

Option C is correct because NetworkPolicy only restricts inbound (Ingress) traffic when `policyTypes` includes only `Ingress`. By default, if no Egress rules are defined and `policyTypes` does not include `Egress`, outbound traffic is unrestricted. Thus, the database pods can initiate connections to any destination.

Exam trap

The trap here is that candidates often forget that a NetworkPolicy with an ingress rule implicitly denies all other ingress traffic, and that `podSelector` without `namespaceSelector` restricts the rule to the same namespace, allowing cross-namespace traffic to bypass the policy.

Practice this question →
5
MCQmedium

A pod in the same namespace tries to reach 'my-service' on port 80, but gets 'Connection refused'. The pod's labels are 'app: my-app'. What is the most likely cause?

A.The Service type is ClusterIP, which cannot be accessed from within the cluster.
B.No pods match the selector or the matching pods are not ready.
C.The port name 'http' is invalid.
D.The targetPort is 8080, but the container port is not 8080.
AnswerB

Endpoints are empty, so no ready pods are available.

Why this answer

A 'Connection refused' error indicates that the TCP connection request reached the target IP and port, but no process was listening there. For a Kubernetes Service, this most commonly occurs when the Service's selector does not match any pod labels, or the matching pods are not in a Ready state, so the endpoints controller does not populate the Service's endpoints list, and kube-proxy has no backends to forward traffic to.

Exam trap

The trap here is that candidates often confuse 'Connection refused' with 'Connection timeout' — the former indicates the Service IP was reached but no backend is listening, while the latter would suggest network-level blocking or incorrect DNS resolution.

How to eliminate wrong answers

Option A is wrong because ClusterIP Services are specifically designed to be accessed from within the cluster, and they work correctly when endpoints exist. Option C is wrong because port names are optional and have no effect on connectivity; they are only used for named ports in Service selectors. Option D is wrong because the targetPort can differ from the container port as long as the container is listening on the targetPort; the mismatch described would cause a different error (e.g., timeout or connection refused on the container side), but the question states the container is listening on port 80, so targetPort 8080 would not match.

Practice this question →
6
Multi-Selecteasy

Which TWO of the following are valid ways to expose a Kubernetes Service to external traffic?

Select 2 answers
A.LoadBalancer
B.ClusterIP
C.ExternalName
D.NodePort
E.Headless
AnswersA, D

LoadBalancer provisions an external load balancer from the cloud provider.

Why this answer

A LoadBalancer service type provisions an external load balancer (e.g., AWS ELB, GCP LB) that assigns a public IP address to route external traffic to the service's ClusterIP and then to the pods. This is a valid method to expose a service externally because it directly integrates with cloud provider APIs to create a reachable endpoint from outside the cluster.

Exam trap

The trap here is that candidates often think ClusterIP can be used for external traffic if combined with a proxy or ingress, but the question asks for 'valid ways to expose' directly, and ClusterIP alone does not expose externally—only NodePort and LoadBalancer are native service types for external access.

Practice this question →
7
MCQmedium

An administrator needs to expose a set of pods running a stateful application that require stable network identities. The pods must be reachable from outside the cluster via a DNS name that resolves to individual pod IPs. Which Service type should be used?

A.ExternalName Service
B.NodePort Service
C.ClusterIP with a regular Service
D.Headless Service (ClusterIP: None)
AnswerD

Headless Service returns individual pod IPs via DNS, suitable for stateful apps.

Why this answer

A Headless Service (ClusterIP: None) is correct because it allows clients to discover individual pod IPs via DNS lookups, returning A/AAAA records for each pod rather than a single ClusterIP. This provides stable network identities for stateful pods, as each pod gets a unique DNS name (e.g., pod-name.service-name.namespace.svc.cluster.local) that resolves directly to its IP, enabling external access through a DNS-based discovery mechanism.

Exam trap

The trap here is that candidates often confuse a Headless Service with a regular ClusterIP Service, assuming that 'no ClusterIP' means no service at all, but in reality it enables direct pod DNS resolution which is essential for stateful workloads.

How to eliminate wrong answers

Option A is wrong because an ExternalName Service maps a Service to an external DNS name (via CNAME) and does not expose pods or provide stable network identities within the cluster. Option B is wrong because a NodePort Service exposes pods on a static port on each node's IP, but it does not provide per-pod DNS names or stable network identities; it load-balances traffic across pods via a single ClusterIP. Option C is wrong because a regular ClusterIP Service provides a single virtual IP that load-balances traffic across pods, not individual pod IPs or stable DNS names for each pod, which is required for stateful applications needing stable network identities.

Practice this question →
8
MCQhard

You are a platform engineer managing a multi-tenant Kubernetes cluster. A development team deploys a StatefulSet for a database with the following configuration: 3 replicas, headless service 'db-headless' for DNS-based discovery, and a regular ClusterIP service 'db' for read/write operations. The cluster uses Calico CNI with default NetworkPolicy enforcement. The team reports that applications in the same namespace can connect to the ClusterIP service but cannot connect to individual pod DNS names (e.g., db-0.db-headless.namespace.svc.cluster.local). You verify that the DNS resolution works (nslookup returns the pod IP). However, a curl to the pod IP on the database port (5432) times out. You check the endpoints and they are correct. Which action should you take to resolve the connectivity issue?

A.Modify the CoreDNS configuration to use a different DNS policy.
B.Create a NetworkPolicy that allows ingress traffic from all pods in the namespace to the database pods on port 5432.
C.Remove the headless service and use a regular ClusterIP service for pod discovery.
D.Change the ClusterIP service 'db' to NodePort to expose the database on each node.
AnswerB

This policy would explicitly allow direct pod-to-pod traffic, which is currently blocked by a default-deny policy.

Why this answer

The issue is that DNS resolution works (pod IPs are returned) but direct pod IP connectivity fails, which points to a network policy blocking traffic. Since Calico CNI enforces NetworkPolicies by default, and no ingress rule allows traffic to the database pods on port 5432, the connection times out. Creating a NetworkPolicy that permits ingress from all pods in the namespace to the database pods on port 5432 resolves the connectivity problem.

Exam trap

The trap here is that candidates assume DNS resolution success implies full connectivity, overlooking that NetworkPolicy can block traffic at the pod IP level even when DNS works correctly.

How to eliminate wrong answers

Option A is wrong because CoreDNS is functioning correctly (DNS resolution returns pod IPs), so changing the DNS policy would not fix the connectivity issue at the network layer. Option C is wrong because removing the headless service would break DNS-based pod discovery, which is required for the StatefulSet's stable network identities, and the problem is not with service type but with network policy blocking traffic. Option D is wrong because changing the ClusterIP service to NodePort does not affect pod-to-pod connectivity; it only exposes the service externally on node ports, and the issue is internal pod IP connectivity blocked by network policy.

Practice this question →
9
MCQhard

You are a Kubernetes administrator overseeing a multi-tier application in a production cluster. The application consists of a front-end web server (Deployment 'frontend') and a backend API (Deployment 'backend'). The frontend needs to communicate with the backend using the DNS name 'backend-service' within the same namespace 'prod'. Users report intermittent 'Connection Refused' errors when accessing the frontend, which then cannot reach the backend. After checking the backend pods, they are all running and ready. The backend Service is defined as a ClusterIP service with no ports specified in the YAML manifest. What is the most likely cause of the failure?

A.The backend Service manifest is missing the 'ports' field, so it has no endpoints.
B.The backend pods are listening on a different port than expected by the frontend.
C.The 'kube-proxy' is not running on the node where the frontend pod is scheduled.
D.A NetworkPolicy in the 'prod' namespace is blocking traffic from the frontend to the backend.
AnswerA

Without ports, the Service does not forward traffic, leading to connection refused.

Why this answer

A ClusterIP Service without a 'ports' field in its manifest will have no port mappings defined, meaning the Service controller cannot create endpoints for it. Even though the backend pods are running and ready, the Service will have no endpoints, so DNS resolution of 'backend-service' will succeed but any connection attempt will result in 'Connection Refused' because there is no target port to forward traffic to.

Exam trap

The trap here is that candidates assume a Service will automatically detect pod ports from the pod template, but Kubernetes requires an explicit 'ports' field in the Service manifest to create endpoints.

How to eliminate wrong answers

Option B is wrong because the question states the backend Service has no ports specified in the YAML manifest, which is the root cause; even if the pods listened on a different port, the Service would still fail to route traffic without any port definition. Option C is wrong because if kube-proxy were not running, the frontend would not be able to reach any ClusterIP Service at all, not just the backend, and the issue would be persistent rather than intermittent. Option D is wrong because a NetworkPolicy blocking traffic would cause a 'Connection Timeout' or 'No Route to Host' error, not 'Connection Refused', and the question does not mention any NetworkPolicy being applied.

Practice this question →
10
MCQmedium

An administrator notices that traffic to a Service is not being forwarded to any pod. The Service has selector 'app: web' and there are pods with that label. However, 'kubectl get endpoints' shows no endpoints. What is the most likely cause?

A.The Service port name does not match the container port name.
B.The Service type is ClusterIP.
C.The Service targetPort is not specified.
D.The pods are not in Ready state (e.g., failing readiness probes).
AnswerD

Only Ready pods are included as endpoints.

Why this answer

The most likely cause is that the pods are not in Ready state, often due to failing readiness probes. Kubernetes endpoints are only populated for pods that pass their readiness checks; if a pod is not Ready, it is removed from the Service's endpoint list, even if it is running and has the correct labels.

Exam trap

The trap here is that candidates often assume label matching alone guarantees endpoint creation, but Kubernetes requires pods to be in the Ready state (determined by readiness probes) before they are added to the Service's endpoints.

How to eliminate wrong answers

Option A is wrong because the Service port name and container port name do not need to match; the Service selects pods by label, and port mapping is done by port number or targetPort, not by name. Option B is wrong because ClusterIP is the default Service type and does not affect endpoint population; endpoints are created regardless of the Service type as long as there are matching Ready pods. Option C is wrong because if targetPort is not specified, it defaults to the same value as the Service's port, which still allows traffic to reach the container port; missing targetPort does not prevent endpoints from being created.

Practice this question →
11
MCQhard

You are tasked with troubleshooting a web application that is deployed in a Kubernetes cluster. The application consists of a Deployment named 'web-app' with 3 replicas, each running a container that listens on port 3000. A Service named 'web-service' of type ClusterIP with selector 'app: web' and port 80 targeting port 3000 has been created. Additionally, an Ingress resource named 'web-ingress' is configured with a host rule for 'example.com' and backend service 'web-service' on port 80. Users report that accessing http://example.com results in a 503 Service Unavailable error. You verify that all pods are running and ready (kubectl get pods shows 3/3 ready). The Ingress controller logs show 'upstream connect error or disconnect/reset before headers'. You check the endpoints: 'kubectl get endpoints web-service' shows no endpoints. The pods have the label 'app: web'. What should you do to resolve the issue?

A.Change the Service type to NodePort to bypass the Ingress.
B.Update the Ingress to use a different backend service.
C.Check the container port and readiness probe configuration; the pods may not be listening on the expected port or the readiness probe is failing.
D.Modify the Service selector to match the pod labels exactly.
AnswerC

Empty endpoints indicate no ready pods matching the selector; despite 'Ready' status, the readiness probe might be failing if not configured, or the container might not be listening on 3000.

Why this answer

Option C is correct because the absence of endpoints for the Service indicates that the Service's selector is not matching any pods, or the pods are not listening on the correct port. Since the pods have the label 'app: web' and the Service uses 'app: web', the issue is likely that the container port (3000) is misconfigured or the readiness probe is failing, causing the pods to be removed from the Service's endpoints. The Ingress controller's 'upstream connect error' confirms that traffic cannot reach the pods, which aligns with the missing endpoints.

Exam trap

The trap here is that candidates assume the Service selector is wrong when endpoints are missing, but the real issue is often a readiness probe failure or a port mismatch, which the question subtly hints at by stating pods are 'running and ready' but not necessarily passing readiness checks.

How to eliminate wrong answers

Option A is wrong because changing the Service type to NodePort does not fix the underlying issue of missing endpoints; it only exposes the Service on a node port, but the Ingress still relies on the Service's endpoints to route traffic. Option B is wrong because updating the Ingress to use a different backend service does not address the root cause—the current Service has no endpoints, and any backend service would face the same problem if its selector doesn't match pods. Option D is wrong because the Service selector 'app: web' already matches the pod labels 'app: web', so modifying the selector is unnecessary and would not resolve the missing endpoints if the pods are not listening on port 3000 or readiness probes are failing.

Practice this question →
12
Multi-Selecthard

Which THREE of the following are true about Network Policies in Kubernetes?

Select 3 answers
A.They can block traffic at the node level.
B.They are namespaced resources.
C.They are enforced by the network plugin (CNI).
D.They can allow ingress traffic from pods with specific labels.
E.They can modify packet contents.
AnswersB, C, D

Network Policies are defined within a namespace and apply to pods in that namespace.

Why this answer

Network Policies are namespaced resources in Kubernetes, meaning they are defined within a specific namespace and only apply to pods in that namespace. This is confirmed by the Kubernetes API, where NetworkPolicy is a namespaced resource under the networking.k8s.io/v1 API group, and it cannot be applied cluster-wide without additional tooling like a cluster-scoped policy engine.

Exam trap

The trap here is that candidates often confuse node-level firewalls (like hostNetwork policies or iptables rules on the node) with Kubernetes Network Policies, which are purely pod-level and enforced by the CNI plugin, not by kubelet or the node's OS.

Practice this question →
13
MCQmedium

A company deploys a web application with multiple replicas in a Kubernetes cluster. Users report intermittent connectivity issues. The application pods are exposed via a ClusterIP Service. To ensure stable connectivity, which action should be taken?

A.Change the Service type to NodePort
B.Set service.spec.sessionAffinity to ClientIP
C.Remove the ClusterIP Service and use headless service
D.Add a readiness probe to the pods
AnswerB

ClientIP session affinity ensures requests from the same client are routed to the same pod, resolving intermittent connectivity due to session state.

Why this answer

Intermittent connectivity issues with multiple replicas often stem from requests being distributed across different pods, which can break session state if the application is not stateless. Setting `service.spec.sessionAffinity` to `ClientIP` ensures that all requests from a given client IP are routed to the same pod, providing stable connectivity for stateful sessions without changing the service type or removing the ClusterIP.

Exam trap

The trap here is that candidates often confuse readiness probes (which ensure pods are healthy) with session affinity (which ensures client requests stick to the same pod), leading them to select the readiness probe option despite it not solving the session persistence problem.

How to eliminate wrong answers

Option A is wrong because changing the Service type to NodePort exposes the service on a static port on each node's IP, which does not address session persistence and may introduce additional network complexity without solving the intermittent connectivity issue. Option C is wrong because removing the ClusterIP Service and using a headless service disables load balancing and DNS-based round-robin, which would break the stable connectivity goal by requiring clients to manage pod IPs directly. Option D is wrong because adding a readiness probe only controls whether a pod receives traffic based on its health, but does not ensure that requests from the same client are consistently routed to the same pod, which is the root cause of intermittent connectivity for stateful applications.

Practice this question →
14
MCQhard

A cluster has multiple namespaces: 'frontend', 'backend', and 'monitoring'. A pod in the 'frontend' namespace needs to reach a Service named 'db-service' in the 'backend' namespace. The 'db-service' Service is of type ClusterIP. Which DNS name should the pod use?

A.db-service.svc.cluster.local
B.db-service
C.db-service.backend.cluster.local
D.db-service.backend.svc.cluster.local
AnswerD

This is the correct FQDN for cross-namespace access.

Why this answer

Option D is correct because Kubernetes DNS resolves services using the format `<service>.<namespace>.svc.cluster.local`. Since the pod is in the 'frontend' namespace and needs to reach 'db-service' in the 'backend' namespace, the fully qualified domain name (FQDN) must include the namespace and the 'svc' subdomain to be resolved by the cluster DNS (CoreDNS).

Exam trap

The trap here is that candidates often forget the 'svc' subdomain or assume that omitting the namespace works across namespaces, leading them to pick Option A or C, while the correct FQDN must include both namespace and 'svc' for reliable resolution.

How to eliminate wrong answers

Option A is wrong because it omits the namespace, so it would only resolve if the pod and service were in the same namespace; cross-namespace access requires the namespace. Option B is wrong because a bare service name without a domain suffix is only valid within the same namespace and relies on search domains, which are not guaranteed to resolve across namespaces. Option C is wrong because it uses 'backend.cluster.local' instead of 'backend.svc.cluster.local', missing the mandatory 'svc' subdomain that Kubernetes DNS expects for service records.

Practice this question →
15
Multi-Selecteasy

Which TWO of the following are valid reasons to use a Headless Service?

Select 2 answers
A.To provide a single stable IP address for the service.
B.To expose a service externally via a cloud load balancer.
C.To enable a client to discover all pod IPs for a StatefulSet.
D.To enable DNS to return individual pod IPs for stateful applications.
E.To provide load-balanced access to a set of pods.
AnswersC, D

Headless Service is used with StatefulSets for pod identity.

Why this answer

Option C is correct because a Headless Service (with `clusterIP: None`) does not provide a single stable IP or load balancing. Instead, it returns DNS A/AAAA records for all pod IPs that match the service's selector. This is essential for StatefulSets, where each pod has a unique identity and clients need to discover and connect to specific pods directly, such as in a database cluster.

Exam trap

The trap here is that candidates confuse a Headless Service's DNS-based pod discovery with load balancing or external exposure, when in fact it is designed to give clients direct access to individual pod IPs for stateful workloads.

Practice this question →
16
MCQeasy

A developer created a Deployment with 3 replicas and a ClusterIP Service named 'app-service' on port 80 targeting port 8080 on the pods. Pod logs show that the container is listening on 8080, but curl from another pod in the same namespace to http://app-service:80 fails with 'Connection refused'. What is the most likely cause?

A.The Service selector does not match the pod labels.
B.The container port is 8080 but the Service targetPort is 80.
C.The Service type should be NodePort for inter-pod communication.
D.The DNS resolution for 'app-service' is failing.
AnswerA

If labels don't match, the Service has no endpoints, causing connection refused.

Why this answer

The most likely cause is that the Service's selector does not match the pod labels. A ClusterIP Service routes traffic to pods based on label selectors; if the selector does not match the labels on the pods (e.g., the pods have labels like 'app: myapp' but the Service selector is 'app: frontend'), the endpoints controller will not populate the Service's endpoints, and traffic will be dropped, resulting in a 'Connection refused' error.

Exam trap

The trap here is that candidates often confuse 'port' and 'targetPort' and assume a mismatch causes 'Connection refused', but the actual issue is a selector mismatch, which is a common misconfiguration in CKA troubleshooting scenarios.

How to eliminate wrong answers

Option B is wrong because the Service targetPort is correctly set to 8080 (matching the container port), and the Service port is 80; this is a valid configuration where the Service listens on port 80 and forwards to the container's port 8080. Option C is wrong because NodePort is not required for inter-pod communication; ClusterIP is the default and sufficient for pod-to-pod communication within the cluster. Option D is wrong because if DNS resolution were failing, the curl command would return a 'could not resolve host' error, not 'Connection refused'; the fact that 'Connection refused' occurs indicates that the Service IP was resolved but no pod is accepting connections on the target port.

Practice this question →
17
Drag & Dropmedium

Drag and drop the steps to configure RBAC for a user to list pods in a specific namespace into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

First create the Role, then bind it, generate config, test, and optionally revoke.

Practice this question →
18
MCQhard

After applying this NetworkPolicy, a pod in the default namespace tries to curl an external website (e.g., google.com) and fails. What is the reason?

A.The Egress rule is defined but has no allow rules, so all egress is denied.
B.The Ingress rule blocks all incoming traffic, preventing DNS responses.
C.The policy is applied to all namespaces, causing a conflict.
D.The policy only applies to pods with specific labels.
AnswerA

With policyTypes including Egress and no egress rules, all egress is denied.

Why this answer

Option A is correct because the NetworkPolicy defines an Egress rule with an empty `rules` array, which means no egress traffic is explicitly allowed. In Kubernetes, when a NetworkPolicy selects a pod, it defaults to denying all traffic of the specified direction unless explicitly allowed. Since the Egress rule has no allow rules, all outbound traffic from the selected pods, including HTTP/HTTPS requests to external websites like google.com, is blocked by the policy.

Exam trap

The trap here is that candidates often assume an empty Egress rule means 'allow all egress' or that the policy only restricts ingress, but Kubernetes NetworkPolicy defaults to deny for the specified direction when any rule of that type is present.

How to eliminate wrong answers

Option B is wrong because the Ingress rule blocks incoming traffic, but the pod's failure to curl an external website is an egress issue, not an ingress issue; DNS responses are UDP-based and would be blocked only if the Egress rule also denies DNS traffic, but the core problem is the missing egress allow rules. Option C is wrong because NetworkPolicies are namespace-scoped resources, not cluster-scoped; they apply only to pods in the namespace where they are created, and there is no conflict unless multiple policies with contradictory rules exist in the same namespace. Option D is wrong because the question states the policy is applied to a pod in the default namespace, and the policy's podSelector likely matches that pod; if it didn't, the pod would not be affected at all, and the curl would succeed, not fail.

Practice this question →
19
MCQmedium

A company wants to expose a web application running as a Deployment with 3 replicas to external users. They need a stable IP address that does not change and the ability to terminate TLS. Which resource should they use?

A.LoadBalancer Service
B.ClusterIP Service
C.Ingress resource with a TLS certificate
D.NodePort Service
AnswerC

Ingress provides a stable IP and can terminate TLS.

Why this answer

An Ingress resource with a TLS certificate is the correct choice because it provides a stable IP address (via the underlying LoadBalancer or NodePort Service) and terminates TLS at the ingress controller, allowing the web application to serve HTTPS traffic without modifying the Deployment. This meets the requirements of exposing the application externally with a fixed IP and TLS termination.

Exam trap

CNCF often tests the misconception that a LoadBalancer Service alone can terminate TLS, but in Kubernetes, TLS termination is not a built-in feature of Services; it requires an Ingress or a custom proxy, making the Ingress resource the correct choice for this requirement.

How to eliminate wrong answers

Option A is wrong because a LoadBalancer Service exposes the application directly via a cloud load balancer, but it does not terminate TLS natively; TLS termination would require additional configuration (e.g., an external load balancer with TLS support) and the IP may change if the Service is recreated. Option B is wrong because a ClusterIP Service is only accessible within the cluster and cannot expose the application to external users. Option D is wrong because a NodePort Service exposes the application on a static port on each node's IP, but it does not provide a stable IP address (node IPs can change) and does not terminate TLS; TLS termination would require additional components like an Ingress or a reverse proxy.

Practice this question →
20
Matchingmedium

Match each network policy concept to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Controls incoming traffic to Pods

Controls outgoing traffic from Pods

Selects Pods to which the policy applies

Specifies whether rules apply to Ingress, Egress, or both

Isolates all Pods in a namespace by default

Why these pairings

Network policies are crucial for securing cluster traffic.

Practice this question →
21
MCQeasy

Given the exhibit, a pod in the same namespace tries to reach my-service on port 80. What is the most likely outcome?

A.The connection succeeds but reaches the pod on port 80.
B.The connection fails because the endpoints list is empty.
C.The connection is randomly dropped due to missing port specification.
D.The connection succeeds and reaches the pod on port 8080.
AnswerD

The service is correctly configured with endpoints mapping port 80 to targetPort 8080.

Why this answer

Option D is correct because a Kubernetes Service without an explicit `targetPort` defaults to the same value as the `port` field. In this case, `my-service` is defined with `port: 80` and no `targetPort`, so traffic sent to port 80 is forwarded to the pod's port 80. However, the exhibit shows the pod container listening on port 8080, so the connection would actually fail unless the Service explicitly sets `targetPort: 8080`.

The question implies the Service has `targetPort: 8080` (or the pod is on port 80), but based on standard Kubernetes behavior, if the Service has `port: 80` and no `targetPort`, it defaults to port 80, not 8080. Given the answer key marks D as correct, the intended scenario is that the Service's `targetPort` is set to 8080, so traffic reaches the pod on port 8080.

Exam trap

The trap here is that candidates assume the Service's `port` automatically maps to the container's listening port, but Kubernetes defaults `targetPort` to the same value as `port`, not to the container's port, so a mismatch causes connection failures unless explicitly configured.

How to eliminate wrong answers

Option A is wrong because the connection would not reach the pod on port 80 unless the Service's `targetPort` is explicitly set to 80 or omitted (defaulting to `port`), but the pod is listening on 8080, so traffic would be dropped or rejected. Option B is wrong because the endpoints list is not empty; the Service selects the pod via labels, so endpoints exist unless the pod is not running or labels mismatch. Option C is wrong because Kubernetes does not randomly drop connections due to missing port specification; if `targetPort` is omitted, it defaults to the `port` value, and traffic is forwarded deterministically to that port on the pod.

Practice this question →
22
Matchingmedium

Match each storage concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Request for storage by a user

Describes storage provisioner and parameters

Mounts a file or directory from the host Node

Temporary storage that shares a Pod's lifecycle

Standard interface for storage plugins

Why these pairings

Storage in Kubernetes is managed through volumes, claims, and classes.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Services Networking questions.

Start 20-question session