CKAD Practice Test 31 — 15 Questions

Question 1

In a Deployment YAML, which field defines the number of pods to run?

Accepted Answer

spec.replicas. In a Kubernetes Deployment YAML, the `spec.replicas` field directly specifies the desired number of Pod replicas that the Deployment controller should maintain. This field is part of the Deployment's specification and tells the controller to create or scale Pods to match the given count.

Answer

spec.strategy.replicas

Answer

spec.template.replicas

Answer

metadata.replicas

Question 2

Which command shows resource usage (CPU/memory) of pods in the default namespace?

Accepted Answer

kubectl top pod. `kubectl top pod` is the Kubernetes command that displays real-time CPU and memory usage metrics for pods, leveraging the metrics server to collect resource utilization data. This command is essential for monitoring pod performance and is part of the Application Observability and Maintenance domain.

Answer

kubectl get pods -o wide

Answer

kubectl logs pod

Answer

kubectl describe pod

Question 3

Which of the following is a valid way to expose a Secret as an environment variable in a Pod?

Accepted Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef: .... `secretKeyRef` is the Kubernetes API field used to reference a specific key from a Secret object and expose its value as an environment variable in a Pod. This is defined in the Pod spec under `env[].valueFrom.secretKeyRef`, which requires the `name` of the Secret and the `key` within that Secret.

Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      configMapKeyRef: ...

Answer

env:
  - name: DB_PASSWORD
    value: $(DB_PASSWORD_SECRET)

Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      fieldRef: ...

Question 4

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

Accepted Answer

To return a CNAME record pointing to an external domain. 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.

Answer

To expose the service on a static port on each node

Answer

To expose the service using an external load balancer

Answer

To assign a static cluster IP

Question 5

You have a multi-container pod with a main container and a sidecar container that collects logs. The sidecar container should start before the main container and must complete initialization tasks before the main container starts. Which type of container should you use for this purpose?

Accepted Answer

Init container. Init containers run to completion before any regular containers in the pod start, making them ideal for prerequisites like initialization tasks or log setup. In this scenario, the sidecar must complete its initialization before the main container begins, which is exactly the behavior of an init container. Regular sidecar containers run concurrently with the main container, not before it.

Answer

Ephemeral container

Answer

Job

Answer

Regular sidecar container

Question 6

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

Accepted Answer

web.default.svc.cluster.local. In Kubernetes, the DNS name for a Service follows the pattern `..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.

Answer

web.default.cluster.local

Answer

web.svc.cluster.local

Answer

web.default.pod.cluster.local

Question 7

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?

Accepted Answer

A headless service with clusterIP: None and selector matching the StatefulSet. 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.

Answer

A ClusterIP service named 'mysql'

Answer

A NodePort service named 'mysql'

Answer

An ExternalName service pointing to an external database

Question 8

A container image requires a seccomp profile that is not the default. The cluster supports the RuntimeDefault seccomp profile. Which Pod securityContext field should be configured to use the RuntimeDefault seccomp profile?

Accepted Answer

seccompProfile:
  type: RuntimeDefault. The `seccompProfile` field under the Pod's `securityContext` is the proper way to specify a seccomp profile in Kubernetes. Setting `type: RuntimeDefault` tells the container runtime (e.g., containerd or CRI-O) to use the default seccomp profile provided by the runtime, which is a secure baseline that blocks around 44 system calls while allowing common ones like `read`, `write`, and `exit`. This field was introduced in Kubernetes 1.19 (GA in 1.22) and is the standard approach for configuring seccomp at the Pod or container level.

Answer

seccomp:
  type: RuntimeDefault

Answer

capabilities:
  add: [SECCOMP]

Answer

securityContext:
  seccomp:
    type: Unconfined

Question 9

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?

Accepted Answer

kubectl expose deployment web-app --port=80. `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.

Answer

kubectl expose service web-app --port=80

Answer

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

Answer

kubectl expose pod web-app --port=80

Question 10

A security requirement states that a container must run with a read-only root filesystem. Which field must be set in the container's securityContext?

Accepted Answer

readOnlyRootFilesystem: true. Setting `readOnlyRootFilesystem: true` in the container's `securityContext` enforces that the container's root filesystem is mounted as read-only, preventing any writes to the filesystem at the root level. This satisfies the security requirement by ensuring that even if a process is compromised, it cannot modify system binaries, configuration files, or other critical files within the container's root filesystem.

Answer

runAsUser: 1000

Answer

capabilities:
  drop: ["ALL"]

Answer

allowPrivilegeEscalation: false

Question 11

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

Accepted Answer

ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend. 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.

Answer

ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          app: frontend

Answer

ingress:
  - ports:
    - port: 80

Answer

ingress:
  - from:
    - ipBlock:
        cidr: 10.0.0.0/8

Question 12

Which TWO statements about headless services are correct?

Accepted Answer

DNS returns the pod IPs directly. 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.

Answer

They require a selector to match pods

Answer

They provide load balancing across pods

Answer

They have a ClusterIP assigned

Question 13

An administrator needs to create a ConfigMap named 'app-config' from a file called 'config.properties'. Which kubectl command accomplishes this?

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. `kubectl create configmap app-config --from-file=config.properties` reads the file `config.properties` and creates a ConfigMap where the key is the filename (config.properties) and the value is the file's content. This is the standard way to create a ConfigMap from a single file in Kubernetes.

Answer

kubectl create configmap app-config --from-literal=config.properties

Answer

kubectl create configmap app-config --from-env-file=config.properties

Answer

kubectl create configmap app-config --from-file=key1=config.properties

Question 14

You are implementing a canary deployment for a microservice named 'api'. The stable version is deployed as 'api-stable' with label 'version: stable'. You create a canary Deployment 'api-canary' with label 'version: canary'. Both Deployments have the same label 'app: api'. You want a Service 'api-svc' to route 90% of traffic to stable and 10% to canary. Which Service configuration achieves this?

Accepted Answer

selector: {app: api} and adjust the number of replicas in each Deployment to achieve the desired ratio (e.g., 9 stable, 1 canary). Kubernetes Services distribute traffic based on the number of ready Pods matching the selector. By setting 9 replicas for 'api-stable' and 1 replica for 'api-canary', both with the same selector 'app: api', the Service will route approximately 90% of requests to stable and 10% to canary, achieving the desired canary deployment ratio without native traffic splitting.

Answer

Add annotation 'traffic-weight: 90' to stable and 'traffic-weight: 10' to canary

Answer

selector: {app: api, version: stable}

Answer

Create two separate Services, each targeting one version, and rely on DNS weighting

Question 15

A developer wants to perform a canary deployment where 10% of traffic goes to a new version (v2) of an application. They create two Deployments (app-v1 and app-v2) and a Service. The Service selector is configured to match labels: 'app: myapp, version: v1'. How can they route 10% of traffic to v2 with minimal changes?

Accepted Answer

Change the Service selector to 'app: myapp' (remove version label) and set v1 replicas to 9 and v2 replicas to 1.. To achieve a canary deployment with 10% traffic to v2, the Service selector must match pods from both versions. By changing the selector to 'app: myapp' (removing the version label), the Service will load-balance across all pods with that label. Then, by setting v1 replicas to 9 and v2 replicas to 1, the total pods are 10, so v2 receives approximately 10% of traffic. This requires minimal changes: one selector update and replica adjustments.

Answer

Use kubectl rollout pause on the v2 Deployment.

Answer

Set the v2 Deployment's spec.replicas to 10% of the total replicas and keep the Service selector unchanged.

Answer

Add a NetworkPolicy to limit traffic to v2 pods to 10%.