CKA Services and Networking — 20 Questions

Question 1

You run 'kubectl get svc my-service -o yaml' and see 'type: ClusterIP'. The service has no endpoints. What is the most likely cause?

Accepted Answer

No pods with labels matching the service selector are running and ready.. A Kubernetes Service of type ClusterIP relies on a label selector to identify target Pods. If no Pods match the selector and are in the Ready state, the Service will have no endpoints, causing traffic to be dropped. The absence of endpoints directly indicates a mismatch or absence of matching, ready Pods.

Answer

The service type is ClusterIP, which does not support endpoints.

Answer

The service's port does not match the container port.

Answer

The service is misconfigured and needs to be deleted and recreated.

Question 2

An administrator runs 'kubectl run nginx --image=nginx --port=80' and then 'kubectl expose pod nginx --port=80 --type=NodePort'. Later, they run 'kubectl get svc nginx' and see that the NodePort is set to 0. What is the most likely reason?

Accepted Answer

The pod was not ready when the service was created, so NodePort assignment was delayed.. By default, Kubernetes restricts NodePort allocations to the range 30000-32767. If a user specifies a nodePort outside of this range (such as 8080) in the Service manifest, the API server will reject the creation with a validation error. This range can be customized using the `--service-node-port-range` flag on the kube-apiserver.

Answer

The nodePort field was explicitly set to 0 in the service YAML, but the administrator used a flag that was ignored.

Answer

The cluster has a mutating webhook that converted the service type to ClusterIP because NodePort is disabled.

Answer

The pod was created by a Deployment, so its labels do not match the service selector.

Question 3

A cluster has a NetworkPolicy that denies all ingress traffic by default. An administrator wants to allow TCP traffic on port 8080 from pods with label 'app: web' in the same namespace. Which NetworkPolicy egress rule is needed?

Accepted Answer

An ingress rule with podSelector matching 'app: web' and ports.. To allow incoming traffic to a pod that has a default-deny ingress policy, an ingress rule must be defined on that pod's NetworkPolicy. The rule needs to specify a podSelector matching the source pods ('app: web') and the destination port (8080).

Answer

An ingress rule with namespaceSelector matching the same namespace.

Answer

An egress rule with namespaceSelector and podSelector.

Answer

An egress rule with podSelector matching 'app: web' and ports.

Question 4

What is the default DNS name for a service named 'my-svc' in namespace 'default'?

Accepted Answer

my-svc.default.svc.cluster.local. In Kubernetes, the default DNS name for a service follows the pattern `..svc.cluster.local`. For a service named 'my-svc' in the 'default' namespace, the fully qualified domain name (FQDN) is `my-svc.default.svc.cluster.local`. This is defined by the cluster DNS specification (CoreDNS or kube-dns) and allows pods to resolve the service by name within the cluster.

Answer

my-svc.default.cluster.local

Answer

my-svc.svc.cluster.local

Answer

my-svc.cluster.local

Question 5

A developer runs 'kubectl port-forward service/my-service 8080:80'. What does this command do?

Accepted Answer

It forwards incoming traffic on local port 8080 to port 80 on the service's ClusterIP.. `kubectl port-forward` creates a tunnel from a local port on the client machine to a specified port on a Kubernetes resource, in this case a Service. It forwards traffic received on localhost:8080 to the Service's ClusterIP on port 80, allowing the developer to access the service without exposing it externally.

Answer

It creates a proxy that routes traffic from the service's ClusterIP to the local machine on port 8080.

Answer

It exposes the service as a NodePort on port 8080.

Answer

It creates a new service of type LoadBalancer on port 8080.

Question 6

Which of the following commands can be used to check the endpoints of a service named 'my-service'?

Accepted Answer

kubectl get endpoints my-service. The `kubectl get endpoints my-service` command directly retrieves the Endpoints object associated with the service, which lists the IP addresses and ports of the pods that match the service's selector. This is the standard and most direct way to check the active endpoints for a service in Kubernetes.

Answer

kubectl get pod my-service

Answer

kubectl get service my-service -o yaml

Answer

kubectl get svc my-service --show-endpoints

Question 7

What is the default kube-proxy mode in Kubernetes v1.29?

Accepted Answer

iptables. In Kubernetes v1.29, the default kube-proxy mode is `iptables`. This mode uses Linux iptables rules to handle service traffic, providing better performance and reliability than the older userspace mode. It is the default because it balances simplicity and efficiency for most cluster configurations.

Answer

nftables

Answer

userspace

Answer

ipvs

Question 8

