CKA Services and Networking Practice Test 10 — 15 Questions

Question 1

In a Kubernetes cluster using CoreDNS, what is the DNS name for a Service named 'api' in namespace 'backend'?

Accepted Answer

api.backend.svc.cluster.local. In Kubernetes, CoreDNS resolves Service DNS names using the format `..svc.cluster.local`. For a Service named 'api' in namespace 'backend', the fully qualified DNS name is `api.backend.svc.cluster.local`. This allows Pods to discover the Service via DNS, with CoreDNS serving as the cluster DNS provider.

Answer

backend.api.svc.cluster.local

Answer

api.backend.cluster.local

Answer

api.svc.backend.cluster.local

Question 2

You have an Ingress resource with a TLS section specifying a secret named 'tls-secret'. The certificate in 'tls-secret' is expired. What happens when a client connects via HTTPS to the Ingress host?

Accepted Answer

TLS handshake succeeds but the client receives a warning about the expired certificate. When a client connects via HTTPS to an Ingress host with an expired TLS certificate, the Ingress controller (e.g., NGINX) still terminates the TLS handshake successfully because TLS termination does not validate certificate expiration at the server side. The expired certificate is presented to the client, and the client's browser or tool (e.g., curl) will show a warning about the expired certificate but the connection proceeds unless the client is configured to reject expired certificates. The Ingress controller does not enforce certificate validity; it only serves the configured secret.

Answer

The Ingress controller returns an error and refuses to terminate TLS

Answer

The Ingress controller automatically renews the certificate

Answer

The secret is ignored and HTTP is used instead

Question 3

Which kube-proxy mode uses iptables rules to handle service traffic and is the default in many distributions?

Accepted Answer

iptables. The iptables mode is the default kube-proxy mode in many Kubernetes distributions, including kubeadm-based clusters. In this mode, kube-proxy watches the Kubernetes API server for Service and Endpoint changes and programs iptables rules in the kernel's netfilter framework to direct traffic to the appropriate backend Pods, providing efficient NAT-based load balancing without requiring a userspace proxy.

Answer

userspace

Answer

ipvs

Answer

nftables

Question 4

A NetworkPolicy named 'default-deny-ingress' is applied to all pods in a namespace. The policy has no rules. An administrator then creates a new NetworkPolicy that allows ingress traffic to pods with label 'app: web' from any source using a podSelector with '{}'. Will traffic be allowed to pods labeled 'app: web'?

Accepted Answer

Yes, because the new policy allows traffic to pods with label 'app: web'. A NetworkPolicy with a podSelector of '{}' selects all pods in the namespace, and the 'from' section with an empty podSelector (or no 'from' selector at all) allows traffic from any source. When multiple NetworkPolicies are applied, they are additive: if any policy allows the traffic, it is allowed, overriding a default-deny policy that has no rules. Thus, the new policy explicitly permits ingress to pods with label 'app: web', so traffic to those pods is allowed.

Answer

No, because the new policy's empty podSelector selects all pods but does not specify a source

Answer

Yes, because the default-deny policy is ignored when a new policy exists

Answer

No, because the default-deny policy takes precedence

Question 5

You want to expose a Deployment named 'web' on port 80 internally within the cluster. Which command creates a ClusterIP Service?

Accepted Answer

kubectl expose deployment web --port=80 --type=ClusterIP. `kubectl expose deployment web --port=80 --type=ClusterIP` creates a ClusterIP Service that exposes the Deployment named 'web' on port 80 internally within the cluster. The `--type=ClusterIP` is the default service type, making this command explicitly create a ClusterIP Service, which is only reachable from inside the Kubernetes cluster.

Answer

kubectl create deployment web --image=nginx --port=80

Answer

kubectl run web --image=nginx --port=80

Answer

kubectl create service clusterip web --tcp=80:80

Question 6

Which resource is used to configure TLS termination and path-based routing for HTTP(S) traffic into a cluster?

Accepted Answer

