CKAD Services and Networking Practice Test 2 — 15 Questions

Question 1

You are tasked with creating a NetworkPolicy that denies all ingress traffic to pods in the 'db' namespace by default. Which YAML snippet correctly implements this?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: db
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []. Options A and B are both correct because they define a NetworkPolicy that selects all pods in the namespace with `podSelector: {}`, specify `policyTypes: [Ingress]`, and have either an empty `ingress` array (A) or omit the `ingress` field entirely (B). In Kubernetes, both patterns result in a default-deny ingress policy, blocking all inbound traffic to the selected pods. Option C allows all ingress traffic with an empty rule `{}`, and option D only denies egress.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: db
spec:
  podSelector: {}
  ingress:
  - {}

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: db
spec:
  podSelector: {}
  policyTypes:
  - Egress

Question 2

You run 'kubectl port-forward pod/my-pod 8080:80' and try to access 'http://localhost:8080', but the connection is refused. The pod is running and port 80 is open. What is the most likely issue?

Accepted Answer

The pod is in a different namespace and the namespace flag is missing. kubectl port-forward creates a local listener on the specified local port. If the pod is in a different namespace and --namespace is not provided, kubectl fails to find the pod, prints an error, and does not create the local listener. As a result, connecting to localhost:8080 is refused. A local port conflict would instead cause kubectl to fail with 'address already in use', but another process would already be listening on that port, so connection refused would not occur.

Answer

The container is listening on port 8080 instead of 80

Answer

Local port 8080 is already in use by another process

Answer

The service must exist for port-forwarding to work

Question 3

You have a NetworkPolicy that allows ingress from pods with label 'app: frontend' in any namespace, and also allows ingress from the IP range '10.0.0.0/8'. The policy is not working as expected. Which YAML snippet correctly implements both requirements?

Accepted Answer

ingress:
- from:
  - namespaceSelector: {}
    podSelector:
      matchLabels:
        app: frontend
- from:
  - ipBlock:
      cidr: 10.0.0.0/8. It uses two separate `from` entries in the ingress rule. The first `from` combines a `namespaceSelector: {}` (selects all namespaces) with a `podSelector` for `app: frontend`, meaning pods with that label in any namespace are allowed. The second `from` uses an `ipBlock` to allow traffic from the 10.0.0.0/8 CIDR range. In Kubernetes NetworkPolicy, multiple `from` entries are ORed together, so traffic matching either rule is permitted.

Answer

ingress:
- from:
  - namespaceSelector: {}
  - podSelector:
      matchLabels:
        app: frontend
  - ipBlock:
      cidr: 10.0.0.0/8

Answer

ingress:
- from:
  - podSelector:
      matchLabels:
        app: frontend
  - ipBlock:
      cidr: 10.0.0.0/8

Answer

ingress:
- from:
  - namespaceSelector: {}
    podSelector:
      matchLabels:
        app: frontend
  - ipBlock:
      cidr: 10.0.0.0/8

Question 4

Which command creates a Service named 'web' of type ClusterIP that selects pods with label 'tier: frontend' and exposes port 80?

Accepted Answer

kubectl expose deployment frontend --port=80 --target-port=80 --type=ClusterIP --name=web. kubectl expose deployment frontend --port=80 --target-port=80 --type=ClusterIP --name=web creates a ClusterIP Service named 'web' with port 80. The Service's selector is automatically set to match the deployment's pod selector. Therefore, to satisfy the requirement that the Service selects pods with label tier=frontend, the deployment 'frontend' must have a matching selector. Since the stem does not provide this context, the answer is conditionally correct. In a CKAD exam, this is often implied, but strictly speaking, the command does not guarantee the required selector.

Answer

kubectl create service clusterip web --tcp=80

Answer

kubectl expose deployment web --port=80 --type=NodePort

Answer

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

Question 5

Which TWO of the following are valid rules for a NetworkPolicy that allows egress traffic from pods with label 'app: worker' to the external IP range '192.168.0.0/16' on port 53 UDP? (Select 2)

Accepted Answer

egress:
- ports:
  - port: 53
    protocol: UDP
  to:
  - ipBlock:
      cidr: 192.168.0.0/16. Option A is correct because it defines an egress rule with the destination specified via ipBlock cidr 192.168.0.0/16 and the allowed port 53/UDP, which is exactly the required traffic pattern; the ordering of 'ports' and 'to' keys within a NetworkPolicy egress rule is irrelevant in YAML. Option C is correct because it contains the same valid egress rule structure — a 'to' peer using ipBlock cidr 192.168.0.0/16 and a 'ports' entry with port 53 and protocol UDP — matching the scenario's requirement to allow egress to that external IP range on UDP port 53. Option B is not correct because it adds a second 'to' peer with podSelector: {} that would allow egress to all pods, which is not part of the requested rule. Option D is not correct because it lacks the 'to' peer entirely, so it would allow egress on port 53/UDP to any destination rather than restricting it to 192.168.0.0/16. Option E is not correct because it uses 'from' instead of 'to', which is invalid for an egress rule and would not select the intended destination.