Which TWO of the following are valid ways to expose a Deployment named 'web' as a service?

Accepted Answer

kubectl expose deployment web --port=80. Valid because `kubectl expose deployment web --port=80` creates a ClusterIP Service that selects Pods with the label `app=web`, which is automatically set by `kubectl create deployment` and matches the Deployment's Pods. Option D is valid because applying a Service manifest with `selector: app: web` manually creates a Service that targets the Pods. Option E is not valid because `kubectl create service clusterip web-service --tcp=80:80` creates a Service with the selector `app: web-service` (derived from the Service name), which does not match the Deployment's Pod label (`app: web`), so it does not target the Pods. Options A and B do not create Service objects: A uses `kubectl port-forward` which only forwards ports locally, and B uses the deprecated `kubectl run --expose` which creates a standalone Pod (not a Deployment) with a temporary Service.

Answer

kubectl port-forward deployment/web 8080:80

Answer

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

Answer

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

Question 9

Which THREE of the following are requirements for an Ingress resource to work?

Accepted Answer

An Ingress controller must be deployed in the cluster.. For an Ingress resource to function and successfully route traffic:

1. **An Ingress controller must be deployed** (Option B): The Ingress resource itself is just a configuration. An Ingress controller (like ingress-nginx) is required to monitor Ingress resources and configure the data plane to route traffic.
2. **The backend services must have active endpoints** (Option D): The Ingress controller routes traffic directly to the Pod IPs (endpoints) of the backend services. If the services have no endpoints (e.g., no running pods or failing readiness probes), the Ingress controller cannot route traffic and will return an error (typically 503).
3. **The Ingress must define either a default backend or at least one routing rule** (Option E): The Kubernetes API validation requires that an Ingress spec contains either a `defaultBackend` or a list of `rules` (or both). An Ingress with neither is invalid and cannot be created.

Hosts (Option A) and TLS configuration (Option C) are optional.

Answer

The Ingress resource must specify a host.

Answer

The Ingress resource must have a TLS section.

Question 10

Which TWO of the following statements about NetworkPolicy are true?

Accepted Answer

A NetworkPolicy can have both ingress and egress rules.. A NetworkPolicy resource can define both `ingress` and `egress` rules in its spec, allowing administrators to control inbound and outbound traffic to and from selected pods. This is explicitly supported by the Kubernetes NetworkPolicy API, where each rule can specify `from` (for ingress) or `to` (for egress) selectors, along with ports and protocols.

Answer

NetworkPolicy can filter traffic based on source IP addresses.

Answer

NetworkPolicy is a cluster-scoped resource.

Answer

By default, pods are isolated and all traffic is denied.

Question 11

Which kubectl command creates a service of type NodePort that exposes a deployment named 'web' on port 80?

Accepted Answer

kubectl expose deployment web --type=NodePort --port=80. The `kubectl expose deployment web --type=NodePort --port=80` command creates a Service of type NodePort that exposes the 'web' deployment on port 80. The `--type=NodePort` flag explicitly sets the Service type to NodePort, and `--port=80` defines the port the Service listens on. By default, `kubectl expose` uses the container's target port from the deployment's pod template, so no `--target-port` is required if it matches the container port.

Answer

kubectl create service nodeport web --tcp=80:8080

Answer

kubectl expose deployment web --port=80 --target-port=8080

Answer

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

Question 12

A developer runs 'kubectl run nginx --image=nginx --expose --port=80'. What Kubernetes resources are created?

Accepted Answer

A pod named 'nginx' and a ClusterIP service named 'nginx'. The `kubectl run nginx --image=nginx --expose --port=80` command creates a pod named 'nginx' and automatically generates a ClusterIP service named 'nginx' that exposes port 80. The `--expose` flag triggers the creation of a service of type ClusterIP (the default service type) to provide stable network access to the pod.

Answer

Only a pod named 'nginx'

Answer

A pod named 'nginx' and a LoadBalancer service named 'nginx'

Answer

A deployment named 'nginx' and a NodePort service named 'nginx'

Question 13

You have a NetworkPolicy that selects pods with label 'role: db' in the 'default' namespace. The policy has no ingress rules defined. What is the effect on traffic to the selected pods?

Accepted Answer

All ingress traffic is denied. A NetworkPolicy with no ingress rules defaults to denying all ingress traffic to the selected pods. This is because Kubernetes NetworkPolicies are whitelist-based: if no ingress rules are specified, the policy implicitly denies all incoming traffic, even if other policies allow it. The selected pods with label 'role: db' will therefore receive no ingress traffic.

Answer