Ingress. An Ingress resource provides HTTP and HTTPS routing to services within a Kubernetes cluster, enabling TLS termination and path-based routing. It acts as a layer 7 load balancer, directing external traffic to the appropriate backend Service based on hostnames and paths defined in its rules.

Answer

Service

Answer

NetworkPolicy

Answer

Gateway

Question 7

Which TWO statements about EndpointSlices are true? (Choose 2)

Accepted Answer

EndpointSlices are automatically created and managed by the EndpointSlice controller. Option B is correct because the EndpointSlice controller in the Kubernetes control plane (kube-controller-manager) automatically creates and manages EndpointSlice objects for Services that have selectors, keeping them in sync with the matching Pods. Option D is correct because EndpointSlices natively support dual-stack networking by including an addressType field (IPv4, IPv6, or FQDN) and can represent endpoints of both IP families for a Service. Option A is wrong because EndpointSlices back Services of any type that use selectors, including ClusterIP, NodePort, and LoadBalancer, not just ClusterIP. Option C is wrong because EndpointSlices were introduced as an alpha feature in Kubernetes 1.16 and became GA in 1.21; older versions still rely solely on Endpoints, so they do not replace Endpoints in all versions. Option E is wrong because the default maximum is 100 endpoints per EndpointSlice, but this is a configurable limit (via --max-endpoints-per-slice on the controller manager), so stating a fixed cap of 100 as an absolute truth is inaccurate.

Answer

EndpointSlices are only used for Services of type ClusterIP

Answer

EndpointSlices replace Endpoints in all Kubernetes versions

Answer

EndpointSlices can contain up to 100 endpoints each

Question 8

Which FOUR are correct ways to configure a default deny all ingress traffic NetworkPolicy? (Choose 4)

Accepted Answer

A NetworkPolicy with podSelector: {} and an ingress rule with from: []. Option C is correct because `podSelector: {}` selects all pods in the namespace and `ingress: []` defines an empty ingress rule set, which denies all ingress traffic to those pods. Option D is correct because a NetworkPolicy with `podSelector: {}` and no rules at all (only metadata and spec) has no ingress rules, so it isolates all selected pods and denies all ingress by default. Option E is correct because omitting the `ingress` field entirely is equivalent to having an empty ingress rule set, which denies all ingress traffic to the selected pods. Option A is also correct: an ingress rule with `from: []` contains an empty list of sources, which matches no sources and therefore allows no ingress traffic; the presence of the rule does not permit traffic because no source matches. Option B is incorrect because `from: [{}]` contains an empty object, which matches all sources and therefore allows all ingress traffic, the opposite of deny all.

Answer

A NetworkPolicy with podSelector: {} and an ingress rule with from: [{}]

Question 9

Which TWO commands can be used to test DNS resolution for a Service named 'my-svc' in namespace 'default' from within a temporary pod? (Choose 2)

Accepted Answer

kubectl run test --image=busybox --rm -it --restart=Never -- nslookup my-svc. Option B is correct because nslookup is a DNS query tool included in busybox that resolves the Service name 'my-svc' to its ClusterIP by querying the cluster DNS (CoreDNS), directly testing DNS resolution from inside a temporary busybox pod. Option E is incorrect because the standard busybox image does not include dig; the command would fail with 'dig: not found'. To use dig, you must use an image that contains it, such as gcr.io/kubernetes-e2e-test-images/dnsutils:1.3. Options A and D are incorrect because wget and curl are HTTP clients that test connectivity to a web endpoint, not DNS resolution itself, and they would fail if the Service has no HTTP listener. Option C is incorrect because ping tests ICMP reachability, not DNS resolution, and many Service ClusterIPs do not respond to ICMP even when DNS works.

Answer

kubectl run test --image=busybox --rm -it --restart=Never -- wget my-svc

Answer

kubectl run test --image=busybox --rm -it --restart=Never -- ping my-svc

Answer

kubectl run test --image=busybox --rm -it --restart=Never -- curl my-svc

Answer

kubectl run test --image=busybox --rm -it --restart=Never -- dig my-svc

Question 10

