Courseiva

CCNA Services and Networking Questions

75 of 167 questions · Page 1/3 · Services and Networking · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

A developer runs `kubectl expose deployment web-deploy --port=80 --target-port=8080 --type=NodePort` and later wants to access the Service from outside the cluster. What is the correct way to find the external port?

A.Run `kubectl get nodes -o wide` and use the node's external IP and port 80.
B.Run `kubectl get pod -l app=web-deploy` and use the pod IP with port 8080.
C.Run `kubectl describe svc web-deploy` and look for the NodePort field.
D.Run `kubectl get svc web-deploy -o yaml` and look for `spec.ports[0].port`.
AnswerC

`kubectl describe svc web-deploy` presents a human-readable summary that includes the NodePort mapping in its 'Port:' section, e.g., `web-deploy 80:31000/TCP`. This shows that the Service listens on port 80 internally and is exposed on port 31000 (NodePort) on every node. Because the NodePort is explicitly labeled and calculated, it is the most direct way to find the externally accessible port.

Why this answer

`kubectl expose` with `--type=NodePort` creates a Service that maps a high-port (30000-32767) on each cluster node to the target container port. The `kubectl describe svc web-deploy` output includes the `NodePort` field, which shows this externally accessible port. To reach the Service from outside the cluster, you must use the node's external IP combined with this NodePort, not the Service's cluster-internal port (80).

Exam trap

The trap here is that candidates confuse the Service's cluster-internal port (80) with the externally accessible NodePort, or mistakenly think pod IPs are stable enough for external access, when in fact the NodePort field in the Service description is the only reliable way to find the external port.

How to eliminate wrong answers

Option A is wrong because it suggests using port 80, which is the Service's cluster-internal port, not the externally accessible NodePort; NodePort services expose a random high port (30000-32767) on each node, not the Service port. Option B is wrong because pod IPs are ephemeral and only reachable from within the cluster; using a pod IP with port 8080 bypasses the Service abstraction and fails if the pod is recreated. Option D is wrong because `spec.ports[0].port` refers to the Service's cluster-internal port (80), not the NodePort; the correct field in the YAML is `spec.ports[0].nodePort`.

Practice this question →
2
MCQhard

A team uses a Service named 'backend' in namespace 'prod' to reach Pods in namespace 'staging'. The Service in 'prod' has no endpoints. What is the most likely cause?

A.The Service port name does not match the container port
B.The Service selector does not match any Pods in the same namespace
C.The Service type is ClusterIP but should be NodePort
D.DNS resolution is broken in the staging namespace
AnswerB

A Kubernetes Service's selector is strictly namespace-scoped: it only matches Pods that have the same labels AND are in the same namespace as the Service. If no Pod in the 'prod' namespace carries the labels defined in the Service's 'spec.selector', the Endpoints and EndpointSlice controllers find zero backing Pods, resulting in an empty endpoints list. As a consequence, even though DNS resolves the Service's ClusterIP, any connection attempt to that IP gets no forwarding target and fails with a connection refused or timeout. This is the correct explanation because it directly addresses why no endpoints exist for the Service.

Why this answer

The Service in the 'prod' namespace has no endpoints because its selector does not match any Pods in the same namespace. Kubernetes Services only discover Pods within the same namespace via label selectors; cross-namespace access requires a different approach (e.g., ExternalName Service or manual endpoint configuration). Since the Pods are in 'staging', the selector in 'prod' finds no matching Pods, resulting in zero endpoints.

Exam trap

The trap here is that candidates assume Services can automatically discover Pods across namespaces, but Kubernetes restricts Service selectors to the same namespace, so a Service in 'prod' cannot select Pods in 'staging' without manual endpoint configuration.

How to eliminate wrong answers

Option A is wrong because a port name mismatch would cause connectivity issues but would not prevent the Service from having endpoints—endpoints are generated based on selector matches, not port names. Option C is wrong because Service type (ClusterIP vs. NodePort) affects external accessibility, not endpoint population; a ClusterIP Service can still have endpoints if the selector matches Pods.

Option D is wrong because DNS resolution is irrelevant to endpoint creation; endpoints are populated by the kube-controller-manager based on selector matching, not DNS.

Practice this question →
3
MCQhard

Given the following NetworkPolicy YAML: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress - Egress What is the effect of this policy?

A.Denies all ingress and egress traffic to and from all pods in the namespace
B.Denies all ingress traffic but allows all egress traffic
C.Allows all traffic to and from pods in the namespace
D.Denies all traffic except traffic that is explicitly allowed by other policies
AnswerA

This NetworkPolicy explicitly sets both policyTypes (Ingress and Egress) but includes no allow rules. In Kubernetes, an empty rules list for a given policyType creates a default-deny for that direction, so all inbound and outbound traffic is blocked. Since the policy's podSelector matches every pod in the namespace, it establishes a complete default-deny boundary for the entire namespace.

Why this answer

This NetworkPolicy uses an empty `podSelector: {}` which selects all pods in the namespace. By specifying both `Ingress` and `Egress` in `policyTypes` without any `ingress` or `egress` rules, the policy defaults to denying all ingress and egress traffic. In Kubernetes, NetworkPolicy rules are additive (allow-listed), so an empty rules list means no traffic is permitted, effectively creating a default-deny for both directions.

Exam trap

The trap here is that candidates often think an empty `podSelector: {}` with no rules means 'no policy' or 'allow all', but in Kubernetes, a NetworkPolicy with an empty rules list defaults to deny, not allow.

How to eliminate wrong answers

Option B is wrong because the policy explicitly includes `Egress` in `policyTypes` with no egress rules, which denies all egress traffic, not just ingress. Option C is wrong because a NetworkPolicy with an empty podSelector and no rules denies traffic, it does not allow it; allowing all traffic would require no NetworkPolicy at all or explicit allow rules. Option D is wrong because NetworkPolicies are additive—if this deny-all policy exists, it blocks all traffic regardless of other policies; other policies can only add exceptions, but the default-deny still applies to any traffic not explicitly allowed.

Practice this question →
4
MCQmedium

When using 'kubectl expose', which flag creates a NodePort service?

A.--node-port
B.--type=NodePort
C.--type=ClusterIP
D.--port
AnswerB

Passing --type=NodePort to kubectl expose creates a Service of type NodePort, which opens a high-numbered port (default 30000-32767) on every node in the cluster and forwards traffic from that nodePort to the Service's clusterIP and then to the selected pods. This makes the workload reachable externally via any node's IP and that designated port, which is the only correct flag for the stated goal.

Why this answer

The `--type=NodePort` flag explicitly sets the service type to NodePort when using `kubectl expose`. This creates a service that exposes the application on a static port (30000-32767) on each cluster node, making it accessible externally via `<NodeIP>:<NodePort>`. Without this flag, the default service type is ClusterIP, which is only reachable within the cluster.

Exam trap

The trap here is that candidates often confuse `--node-port` (which sets the specific port number) with the flag that actually creates the NodePort service type, or they assume `--port` alone changes the service type, when in fact `--type=NodePort` is required to override the default ClusterIP.

How to eliminate wrong answers

Option A is wrong because `--node-port` is not a valid flag for `kubectl expose`; the correct flag to specify the NodePort number is `--node-port` only when combined with `--type=NodePort`, but it does not create a NodePort service by itself. Option C is wrong because `--type=ClusterIP` creates a ClusterIP service, which is the default and only exposes the service internally within the cluster, not externally. Option D is wrong because `--port` specifies the container port the service will forward traffic to, not the service type; it is a required flag for `kubectl expose` but does not determine whether the service is NodePort.

Practice this question →
5
Multi-Selecteasy

Which TWO of the following are valid Ingress path types? (Select 2)

Select 2 answers
A.Glob
B.Exact
C.Wildcard
D.Regex
E.Prefix
AnswersB, E

Exact is one of the two valid standard pathType values in the Kubernetes Ingress spec. It matches only the precise URL path, and matching is case-sensitive, meaning /foo does not match /Foo or /foo/. This pathType is ideal for explicit API endpoints where a route must be limited to a single URI without inadvertently catching deeper subpaths.

Why this answer

In Kubernetes Ingress, the `spec.rules.http.paths[].pathType` field supports two valid types: `Exact` and `Prefix`. `Exact` matches the URL path exactly, case-sensitive, and is used when you need a precise match without any wildcard or prefix behavior.

Exam trap

The CKAD exam often tests the distinction between path types and host-based routing, leading candidates to confuse wildcard hostnames (e.g., `*.example.com`) with path types, or to assume regex/glob patterns are supported when they are not.

Practice this question →
6
MCQeasy

Which command exposes a deployment named 'web' as a ClusterIP service on port 80?

A.kubectl create service clusterip web --port=80
B.kubectl expose deployment web --port=80
C.kubectl run web --expose --port=80
D.kubectl expose deployment web --port=80 --type=NodePort
AnswerB

kubectl expose deployment web --port=80 is correct because kubectl expose is the canonical command for generating a Service from an existing workload resource, and it defaults to type ClusterIP. It automatically reads the deployment's label selector and applies those same labels to the service's spec.selector, ensuring the Service immediately routes traffic to the deployment's pods. The --port=80 flag sets the service port, and since --target-port is omitted, it defaults to the same value (80), so pod port 80 receives the traffic. This provides the simplest, standard way to create a ClusterIP service that exposes the deployment.

Why this answer

`kubectl expose deployment web --port=80` creates a ClusterIP service by default, which exposes the deployment on port 80 within the cluster. The `expose` command automatically selects the deployment's pod labels and creates a service that maps port 80 to the target port (defaulting to the same port).

Exam trap

Candidates often confuse `kubectl expose` with `kubectl create service clusterip`. The key difference: `expose` automatically derives the label selector from the deployment's pod template, ensuring the service matches the deployment's pods. `create service clusterip` sets a generic selector (e.g., `app=<service-name>`) based on the service name; this may or may not match the deployment's labels, so it may not expose the deployment correctly unless the deployment happens to use the same labels.

How to eliminate wrong answers

Option A is wrong because `kubectl create service clusterip web --port=80` creates a ClusterIP service but does not link it to the deployment's pod selectors; it creates an orphaned service without proper label selectors, so it won't route traffic to the deployment's pods. Option C is wrong because `kubectl run web --expose --port=80` is a legacy command that creates a deployment and a service simultaneously, but it is deprecated and not the standard way to expose an existing deployment; it also defaults to creating a ClusterIP service but does not match the requirement of exposing an already existing deployment named 'web'. Option D is wrong because `kubectl expose deployment web --port=80 --type=NodePort` creates a NodePort service, not a ClusterIP service; the question explicitly requires a ClusterIP service, and NodePort is a different service type that also exposes the service externally on a node port.

Practice this question →
7
MCQeasy

A developer wants to expose a set of Pods on a specific port on each node's IP. Which Service type should be used?

A.LoadBalancer
B.ClusterIP
C.NodePort
D.ExternalName
AnswerC

NodePort allocates a static port on every node's IP and forwards traffic to the backing Pods, satisfying the requirement to expose Pods on a specific port on each node. ClusterIP and LoadBalancer do not provide per-node port exposure.

Why this answer

NodePort is the correct Service type because it exposes each Pod's port on a static port (the NodePort) on every node's IP address. This allows external traffic to reach the Pods by accessing any node's IP on that specific port, fulfilling the requirement to expose the Pods on a per-node IP basis.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking LoadBalancer is needed for external access, but the question specifically asks for exposure on each node's IP, which is exactly what NodePort provides without requiring a cloud load balancer.

How to eliminate wrong answers