Only traffic from pods with label 'role: frontend' is allowed

Answer

Both ingress and egress traffic are denied

Answer

All ingress traffic is allowed

Question 14

An ingress resource is defined with the following snippet:
```yaml
spec:
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 80
```
The secret 'app-tls' exists and contains a valid certificate. However, accessing https://app.example.com returns a certificate warning in the browser. What is the most likely cause?

Accepted Answer

The TLS secret is in a different namespace than the ingress resource. The TLS secret must reside in the same namespace as the Ingress resource because the Ingress controller reads the secret from the Ingress's namespace. If the secret is in a different namespace, the controller cannot access it, causing it to fall back to its default (untrusted) certificate or fail to serve the correct certificate, which results in a browser certificate warning.

Answer

The ingress controller does not support TLS termination

Answer

The path type is Prefix but should be Exact

Answer

The secret name does not match the TLS section host

Question 15

Which of the following is a valid ClusterIP service definition that exposes port 80 and targets container port 8080?

Accepted Answer

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080. Option B is correct. In Kubernetes, if the `spec.type` field is omitted, it defaults to `ClusterIP`. Thus, Option B is a valid ClusterIP service. Option A is incorrect because `type: ClusterIP` is defined at the root level of the YAML instead of under the `spec` field, which is invalid. Option C defines a NodePort service. Option D defines a LoadBalancer service. Option E lacks a selector to target the application pods.

Answer

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
type: ClusterIP

Answer

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Answer

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: LoadBalancer

Answer

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Question 16

A pod 'my-pod' in the 'default' namespace cannot resolve the service 'db-service' in the 'production' namespace. Which DNS name should be used to reach the service from 'my-pod'?

Accepted Answer

db-service.production.svc.cluster.local. Kubernetes DNS resolves services across namespaces using the fully qualified domain name (FQDN) format `..svc.cluster.local`. Since 'my-pod' is in the 'default' namespace and 'db-service' is in the 'production' namespace, the short name 'db-service' will not resolve; the FQDN must include the namespace and the cluster domain suffix to reach the service.

Answer

db-service

Answer

db-service.production.pod.cluster.local

Answer

production.db-service.svc.cluster.local

Question 17

You apply the following NetworkPolicy:
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
```
What is the result?

Accepted Answer

All ingress and egress traffic to/from all pods in the namespace is denied. This NetworkPolicy uses an empty `podSelector: {}` which selects all pods in the namespace. By specifying both `Ingress` and `Egress` in `policyTypes` without any rules, the policy defaults to denying all ingress and egress traffic for those pods. This is the standard Kubernetes behavior: a NetworkPolicy with no rules under a given `policyTypes` entry acts as a deny-all for that direction.

Answer

All traffic is allowed because no ingress/egress rules are specified

Answer

Only ingress traffic is denied; egress traffic is allowed

Answer

The policy is invalid because podSelector is empty

Question 18

Which kube-proxy mode uses IP Virtual Server (IPVS) for load balancing and supports more algorithms than the default mode?

Accepted Answer

ipvs. The IP Virtual Server (IPVS) mode in kube-proxy leverages the Linux kernel's IPVS module, which is built on the Netfilter framework and operates in the kernel space. Unlike the default iptables mode, IPVS supports a variety of load-balancing algorithms (e.g., round-robin, least-connection, source-hashing) and provides better scalability and performance for large clusters by using a hash table for service-to-endpoint mapping.

Answer

userspace

Answer

iptables

Answer

kube-proxy

Question 19

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

Accepted Answer

kubectl port-forward pod/my-pod 8080:8080. `kubectl port-forward` creates a direct tunnel from a local port to a specific pod, allowing you to access the pod's HTTP endpoint on port 8080 from your local machine on port 8080. This command targets the pod directly (`pod/my-pod`) and maps local port 8080 to the pod's port 8080, which is exactly what the question requires for temporary, ad-hoc access without creating a Service.

Answer

kubectl expose pod my-pod --port=8080

Answer

kubectl proxy --port=8080

Answer

kubectl port-forward service/my-service 8080:8080

Question 20

An Ingress resource uses 'networking.k8s.io/v1' API. Which field specifies the hostname and path rules for routing traffic?

Accepted Answer

spec.rules. In the 'networking.k8s.io/v1' Ingress API, the 'spec.rules' field is where you define an array of routing rules, each containing a 'host' field for the hostname and an 'http' subfield with 'paths' that specify path-based routing to backend services. This is the primary mechanism for directing traffic based on hostname and path.

Answer

spec.ingress

Answer

spec.tls

Answer

spec.backend