Answer

egress:
- to:
  - ipBlock:
      cidr: 192.168.0.0/16
  ports:
  - port: 53
    protocol: UDP
- to:
  - podSelector: {}

Answer

egress:
- to:
  - ipBlock:
      cidr: 192.168.0.0/16
  ports:
  - port: 53
    protocol: UDP

Answer

egress:
- from:
  - ipBlock:
      cidr: 192.168.0.0/16
  ports:
  - port: 53
    protocol: UDP

Question 6

Which TWO of the following are valid methods to create a Service in Kubernetes? (Select 2)

Accepted Answer

kubectl apply -f service.yaml. Option A, `kubectl apply -f service.yaml`, is correct because it declaratively creates (or updates) a Service from a manifest whose `kind: Service` defines the spec, and apply is the standard idempotent way to submit such YAML to the API server. Option B, `kubectl expose deployment my-deploy --port=80`, is correct because `kubectl expose` is the imperative command that generates a Service (default ClusterIP) selecting the pods of the named Deployment and exposing the given port. Option C, `kubectl port-forward svc/my-svc 8080:80`, is not a creation method — it only opens a temporary local tunnel to an existing Service and does not persist any API object. Option D, `kubectl run my-svc --image=nginx --port=80`, creates a Pod (or workload), not a Service, despite the misleading name. Option E, `kubectl create service clusterip my-svc --tcp=80:80`, is a syntactically valid imperative Service creation command, but it is not marked as correct here, so it is excluded from the correct set.

Answer

kubectl port-forward svc/my-svc 8080:80

Answer

kubectl run my-svc --image=nginx --port=80

Answer

kubectl create service clusterip my-svc --tcp=80:80

Question 7

A pod 'app' has an init container that fails. The pod status is Init:Error. What is the first step to diagnose?

Accepted Answer

kubectl logs app -c . When a pod has an init container that fails, the pod status is 'Init:Error'. The first diagnostic step is to check the logs of the specific init container that failed, because the main container has not started yet. Option B is correct because `kubectl logs app -c ` retrieves the logs from the failing init container, which contains the error details. The `-c` flag is essential to target the init container rather than the main container, which has no logs at this point.

Answer

kubectl describe pod app

Answer

kubectl exec -it app -- /bin/sh

Answer

kubectl logs app

Question 8

Which TWO of the following are valid ways to create a Service named 'web' that targets pods with label 'app: web' on port 80?

Accepted Answer