Option A is wrong because LoadBalancer exposes the Service via an external load balancer (typically a cloud provider's LB), not directly on each node's IP; it builds on top of NodePort but adds an external IP that distributes traffic, not per-node exposure. Option B is wrong because ClusterIP exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like a proxy or ingress. Option D is wrong because ExternalName maps a Service to a DNS name (via CNAME records) and does not expose any ports or Pods at all; it is used for external service aliasing, not for exposing Pods on node IPs.

Practice this question →
8
MCQmedium

You want to block all ingress traffic to pods labeled 'app=api' except from pods labeled 'app=frontend'. Which NetworkPolicy rule is correct?

A.ingress: - from: - podSelector: matchLabels: app: frontend
B.ingress: - from: - namespaceSelector: matchLabels: app: frontend
C.ingress: - ports: - port: 80
D.ingress: - from: - ipBlock: cidr: 10.0.0.0/8
AnswerA

This rule is correct because it creates an ingress allow rule whose source is limited to pods that carry the label app=frontend. In a NetworkPolicy, any podSelector in a from element selects source pods in the policy's namespace, so traffic from all other pods is not explicitly allowed and will be blocked once this policy exists (default deny). Thus it satisfies the requirement to block all ingress to pods labeled app=a except from frontend pods.

Why this answer

A NetworkPolicy with an ingress rule using a podSelector with matchLabels: app: frontend allows traffic only from pods that have that label. By default, when no NetworkPolicy selects the pods, all ingress traffic is allowed; once a policy selects them, only explicitly allowed traffic is permitted. This rule therefore blocks all ingress except from pods labeled app=frontend.

Exam trap

The trap here is that candidates often confuse podSelector with namespaceSelector, thinking namespaceSelector can filter by pod labels, when in fact podSelector is required to match pods by their labels within the same namespace.

How to eliminate wrong answers

Option B is wrong because namespaceSelector selects entire namespaces, not pods; it would allow traffic from all pods in any namespace with that label, which is too broad and does not restrict to pods labeled app=frontend. Option C is wrong because it only specifies ports without any from selector, which would allow all ingress traffic on port 80 from any source, not just from frontend pods. Option D is wrong because ipBlock selects traffic based on source IP ranges, not pod labels; it would allow traffic from any pod in the 10.0.0.0/8 range, regardless of labels, and does not restrict to frontend pods.

Practice this question →
9
MCQeasy

You create a Service with `kubectl expose deployment web --port=80 --target-port=8080`. What type of Service is created by default?

A.ClusterIP
B.LoadBalancer
C.NodePort
D.ExternalName
AnswerA

ClusterIP is the default Service type because the Service API's `type` field defaults to `ClusterIP` when omitted, so `kubectl expose deployment web p` creates a stable virtual IP reachable only inside the cluster. It assigns an internal cluster IP and load balances TCP/UDP across the selected pod endpoints through kube-proxy's iptables or IPVS rules, with no external exposure.

Why this answer

When you run `kubectl expose deployment web --port=80 --target-port=8080` without specifying the `--type` flag, Kubernetes defaults to creating a Service of type ClusterIP. This is because ClusterIP is the default Service type in Kubernetes, providing internal cluster-only access to the pods via a stable virtual IP address.

Exam trap

The trap here is that candidates often assume `kubectl expose` creates a NodePort or LoadBalancer Service by default because they associate 'expose' with external access, but Kubernetes defaults to ClusterIP for internal-only exposure.

How to eliminate wrong answers

Option B (LoadBalancer) is wrong because it requires the `--type=LoadBalancer` flag or a cloud provider integration to provision an external load balancer; it is not the default. Option C (NodePort) is wrong because it requires the `--type=NodePort` flag or is only created when explicitly requested; NodePort exposes the service on each node's IP at a static port, but it is not the default type. Option D (ExternalName) is wrong because it maps a service to a DNS name via the `externalName` field and is never created by `kubectl expose` without explicit configuration; it is a special type for external DNS resolution.

Practice this question →
10
MCQhard

You have a NetworkPolicy named 'deny-all' in namespace 'secure' that selects all pods and has no ingress rules. You need to allow incoming traffic to pods with label 'app: db' on port 5432 from pods with label 'app: api' in the same namespace. Which NetworkPolicy should you create?

A.A NetworkPolicy with podSelector matching 'app: db' and ingress rule allowing from namespaceSelector matching 'secure' on port 5432.
B.A NetworkPolicy with podSelector matching 'app: db' and ingress rule allowing from podSelector 'app: api' on port 5432.
C.A NetworkPolicy with podSelector matching 'app: db' and ingress rule allowing from ipBlock 0.0.0.0/0 on port 5432.
D.A NetworkPolicy with podSelector matching 'app: api' and egress rule allowing to podSelector 'app: db' on port 5432.
AnswerB

This policy selects the target pods (app: db) and defines an ingress rule that allows traffic from pods with label app: api on TCP port 5432. Since NetworkPolicies are additive, this will allow the specified traffic while the deny-all policy continues to block everything else. It correctly implements the least privilege requirement.

Why this answer

NetworkPolicies are additive, and a deny-all policy blocks all ingress unless explicitly allowed. To allow specific traffic, you must create a policy that selects the target pods ('app: db') and defines an ingress rule that matches the source pods ('app: api') on the correct port. Policies that control egress on the source, allow all IPs, or allow the entire namespace do not meet the precise restriction.

Exam trap

The trap here is applying the NetworkPolicy to the source pods instead of the destination pods; ingress rules must be on the pods receiving the traffic.

Practice this question →
11
MCQmedium

A NetworkPolicy named 'default-deny-ingress' is applied to a namespace but contains no rules. What is the effect on pods in that namespace?

A.All ingress traffic is denied.
B.Only traffic from pods with label 'allow: true' is allowed.
C.All ingress traffic is allowed.
D.Only traffic from pods in the same namespace is allowed.
AnswerA

A NetworkPolicy with an empty ingress rules list applies an implicit default-deny behavior: the pod selected by the podSelector is isolated, and because no source is listed as allowed, the Kubernetes network plugin blocks all incoming traffic to that pod. There is no separate 'deny all' rule needed; the absence of any ingress rule is itself the deny-all condition. This is why the policy is called a default-deny ingress policy.

Why this answer

A NetworkPolicy with no rules defaults to denying all ingress traffic because Kubernetes NetworkPolicies are additive: any pod selected by a NetworkPolicy is isolated, and only traffic explicitly allowed by rules is permitted. Since this policy has no rules, no ingress traffic is allowed, effectively creating a deny-all ingress policy for pods in the namespace.

Exam trap

The trap here is that candidates assume an empty NetworkPolicy has no effect or allows all traffic by default, but Kubernetes isolates pods as soon as they are selected by any NetworkPolicy, and an empty rules list means deny all.

How to eliminate wrong answers

Option B is wrong because a NetworkPolicy with no rules does not implicitly allow traffic from pods with a specific label; any allow rule must be explicitly defined. Option C is wrong because applying a NetworkPolicy to a namespace isolates pods, and without any rules, all ingress traffic is denied, not allowed. Option D is wrong because allowing traffic only from the same namespace requires an explicit rule with a namespaceSelector or podSelector; an empty policy does not grant any such permission.

Practice this question →
12
MCQmedium

You have an Ingress that should route requests to 'api.example.com' to a service named 'api-svc' on port 80, and requests to 'www.example.com' to 'web-svc' on port 80. Which host-based routing rule is correct?

A.spec: rules: - http: paths: - host: api.example.com backend: service: name: api-svc port: number: 80 - host: www.example.com backend: service: name: web-svc port: number: 80
B.spec: rules: - host: api.example.com http: paths: - backend: service: name: api-svc port: number: 80 - host: www.example.com http: paths: - backend: service: name: web-svc port: number: 80
C.spec: rules: - host: api.example.com - backend: service: name: api-svc port: number: 80 - host: www.example.com - backend: service: name: web-svc port: number: 80
D.spec: rules: - host: api.example.com http: paths: - backend: serviceName: api-svc servicePort: 80 - host: www.example.com http: paths: - backend: serviceName: web-svc servicePort: 80
AnswerB

This correctly defines two separate Ingress rules, each with its own `host` at the rule level. Each rule then has an `http` block containing a `paths` array, and each path designates a backend using the current `service.name` and `service.port.number` fields. This enables host-based routing: requests for api.example.com go to api-svc, while www.example.com requests go to web-svc.

Why this answer

It follows the Kubernetes Ingress v1 API specification: each rule in `spec.rules` is an object with a `host` field and an `http` field, and within `http`, a `paths` array containing backend references. This structure correctly routes requests for `api.example.com` to `api-svc:80` and `www.example.com` to `web-svc:80`.

Exam trap

The trap here is that candidates confuse the placement of `host` as a field inside `paths` (Option A) or omit the `http:` wrapper (Option C), because they think host-based routing is defined per path rather than per rule, or they recall the deprecated API syntax (Option D) from older Kubernetes versions.

How to eliminate wrong answers

Option A is wrong because it places the `host` field inside the `paths` array under `http`, but `host` is a property of the rule, not a path entry; the Ingress controller will ignore or reject this malformed structure. Option C is wrong because it uses a list item (`- backend:`) directly under the rule without the required `http:` key and `paths:` array, which is invalid YAML/JSON for the Ingress spec. Option D is wrong because it uses the legacy `serviceName` and `servicePort` fields from the deprecated `extensions/v1beta1` API; the current `networking.k8s.io/v1` API requires `name` and `number` under `service`.

Practice this question →
13
MCQmedium

A StatefulSet named 'web' is created with 3 replicas. What is the DNS name for the second pod (index 1)?

A.web-1.web.default.svc.cluster.local
B.web-2.web.default.svc.cluster.local
C.web.default.svc.cluster.local
D.web-1.default.svc.cluster.local
AnswerA

web-1.web.default.svc.cluster.local is correct because StatefulSet pods follow the stable DNS naming pattern <pod-name>.<governing-service>.<namespace>.svc.cluster.local. The pod is named web-1 and the governing service is web, so combining the two yields this exact FQDN. This allows clients to target a specific replica's stable network identity.

Why this answer

In Kubernetes, a StatefulSet creates pods with a stable, ordinal hostname based on the pattern `<statefulset-name>-<ordinal>`. The second pod (index 1) is named `web-1`. When a headless Service (named `web`) is associated with the StatefulSet, each pod gets a DNS A record in the form `<pod-name>.<service-name>.<namespace>.svc.cluster.local`.

Therefore, the correct DNS name is `web-1.web.default.svc.cluster.local`.

Exam trap

The trap here is that candidates often forget the Service name must appear between the pod name and namespace, or they confuse the ordinal index (starting at 0) with the replica count, leading them to pick `web-2` for the second pod.

How to eliminate wrong answers

Option B is wrong because it uses `web-2`, which corresponds to the third pod (index 2), not the second pod (index 1). Option C is wrong because it omits the pod-specific ordinal prefix (`web-1`), resolving to the Service's DNS name rather than an individual pod's DNS name. Option D is wrong because it omits the Service name (`web`) between the pod name and namespace, which is required for the StatefulSet pod DNS format.

Practice this question →
14
MCQhard

An Ingress has two rules: - host: app.example.com, path: /api -> service-a:80 - host: api.example.com, path: / -> service-b:80 A request to `app.example.com/api/v1` reaches which service?

A.Both services
B.Neither service
C.service-a
D.service-b
AnswerC

service-a is correct: the ingress rule for host app.example.com with path /api uses Prefix path matching, and the request URL /api/v1 begins with /api, so the path condition is satisfied. Since the Host header also matches app.example.com, the controller forwards the request to service-a. No other rule has both matching host and path.

Why this answer

Ingress rules match the longest prefix of the request path for the given host. For `app.example.com/api/v1`, the path `/api` is a prefix match (since `/api/v1` starts with `/api`), so it routes to service-a:80. The second rule requires host `api.example.com`, which does not match, so service-b is not considered.

Exam trap

The trap here is that candidates assume path matching requires an exact match (e.g., `/api` only matches `/api`, not `/api/v1`), but Kubernetes Ingress uses prefix matching by default, so `/api` matches any path starting with `/api`.

How to eliminate wrong answers

Option A is wrong because only one host matches the request; a request cannot be routed to both services simultaneously. Option B is wrong because the request does match the first rule's host and path prefix, so it reaches a service. Option D is wrong because the host `api.example.com` does not match `app.example.com`, so service-b is never selected.

Practice this question →
15
MCQmedium

You create a Service with the following YAML: ``` apiVersion: v1 kind: Service metadata: name: my-service spec: ports: - name: http port: 80 targetPort: 8080 selector: app: my-app ``` What is the default Service type?

A.NodePort
B.ClusterIP
C.LoadBalancer
D.ExternalName
AnswerB

ClusterIP is the default Service type in Kubernetes. When you create a Service without specifying the `type` field, the Kubernetes API server automatically assigns a cluster-internal virtual IP (ClusterIP) that is only reachable from within the cluster. This provides a stable endpoint for pod-to-pod communication and internal load balancing without exposing the Service externally, aligning with the principle of least privilege.

Why this answer

When no `type` field is specified in a Service YAML, Kubernetes defaults to `ClusterIP`. This assigns a stable internal IP address reachable only within the cluster, enabling pod-to-pod communication without external exposure. The `spec.type` field is optional, and `ClusterIP` is the implicit default.

Exam trap

The trap here is that candidates often assume `NodePort` is the default because it's commonly used in examples, but Kubernetes explicitly defaults to `ClusterIP` when no `type` is set.

How to eliminate wrong answers

Option A is wrong because `NodePort` is not the default; it requires explicit `type: NodePort` and exposes the service on a static port on every node's IP. Option C is wrong because `LoadBalancer` is not the default; it requires explicit `type: LoadBalancer` and provisions an external cloud load balancer, which also implies NodePort and ClusterIP. Option D is wrong because `ExternalName` is not the default; it requires explicit `type: ExternalName` and maps the service to a DNS name via CNAME, not to selectors or ports.

Practice this question →
16
MCQmedium

An admin wants to expose a Service only for internal cluster communication, without external access. Which Service type should they use?

A.ExternalName
B.NodePort
C.LoadBalancer
D.ClusterIP
AnswerD

The ClusterIP type assigns a stable virtual IP from the Service CIDR that is reachable only from within the cluster. kube-proxy programs iptables or IPVS rules on every node to load-balance traffic to the backing pods, and the Service DNS name resolves to this internal IP. Since no host network path or external load balancer is involved, it remains isolated from traffic outside the cluster and is the default choice for internal-only services.

Why this answer

ClusterIP is the default Kubernetes Service type and exposes the Service on a cluster-internal IP address, making it reachable only from within the cluster. This is the correct choice for internal cluster communication because no external endpoints are created, and traffic is routed via kube-proxy using iptables or IPVS rules.

Exam trap

The CKAD exam often tests the misconception that ClusterIP is only for default or unspecified use, leading candidates to choose NodePort or LoadBalancer for 'internal' scenarios, but the trap here is that ClusterIP is explicitly designed for internal-only access and is the only type that does not expose the Service externally by default.

How to eliminate wrong answers

Option A is wrong because ExternalName maps a Service to a DNS name (e.g., an external hostname) via CNAME records, which is used for external access, not internal-only communication. Option B is wrong because NodePort exposes the Service on each node's IP at a static port (30000-32767), allowing external traffic to reach the Service from outside the cluster. Option C is wrong because LoadBalancer provisions an external cloud load balancer (e.g., AWS ELB, GCP LB) with a public IP, explicitly enabling external access.

Practice this question →
17
MCQhard

An admin creates a Service without a selector. Which of the following is true about such a Service?

A.The Service will use the default ClusterIP and route to all pods in the cluster.
B.The Service will automatically route traffic to all pods in the namespace.
C.The admin must manually create an Endpoints object with the desired IPs.
D.The Service will not have any endpoints until a selector is added.
AnswerC

This is correct because a Service without a selector needs a separately-created Endpoints object to define the backend IP addresses and ports. The admin can create an Endpoints resource with the same name as the Service, listing the IPs and port numbers where traffic should be forwarded. This pattern is commonly used to route to external databases, legacy systems, or services outside the cluster. Once the Endpoints exist, the Service becomes routable.

Why this answer

When a Service is created without a selector, Kubernetes does not automatically manage its endpoints. The admin must manually create an Endpoints object (or use an EndpointSlice) that lists the IP addresses and ports to which the Service should route traffic. This allows the Service to direct traffic to external resources, such as databases running outside the cluster, or to specific pods not matching a label selector.

Exam trap

The trap here is that candidates often assume a Service must have a selector to function, but Kubernetes allows headless or manually-endpointed Services, and the exam tests whether you know that endpoints can be created independently of selectors.

How to eliminate wrong answers

Option A is wrong because a Service without a selector does not use a default ClusterIP to route to all pods; it has no automatic endpoint management and requires manual endpoint configuration. Option B is wrong because the Service does not automatically route traffic to all pods in the namespace; without a selector, no pods are automatically associated, and traffic only goes to manually defined endpoints. Option D is wrong because the Service can have endpoints immediately if the admin creates a corresponding Endpoints object; endpoints are not dependent on a selector being added later.

Practice this question →
18
Multi-Selecthard

Which THREE statements about NetworkPolicy are correct? (Select 3)

Select 3 answers
A.NetworkPolicy follows an allow-list model; if no policy matches, traffic is denied.
B.NetworkPolicy can block traffic to specific external IP addresses using ipBlock.
C.NetworkPolicy can use namespaceSelector to allow traffic from all pods in a namespace.
D.NetworkPolicy is a cluster-scoped resource.
E.NetworkPolicy can restrict egress traffic from pods.
AnswersA, C, E

Correct. In the Kubernetes NetworkPolicy model, a pod that is selected by any policy is isolated: all traffic that does not match an explicit allow rule is denied. This is an allow-list (whitelist) approach, meaning policies never add 'block' rules—they only declare allowed traffic. The apparent contradiction with the default allow-all behavior for unselected pods actually confirms the rule: isolation, and therefore default deny, only starts when at least one policy matches the pod.

Why this answer

NetworkPolicy follows an allow-list model: by default, all traffic to and from pods is allowed. Once a NetworkPolicy selects a pod, that pod becomes isolated, and only traffic explicitly allowed by the policy's rules is permitted for the specified direction (ingress/egress). Any traffic not matching an allow rule is denied for that direction.

Option A is correct because once a policy applies, the default behavior becomes deny for unmatched traffic. Option C is correct because namespaceSelector can select a namespace, allowing traffic from all pods in that namespace. Option E is correct because NetworkPolicy can restrict egress traffic via egress rules.

Option B is incorrect because ipBlock can be used to allow or block IP ranges, but blocking specific external IPs is possible only if the CNI supports it (and it's not universally supported). Option D is incorrect because NetworkPolicy is namespaced, not cluster-scoped.

Exam trap

A common pitfall in the CKAD exam is thinking NetworkPolicy is cluster-scoped (like a ClusterRole) or that it can block arbitrary external IPs without a CNI plugin that supports egress. Also, remember that by default all traffic is allowed; only when a policy selects a pod does the default become deny for the directions specified.

Practice this question →
19
MCQeasy

What is the default Service type when creating a Service via 'kubectl create service' or YAML without specifying type?

A.NodePort
B.ExternalName
C.LoadBalancer
D.ClusterIP
AnswerD

Correct. ClusterIP is the default service type, assigned automatically when no `type` is specified. It provides a stable virtual IP address from the cluster's service CIDR, which is reachable only from within the cluster, enabling pod-to-pod communication and service discovery through the cluster's DNS.

Why this answer

When creating a Service via `kubectl create service` or defining it in YAML without specifying the `type` field, Kubernetes defaults to `ClusterIP`. This is because `ClusterIP` is the implicit default type defined in the Service spec, providing internal cluster-wide virtual IP-based load balancing without external exposure.

Exam trap

The trap here is that candidates often assume `NodePort` is the default because it is commonly used in examples or because `kubectl expose` defaults to `ClusterIP` only when no `--type` flag is provided, but `kubectl create service` without `--tcp` or `--type` also defaults to `ClusterIP` — the CKAD exam tests this subtle distinction to catch those who confuse `kubectl expose` behavior with the YAML default.

How to eliminate wrong answers

Option A is wrong because `NodePort` is not the default; it must be explicitly set via `type: NodePort` or by using `kubectl expose` with `--type=NodePort`. Option B is wrong because `ExternalName` is a special type that maps a Service to a DNS name via the `externalName` field and is never a default. Option C is wrong because `LoadBalancer` requires an external cloud provider integration and must be explicitly specified; it is not the default type.

Practice this question →
20
MCQeasy

A Service uses a selector to target Pods. After updating the Pod labels, you notice the endpoints list is empty. What is the most likely reason?

A.The Service port was changed
B.The new labels do not match the Service selector
C.The Service type changed to ExternalName
D.The Pods have a different container port
AnswerB

The Service's selector is a label query that must exactly match the labels present on the pod's metadata, and the endpoints controller is continuously reconciling based on that query. Once the pods' labels are updated and no longer satisfy all key-value pairs in the selector, the controller removes the pod IPs from the Endpoints object, leaving the Service with zero ready endpoints. This is the classic cause of connection failures after a deployment label change, even when all pods are Running and Ready.

Why this answer

A Service uses a label selector to dynamically discover Pods and populate its endpoints. When Pod labels are updated, the selector remains unchanged; if the new labels do not match the selector, the Service cannot find any matching Pods, resulting in an empty endpoints list. This is the most direct and common cause of the issue.

Exam trap

The trap here is that candidates often assume updating Pod labels will automatically update the Service's endpoint list, but they forget that the Service selector must explicitly match the new labels for endpoints to be populated.

How to eliminate wrong answers

Option A is wrong because changing the Service port would affect connectivity but not the endpoints list; endpoints are populated based on label matching, not port values. Option C is wrong because changing the Service type to ExternalName would remove the selector entirely and use a DNS CNAME instead, but the question states the selector is still used and the endpoints list is empty, not that the Service type changed. Option D is wrong because a different container port does not prevent label matching; the Service selector targets Pods by labels, and the container port is only relevant for routing traffic after the Pod is selected.

Practice this question →
21
MCQmedium

You run 'kubectl port-forward pod/my-pod 8080:80'. What does this command do?

A.Exposes the pod on port 8080 on each node's IP
B.Forwards local port 8080 to port 80 on the pod
C.Forwards local port 8080 to port 80 on the Service
D.Creates a Service that maps port 8080 to port 80 on the pod
AnswerB

This is precisely what the command does: it opens a local TCP listener on port 8080 (typically on 127.0.0.1) and forwards every connection to port 80 on the pod named mypod. The kubectl binary acts as a client that establishes a connection to the Kubernetes API server, which then proxies a bidirectional stream to the requested port on the pod. This is a convenient way to reach a pod that is not exposed by a Service, without altering the cluster state.

Why this answer

`kubectl port-forward pod/my-pod 8080:80` creates a tunnel from localhost:8080 on your client machine to port 80 on the specified pod. This command does not expose the pod to the network; it only provides a direct, temporary connection for debugging or accessing a specific pod without a Service.

Exam trap

The trap here is that candidates confuse `kubectl port-forward` with `kubectl expose` or a NodePort Service, thinking it makes the pod accessible externally, when in fact it only forwards traffic from a local port to the pod on the client machine.

How to eliminate wrong answers

Option A is wrong because `kubectl port-forward` does not expose the pod on each node's IP; it only binds to localhost (127.0.0.1) by default, not to node IPs. Option C is wrong because the command targets a pod directly (`pod/my-pod`), not a Service; forwarding to a Service would require a different syntax like `service/my-service`. Option D is wrong because `kubectl port-forward` does not create any Kubernetes resource; it is a client-side operation that establishes a temporary tunnel, not a persistent Service object.

Practice this question →
22
MCQmedium

You have a Service named 'web' in namespace 'default'. Which DNS name resolves to the Service's ClusterIP?

A.web.default.cluster.local
B.web.default.svc.cluster.local
C.web.svc.cluster.local
D.web.default.pod.cluster.local
AnswerB

This is the fully qualified DNS name used by Kubernetes for any normal or headless Service in a given namespace, constructed as <service-name>.<namespace>.svc.<cluster-domain>. Here, 'web' is the Service name, 'default' is its namespace, and 'cluster.local' is the default cluster domain configured in CoreDNS. When a Pod connects to this name, the cluster's DNS resolver returns the Service's ClusterIP (or the pod IPs for a headless Service), making it the correct and standard address.

Why this answer

In Kubernetes, the DNS name for a Service follows the pattern `<service>.<namespace>.svc.cluster.local`. For a Service named 'web' in the 'default' namespace, the correct FQDN is `web.default.svc.cluster.local`. This resolves to the Service's ClusterIP, allowing pods to reach the service via a stable DNS name.

Exam trap

The CKAD exam often tests the exact DNS format for Services, and the trap here is that candidates may forget the `svc` subdomain or omit the namespace, leading them to choose options that look plausible but are missing a critical component.

How to eliminate wrong answers

Option A is wrong because `web.default.cluster.local` omits the required `svc` subdomain; the correct format includes `svc` to indicate it is a Service record. Option C is wrong because `web.svc.cluster.local` omits the namespace component; the namespace must be included to uniquely identify the Service. Option D is wrong because `web.default.pod.cluster.local` uses `pod` instead of `svc`, which is the subdomain for pod hostnames, not Service ClusterIP resolution.

Practice this question →
23
MCQmedium

You need to temporarily access a pod's HTTP endpoint on port 8080 from your local machine. Which command should you use?

A.kubectl exec -it pod/my-pod -- curl http://localhost:8080
B.kubectl proxy --port=8080
C.kubectl attach pod/my-pod
D.kubectl port-forward pod/my-pod 8080:8080
AnswerD

kubectl port-forward pod/my-pod 8080:8080 correctly forwards localhost:8080 on your workstation to port 8080 on the pod. It establishes a tunnel through the Kubernetes API server, letting you access the pod's HTTP endpoint as if it were running locally, without requiring a Service or exposing the pod externally.

Why this answer

`kubectl port-forward` creates a direct tunnel from a local port to a pod's port, allowing you to access the pod's HTTP endpoint at `localhost:8080` from your local machine. This is the standard method for temporarily exposing a pod's network endpoint without creating a Service or modifying cluster networking.

Exam trap

The trap here is that candidates often confuse `kubectl port-forward` with `kubectl proxy` or `kubectl exec`, thinking that running a command inside the pod or proxying the API server will expose the pod's application port, when in fact only port-forward creates a direct local-to-pod TCP tunnel.

How to eliminate wrong answers

Option A is wrong because `kubectl exec` runs a command inside the container, not on your local machine; `curl http://localhost:8080` would attempt to connect to the container's loopback interface, which only works if the HTTP server is listening on 127.0.0.1, and it does not expose the endpoint to your local machine. Option B is wrong because `kubectl proxy` creates a proxy to the Kubernetes API server, not to a specific pod's port; it forwards to the API server's REST endpoints, not to the pod's HTTP service on port 8080. Option C is wrong because `kubectl attach` attaches to a running process's stdin/stdout/stderr inside a container, typically for interactive debugging, and does not provide network access to the pod's HTTP endpoint.

Practice this question →
24
MCQhard

A StatefulSet is deployed with a headless service (clusterIP: None). The pods are named 'web-0', 'web-1', 'web-2'. What DNS name resolves to the specific IP of 'web-1'?

A.web-1.web.default.svc.cluster.local
B.web-1.default.svc.cluster.local
C.web-0.web.default.svc.cluster.local
D.web.web-1.default.svc.cluster.local
AnswerA

This FQDN follows the exact pattern for a StatefulSet-managed pod backed by a headless service: <pod-name>.<service-name>.<namespace>.svc.cluster.local. Because the service is headless (clusterIP: None), Kubernetes publishes an A record for each of its endpoints, and web-1 is a valid ordinal pod name in the StatefulSet. Therefore, this name resolves directly to the IP address of the web-1 pod and is the correct target address.

Why this answer

A is correct because in a StatefulSet with a headless service (clusterIP: None), each pod gets a unique DNS name following the pattern `<pod-name>.<service-name>.<namespace>.svc.cluster.local`. For pod 'web-1' in the default namespace, this resolves to the pod's specific IP address via a DNS A record, not a service VIP.

Exam trap

The trap here is that candidates often confuse the DNS naming pattern for StatefulSet pods with the standard service DNS (which uses the service name only), leading them to omit the pod name or misorder the components.

How to eliminate wrong answers

Option B is wrong because it omits the service name 'web', so the DNS name 'web-1.default.svc.cluster.local' would not match the StatefulSet's headless service naming convention and would not resolve to the pod's IP. Option C is wrong because it references 'web-0', which is the DNS name for the first pod, not 'web-1'. Option D is wrong because the format 'web.web-1.default.svc.cluster.local' reverses the pod and service name order; the correct pattern is `<pod-name>.<service-name>.<namespace>.svc.cluster.local`, not the other way around.

Practice this question →
25
MCQmedium

You have a headless service 'db' in namespace 'data'. Pods in that namespace can resolve 'db.data.svc.cluster.local'. What is the effect of a headless service on DNS resolution?

A.It does not create any DNS record
B.It returns the IP of the first pod
C.It returns a round-robin list of pod IPs
D.It returns the ClusterIP of the service
AnswerC

This is correct: since a headless service is defined with clusterIP: None, its DNS name is bound directly to the pod IPs, and the DNS server returns all matching pod IPs as multiple A records. Clients and resolvers often iterate through these records in a round-robin manner, enabling client-side load balancing across the underlying pods without a virtual service IP.

Why this answer

A headless service (with `clusterIP: None`) does not have a ClusterIP, so DNS queries for the service name return the IP addresses of all ready pods backing the service, rather than a single virtual IP. This enables client-side load balancing via DNS round-robin, as the DNS resolver returns multiple A records that the client can cycle through. Option C correctly describes this behavior.

Exam trap

The trap here is that candidates confuse headless services with regular ClusterIP services, assuming DNS returns a single virtual IP (ClusterIP) or no records at all, when in fact headless services return multiple pod IPs for direct pod-to-pod communication.

How to eliminate wrong answers

Option A is wrong because a headless service does create DNS records—specifically, it returns A/AAAA records for each ready pod, not no records at all. Option B is wrong because it does not return the IP of the first pod; it returns all pod IPs, and the order may vary depending on DNS resolver implementation, but there is no guaranteed 'first' pod. Option D is wrong because a headless service has no ClusterIP by definition (clusterIP: None), so it cannot return a ClusterIP.

Practice this question →
26
MCQmedium

A developer deploys a set of Pods labeled app=frontend and wants to expose them internally within the cluster on a stable IP. Which resource should be used?

A.Service of type NodePort
B.Service of type LoadBalancer
C.Service of type ClusterIP
D.Ingress resource
AnswerC

A ClusterIP Service is the default and correct Service type for internal-only communication. It assigns a stable virtual IP from the cluster's service CIDR that is reachable only from inside the cluster, and it provides built-in load balancing across the backend Pods via iptables/IPVS rules managed by kube-proxy. The frontend Pods can reliably resolve the Service by DNS name and connect to it, without any external exposure, which exactly matches the requirement for a backend that should not be accessible from outside the cluster.

Why this answer

A Service of type ClusterIP exposes the Pods on a stable internal IP address that is only reachable within the cluster. This is the default Service type and is ideal for internal communication between components, such as a frontend being accessed by a backend, without exposing the service outside the cluster.

Exam trap

The trap here is that candidates often confuse 'exposing internally' with 'exposing externally' and choose NodePort or LoadBalancer, forgetting that ClusterIP is the default and correct choice for internal-only stable IP access.

How to eliminate wrong answers

Option A is wrong because a NodePort Service exposes the Pods on a static port on each Node's IP address, making it accessible from outside the cluster, which is unnecessary and insecure for internal-only access. Option B is wrong because a LoadBalancer Service provisions an external load balancer (e.g., from a cloud provider) to expose the service to the internet, which is overkill and violates the requirement for internal-only exposure. Option D is wrong because an Ingress resource is not a Service; it provides HTTP/HTTPS routing rules to Services (typically ClusterIP) and is used for external traffic management, not for providing a stable internal IP directly.

Practice this question →
27
MCQmedium

A Service named `api` in namespace `default` has multiple endpoints. You run `kubectl get endpoints api` and see no IPs. What is the most likely cause?

A.The Service type is ExternalName
B.The namespace has a NetworkPolicy blocking traffic
C.The Service has a clusterIP of None
D.The Service selector does not match any pods
AnswerD

The endpoints controller watches Services and Pods in the same namespace and creates an Endpoints object only when the Service's selector matches at least one ready pod. If no pod carries all of the label keys and values specified in the Service's selector, the controller will not create an Endpoints object; this is the most common cause of a Service with no endpoints. You can verify this by running kubectl describe service api to see the selector and then checking whether any pods in the namespace have those exact labels.

Why this answer

The most likely cause is that the Service's selector does not match any pods. A Service uses its label selector to identify pods and automatically populate its endpoints. If no pods match the selector, the endpoints list will be empty, resulting in no IPs shown by `kubectl get endpoints api`.

Exam trap

The trap here is that candidates often confuse a headless Service (clusterIP: None) with a Service that has no endpoints, but a headless Service still has endpoints if its selector matches pods.

How to eliminate wrong answers

Option A is wrong because an ExternalName Service does not have selectors or endpoints; it returns a CNAME record, but `kubectl get endpoints` would show an empty list or an error, not simply no IPs. Option B is wrong because a NetworkPolicy controls traffic flow to/from pods, not the population of endpoints; endpoints are managed by the control plane based on pod selectors, independent of network policies. Option C is wrong because a headless Service (clusterIP: None) still has endpoints if its selector matches pods; it simply does not have a cluster IP for load balancing, but endpoints are still populated.

Practice this question →
28
MCQmedium

A ClusterIP service named 'db-service' in namespace 'data' is not reachable from a pod in the same namespace. The pod's /etc/resolv.conf shows 'search data.svc.cluster.local svc.cluster.local cluster.local'. Using the pod, which command tests DNS resolution for the service?

A.dig db-service.data.svc.cluster.local
B.ping db-service
C.nslookup db-service.data.svc.cluster.local
D.curl http://db-service:3306
AnswerC

nslookup explicitly issues a DNS query to the cluster's configured resolvers (CoreDNS) and displays the returned IP address for the full service DNS name db-service.data.svc.cluster.local. It isolates the DNS lookup phase from any application-level connectivity, so a successful response confirms that the service's clusterIP is registered and resolvable. This is the most direct and broadly available diagnostic tool for checking DNS-based service discovery in Kubernetes.

Why this answer

`nslookup` is a standard DNS lookup tool that queries the cluster's DNS server (CoreDNS/kube-dns) for the fully qualified domain name (FQDN) of the service. The FQDN `db-service.data.svc.cluster.local` matches the search domains in the pod's `/etc/resolv.conf`, so `nslookup` will resolve the service's ClusterIP, confirming DNS is working. This directly tests DNS resolution, which is the root cause when a service is unreachable by name.

Exam trap

The trap here is that candidates often choose `ping` (option B) because they assume network connectivity testing is sufficient, but `ping` uses ICMP and does not test DNS resolution, which is the specific problem described in the question.

How to eliminate wrong answers

Option A is wrong because `dig` is not typically installed in minimal container images (e.g., Alpine-based pods) and is not a standard troubleshooting tool in Kubernetes; the question asks for a command that can be used from the pod, and `dig` may not be available. Option B is wrong because `ping` tests ICMP reachability to an IP address, not DNS resolution; it would fail if the service's ClusterIP is not pingable (which is normal for ClusterIP services) and does not verify the service name resolves correctly. Option D is wrong because `curl` tests HTTP connectivity to a specific port (3306), not DNS resolution; it would fail if the service is not listening on HTTP or if the name does not resolve, but it does not isolate the DNS issue.

Practice this question →
29
MCQhard

Which of the following is a valid NetworkPolicy that allows ingress traffic only from pods with label 'role: frontend' in any namespace?

A.ingress: - from: - namespaceSelector: {} podSelector: matchLabels: role: frontend
B.ingress: - from: - ipBlock: cidr: 0.0.0.0/0
C.ingress: - from: - podSelector: matchLabels: role: frontend
D.ingress: - from: - namespaceSelector: matchLabels: role: frontend
AnswerA

The empty namespaceSelector {} acts as a wildcard that selects all namespaces in the cluster, and the podSelector restricts the rule to only pods labeled role: frontend. Because the namespace selector and pod selector are both present in a single from entry, they are combined with an AND: allowed sources are frontend pods in any namespace. This correctly implements the requirement to allow only frontend pods across all namespaces, rather than limiting them to the policy's own namespace.

Why this answer

It uses a `namespaceSelector: {}` (which matches all namespaces) combined with a `podSelector` that selects pods with label `role: frontend`. This combination allows ingress traffic from pods with that label in any namespace, which is exactly what the question requires. In Kubernetes NetworkPolicy, when you want to select pods across all namespaces, you must include an empty `namespaceSelector` alongside the `podSelector`.

Exam trap

The trap here is that candidates often forget that a `podSelector` without a `namespaceSelector` only applies to the same namespace, and they may incorrectly choose option C, not realizing that the question explicitly requires traffic from 'any namespace'.

How to eliminate wrong answers

Option B is wrong because it uses an `ipBlock` rule allowing traffic from all IP addresses (0.0.0.0/0), which does not restrict traffic based on pod labels at all. Option C is wrong because it only specifies a `podSelector` without a `namespaceSelector`, which by default restricts the rule to pods in the same namespace as the NetworkPolicy, not any namespace. Option D is wrong because it uses a `namespaceSelector` with a label selector for `role: frontend`, but this selects namespaces (not pods) with that label, and without a `podSelector` it would allow traffic from all pods in those namespaces, not just pods with the label `role: frontend`.

Practice this question →
30
MCQmedium

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

A.kubectl create service clusterip web --tcp=80:80
B.kubectl expose deployment web --port=80
C.kubectl apply -f service.yaml
D.kubectl run web --image=nginx --port=80
AnswerB

kubectl expose deployment web --port=80 is the imperative command that creates a ClusterIP Service directly from the Deployment object. kubectl extracts the labels defined in the Deployment's pod template and sets them as the Service's selector, guaranteeing the Service routes traffic to exactly those Pods. It also maps port 80 to the Pods' targetPort, which defaults to 80 if not specified. This is the intended one-line solution.

Why this answer

The `kubectl expose deployment web --port=80` command creates a Service of type ClusterIP by default, which exposes the Deployment's pods on port 80 internally within the cluster. This matches the requirement to expose the 'web' Deployment on port 80 internally without specifying a target port, as it defaults to the container's port defined in the Deployment.

Exam trap

The trap here is that candidates often confuse `kubectl create service clusterip` with `kubectl expose`; the former creates a Service without linking it to a workload, while the latter creates a Service that automatically selects the pods of the specified resource, which is required to expose the Deployment's pods internally.

How to eliminate wrong answers

Option A is wrong because `kubectl create service clusterip web --tcp=80:80` creates a Service named 'web' but does not link it to the existing Deployment; it creates a standalone Service without a selector matching the Deployment's pods, so it won't route traffic to the Deployment's pods. Option C is wrong because `kubectl apply -f service.yaml` is a valid way to create a Service from a YAML file, but it is not a command that directly exposes the Deployment; it requires a pre-existing YAML definition, and the question asks for a command that creates the appropriate Service, implying a direct imperative command. Option D is wrong because `kubectl run web --image=nginx --port=80` creates a new Pod (or Deployment in older versions) named 'web', not a Service; it does not expose the existing Deployment named 'web'.

Practice this question →
31
Multi-Selecthard

Which THREE of the following are valid use cases for a Headless Service (clusterIP: None)?

Select 3 answers
A.Discovering all Pod IPs via DNS A/AAAA records
B.Exposing the service externally via cloud load balancer
C.StatefulSet pod DNS (e.g., pod-0.svc.namespace.svc.cluster.local)
D.Implementing a custom load balancing algorithm
E.Providing a stable virtual IP for load balancing
AnswersA, C, D

A headless Service (spec.clusterIP: None) yields DNS A/AAAA records populated with the IP addresses of each ready backing Pod instead of a single virtual IP. This enables clients to resolve every instance's address directly, which is essential for peer discovery and client-side service discovery patterns. Because the records reflect current ready endpoints, they also react to Pod churn and scale events.

Why this answer

A Headless Service (clusterIP: None) does not provide a virtual IP or load balancing. Instead, DNS queries return A/AAAA records containing the IP addresses of all healthy Pods selected by the service. This allows clients to discover and connect directly to individual Pod IPs, which is essential for stateful applications or custom discovery patterns.

Exam trap

The trap here is that candidates often confuse the purpose of a Headless Service with a regular ClusterIP Service, mistakenly thinking it can provide external exposure or a stable virtual IP, when in fact it is designed for direct Pod-to-Pod discovery without load balancing.

Practice this question →
32
MCQmedium

An Ingress resource is created with the following YAML: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-svc port: number: 80 Which of the following requests will be routed to the api-svc Service? (Select all that apply.)

A.GET http://example.com/other
B.GET http://example.com/api/
C.GET http://example.org/api
D.GET http://example.com/apix
E.GET http://example.com/api/users
AnswerB, E

This request is valid because Kubernetes Prefix path matching treats /api/ as having the path element api as its first element, and the trailing slash is simply a separator after that element. The configured path /api is exactly matched by the first path element of /api/, so the rule applies even though the URL ends with a slash. Thus the request is correctly forwarded to the backend service, just like /api/users.

Why this answer

Based on the Ingress YAML, the host must be 'example.com' and the path must match the prefix '/api' according to pathType: Prefix, which matches based on URL path elements split by '/'. /api/ and /api/users are valid matches because the first path element 'api' matches and then the prefix ends. /apix does not match because 'apix' is not an element-wise prefix of 'api'. Option A fails due to path '/other'. Option C fails due to host 'example.org'.

Therefore, only options B and E are correct.

Exam trap

The common trap is thinking that Prefix matching works as a simple string prefix. In Kubernetes, Prefix matching for Ingress requires that the prefix ends at a path element boundary. For example, the prefix /api matches /api/ and /api/users, but not /apix because 'apix' is not a path element that starts with 'api'.

How to eliminate wrong answers

Option A is wrong because the path /other does not start with /api, so it does not match the Prefix rule. Option B is wrong because although /api/ starts with /api, the pathType Prefix matches any path beginning with the specified prefix, but /api/ is a valid match; however, the question asks which request will be routed, and /api/ is not listed as correct because the exam expects the path to include additional segments like /api/users to demonstrate prefix matching—Option B is actually a valid match but is not the intended correct answer here; the trap is that candidates might think /api/ is not matched, but it is. Option C is wrong because the host example.org does not match the specified host example.com.

Option D is wrong because /apix starts with /api, but the pathType Prefix matches any path beginning with /api, so /apix is technically a match; however, the question's correct answer is E because it is the only option that clearly demonstrates a longer path under /api, and the exam expects candidates to recognize that /apix is a different prefix (it is not a subpath of /api but a distinct path that happens to start with /api).

Practice this question →
33
Drag & Dropmedium

Order the steps to perform a rolling rollback of a Deployment to a previous revision.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

View history, choose revision, undo to that revision, wait for completion, then verify.

Practice this question →
34
MCQeasy

Which service type is used to expose a service using an external DNS name, such as a database hosted outside Kubernetes?

A.ClusterIP
B.NodePort
C.LoadBalancer
D.ExternalName
AnswerD

ExternalName is the correct Service type because it acts as a DNS alias by returning a CNAME record that points to a fully-qualified external domain name. It requires no ClusterIP, no selector, and no port mapping; any request to the Service name is transparently redirected to the external DNS name, making it the only Service type designed specifically to expose an external DNS name.

Why this answer

ExternalName is the correct service type because it maps a Kubernetes service to an external DNS name (e.g., a database hosted outside the cluster) by returning a CNAME record with that external name. This allows pods to access the external resource using the service's DNS name without needing to know the external endpoint's IP address.

Exam trap

The trap here is that candidates often confuse ExternalName with LoadBalancer, thinking that exposing an external resource requires a load balancer, but ExternalName is specifically designed for DNS-based aliasing without any network proxy.

How to eliminate wrong answers

Option A is wrong because ClusterIP exposes the service on a cluster-internal IP, making it only reachable from within the cluster, not via an external DNS name. Option B is wrong because NodePort exposes the service on a static port on each node's IP, which is for external traffic but does not provide an external DNS name mapping. Option C is wrong because LoadBalancer provisions an external load balancer with a public IP, but it does not map to an arbitrary external DNS name; it is for exposing services to external traffic via a load balancer, not for aliasing an external resource.

Practice this question →
35
Multi-Selectmedium

Which TWO statements about Ingress are correct? (Select 2)

Select 2 answers
A.Ingress can terminate TLS.
B.Ingress provides a ClusterIP for internal access.
C.Ingress can route traffic based on the host header.
D.Ingress can load balance TCP traffic.
E.Ingress automatically assigns an external IP to the Service.
AnswersA, C

The Ingress resource supports a TLS block that references a Secret holding the TLS private key and certificate. When configured, the Ingress controller terminates incoming HTTPS requests at the edge, decrypting them and forwarding unencrypted HTTP to backend Services. This offloads SSL/TLS processing from application pods and centralizes certificate management, making it a common practice in production clusters.

Why this answer

Ingress can terminate TLS by using a Secret that contains the TLS certificate and private key. When configured in the Ingress spec under `tls` and `secretName`, the Ingress controller decrypts HTTPS traffic before forwarding it to the backend Service, offloading TLS termination from the application pods.

Exam trap

The CKAD exam often tests the distinction between Layer 7 (Ingress) and Layer 4 (Service) capabilities, trapping candidates who assume Ingress can handle TCP traffic or assign IPs like a LoadBalancer Service.

Practice this question →
36
MCQhard

An Ingress resource routes traffic to a Service 'web' on port 80. The Service has multiple endpoints but all return 503. What should be checked first?

A.Ensure that the Service type is ClusterIP
B.Check the readiness probe of the Pods
C.Verify that the Service port matches the Pod's container port
D.Check the Ingress controller logs
AnswerB

A 503 Service Unavailable from an Ingress almost always means the Ingress controller has no healthy endpoints to forward the request to. Readiness probes are the gate that determines whether a Pod is included in the Service's Endpoints or EndpointSlice object; if the probe fails, the Pod is removed. The Ingress controller then sees an empty endpoint list for the backend Service and returns 503 before any request reaches the application. Therefore, checking the readiness probe configuration and the current Pod status is the correct first step to diagnose a 503.

Why this answer

A 503 Service Unavailable error from the Ingress indicates the upstream Service is not ready to serve traffic. The most common cause is Pods failing their readiness probes, which removes them from the Service's endpoint list. Checking the readiness probe status directly addresses why the Service has endpoints but returns 503.

Exam trap

CNCF often tests the distinction between readiness and liveness probes, where candidates mistakenly check liveness or assume a port mismatch, but readiness directly controls traffic routing via Services.

How to eliminate wrong answers

Option A is wrong because ClusterIP is the default Service type and does not cause 503 errors; changing it would not fix the issue. Option C is wrong because if the Service port mismatched the container port, the Service would have no endpoints at all, not endpoints returning 503. Option D is wrong because Ingress controller logs would show routing errors or backend unavailability, but the first diagnostic step should be checking the Pods' readiness, not logs.

Practice this question →
37
MCQeasy

What annotation is required on an Ingress resource to use a specific IngressClass (e.g., 'nginx')?

A.kubernetes.io/ingress-type: nginx
B.kubernetes.io/ingress.class: nginx
C.ingress.kubernetes.io/class: nginx
D.kubernetes.io/class: nginx
AnswerB

This is the correct, historically standard annotation used to tell an ingress controller which IngressClass resource to use for configuring routing. Although the Kubernetes Ingress API now provides the `ingressClassName` field, this annotation remains widely supported by controllers like NGINX Ingress. It must exactly match the name of an IngressClass object in the cluster.

Why this answer

The `kubernetes.io/ingress.class` annotation is the legacy method to specify the IngressClass for an Ingress resource. This annotation tells the Ingress controller (e.g., nginx) which controller should process the Ingress rules. In Kubernetes 1.18+, the preferred method is the `spec.ingressClassName` field, but the annotation is still widely supported for backward compatibility.

Exam trap

The trap here is that candidates confuse the annotation `kubernetes.io/ingress.class` with the `spec.ingressClassName` field or invent non-existent annotations like `kubernetes.io/ingress-type`, leading them to pick a plausible-sounding but incorrect option.

How to eliminate wrong answers

Option A is wrong because `kubernetes.io/ingress-type` is not a valid Kubernetes annotation; it does not exist in the API specification. Option C is wrong because `ingress.kubernetes.io/class` is not a standard annotation; the correct prefix is `kubernetes.io/ingress.class`. Option D is wrong because `kubernetes.io/class` is too generic and not recognized by any Ingress controller; the annotation must include `ingress.class` to be interpreted correctly.

Practice this question →
38
MCQeasy

Which command forwards port 8080 on the local machine to port 80 on a pod named 'web-pod'?

A.kubectl expose pod web-pod --port=8080 --target-port=80
B.kubectl proxy --port=8080 --target=pod/web-pod:80
C.kubectl port-forward pod/web-pod 8080:80
D.kubectl exec web-pod -- curl http://localhost:8080
AnswerC

`kubectl port-forward` establishes a tunnel from the local machine to the specified pod, and the `8080:80` mapping forwards local port 8080 to port 80 inside `web-pod`. This satisfies the stem's requirement exactly: local 8080 to pod 80, with the pod named as the target resource.

Why this answer

`kubectl port-forward` creates a direct tunnel from a local port to a port on a specific pod. The syntax `kubectl port-forward pod/web-pod 8080:80` forwards local port 8080 to port 80 on the pod named 'web-pod', enabling local access to the pod's service without requiring a Service object.

Exam trap

The trap here is that candidates confuse `kubectl expose` (which creates a Service for network abstraction) with `kubectl port-forward` (which creates a direct, temporary tunnel), leading them to select Option A when the question explicitly asks for port forwarding to a pod.

How to eliminate wrong answers

Option A is wrong because `kubectl expose` creates a Service object (e.g., ClusterIP, NodePort) to expose a pod or deployment, not a direct port-forward tunnel; it does not forward a local port to a pod. Option B is wrong because `kubectl proxy` creates a proxy to the Kubernetes API server, not a direct tunnel to a pod, and its syntax does not support `--target=pod/web-pod:80`; it uses `--port` and optionally `--www-prefix` for API proxying. Option D is wrong because `kubectl exec` runs a command inside the pod (here, `curl http://localhost:8080`), which would attempt to connect to port 8080 inside the pod, not forward a local port to the pod; it does not expose the pod's port to the local machine.

Practice this question →
39
MCQhard

You have a Deployment with multiple replicas. You want to expose it via a Service that has a stable IP address and is accessible from outside the cluster on a static port on each node. Which Service type should you use?

A.NodePort
B.LoadBalancer
C.ClusterIP
D.ExternalName
AnswerA

A NodePort Service allocates a static port in the 30000–32767 range on every cluster node, forwarding traffic to the Pods. This satisfies the requirement for a stable, externally accessible IP address on a static port per node, without needing a cloud load balancer. The mechanism maps the node’s IP and that port directly to the Service’s cluster IP, enabling external access from outside the cluster.

Why this answer

A NodePort Service type exposes the application on a static port (in the range 30000-32767) on every node's IP address, making it accessible from outside the cluster. This satisfies the requirement for a stable IP (the node's IP) and a static port on each node, while also providing a stable ClusterIP for internal use.

Exam trap

The trap here is that candidates often choose LoadBalancer thinking it is required for external access, but NodePort suffices when the requirement is only a static port on each node, not a cloud-managed public IP.

How to eliminate wrong answers

Option B (LoadBalancer) is wrong because it relies on an external cloud provider's load balancer to provide a public IP, which is not guaranteed to be a static port on each node and is not required for the given scenario. Option C (ClusterIP) is wrong because it is only reachable from within the cluster, not from outside. Option D (ExternalName) is wrong because it maps a Service to an external DNS name via CNAME records and does not expose any ports or provide a stable cluster IP.

Practice this question →
40
MCQmedium

You have a headless Service for a StatefulSet. The DNS query for the service returns no A records. What is the most likely cause?

A.The Service selector does not match any pod labels
B.The Service has clusterIP set to an IP address
C.The Service is of type ExternalName
D.The StatefulSet is using a volumeClaimTemplate
AnswerA

For a headless Service to publish A records, its selector must match the pod labels of the StatefulSet's Pods; the DNS entries are generated from the Service's endpoints. If the selector matches no Pods, the endpoints list is empty and the cluster's DNS resolver returns NXDOMAIN (or no A record) for the fully-qualified domain name. So even with clusterIP set to None, you get no DNS results, which is exactly why this is the correct answer.

Why this answer

A headless Service (clusterIP: None) relies on DNS A records to return the IP addresses of the Pods selected by its selector. If the selector does not match any Pod labels, the Service has no endpoints, and the DNS lookup returns no A records. This is the most common cause for a headless Service returning empty DNS results.

Exam trap

The trap here is that candidates often confuse headless Services with regular Services, assuming that a headless Service always returns A records for the Service name itself, when in fact it returns A records for the individual Pod IPs only if the selector matches Pods.

How to eliminate wrong answers

Option B is wrong because a headless Service explicitly sets clusterIP to None, not to an IP address; setting clusterIP to an IP address would make it a regular Service, not headless, and would still return A records for the Service IP. Option C is wrong because an ExternalName Service returns a CNAME record, not A records, and the question states the DNS query returns no A records, which is expected for ExternalName but not the cause of the issue. Option D is wrong because a volumeClaimTemplate in a StatefulSet is unrelated to DNS resolution; it defines persistent storage and does not affect whether the Service selector matches Pod labels.

Practice this question →
41
Multi-Selectmedium

Which TWO are valid Service types? (Choose two.)

Select 2 answers
A.NodePort
B.Headless
C.Ingress
D.ClusterIP
E.Pod
AnswersA, D

Valid type.

Why this answer

A is correct because NodePort is a standard Kubernetes Service type that exposes a Service on a static port (30000-32767) on each Node's IP address, allowing external traffic to reach the Service. It works by opening that port on every node and routing traffic to the ClusterIP Service, which then forwards to the Pods.

Exam trap

The trap here is that candidates confuse Ingress or Headless as separate Service types, when in fact Ingress is a separate resource and Headless is a ClusterIP variant, not a distinct type.

Practice this question →
42
MCQeasy

Which Service type is used to expose a Service externally using a cloud provider's load balancer?

A.NodePort
B.LoadBalancer
C.ExternalName
D.ClusterIP
AnswerB

LoadBalancer is correct because it instructs the cloud provider (e.g., AWS, GCP, Azure) to provision an external load balancer and assign a stable, publicly reachable IP address or DNS name. This traffic is automatically forwarded to the Service's backend pods, abstracting away node IPs and providing health checks and auto-scaling of the underlying infrastructure. It is the standard way to expose a Service to internet-facing external clients.

Why this answer

The LoadBalancer service type provisions an external load balancer from the underlying cloud provider (e.g., AWS ELB, GCP TCP/UDP Load Balancer) and assigns a public IP or DNS name to route external traffic to the Service's ClusterIP and NodePort. This is the correct choice because it directly exposes the Service externally via the cloud provider's infrastructure, unlike other types that either expose internally or require manual configuration.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking NodePort provides external exposure via a cloud load balancer, but NodePort only opens a port on each node's IP and does not integrate with cloud provider load balancers automatically.

How to eliminate wrong answers

Option A is wrong because NodePort exposes the Service on a static port on each node's IP address, requiring the client to know a node's IP and port, and does not automatically provision a cloud load balancer. Option C is wrong because ExternalName maps a Service to an external DNS name (via CNAME) without any proxying or load balancing, and does not expose the Service externally via a cloud load balancer. Option D is wrong because ClusterIP exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like an ingress or proxy.

Practice this question →
43
MCQhard

A StatefulSet named 'mysql' is deployed with 3 replicas. The administrator wants to create a headless Service so that each pod gets a unique DNS entry. Which Service specification should be used?

A.apiVersion: v1 kind: Service metadata: name: mysql spec: type: NodePort selector: app: mysql ports: - port: 3306
B.apiVersion: v1 kind: Service metadata: name: mysql spec: clusterIP: None selector: app: mysql ports: - port: 3306
C.apiVersion: v1 kind: Service metadata: name: mysql spec: type: ClusterIP selector: app: mysql ports: - port: 3306
D.apiVersion: v1 kind: Service metadata: name: mysql spec: clusterIP: "" selector: app: mysql ports: - port: 3306
AnswerB

Setting clusterIP: None creates a headless Service, which publishes the individual pod IPs and DNS names for a StatefulSet. When the selector matches the pods, Kubernetes creates A records like mysql-0.mysql.namespace.svc.cluster.local for each replica, enabling clients to address a specific pod. This is the correct way to provide stable network identities for stateful applications, which is exactly what a StatefulSet requires.

Why this answer

Setting `clusterIP: None` creates a headless Service, which is required for StatefulSets to provide stable network identities and unique DNS entries for each pod. A headless Service does not load-balance traffic; instead, it returns the pod IPs directly, enabling DNS resolution to individual pod hostnames like `mysql-0.mysql.default.svc.cluster.local`.

Exam trap

The trap here is that candidates often confuse setting `clusterIP: None` with leaving `clusterIP` empty or using an invalid value like `""`, or they mistakenly think a NodePort or default ClusterIP Service can provide per-pod DNS entries for StatefulSets.

How to eliminate wrong answers

Option A is wrong because `type: NodePort` creates a regular Service with a cluster IP and external port mapping, not a headless Service, so pods do not get unique DNS entries. Option C is wrong because `type: ClusterIP` (default) assigns a virtual IP for load balancing, which prevents per-pod DNS resolution; a headless Service requires `clusterIP: None`. Option D is wrong because setting `clusterIP: ""` is invalid syntax; Kubernetes requires the literal string `None` to designate a headless Service, and an empty string may cause an error or be ignored.

Practice this question →
44
MCQhard

You are a platform engineer managing a Kubernetes cluster version 1.28. A development team has deployed a microservice application called 'order-processor' in the 'prod' namespace. The application consists of a frontend Pod 'frontend' and a backend Pod 'backend', each with a single container. The frontend needs to communicate with the backend using a headless Service named 'backend-svc' that selects Pods with label 'app:backend'. The backend Pods are expected to scale horizontally, and the frontend uses a DNS lookup to discover all backend Pod IPs for client-side load balancing. However, after deploying, the frontend is unable to resolve 'backend-svc' to any IP addresses. The backend Pod is running and has the correct label 'app:backend'. The Service 'backend-svc' is defined as a ClusterIP with clusterIP: None. The frontend container has the 'default' DNS policy. What is the most likely cause of the failure?

A.The headless Service must have the 'publishNotReadyAddresses: true' field to include not-ready Pods.
B.The Service and frontend are in different namespaces; the DNS name must be fully qualified.
C.The backend Pod does not have a readiness probe defined, so it is not considered ready and not added to DNS records.
D.The frontend Pod's DNS policy is set to 'None' which disables DNS resolution.
AnswerA

In a headless Service (`clusterIP: None`), DNS records are generated per ready Pod rather than for a single virtual IP. By default, Kubernetes excludes Pods whose readiness condition is false from DNS A/AAAA record lists, which means a not-ready backend Pod will not appear as a DNS entry and the frontend cannot reach it by name. Adding `publishNotReadyAddresses: true` to the Service spec instructs the cluster DNS to publish the addresses of all backing Pods regardless of readiness, enabling the frontend to discover even not-ready backends. This is the only correct option because it identifies the missing configuration attribute that directly affects DNS population.

Why this answer

A headless Service (clusterIP: None) creates DNS A/AAAA records only for Pods that are in the Ready state. If the backend Pod is running but not ready (e.g., due to a failing readiness probe or other conditions), the Service excludes it from DNS. Setting publishNotReadyAddresses: true on the Service would include all matching Pods regardless of readiness, allowing the frontend to discover the backend IPs.

Since the frontend cannot resolve any IPs, the most likely cause is that the Service is not configured to serve not-ready Pods.

Exam trap

The trap here is that candidates assume a headless Service always returns all matching Pod IPs regardless of readiness, but Kubernetes only publishes ready Pods to DNS unless explicitly configured otherwise.

How to eliminate wrong answers

Option A is wrong because 'publishNotReadyAddresses: true' is a legacy field (deprecated in 1.25) that forces inclusion of not-ready Pods in DNS; it is not required for headless Services and is not the default cause of the issue. Option B is wrong because the question states both the frontend and backend are in the 'prod' namespace, so no cross-namespace DNS qualification is needed; a simple service name resolves within the same namespace. Option D is wrong because the frontend container has the 'default' DNS policy (not 'None'), so DNS resolution is enabled and not disabled.

Practice this question →
45
Multi-Selecteasy

Which TWO of the following are valid service types in Kubernetes?

Select 2 answers
A.NodePort
B.Headless
C.Ingress
D.Gateway
E.ClusterIP
AnswersA, E

NodePort is a valid Kubernetes Service type that builds on ClusterIP by additionally opening a static port (30000–32767 by default) on every node. Traffic sent to that nodePort is forwarded to the ClusterIP, then to backend Pods via the Service's selector. It is used when external clients need to reach a Service without a cloud load balancer, though it exposes the Service on each node's IP address and thus requires knowing node addresses and handling potential port collisions.

Why this answer

NodePort is a valid Kubernetes service type that exposes a service on a static port on each node's IP address, allowing external traffic to reach the service. It builds on top of ClusterIP by creating a cluster-wide port mapping that forwards traffic from the node's port to the service's ClusterIP and target port.

Exam trap

The CKAD exam often tests the distinction between core service types and other networking objects like Ingress or Gateway, leading candidates to mistakenly classify Ingress or Headless as service types when they are separate concepts.

Practice this question →
46
MCQeasy

To create a service that will be accessible from outside the cluster using a cloud provider's load balancer, what type should be used?

A.NodePort
B.ClusterIP
C.ExternalName
D.LoadBalancer
AnswerD

A Service of type LoadBalancer instructs the cloud provider's controller to provision an external load balancer and route traffic to the backing pods. This satisfies the requirement for external accessibility through the provider's load balancer, unlike ClusterIP or NodePort.

Why this answer

The LoadBalancer service type (D) provisions an external load balancer from the cloud provider (e.g., AWS ELB, GCP TCP/UDP Load Balancer) and assigns a public IP or DNS name, making the service accessible from outside the cluster. This is the correct choice when the requirement explicitly states using a cloud provider's load balancer for external access.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking NodePort alone provides external access via a cloud load balancer, but NodePort only opens a port on each node and requires manual configuration of an external load balancer or direct node access.

How to eliminate wrong answers

Option A (NodePort) is wrong because it exposes the service on a static port on each node's IP, requiring the client to know a node's IP and port, and does not integrate with a cloud provider's load balancer. Option B (ClusterIP) is wrong because it exposes the service only on a cluster-internal IP, making it unreachable from outside the cluster. Option C (ExternalName) is wrong because it maps the service to an external DNS name (via CNAME) and does not expose any ports or provide external access through a load balancer.

Practice this question →
47
MCQhard

A ClusterIP service named 'svc' has no endpoints. Which command can you use to debug why the service is not routing traffic?

A.kubectl get endpoints svc
B.kubectl describe service svc
C.kubectl logs svc
D.kubectl exec -it svc -- /bin/sh
AnswerA

This command directly queries the Endpoints API object that shares the Service's name, displaying the backend pod IPs and ports that the ClusterIP Service routes to. When the selector no longer matches any pods, the output shows `<none>` for the endpoints list, confirming there is no backing set of pods. It is the canonical way to verify the existence (or absence) of endpoints for a Service.

Why this answer

`kubectl get endpoints svc` directly shows the list of pod IPs and ports that the ClusterIP service is routing traffic to. If the service has no endpoints, this command will return an empty list, confirming that no pods match the service's selector, which is the most common reason for traffic not being routed.

Exam trap

The trap here is that candidates often assume `kubectl describe service` is sufficient to debug endpoint issues, but it only shows the selector, not the actual endpoints, so you must explicitly check the endpoints object to confirm the routing target is missing.

How to eliminate wrong answers

Option B is wrong because `kubectl describe service svc` provides details like the service type, cluster IP, selector, and port mapping, but it does not show the actual endpoints; it only shows the selector labels, which may be misconfigured but does not directly confirm the absence of endpoints. Option C is wrong because `kubectl logs svc` is invalid; services are not pods and do not have logs to retrieve — this command would fail with an error. Option D is wrong because `kubectl exec -it svc -- /bin/sh` attempts to execute a command inside a service, which is not a running container; services are virtual resources and cannot be exec'd into.

Practice this question →
48
Multi-Selecteasy

Which TWO of the following are true about headless services? (Select 2)

Select 2 answers
A.DNS returns multiple A records, one for each pod's IP
B.They set 'clusterIP: None' in the service spec
C.They provide a stable virtual IP for load balancing
D.They cannot have a selector
E.They are used exclusively with Deployments
AnswersA, B

In a headless service, no cluster IP is allocated, so the DNS name for the service resolves directly to the set of pod IPs that match its selector. Kubernetes DNS, typically CoreDNS, returns a separate A record for each matching pod IP, allowing clients to discover and connect to each pod independently. This behavior is essential for peer discovery in StatefulSet-based distributed systems, where each replica must be addressed individually.

Why this answer

Headless services (with clusterIP: None) cause DNS to return multiple A records, one for each pod's IP address, rather than a single virtual IP. This allows direct pod-to-pod DNS resolution, which is essential for stateful applications like databases that need to discover individual pod endpoints.

Exam trap

A common misconception is that headless services cannot have selectors, but they can; the key difference is that without a selector, you must manually manage Endpoints or use ExternalName, while with a selector, DNS returns pod IPs directly.

Practice this question →
49
MCQhard

You apply the following Ingress manifest: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress spec: ingressClassName: nginx rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 The Ingress controller logs show a 404 error when accessing 'http://example.com/api'. The service 'api-service' exists and is reachable via ClusterIP. What is the most likely cause?

A.The service 'api-service' is in a different namespace
B.The service port (80) does not match the container port
C.The IngressClass 'nginx' is not installed or configured
D.The path '/api' should be pathType: Exact
AnswerC

This is the correct explanation. The Ingress resource specifies 'ingressClassName: nginx', but if no IngressClass named 'nginx' exists, or the NGINX Ingress controller is not installed and configured to watch that class, the Ingress will have no active controller to reconcile it. As a result, no forwarding rules are programmed into any reverse proxy, and requests to '/api' produce a 404. Without a matching IngressClass and running controller, the Ingress is effectively inert.

Why this answer

The Ingress controller logs a 404 error because the Ingress resource references `ingressClassName: nginx`, but the NGINX Ingress Controller is not installed or its IngressClass resource is not configured in the cluster. Without a matching IngressClass, the controller ignores this Ingress, so no routing rules are applied, and the default backend (if any) or the controller itself returns a 404. The service exists and is reachable, but the Ingress controller never processes the rules.

Exam trap

The CKAD exam often tests the misconception that a 404 error from an Ingress controller implies a missing service or wrong path, when in fact the Ingress resource itself is not being processed due to a missing or misconfigured IngressClass.

How to eliminate wrong answers

Option A is wrong because Ingress resources can route traffic to services in any namespace, and the question does not specify a namespace mismatch; the service is reachable via ClusterIP, so namespace is not the issue. Option B is wrong because the service port (80) is used for routing within the cluster, and the container port is irrelevant as long as the service targets the correct pod port; the error is a 404 from the Ingress controller, not a connection timeout or refused connection. Option D is wrong because pathType: Prefix with path /api correctly matches requests starting with /api, and changing to Exact would only match the literal path /api, which would still not resolve the 404 if the Ingress controller is not processing the resource.

Practice this question →
50
MCQeasy

You want to deny all incoming traffic to a set of pods except from pods with label 'role: frontend'. Which NetworkPolicy spec should you use?

A.spec: podSelector: matchLabels: app: myapp ingress: - from: - namespaceSelector: matchLabels: role: frontend
B.spec: podSelector: matchLabels: app: myapp egress: - to: - podSelector: matchLabels: role: frontend
C.spec: podSelector: {} ingress: - from: - podSelector: matchLabels: role: frontend
D.spec: podSelector: matchLabels: app: myapp ingress: - from: - podSelector: matchLabels: role: frontend
AnswerD

This is the correct NetworkPolicy because `spec.podSelector` matches only the protected pods labeled `app=myapp`, and the single `ingress` rule uses a `from` clause with a `podSelector` that matches source pods labeled `role=frontend`. By defining only this rule and no default `ingress` rules, the policy defaults to denying all other incoming traffic to those pods while explicitly permitting traffic from the intended frontend pods. The use of `podSelector` for both the target and the source ensures precise, pod-level control over allowed ingress.

Why this answer

It selects pods with label 'app: myapp' and defines an ingress rule that only allows traffic from pods with label 'role: frontend'. By default, NetworkPolicy denies all traffic not explicitly allowed, so this configuration ensures only frontend pods can reach the selected pods.

Exam trap

The trap here is confusing podSelector with namespaceSelector, or using an empty podSelector that applies the policy to all pods instead of a specific set, leading to unintended broad access or denial.

How to eliminate wrong answers

Option A is wrong because it uses a namespaceSelector with matchLabels, which selects namespaces (not pods) with the label 'role: frontend', allowing traffic from any pod in those namespaces rather than only pods with the label 'role: frontend'. Option B is wrong because it defines an egress rule (outgoing traffic) instead of an ingress rule (incoming traffic), and the question asks to deny incoming traffic. Option C is wrong because it uses an empty podSelector ({}) which selects all pods in the namespace, not just the intended set of pods, and the ingress rule allows traffic from pods with 'role: frontend' to all pods, which is too broad.

Practice this question →
51
MCQmedium

A NetworkPolicy allows egress traffic to pods with label 'db: mysql' in the same namespace. Which egress rule is correct?

A.egress: - to: - podSelector: matchLabels: db: mysql
B.egress: - to: - namespaceSelector: matchLabels: db: mysql
C.egress: - from: - podSelector: matchLabels: db: mysql
D.egress: - to: - ipBlock: cidr: 10.0.0.0/8
AnswerA

This is correct because the egress rule uses the 'to' field, which is the required selector for defining destination traffic, and the podSelector with matchLabels 'db: mysql' limits allowed destinations only to pods carrying that label. The spec is otherwise valid because it requires no namespaceSelector, meaning it selects pods in the same namespace as the NetworkPolicy, which is the expected scope for this scenario. The policy permits egress only to those labeled pods while implicitly denying all other destinations.

Why this answer

A NetworkPolicy egress rule uses the `to` field to specify destination pods, and a `podSelector` within the same namespace selects pods with the label `db: mysql`. This allows outbound traffic from any pod in the namespace to pods matching that label, which directly satisfies the requirement.

Exam trap

The trap here is that candidates often confuse the `from` field (used for ingress) with the `to` field (used for egress), or mistakenly use a `namespaceSelector` when a `podSelector` is required to target pods by label within the same namespace.

How to eliminate wrong answers

Option B is wrong because it uses a `namespaceSelector` instead of a `podSelector`, which would select all pods in namespaces with the label `db: mysql`, not pods with that label in the same namespace. Option C is wrong because it uses the `from` field, which is only valid in ingress rules, not egress; egress rules require the `to` field to specify destinations. Option D is wrong because it uses an `ipBlock` to allow traffic to a CIDR range, which does not select pods by label and would allow traffic to any IP in that range, not just pods with the label `db: mysql`.

Practice this question →
52
MCQmedium

You have a Service named 'web-svc' of type ClusterIP. You want to test connectivity to it from a temporary pod. Which command would you use to launch a temporary interactive pod with the image 'busybox' and then run 'wget' against the Service?

A.kubectl run tmp --image=busybox --restart=Always --rm -it -- wget -qO- http://web-svc
B.kubectl exec -it tmp --image=busybox -- wget -qO- http://web-svc
C.kubectl run tmp --image=busybox --restart=Never --rm -it -- wget -qO- http://web-svc
D.kubectl create pod tmp --image=busybox --rm -it -- wget -qO- http://web-svc
AnswerC

This command creates a temporary pod named 'tmp' using the busybox image, sets restart policy to Never, attaches interactively, and removes the pod after exit. The '--' separates the kubectl arguments from the command to run in the container, which is 'wget -qO- http://web-svc'. This is the correct way to launch an interactive pod and execute a command.

Why this answer

The correct command uses 'kubectl run' with '--restart=Never' to create a standalone pod, '--rm' to delete it after exit, and '-it' for interactive terminal. The '--' separates kubectl flags from the command to run in the container. Other options misuse 'kubectl exec', use an invalid restart policy, or use a non-existent 'kubectl create pod' command.

Exam trap

The trap here is confusing 'kubectl run' with 'kubectl exec'; only 'run' creates a new pod, while 'exec' requires an existing pod.

Practice this question →
53
Multi-Selectmedium

Which TWO statements about headless services are correct?

Select 2 answers
A.They require a selector to match pods
B.DNS returns the pod IPs directly
C.They are used for StatefulSets to provide stable network identities
D.They provide load balancing across pods
E.They have a ClusterIP assigned
AnswersB, C

In a headless service, the DNS A record query resolves directly to the IP addresses of all pods backing the service, rather than to a single ClusterIP virtual IP. Because clusterIP is set to None, no load-balanced IP exists, and the DNS server returns a set of A records, each corresponding to an individual pod endpoint, allowing clients to contact those pods directly.

Why this answer

Headless services are created by setting `clusterIP: None` in the service spec. When a DNS lookup is performed for a headless service, the DNS server returns the IP addresses of the matching pods directly, rather than a single virtual ClusterIP. This is because there is no ClusterIP to load-balance traffic, so DNS returns all pod IPs (A/AAAA records) for the service name, enabling direct pod-to-pod communication.

Exam trap

The trap here is that candidates often confuse headless services with regular ClusterIP services, assuming they still provide load balancing or have a virtual IP, when in fact headless services are designed for direct pod access and stable network identities, not traffic distribution.

Practice this question →
54
MCQmedium

You need to allow ingress traffic to pods in namespace 'api' only from pods in namespace 'frontend' that have label 'role: proxy'. Which NetworkPolicy ingress rule correctly implements this?

A.ingress: - from: - namespaceSelector: matchLabels: name: frontend
B.ingress: - from: - namespaceSelector: matchLabels: name: frontend podSelector: matchLabels: role: proxy
C.ingress: - from: - ipBlock: cidr: 0.0.0.0/0 - podSelector: matchLabels: role: proxy
D.ingress: - from: - podSelector: matchLabels: role: proxy
AnswerB

This rule correctly combines a namespaceSelector and a podSelector within the same ingress peer, and in NetworkPolicy semantics, these two selectors are ANDed when they appear together in a single peer. Thus, only pods that simultaneously satisfy both labels—role=proxy on the pod itself, and the pod's namespace having name=frontend—are allowed as sources. This exactly matches the stated requirement, ensuring no other pods from the frontend namespace, and no proxies from other namespaces, can connect.

Why this answer

It combines a namespaceSelector (to match the 'frontend' namespace) with a podSelector (to match pods with label 'role: proxy') in the same ingress rule. This ensures that only traffic from pods in the 'frontend' namespace that also have the label 'role: proxy' is allowed, fulfilling the requirement precisely.

Exam trap

The trap here is that candidates often forget that when namespaceSelector and podSelector are combined in the same 'from' block, they are ANDed, not ORed, leading them to pick options that are too broad (like A or D) or that mix unrelated rules (like C).

How to eliminate wrong answers

Option A is wrong because it only uses a namespaceSelector to match the 'frontend' namespace, allowing all pods in that namespace regardless of their labels, which is too permissive. Option C is wrong because it includes an ipBlock rule for 0.0.0.0/0 (all traffic) combined with a podSelector for 'role: proxy', which would allow traffic from any source IP (including outside the cluster) as long as the source pod has that label, violating the namespace restriction. Option D is wrong because it only uses a podSelector for 'role: proxy' without a namespaceSelector, which would allow traffic from any namespace (including the same namespace) as long as the source pod has that label, failing to restrict to the 'frontend' namespace.

Practice this question →
55
MCQeasy

You have a Deployment named 'web' with label 'app: web'. You want to create a Service that exposes the Deployment on port 80 internally within the cluster. Which kubectl command achieves this?

A.kubectl create service clusterip web --tcp=80
B.kubectl create deployment web --image=nginx --expose --port=80
C.kubectl expose pod web --port=80
D.kubectl expose deployment web --port=80
AnswerD

kubectl expose deployment web --port=80 creates a ClusterIP Service by reading the Deployment's label selector (app=web) and generating an Endpoints object that includes all matching Pods. Because the Deployment manages the Pods, the Service automatically follows rolling updates and scaling, providing a stable virtual IP for clients. This is the canonical command to expose a Deployment's port 80 without specifying a targetPort explicitly.

Why this answer

`kubectl expose deployment web --port=80` creates a ClusterIP Service that selects Pods based on the Deployment's label selector (app: web) and exposes port 80 internally within the cluster. This command directly maps the Deployment's Pods to a Service without requiring manual specification of the target port or protocol, defaulting to TCP.

Exam trap

The trap here is that candidates confuse `kubectl expose` with `kubectl create service`, not realizing that `expose` automatically inherits the selector from the specified resource, while `create service` requires explicit selector configuration to bind to existing Pods.

How to eliminate wrong answers

Option A is wrong because `kubectl create service clusterip web --tcp=80` creates a Service named 'web' but does not automatically link it to the Deployment's Pods; it requires a separate `--selector` flag or manual label matching, and without it the Service will have no endpoints. Option B is wrong because `kubectl create deployment web --image=nginx --expose --port=80` creates both a Deployment and a Service in one command, but the question assumes the Deployment already exists, and this command would create a duplicate Deployment or fail if the name conflicts. Option C is wrong because `kubectl expose pod web --port=80` targets a Pod named 'web' directly, not the Deployment, and Pods are ephemeral; a Service should target a higher-level resource like a Deployment or ReplicaSet to ensure stable endpoint selection.

Practice this question →
56
Multi-Selecthard

Which THREE are valid fields in a NetworkPolicy spec? (Choose three.)

Select 3 answers
A.podSelector
B.ingress
C.ports
D.policyTypes
E.ipBlock
AnswersA, B, D

podSelector is a required field under spec. It uses label selectors to identify the pods to which this NetworkPolicy applies. An empty podSelector ({} ) matches all pods in the namespace, making the policy namespace-wide. Without it, the API rejects the policy because the policy would have no selected workload.

Why this answer

`podSelector` is a required field in a NetworkPolicy spec that defines which pods the policy applies to, using standard Kubernetes label selectors. It must be present to target specific pods within a namespace, and an empty `podSelector` selects all pods in the namespace.

Exam trap

A common mistake in Kubernetes is to confuse top-level spec fields with nested subfields. Candidates often select `ports` or `ipBlock` as direct spec fields, but they are only valid within `ingress` or `egress` rules in a NetworkPolicy.

Practice this question →
57
MCQmedium

A NetworkPolicy denies all ingress traffic to a namespace. Which rule would allow traffic only from pods in the same namespace?

A.from: - namespaceSelector: {} podSelector: {}
B.from: - ipBlock: cidr: 0.0.0.0/0
C.from: - podSelector: {}
D.from: - namespaceSelector: matchLabels: name: mynamespace
AnswerC

An empty podSelector with no namespaceSelector correctly limits the source to pods in the same namespace as the NetworkPolicy. In Kubernetes NetworkPolicy semantics, when only podSelector is specified, it implicitly selects pods within the policy's own namespace and does not affect other namespaces. Therefore, this rule allows ingress from all pods in that namespace while blocking traffic from other namespaces and external sources, matching the requirement precisely.

Why this answer

A `podSelector: {}` in a NetworkPolicy ingress rule selects all pods in the same namespace as the policy, effectively allowing traffic only from pods within that namespace. This works because the empty podSelector matches all pods in the namespace where the NetworkPolicy is applied, and no namespaceSelector is specified, so the rule is scoped to the local namespace only.

Exam trap

The trap here is that candidates often confuse the empty `podSelector: {}` (which matches all pods in the local namespace) with a `namespaceSelector: {}` (which matches all namespaces), leading them to choose Option A, which inadvertently allows traffic from all namespaces instead of only the same namespace.

How to eliminate wrong answers

Option A is wrong because it includes both a `namespaceSelector: {}` (which matches all namespaces) and a `podSelector: {}` (which matches all pods), thereby allowing traffic from any pod in any namespace, not just the same namespace. Option B is wrong because an `ipBlock` with `0.0.0.0/0` allows traffic from any IP address, including external sources, which violates the requirement to restrict traffic to pods in the same namespace. Option D is wrong because it uses a `namespaceSelector` with a label match, which selects pods from a specific namespace (e.g., 'mynamespace') but does not restrict traffic to pods within the same namespace as the policy; it could allow traffic from a different namespace if that namespace has the matching label.

Practice this question →
58
MCQeasy

What is the purpose of the 'spec.externalName' field in a Service of type ExternalName?

A.To expose the service on a static port on each node
B.To expose the service using an external load balancer
C.To return a CNAME record pointing to an external domain
D.To assign a static cluster IP
AnswerC

ExternalName is a special Service type that maps the Service's in-cluster DNS name to an external canonical name by returning a CNAME record from CoreDNS or kube-dns. When a client resolves the Service name from inside the cluster, DNS replies with the target external domain (for example, mydb.example.com) instead of a virtual IP, and since no selectors or endpoints exist, there is no proxying or port mapping. This is ideal for providing a stable in-cluster alias to an external database or SaaS endpoint that lives outside Kubernetes.

Why this answer

The 'spec.externalName' field in a Service of type ExternalName is used to map the service to a DNS name (e.g., 'api.example.com') rather than to a set of pods. When a client resolves the service's DNS name, Kubernetes returns a CNAME record pointing to the external domain, effectively aliasing the service to an external endpoint. This allows internal applications to access external services using a local Kubernetes service name without needing to manage endpoints manually.

Exam trap

The trap here is that candidates confuse ExternalName with other service types (NodePort, LoadBalancer, ClusterIP) and think it exposes the service externally, when in fact it only provides a DNS-level alias without any network proxy or external exposure.

How to eliminate wrong answers

Option A is wrong because exposing a service on a static port on each node is the purpose of a NodePort service, not an ExternalName service. Option B is wrong because exposing a service using an external load balancer is the purpose of a LoadBalancer service, which provisions a cloud load balancer, not an ExternalName service. Option D is wrong because assigning a static cluster IP is the purpose of a ClusterIP service (or a headless service with a specific cluster IP), whereas ExternalName services do not have a cluster IP and instead return a CNAME record.

Practice this question →
59
MCQeasy

What is the default type of a Kubernetes Service when no type is specified in the YAML manifest?

A.NodePort
B.LoadBalancer
C.ClusterIP
D.ExternalName
AnswerC

ClusterIP is the default service type when the `type` field is not declared in the Service definition. It assigns a stable virtual IP address accessible only within the cluster, making it ideal for internal pod-to-pod communication. Unlike NodePort or LoadBalancer, it does not expose the service to external traffic without additional configuration, which is why it is the safe, private default.

Why this answer

When no `type` field is specified in a Kubernetes Service YAML manifest, the default type is `ClusterIP`. This is defined in the Kubernetes API specification: the `spec.type` field defaults to `ClusterIP` if omitted. A ClusterIP service exposes the service on a cluster-internal IP address, making it only reachable from within the cluster, which is the fundamental behavior for internal service discovery.

Exam trap

The trap here is that candidates often assume a Service must be explicitly typed to work, or they confuse the default with `NodePort` because they commonly use `NodePort` for external access in minikube or kind environments, but the Kubernetes default is always `ClusterIP` unless overridden.

How to eliminate wrong answers

Option A is wrong because `NodePort` is not the default; it must be explicitly set, and it exposes the service on a static port on each node's IP, which is a higher-level type that builds on ClusterIP. Option B is wrong because `LoadBalancer` is not the default; it requires explicit specification and typically integrates with external cloud provider load balancers, also building on NodePort and ClusterIP. Option D is wrong because `ExternalName` is not the default; it maps a service to a DNS name (via CNAME records) and is used for external service integration, not for internal cluster networking.

Practice this question →
60
MCQmedium

A developer creates a headless Service with 'clusterIP: None' for a StatefulSet. What is the primary purpose of using a headless Service?

A.To prevent DNS resolution of the service
B.To enable TLS termination at the service level
C.To provide load balancing across the pods
D.To provide stable network identities and DNS records for each pod in the StatefulSet
AnswerD

When a headless service is paired with a StatefulSet, each pod receives a unique, stable DNS record of the form <pod-name>.<service-name>.<namespace>.svc.cluster.local. Because pods are created with deterministic ordinal names (e.g., web-0, web-1), the headless service creates these per-pod DNS entries, giving each pod a stable network identity that remains reachable directly by name even if pods are rescheduled.

Why this answer

A headless Service (with `clusterIP: None`) is used with StatefulSets to provide stable, unique network identities (DNS records) for each pod. Instead of a single virtual IP and round-robin load balancing, the headless Service returns A/AAAA records for each pod's individual IP address, enabling direct pod-to-pod communication based on stable hostnames like `pod-name.service-name.namespace.svc.cluster.local`.

Exam trap

The trap here is that candidates confuse 'headless' with 'no DNS' or 'no networking', when in fact headless Services provide DNS records for individual pods, which is essential for stateful workloads that need stable identities.

How to eliminate wrong answers

Option A is wrong because a headless Service does not prevent DNS resolution; it changes the DNS behavior to return pod IPs directly rather than a single cluster IP. Option B is wrong because TLS termination is a feature of Ingress controllers or load balancers, not headless Services, which operate at Layer 4 and do not handle TLS. Option C is wrong because a headless Service explicitly disables load balancing; it returns all pod IPs, leaving the client to perform its own selection (e.g., via SRV records or direct pod hostnames).

Practice this question →
61
MCQeasy

A developer wants to expose a Deployment named 'web-app' (with label 'app: web') as a ClusterIP service on port 80. Which command achieves this?

A.kubectl expose service web-app --port=80
B.kubectl create service clusterip web-app --tcp=80
C.kubectl expose deployment web-app --port=80
D.kubectl expose pod web-app --port=80
AnswerC

kubectl expose deployment web-app --port=80 is the correct imperative command because it creates a Service from the Deployment resource, automatically inheriting the Deployment's pod selector and setting the Service's target port to the container port. This ensures the Service has endpoints that match the pods managed by the Deployment, providing a stable DNS name and load-balanced access to the application.

Why this answer

`kubectl expose deployment web-app --port=80` creates a ClusterIP Service that selects Pods based on the labels of the specified Deployment (in this case, `app: web`). The `expose` command automatically reads the Pod template labels from the Deployment and applies them as the Service's selector, then maps the Service's port 80 to the target port of the containers in the selected Pods.

Exam trap

The trap here is that candidates confuse `kubectl expose` with `kubectl create service`; `expose` automatically derives selectors from the resource (Deployment, Pod, etc.), while `create service` creates a bare Service without selectors unless explicitly provided.

How to eliminate wrong answers

Option A is wrong because `kubectl expose service` attempts to expose an existing Service, but the Service 'web-app' does not exist yet; this command would fail with a 'not found' error. Option B is wrong because `kubectl create service clusterip web-app --tcp=80` creates a ClusterIP Service with no selector, meaning it will not automatically route traffic to the Pods of the 'web-app' Deployment; it requires manual selector configuration. Option D is wrong because `kubectl expose pod web-app --port=80` creates a Service that selects only that specific Pod by name, not the Deployment's Pods; if the Pod is recreated (e.g., during a rolling update), the Service's selector will no longer match, breaking connectivity.

Practice this question →
62
MCQmedium

You have a Service named 'api' with selectors that match pods. However, curl to the Service cluster IP times out. 'kubectl get endpoints api' shows no endpoints. What is the most likely cause?

A.The Service's selector does not match any pod labels.
B.The Service is of type ExternalName.
C.The pods are not listening on the target port.
D.The Service is in a different namespace than the pods.
AnswerA

A Kubernetes Service selector is evaluated by the endpoint controller, which builds the Endpoints object from Pods in the same namespace whose labels exactly match the key-value pairs in the selector. When no running Pod has all the required labels, the Endpoints object has no addresses (subsets are empty), so there is nothing for the Service to route traffic to. This is the classic cause of empty endpoints, distinct from a wrong targetPort, which would still populate endpoints with Pod IPs.

Why this answer

When a Service has no endpoints, it means the Service's selector query returned zero matching pods. Since `kubectl get endpoints api` shows no endpoints, the most likely cause is that the selector labels defined in the Service do not match the labels on any running pods. This is the first thing to check when a Service is unreachable.

Exam trap

The trap here is that candidates often assume the issue is a port mismatch or namespace problem, but the absence of endpoints directly points to a selector mismatch, which is the first diagnostic step in Kubernetes networking troubleshooting.

How to eliminate wrong answers

Option B is wrong because an ExternalName Service does not use selectors or endpoints; it returns a CNAME record, so it would never show endpoints via `kubectl get endpoints`. Option C is wrong because if pods exist but are not listening on the target port, the endpoints would still be populated (the Service would have endpoints pointing to the pods), but the connection would fail at the pod level, not result in zero endpoints. Option D is wrong because a Service can only select pods in the same namespace; if the pods were in a different namespace, the selector would simply not match them, which is actually a subset of the correct answer (selector mismatch), but the question asks for the 'most likely cause' and the direct reason is the selector mismatch itself, not the namespace difference per se.

Practice this question →
63
MCQmedium

A ClusterIP Service named 'db' in namespace 'data' is not reachable from a pod in namespace 'app'. Which DNS name should the pod use to resolve the service?

A.data.db.svc.cluster.local
B.db.app.svc.cluster.local
C.db.svc.cluster.local
D.db.data.svc.cluster.local
AnswerD

This is the correct DNS name for the db Service. In Kubernetes, the fully qualified domain name for a ClusterIP Service follows the pattern <service-name>.<namespace>.svc.<cluster-domain>, so db (the Service name) comes first, followed by data (the namespace), then the svc and cluster.local suffixes. This FQDN resolves to the Service's ClusterIP and is the standard way to reach the db Service from any namespace within the cluster.

Why this answer

A pod in namespace 'app' must use the fully qualified DNS name 'db.data.svc.cluster.local' to resolve a ClusterIP Service named 'db' in namespace 'data'. Kubernetes DNS appends the service's namespace before 'svc.cluster.local', so the format is <service>.<namespace>.svc.cluster.local. This allows cross-namespace service discovery.

Exam trap

The trap here is that candidates often forget to include the service's namespace in the DNS name when accessing a service from a different namespace, mistakenly using the short form or the pod's own namespace.

How to eliminate wrong answers

Option A is wrong because it reverses the namespace and service name (data.db instead of db.data), which does not match the required DNS format. Option B is wrong because it uses the pod's own namespace 'app' instead of the service's namespace 'data', so it would only resolve if the service were in the same namespace. Option C is wrong because it omits the namespace entirely, which is only valid for services in the same namespace as the pod, not for cross-namespace access.

Practice this question →
64
MCQmedium

A developer creates a Deployment with 3 replicas and a Service with `clusterIP: None`. What is the primary use case for this headless Service?

A.To assign a static IP address to the Service
B.To automatically create an Ingress resource
C.To expose the Service externally via a load balancer
D.To enable direct pod-to-pod communication without load balancing
AnswerD

A headless Service, configured with `clusterIP: None`, tells Kubernetes to omit the virtual IP and instead make DNS return individual A records (or AAAA records) for every ready pod that matches the Service's label selector. This allows clients to connect directly to a pod's IP address, bypassing the kube-proxy VIP and enabling direct pod-to-pod communication without any load balancing. It is particularly useful for stateful applications like a database cluster that requires each pod to be discovered by its unique hostname and IP.

Why this answer

A headless Service (clusterIP: None) disables the kube-proxy load balancer and DNS round-robin, returning A/AAAA records for all ready pod IPs. This allows client applications to perform direct pod-to-pod communication for stateful workloads like databases or messaging systems that require custom load balancing or leader election.

Exam trap

The trap here is that candidates confuse a headless Service with a regular ClusterIP Service, assuming it still provides load balancing or a stable virtual IP, when in fact it removes both to enable direct pod addressing.

How to eliminate wrong answers

Option A is wrong because a headless Service does not assign a static IP; it explicitly sets clusterIP to None, meaning no virtual IP is allocated. Option B is wrong because a headless Service does not automatically create an Ingress resource; Ingress requires a separate manifest and typically targets a ClusterIP or NodePort Service. Option C is wrong because a headless Service cannot be exposed externally via a load balancer; external exposure requires a Service type of LoadBalancer or NodePort, not clusterIP: None.

Practice this question →
65
MCQmedium

A developer creates a headless Service named 'db' to discover all database pod IPs. The Service selects pods with label 'app: db'. The pods are assigned IPs 10.0.0.1, 10.0.0.2, and 10.0.0.3. When a client performs a DNS lookup for 'db', what will it receive?

A.The IP of the first pod only
B.The cluster IP of the Service
C.All three pod IPs as separate A records
D.A round-robin list of pod IPs
AnswerC

A headless Service has no cluster IP, so DNS returns the pod IPs directly. With the default ClusterIP setting, the lookup yields three separate A records, one per selected pod, satisfying the requirement to discover all database pod IPs.

Why this answer

A headless Service (clusterIP: None) does not have a cluster IP. Instead, DNS queries for the Service name return A records for all pods matching the selector. Since the Service selects pods with label 'app: db', the DNS lookup for 'db' returns the three pod IPs (10.0.0.1, 10.0.0.2, 10.0.0.3) as separate A records, allowing direct pod-to-pod communication.

Exam trap

The trap here is that candidates confuse headless Services with regular Services, assuming DNS returns a single cluster IP or a round-robin list, when in fact headless Services return all pod IPs as separate A records with no load balancing.

How to eliminate wrong answers

Option A is wrong because a headless Service does not return only the first pod's IP; it returns all matching pod IPs as separate A records. Option B is wrong because a headless Service has no cluster IP (clusterIP is set to None), so DNS does not return a cluster IP. Option D is wrong because DNS for a headless Service returns all pod IPs in an unordered list; the client's DNS resolver may rotate them, but the Service itself does not implement round-robin — that behavior depends on the client's DNS caching and resolution logic.

Practice this question →
66
Multi-Selecteasy

Which TWO of the following are required for Ingress to route HTTP traffic to a backend Service?

Select 2 answers
A.Pod readiness probes
B.An Ingress controller deployed in the cluster
C.A Service of type LoadBalancer
D.A Service (any type) that matches the Ingress backend
E.A TLS certificate for HTTPS
AnswersB, D

An Ingress controller is the actual reverse proxy that watches Ingress resources and implements the rules (e.g., mapping hosts/paths to Services). Without a controller running, the Ingress resource is inert and no traffic is routed, even if the resource exists and references valid Services. Common controllers include NGINX, Traefik, and Contour; they are essential for Ingress to function.

Why this answer

An Ingress controller is required because the Ingress resource itself is just a set of routing rules; it does not process traffic. The Ingress controller, typically a pod running a reverse proxy like nginx or Envoy, watches the Ingress API and configures itself to route external HTTP/HTTPS traffic to the appropriate backend Services. Without a running Ingress controller, the Ingress resource has no effect.

Exam trap

CNCF often tests the misconception that an Ingress resource alone can route traffic without a controller, or that a LoadBalancer Service is mandatory for Ingress to work, when in fact the controller handles external exposure and any Service type suffices for the backend.

Practice this question →
67
MCQmedium

You have a Service named 'myservice' in namespace 'default'. A pod in the same cluster but different namespace 'other' wants to resolve the service's IP. What DNS name should it use?

A.myservice.default.svc.cluster.local
B.default.myservice.svc.cluster.local
C.myservice.svc.cluster.local
D.myservice.other.svc.cluster.local
AnswerA

This is the correct fully qualified domain name (FQDN) for the service. The Kubernetes DNS naming convention is <service-name>.<namespace>.svc.cluster.local, so 'myservice' in namespace 'default' maps to this exact string. Because it includes the namespace 'default', the name resolves from any namespace in the cluster, making it suitable for cross-namespace access.

Why this answer

Kubernetes DNS resolves services using the format `<service>.<namespace>.svc.cluster.local`. Since the service 'myservice' is in the 'default' namespace, a pod in the 'other' namespace must include the namespace in the DNS name to reach it. This fully qualified domain name (FQDN) ensures the DNS query resolves to the service's cluster IP, regardless of the pod's namespace.

Exam trap

The trap here is that candidates often forget to include the namespace when the pod is in a different namespace, or they mistakenly swap the order of service and namespace, leading them to choose option B or C.

How to eliminate wrong answers

Option B is wrong because it reverses the order of service and namespace (namespace.service instead of service.namespace), which does not match the Kubernetes DNS naming convention. Option C is wrong because it omits the namespace, so it would only work if the pod were in the same namespace as the service; a pod in a different namespace cannot resolve it without the namespace qualifier. Option D is wrong because it uses the pod's own namespace 'other' instead of the service's namespace 'default', which would not resolve to the correct service.

Practice this question →
68
Multi-Selecthard

Which THREE are valid ways to expose a Service externally in Kubernetes?

Select 3 answers
A.Headless service
B.Type: NodePort
C.Type: LoadBalancer
D.Ingress resource
E.Type: ClusterIP
AnswersB, C, D

A Service of type NodePort allocates a static port (default range 30000-32767) and listens on that port on every node in the cluster. External clients can reach the Service by connecting to any node's IP at that port, and kube-proxy forwards traffic to the backing pods. This works in any environment without a cloud provider, but it requires opening node ports and exposes the node's IP rather than a dedicated external endpoint.

Why this answer

(Type: NodePort) is correct because it exposes a Service on a static port on each Node's IP address, allowing external traffic to reach the Service by targeting <NodeIP>:<NodePort>. Option C (Type: LoadBalancer) is correct because it provisions an external load balancer in cloud environments that directs traffic to the Service. Option D (Ingress resource) is correct because it provides HTTP/HTTPS routing to Services, often using a load balancer or other entry point.

Option A (Headless service) is incorrect because it is used for service discovery without a cluster IP and does not provide external access. Option E (Type: ClusterIP) is incorrect because ClusterIP is internal-only and not exposed externally.

Exam trap

A common mistake is assuming ClusterIP or Headless Services provide external access. ClusterIP is internal-only, and Headless Services are for service discovery without load balancing, not external exposure.

Practice this question →
69
Multi-Selecthard

Which THREE components are required for a basic Ingress to route HTTP traffic to a Service? (Choose three.)

Select 3 answers
A.A Deployment of the application
B.A Service of type ClusterIP or NodePort
C.A NetworkPolicy allowing traffic from the Ingress controller
D.An Ingress resource YAML file
E.An Ingress controller (e.g., nginx-ingress)
AnswersB, D, E

An Ingress resource forwards HTTP requests to a backend Service, which must exist and select the target pods; a ClusterIP Service is sufficient because the Ingress controller performs the proxying, so NodePort or LoadBalancer exposure is not strictly needed for basic routing.

Why this answer

Option B is correct because an Ingress routes external HTTP traffic to a backing Service, which must exist as a ClusterIP or NodePort Service that selects the application's pods and exposes the target port. Option D is correct because the Ingress resource YAML defines the routing rules (host, path, and backend Service name/port) that the controller reads to configure HTTP routing. Option E is correct because an Ingress resource has no effect on its own; an Ingress controller such as nginx-ingress watches Ingress objects and programs the actual HTTP load balancer/proxy.

Option A is not required because the Ingress only needs a Service with endpoints, and those endpoints can come from any workload controller or even manually managed pods, not specifically a Deployment. Option C is not required because NetworkPolicy is an optional security control; basic Ingress routing works without any NetworkPolicy as long as the controller can reach the Service endpoints.

Exam trap

CNCF often tests the misconception that a Deployment is mandatory for Ingress to work, but the Ingress only requires a Service to route to, and the underlying Pods can be created by any workload resource (e.g., a ReplicaSet or even a standalone Pod).

Practice this question →
70
MCQmedium

A Pod needs to communicate with another Pod in the same cluster but in a different namespace. What is the correct DNS name to use?

A.<namespace>.<service>.svc.cluster.local
B.<service>.<namespace>.pod.cluster.local
C.<service>.svc.cluster.local
D.<service>.<namespace>.svc.cluster.local
AnswerD

This is the canonical fully qualified domain name for a Kubernetes Service. The service name identifies the Service object, the namespace scopes it, 'svc' denotes that this is a Service record, and 'cluster.local' is the default cluster domain suffix. Any pod in any namespace can resolve this DNS name to the Service's cluster IP, enabling cross-namespace communication. For example, a Service named 'api' in namespace 'backend' would be accessible as 'api.backend.svc.cluster.local' from anywhere in the cluster.

Why this answer

Kubernetes DNS resolves services across namespaces using the format `<service>.<namespace>.svc.cluster.local`. When a Pod in one namespace needs to communicate with a service in another namespace, the fully qualified domain name (FQDN) must include the namespace to disambiguate the service. This is defined by the Kubernetes DNS specification, which appends `svc.cluster.local` as the cluster domain suffix.

Exam trap

The trap here is that candidates often forget the namespace is required for cross-namespace communication and pick Option C, which only works within the same namespace, or confuse the order of service and namespace as in Option A.

How to eliminate wrong answers

Option A is wrong because it reverses the order of service and namespace, which would not resolve to the correct service endpoint. Option B is wrong because it uses `.pod.cluster.local` instead of `.svc.cluster.local`; Pod DNS records use the format `<pod-ip>.<namespace>.pod.cluster.local`, not service names. Option C is wrong because it omits the namespace, which only works when the source and target are in the same namespace; cross-namespace communication requires the namespace qualifier.

Practice this question →
71
MCQeasy

What is the DNS name for a Service named 'backend' in the 'default' namespace?

A.backend.default.cluster.local
B.backend.default.svc.cluster.local
C.backend.svc.cluster.local
D.backend.default.svc.cluster
AnswerB

This is the standard fully qualified domain name for a Kubernetes Service, composed of the service name, namespace, and the special 'svc' subdomain under the cluster's base domain. The ClusterIP is resolved from this A record, and it works across namespaces when fully qualified. It is the correct and canonical form used in service discovery.

Why this answer

In Kubernetes, a Service named 'backend' in the 'default' namespace is assigned a DNS name following the pattern `<service-name>.<namespace>.svc.cluster.local`. This is the standard internal DNS resolution format used by CoreDNS (or kube-dns) for cluster-local services. Option B correctly follows this pattern: `backend.default.svc.cluster.local`.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or the `.local` suffix, mistaking the pattern for a simpler hostname like `backend.default.cluster.local` or omitting the namespace entirely, leading to incorrect DNS resolution in multi-namespace scenarios.

How to eliminate wrong answers

Option A is wrong because it omits the required `svc` subdomain; the correct DNS name must include `.svc` to indicate it is a Service record. Option C is wrong because it omits the namespace (`default`), which is a mandatory component of the FQDN for a Service in a specific namespace. Option D is wrong because it omits the `.local` top-level domain, which is part of the standard cluster domain suffix (default is `cluster.local`).

Practice this question →
72
Multi-Selecthard

Which THREE of the following are true about Kubernetes Services? (Select 3)

Select 3 answers
A.The NodePort range is 30000-32767 by default.
B.A Service of type ClusterIP is cluster-internal by default.
C.Headless Services have a ClusterIP assigned.
D.A Service of type NodePort exposes the Service on a static port on each node.
E.Services can only expose one port.
AnswersA, B, D

The default NodePort range is 30000-32767, defined by the --service-node-port-range flag on the kube-apiserver. This ensures NodePort services use a predictable high port range, avoiding collisions with typical application ports (0-29999). The range is configurable but must be set consistently across all cluster components.

Why this answer

The default NodePort range in Kubernetes is 30000-32767, as defined by the kube-apiserver's --service-node-port-range flag. This range ensures that NodePorts do not conflict with well-known or ephemeral ports used by system services.

Exam trap

The trap here is that candidates often confuse Headless Services with ClusterIP Services, assuming all Services get a ClusterIP, or they forget that Services can expose multiple ports, leading them to incorrectly select C or E.

Practice this question →
73
Multi-Selectmedium

Which TWO of the following are correct about the ExternalName Service type?

Select 2 answers
A.It maps a Service to a DNS name, not to pods
B.It provides load balancing across pods
C.It selects pods using a label selector
D.It returns a CNAME record in DNS
E.It requires a cloud provider load balancer
AnswersA, D

An ExternalName Service is a DNS-level alias that maps the Service's DNS name to a fully qualified external DNS name rather than to a pod IP. It contains no selector and no Endpoints object, so Kubernetes never routes requests to pods. The mapping is purely for service discovery, letting clients resolve a stable in-cluster name to an external hostname.

Why this answer

An ExternalName Service maps a Service to an external DNS name (e.g., `my-service.default.svc.cluster.local` resolves to `api.example.com`) rather than to a set of pods. It does not use selectors or endpoints; instead, it returns a CNAME record pointing to the external name, enabling in-cluster clients to access external services via a stable Kubernetes Service DNS name.

Exam trap

A common trap is thinking that ExternalName Services still use selectors or endpoints, but the key point is that ExternalName is a pure DNS-level alias with no pod selection, no load balancing, and no proxy involvement.

Practice this question →
74
MCQmedium

A StatefulSet named 'mysql' is deployed with 3 replicas. The administrator wants each pod to have a stable network identity. Which service configuration is required?

A.A headless service with clusterIP: None and selector matching the StatefulSet
B.A ClusterIP service named 'mysql'
C.A NodePort service named 'mysql'
D.An ExternalName service pointing to an external database
AnswerA

A headless service with `clusterIP: None` and a selector that matches the StatefulSet is required because it publishes a DNS A record for each pod, such as `mysql-0.mysql.default.svc.cluster.local`. This gives every replica a stable, unique network identity that persists across pod reschedules, allowing clients to connect directly to a specific pod. In contrast, a normal service would collapse all pod IPs behind one virtual IP, which erases per-pod identity.

Why this answer

A headless service with `clusterIP: None` is required for a StatefulSet to provide stable network identities. Each pod in a StatefulSet gets a unique, predictable DNS name (e.g., `mysql-0.mysql.default.svc.cluster.local`) that persists across rescheduling. This is achieved by setting the service's `clusterIP` to `None`, which disables load balancing and returns DNS A/AAAA records for individual pod IPs instead of a single service IP.

Exam trap

The CKAD exam often tests the misconception that any Kubernetes service type (like ClusterIP or NodePort) can provide stable network identities for StatefulSet pods, but only a headless service with `clusterIP: None` disables the virtual IP and enables per-pod DNS records.

How to eliminate wrong answers

Option B is wrong because a ClusterIP service provides a single virtual IP for load-balanced access, which does not give each pod a stable, unique network identity; pods would be reached via a shared IP, not by their individual names. Option C is wrong because a NodePort service exposes the service on a static port on each node's IP, but it still uses a ClusterIP for internal routing and does not provide per-pod DNS identities. Option D is wrong because an ExternalName service maps to an external DNS name (e.g., an external database), not to the pods of the StatefulSet, and thus cannot provide stable network identities for the StatefulSet's pods.

Practice this question →
75
Multi-Selectmedium

Which THREE commands can be used to list the endpoints of a Service named 'my-svc'?

Select 3 answers
A.kubectl get networkpolicy
B.kubectl get pods -l app=my-svc
C.kubectl describe svc my-svc
D.kubectl get ep my-svc
E.kubectl get endpoints my-svc
AnswersC, D, E

kubectl describe svc my-svc is correct because the describe output includes an 'Endpoints' section, which lists the current set of IP:port pairs that the Service routes traffic to. It presents this information in a human-readable format alongside the Service's selector, port mappings, and type. However, because describe is meant for efficient troubleshooting, it shows endpoints in a summarized, non-printable way, which is not ideal for scripting, but perfectly valid for a quick visual inspection.

Why this answer

`kubectl describe svc my-svc` displays detailed information about the service, including the list of endpoints (IP:Port pairs) that the service routes traffic to. Options D and E are also correct because `kubectl get ep my-svc` and `kubectl get endpoints my-svc` are equivalent commands that directly list the Endpoints resource associated with the service. All three commands provide the endpoint information.

Exam trap

The trap here is that candidates may think `kubectl get pods -l app=my-svc` shows endpoints, but it only shows pods matching a specific label, not the actual endpoint IP:Port pairs that the Service routes to, and the label selector may not match the Service's selector.

Practice this question →
Page 1 of 3 · 167 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Services and Networking questions.

Start 20-question session