You need to create a Service that exposes port 80 on each node's IP at a static port (30080). Which Service type should you use?

Accepted Answer

NodePort. A NodePort Service exposes the application on a static port (30080) across every node's IP address in the cluster. This is the only Service type that allows you to specify a fixed port on the node's IP, making it the correct choice for this requirement.

Answer

LoadBalancer

Answer

ClusterIP

Answer

ExternalName

Question 11

You run: kubectl expose deployment web --port=80 --target-port=8080 --type=LoadBalancer --name=web-svc. What is the effect of this command?

Accepted Answer

Creates a Service that selects pods with label 'app=web' and maps port 80 to 8080. The `kubectl expose deployment web --port=80 --target-port=8080 --type=LoadBalancer --name=web-svc` command creates a Service named 'web-svc' that automatically inherits the label selector from the 'web' deployment (typically `app=web`). It maps the Service's port 80 to the pods' container port 8080, and the `--type=LoadBalancer` sets the Service type to LoadBalancer, which provisions an external load balancer (if supported by the cluster) and also creates a NodePort and ClusterIP automatically.

Answer

Creates a Service of type ClusterIP which is later changed to LoadBalancer

Answer

Creates a Service that selects all pods in the namespace regardless of labels

Answer

Creates a Service that exposes port 8080 on the node

Question 12

You need to expose multiple HTTP services on a single IP address with path-based routing. Which resource should you use?

Accepted Answer

Ingress. Ingress is the correct resource because it provides HTTP/HTTPS layer-7 routing to multiple services based on hostnames or paths, all exposed on a single IP address. Services of type ClusterIP, NodePort, or LoadBalancer operate at layer 4 and cannot perform path-based routing. An Ingress controller (e.g., NGINX, HAProxy) implements the rules defined in the Ingress resource to direct traffic to the appropriate backend services.

Answer

Service of type ClusterIP

Answer

NetworkPolicy

Answer

Service of type NodePort

Question 13

Which of the following is the default DNS name for a Service named 'api' in namespace 'production'?

Accepted Answer

api.production.svc.cluster.local. In Kubernetes, the default DNS name for a Service follows the pattern `..svc.cluster.local`. For a Service named 'api' in namespace 'production', this resolves to `api.production.svc.cluster.local`. The `svc` subdomain is a fixed component that distinguishes Service DNS records from Pod DNS records, and `cluster.local` is the default cluster domain.

Answer

api.production.cluster.local

Answer

production.api.svc.cluster.local

Answer

api.svc.production.cluster.local

Question 14

You want to forward local port 8080 to port 80 of a pod named 'nginx-pod'. Which command should you use?

Accepted Answer

kubectl port-forward pod/nginx-pod 8080:80. `kubectl port-forward` is the Kubernetes command used to forward a local port to a port on a specific pod. The syntax `kubectl port-forward pod/nginx-pod 8080:80` correctly specifies the pod resource, the local port (8080), and the target pod port (80), enabling access to the pod's port 80 from the local machine.

Answer

kubectl proxy pod/nginx-pod 8080:80

Answer

kubectl forward pod/nginx-pod 8080 80

Answer

kubectl port-forward service/nginx-pod 8080:80

Question 15

You have a NetworkPolicy that denies all ingress traffic by default, and you want to allow traffic only from pods with label 'app: monitoring' in the same namespace. What should the policy spec look like?

Accepted Answer

ingress: - from: - podSelector: matchLabels: app: monitoring. A NetworkPolicy with an ingress rule using only a podSelector allows traffic from pods matching the specified labels within the same namespace. Since the default policy denies all ingress traffic, this rule explicitly permits traffic from pods labeled 'app: monitoring' in the same namespace, which satisfies the requirement.

Answer

ingress: - from: - ipBlock: cidr: 0.0.0.0/0

Answer

ingress: - from: - podSelector: matchLabels: app: monitoring - namespaceSelector: matchLabels: name: my-namespace

Answer

ingress: - from: - namespaceSelector: matchLabels: app: monitoring