CKAD Practice Test 9 — 10 Questions

Question 1

Which of the following commands creates a ClusterIP service named 'my-service' that exposes port 80 on the pod with label 'app=web'?

Accepted Answer

kubectl expose deployment my-deployment --port=80 --name=my-service. `kubectl expose deployment my-deployment --port=80 --name=my-service` creates a ClusterIP service by default, which selects pods based on the labels of the deployment (e.g., `app=web` if the deployment has that label). The `--port=80` flag sets the service port, and the service automatically maps to the container port (defaults to the same port if `--target-port` is omitted). This command satisfies the requirement of exposing port 80 on pods with label `app=web`.

Answer

kubectl expose pod my-pod --port=80 --target-port=8080 --name=my-service

Answer

kubectl create service clusterip my-service --tcp=80:8080 --cluster-ip=10.0.0.1

Answer

kubectl expose deployment my-deployment --type=NodePort --port=80 --name=my-service

Question 2

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The OOMKilled status indicates the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. Since the pod ran successfully for days, the issue is likely a memory leak or increased workload demand, not a configuration error. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory usage without being killed.

Answer

Delete the namespace and redeploy all workloads

Answer

Delete and recreate the pod to clear the crash loop

Answer

Increase the CPU request for the container

Question 3

An Ingress resource is defined as:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
  tls:
  - hosts:
    - example.com
    secretName: tls-secret
What must exist in the cluster for TLS termination to work?

Accepted Answer

A Secret named tls-secret of type kubernetes.io/tls in the same namespace. C is correct because TLS termination requires the actual TLS certificate and key to be stored in a Kubernetes Secret of type `kubernetes.io/tls`. The Ingress controller reads this Secret to terminate HTTPS connections, decrypting traffic before forwarding it to the backend service. Without this Secret, the Ingress controller cannot present a valid certificate to clients.

Answer

An IngressClass annotation specifying the ingress controller

Answer

A ServiceAccount named tls-secret

Answer

A ConfigMap named tls-secret with certificate data

Question 4

You are a Kubernetes administrator responsible for a production cluster. A development team has deployed a Pod named 'app-pod' that runs a container with a PostgreSQL database. The team reports that the Pod is failing to start with an error: 'Error: container has runAsNonRoot and image will run as root (runtime error)'. The Pod YAML is as follows:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: db
    image: postgres:latest
    securityContext:
      runAsNonRoot: true
```

The team wants to ensure the container runs securely without running as root. What is the BEST course of action?

Accepted Answer

Add `runAsUser: 999` to the container's securityContext to run the container as the postgres user.. The PostgreSQL official image runs as the 'postgres' user with UID 999 by default. Adding `runAsUser: 999` to the container's securityContext overrides the user to a non-root UID, satisfying the `runAsNonRoot: true` constraint and allowing the container to start without the runtime error.

Answer

Remove `runAsNonRoot: true` from the securityContext to allow the container to run as root.

Answer

Increase the Pod's resource limits because the error is due to insufficient memory.

Answer

Create a PodSecurityPolicy that allows running as root.

Question 5

You want to restrict ingress traffic to pods with label 'app: web' in namespace 'frontend' to only come from pods in namespace 'backend'. Which NetworkPolicy YAML is correct?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: backend. It defines a NetworkPolicy in the 'frontend' namespace that selects pods with label 'app: web' and allows ingress traffic only from pods in the 'backend' namespace. The key is the `namespaceSelector` with `kubernetes.io/metadata.name: backend`, which matches the namespace named 'backend' (this label is automatically added by Kubernetes to every namespace). The `policyTypes: [Ingress]` explicitly enables ingress rules, and the `from` rule restricts traffic to only those originating from the 'backend' namespace.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

Question 6

You want to debug a pod that is failing to start. The pod does not have a shell installed. Which command can you use to attach an ephemeral debug container to the running (or failed) pod?

Accepted Answer

kubectl debug -it --image=busybox --target=. `kubectl debug` allows you to attach an ephemeral debug container to a running or failed pod, even if the pod lacks a shell. The `--target` parameter specifies the container in the pod to which the debug container attaches, enabling network namespace sharing and process inspection without modifying the original container.

Answer

kubectl attach <pod>

Answer

kubectl exec -it <pod> -- /bin/sh

Answer

kubectl run debug --image=busybox -it --restart=Never

Question 7

A pod manifest includes the following securityContext: securityContext: { runAsUser: 1000, runAsGroup: 3000, fsGroup: 2000 }. What UID will be used for processes in the container?

Accepted Answer

1000. The `runAsUser` field in the pod's securityContext explicitly sets the user ID (UID) for all processes in the container. In this manifest, `runAsUser: 1000` overrides the default UID (usually 0, root) and ensures that the container's main process runs with UID 1000. The `runAsGroup` and `fsGroup` fields affect group IDs and file ownership, not the process UID.

Answer

0 (root)

Answer

3000

Answer

2000

Question 8

Which TWO of the following are valid Kubernetes Secret types? (Select two.)

Accepted Answer

kubernetes.io/ssh-auth. kubectl create secret tls, kubectl create secret ssh-auth, and kubectl create secret generic (which creates an Opaque secret) are all valid Kubernetes Secret types. The type kubernetes.io/ssh-auth is used for SSH credentials, kubernetes.io/tls is used for TLS certificates, and Opaque is the default type for arbitrary user-defined data. Options A (kubernetes.io/password) and C (kubernetes.io/configmap) are not valid Secret types.

Answer

kubernetes.io/password

Answer

kubernetes.io/configmap

Question 9

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

Accepted Answer

NodePort. 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.

Answer

LoadBalancer

Answer

ClusterIP

Answer

ExternalName

Question 10

A Service named 'api' has no endpoints. 'kubectl describe svc api' shows the selector 'app: api', but no pods have that label. What is the most likely reason for missing endpoints?

Accepted Answer

No pods match the Service's selector. The most likely reason for missing endpoints is that no pods match the Service's selector. A Kubernetes Service routes traffic to pods that have labels matching its `spec.selector`. If `kubectl describe svc api` shows `Selector: app=api` but no pods carry the label `app: api`, the Service's endpoint controller will not populate any endpoints, resulting in an empty `Endpoints` object. This is the direct cause of the missing endpoints.

Answer

The Service is in a different namespace than the pods

Answer

The Service port is incorrect

Answer

The Service type is ExternalName