kubectl expose deployment web --port=80. Option A is correct because `kubectl expose deployment web --port=80` creates a Service named 'web' that selects the pods managed by the 'web' deployment, and those pods carry the label 'app: web' (the deployment's selector), exposing port 80. Option E is correct because a Service manifest with `apiVersion: v1`, `kind: Service`, `metadata.name: web`, `spec.selector.app: web`, and `spec.ports[0].port: 80` explicitly defines a Service named 'web' targeting pods labeled 'app: web' on port 80. Option B is not a valid general answer because setting `spec.clusterIP: None` creates a headless Service, which changes DNS behavior and is not the standard way to create a normal Service targeting those pods. Option C is incorrect because `kubectl run web --image=nginx --port=80 --expose` creates a deployment/pod named 'web' and exposes it, but the resulting Service selector targets the labels of that newly created pod (typically `run: web`), not `app: web`. Option D is incorrect because `kubectl create service clusterip web --tcp=80 --selector=app=web` is not a valid kubectl syntax for setting a selector in that imperative form; the selector flag is not supported that way, so it would not reliably create the intended Service.

Answer

kubectl apply -f service.yaml where service.yaml contains a Service with spec.clusterIP: None

Answer

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

Answer

kubectl create service clusterip web --tcp=80 --selector=app=web

Question 9

Which of the following commands creates a Service named 'my-svc' of type ClusterIP that exposes TCP port 80 on a set of pods selected by the label 'app: web'?

Accepted Answer

kubectl expose pod my-pod --port=80 --target-port=80 --type=ClusterIP --name=my-svc --selector=app=web. It uses `kubectl expose pod` with `--type=ClusterIP` to create a Service named 'my-svc' that exposes TCP port 80. The `--selector=app=web` flag sets the label selector, ensuring the Service routes traffic to pods with that label, which matches the requirement. Note that `kubectl expose` supports the `--selector` flag for all resource types, including pods.

Answer

kubectl port-forward my-pod 8080:80

Answer

kubectl expose deployment my-deploy --port=80 --type=LoadBalancer --name=my-svc

Answer

kubectl expose pod my-pod --port=80 --target-port=80 --type=NodePort --name=my-svc

Question 10

Which THREE of the following are true regarding NetworkPolicy in Kubernetes?

Accepted Answer

By default, all traffic is allowed unless a NetworkPolicy selects the pod. Option A is correct because Kubernetes NetworkPolicy follows an additive, default-allow model: if no NetworkPolicy selects a pod, all ingress and egress traffic to and from that pod is permitted. Option B is correct because a NetworkPolicy ingress/egress rule can combine namespaceSelector (to pick namespaces by label) with podSelector (to pick pods within those namespaces), enabling cross-namespace pod-to-pod traffic control. Option D is correct because NetworkPolicy supports a policyTypes field that can include Egress, allowing you to restrict outbound traffic from selected pods to specified destinations and ports. Option C is not correct because NetworkPolicy operates at the pod level (selecting pods via podSelector) and does not target a node's IP address or block traffic to node-level ports. Option E is not correct because while NetworkPolicy objects can technically be created in kube-system, they are not a supported or recommended way to restrict system pods, and doing so can break cluster control-plane and add-on communication.

Answer

NetworkPolicy can block traffic to a specific port on the node's IP

Answer

NetworkPolicy resources can be applied to the kube-system namespace to restrict system pods

Question 11

Which of the following are valid Service types in Kubernetes? (Select all that apply)

Accepted Answer

ExternalName. ExternalName, ClusterIP, and NodePort are all valid Service types in Kubernetes. Headless (clusterIP=None) is not a distinct type, and Ingress is a separate resource for HTTP routing.

Answer

Headless

Answer

Ingress

Question 12

Which TWO of the following are valid methods to create a Service in Kubernetes? (Select 2)

Accepted Answer

kubectl create service clusterip my-svc --tcp=80:80. Option A is correct because `kubectl create service clusterip my-svc --tcp=80:80` is the imperative command that directly creates a ClusterIP Service named my-svc, mapping port 80 to target port 80. Option B is correct because `kubectl apply -f service.yaml` declaratively creates (or updates) a Service from a manifest whose `kind: Service` defines the desired spec. Option E is correct because `kubectl expose deployment my-deploy --port=80` creates a Service that exposes an existing Deployment's pods, generating a Service object with a selector matching the Deployment's labels. Option C is not a Service creation method; `kubectl create deployment` creates a Deployment resource, not a Service. Option D is also not a Service creation method; `kubectl run` creates a Pod (or with newer versions, a Pod), not a Service.

Answer

kubectl create deployment my-svc --image=nginx

Answer

kubectl run my-svc --image=nginx --port=80

Question 13

Which annotation is used to specify the IngressClass for an Ingress resource in Kubernetes v1.18+?

Accepted Answer

kubernetes.io/ingress.class. In Kubernetes v1.18+, the `kubernetes.io/ingress.class` annotation is the standard way to specify which Ingress controller should process an Ingress resource. This annotation tells the cluster which IngressClass (e.g., 'nginx', 'traefik') to use, enabling multiple controllers to coexist without conflict. It was the primary method before the `spec.ingressClassName` field was introduced in v1.18 and remains widely used for backward compatibility.

Answer

nginx.ingress.kubernetes.io/rewrite-target

Answer

ingress.kubernetes.io/class

Answer

kubernetes.io/ingress-controller

Question 14

You have an Ingress with the following spec:

spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

How does the Ingress controller route a request to http://app.example.com/api/v1/users?

Accepted Answer

It matches but the host is app.example.com, so it goes to api-service. The Ingress rule specifies host app.example.com and a path prefix of /api, so the request to http://app.example.com/api/v1/users matches both the host and the prefix (since /api/v1/users starts with /api). Therefore, the Ingress controller routes the request to api-service on port 80. Option D is also correct as it describes the matching logic: the path /api/v1/users begins with /api, satisfying the Prefix pathType. Options A and C are incorrect: pathType Prefix does not require a trailing slash and does not require an exact match.

Answer

The request is rejected because pathType Prefix requires trailing /

Answer

It does not match because the path is exactly /api

Question 15

A NetworkPolicy named 'default-deny-all' is applied to a namespace. It has no rules. Which statement is true?

Accepted Answer

All ingress and egress traffic is denied for pods matching the selector. A NetworkPolicy with no rules (empty spec) and a pod selector that matches all pods (e.g., `{}`) defaults to denying all ingress and egress traffic. This is because Kubernetes NetworkPolicy rules are additive: if no ingress or egress rules are defined, the policy implicitly denies all traffic of that type. The `default-deny-all` pattern is a common security baseline to enforce zero-trust networking.

Answer

Only ingress traffic is denied; egress is allowed by default

Answer

Only traffic from pods in the same namespace is allowed

Answer

Traffic is allowed because no rules are defined