CKAD Application Environment, Configuration and Security Practice Test 16 — 15 Questions

Question 1

Which TWO of the following are valid types for a Kubernetes Secret? (Choose two.)

Accepted Answer

kubernetes.io/tls. Option A, kubernetes.io/tls, is a valid built-in Secret type used to store a TLS certificate and its associated private key, typically consumed by Ingress controllers for HTTPS termination. Option B, kubernetes.io/basic-auth, is also a valid built-in Secret type designed to hold a username and password for basic authentication, with the required keys being 'username' and 'password'. Option C, kubernetes.io/configmap, is not a valid Secret type because ConfigMaps are a separate Kubernetes API object with their own kind and are not represented as a Secret type. Option D, kubernetes.io/tls-key, is not a recognized built-in Secret type; the TLS private key is instead stored as the 'tls.key' data key within a kubernetes.io/tls Secret. Option E, kubernetes.io/ssh-key, is not a built-in Secret type in Kubernetes, as SSH keys would typically be stored using the generic Opaque type or a custom type.

Answer

kubernetes.io/configmap

Answer

kubernetes.io/tls-key

Answer

kubernetes.io/ssh-key

Question 2

Which TWO of the following are required to create a Role and RoleBinding that grants read access to Pods in the 'development' namespace? (Choose two.)

Accepted Answer

A RoleBinding that binds the Role to a subject (User or ServiceAccount). A RoleBinding is the Kubernetes resource that binds a Role (which defines permissions) to a specific subject (User, Group, or ServiceAccount) within a namespace. Without a RoleBinding, the permissions defined in the Role are not granted to any identity, making it a required component for granting access.

Answer

A NetworkPolicy that allows traffic to Pods

Answer

A ClusterRole with the same rules

Answer

A ClusterRoleBinding that binds the Role to a subject

Question 3

Which THREE of the following are valid fields in a Pod's container spec for resource management? (Choose three.)

Accepted Answer

resources.limits.ephemeral-storage. `ephemeral-storage` is a valid resource type in Kubernetes that can be specified under `resources.limits` to control the maximum temporary storage a container can use, preventing pods from exhausting node storage. This is defined in the Kubernetes resource model and is commonly used for scratch space or logs.

Answer

resources.requests.gpu

Answer

resources.requests.storage

Question 4

A developer wants to mount a ConfigMap as a volume in a Pod so that updates to the ConfigMap are reflected in the Pod without restarting. Which two statements are correct? (Choose two.)

Accepted Answer

Using subPath in the volume mount prevents automatic updates.. When a ConfigMap is mounted using `subPath`, Kubernetes treats the mount as a single file rather than a directory of symlinks. This means the atomic update mechanism (which uses symlinks to swap the directory contents) is bypassed, and updates to the ConfigMap are not reflected in the Pod without a restart or remount.

Answer

Using envFrom to inject ConfigMap data as environment variables will update automatically.

Answer

ConfigMap updates are reflected immediately in the volume mount.

Answer

The Pod must be restarted for any ConfigMap change to take effect.

Question 5

You need to create a Secret to store a TLS certificate and private key for use by an Ingress resource. Which two statements are correct? (Choose two.)

Accepted Answer

kubectl create secret tls my-tls --cert=cert.pem --key=key.pem. `kubectl create secret tls my-tls --cert=cert.pem --key=key.pem` is the dedicated command to create a TLS secret, which automatically sets the type to `kubernetes.io/tls` and stores the certificate under the key `tls.crt` and the private key under `tls.key`. This is the standard method for creating secrets intended for use with Ingress resources.

Answer

Use 'kubectl create secret generic tls-secret --from-file=cert.pem --from-file=key.pem' with type Opaque.

Answer

The keys in the data section must be 'cert' and 'key'.

Answer

The Ingress resource references the Secret's data keys directly.

Question 6

A developer wants to restrict a Pod's resource usage. Which two API resources can be used to enforce limits at the namespace level? (Choose two.)

Accepted Answer

LimitRange. LimitRange (C) is correct because it allows administrators to set default resource requests and limits, as well as minimum and maximum constraints, for Pods and containers within a namespace. This enforces resource boundaries at the namespace level, ensuring that individual Pods cannot exceed defined limits.

Answer

PodSecurityPolicy

Answer

HorizontalPodAutoscaler

Answer

NetworkPolicy

Question 7

You are troubleshooting a Pod that cannot start because it fails with 'Error: container has runAsNonRoot and image will run as root'. The Pod's SecurityContext has 'runAsNonRoot: true' and no explicit 'runAsUser'. Which three actions could resolve this? (Choose three.)

Accepted Answer

Remove 'runAsNonRoot: true' from the SecurityContext.. Removing 'runAsNonRoot: true' eliminates the constraint that the container image must run as a non-root user. Since the image runs as root by default and no 'runAsUser' is set, the Pod fails. Removing the flag allows the container to start with its default root user.

Answer

Set 'readOnlyRootFilesystem: true' in the SecurityContext.

Answer

Set 'runAsGroup: 3000' in the SecurityContext.

Question 8

A developer needs to expose database credentials to a Pod as environment variables. The credentials are stored in a Kubernetes Secret named 'db-secret' with keys 'username' and 'password'. Which two methods correctly inject these values? (Choose two.)

Accepted Answer

Define an env entry with 'valueFrom' and 'secretKeyRef' for each key.. `valueFrom` with `secretKeyRef` allows you to reference a specific key from a Kubernetes Secret and inject its value as an environment variable. This is the standard method for exposing individual secret keys to a Pod. Option E is correct because `envFrom` with `secretRef` injects all keys from the referenced Secret as environment variables into the container, which is efficient when you need to expose multiple keys without defining each one individually.

Answer

Set 'env.name' to 'db-secret' and 'env.value' from 'secretKeyRef'.

Answer

Use 'valueFrom' with 'configMapKeyRef'.

Answer

Mount the Secret as a volume and source environment variables from the mounted files.

Question 9

A Deployment named 'web' runs in namespace 'prod'. The team wants every container in that Deployment to receive the environment variable 'LOG_LEVEL' from the ConfigMap 'app-config' key 'log.level', and the ConfigMap may be updated later. The application reads environment variables only at startup. Which single change to the Deployment's Pod template actually delivers the value?

Accepted Answer

Add an env entry with name 'LOG_LEVEL' and valueFrom.configMapKeyRef referencing name 'app-config' and key 'log.level'.. Environment variables sourced from a ConfigMap key use env.valueFrom.configMapKeyRef, which names the ConfigMap and the specific key. Because the application only reads environment variables at startup, the value must be present as an environment variable rather than as a mounted file. Referencing 'app-config' key 'log.level' under the name 'LOG_LEVEL' satisfies the requirement with a single, supported field.

Answer

Add envFrom with configMapRef referencing 'app-config', and set the container's command to export LOG_LEVEL before starting the application.

Answer

Add a volume that mounts the 'app-config' ConfigMap at /etc/config, then add an env entry with valueFrom.configMapKeyRef referencing 'app-config' and key 'log.level'.

Answer

Add a projected volume that combines the 'app-config' ConfigMap with a downwardAPI source, then reference the mount path in the container's env valueFrom.fieldRef.

Question 10

A Pod in namespace 'team-a' runs with a serviceAccountName of 'reporter'. The Pod must read a Secret named 'metrics-token' that lives in namespace 'team-b'. Cluster-wide RBAC and the ServiceAccount token are already configured correctly. Which Pod specification change allows the container to obtain the Secret's data?

Accepted Answer

Use the ServiceAccount token to call the API server for the Secret in 'team-b', then write the returned data into a file the application reads.. Secret references such as secretKeyRef and secret volume sources resolve only inside the Pod's own namespace, so a Pod in 'team-a' cannot directly project a Secret stored in 'team-b'. The API server is the cross-namespace path, and the Pod's ServiceAccount token, combined with the already-correct RBAC, lets the container retrieve the Secret and stage its data into a file the application consumes.

Answer

Create a Secret in 'team-a' that has the same name, and rely on the kubelet to mirror the data from 'team-b' automatically.

Answer

Mount a volume of type secret with secretName 'metrics-token' and add a volumeMount at /var/run/metrics.

Answer

Add an env entry with valueFrom.secretKeyRef naming 'metrics-token' and set the Pod's namespace field to 'team-b'.

Question 11

A developer deploys a Pod that reads configuration from a ConfigMap named 'app-config' using a volume mount at /etc/config. Later, the ConfigMap is updated with new values. The application running in the Pod is designed to re-read the file periodically but continues to see the old values. What is the most likely reason the application is not seeing the updated configuration?

Accepted Answer

The Pod was created with the ConfigMap volume mounted using subPath, which prevents automatic updates.. ConfigMap volumes mounted without subPath are periodically updated by the kubelet, but when subPath is used, the kubelet does not sync changes to that file. The application re-reads the file but sees stale data because the file content is never refreshed. Removing subPath or restarting the Pod would resolve the issue.

Answer

The ConfigMap volume is mounted as read-only, preventing updates from being propagated.

Answer

The ConfigMap was updated using kubectl edit, which does not trigger a volume refresh.

Answer

The application is using an environment variable instead of reading the file from the volume mount.

Question 12

A Pod is configured with a securityContext that sets runAsUser: 1000 and runAsGroup: 3000 at the pod level. A container within that Pod has its own securityContext that sets runAsUser: 2000 but does not set runAsGroup. The container process attempts to create a file in a directory owned by group 3000 with group write permissions. Which two statements are true regarding the effective user and group of the container process? (Choose two.)

Accepted Answer

The container process runs with UID 2000.. Container-level securityContext overrides pod-level for the same field, so runAsUser: 2000 applies. For runAsGroup, the container does not specify it, so it inherits the pod-level runAsGroup: 3000. Thus the process runs as UID 2000 and GID 3000, allowing write access to the group-writable directory.

Answer

The container process runs with UID 1000 because pod-level settings take precedence.

Answer

The container process runs with GID 2000 because the container's runAsUser implies a matching group.

Answer

The container process cannot write to the directory because the group ID does not match the directory's group owner.

Question 13

A developer needs to create a Secret named 'db-credentials' in the 'staging' namespace using the literal values username=admin and password=S3cr3t!. Which kubectl command will accomplish this?

Accepted Answer

kubectl create secret generic db-credentials --from-literal=username=admin --from-literal=password=S3cr3t! -n staging. The kubectl create secret generic command with --from-literal is designed to create a Secret from literal key-value pairs. The -n flag specifies the namespace. The other options either use incorrect flags or syntax that does not match the intended use, such as --from-file requiring files or the tls type requiring certificates.

Answer

kubectl create secret tls db-credentials --from-literal=username=admin --from-literal=password=S3cr3t! -n staging

Answer

kubectl create secret generic db-credentials --from-literal=username:admin --from-literal=password:S3cr3t! -n staging

Answer

kubectl create secret generic db-credentials --from-file=username=admin --from-file=password=S3cr3t! -n staging

Question 14

A Pod is running in a namespace with a default LimitRange that sets a default CPU request of 100m and a default CPU limit of 200m. The Pod's container spec does not specify any CPU requests or limits. What will be the effective CPU request and limit for the container?

Accepted Answer

CPU request: 100m, CPU limit: 200m. A LimitRange with default CPU request and limit values automatically applies those to containers that do not specify their own. The defaultRequest becomes the request, and the default becomes the limit. Thus, the container gets a CPU request of 100m and a limit of 200m, as defined in the LimitRange.

Answer

CPU request: 200m, CPU limit: 200m

Answer

CPU request: 0, CPU limit: 0

Answer

CPU request: 100m, CPU limit: 100m

Question 15

A developer wants to run a container as a non-root user and prevent it from gaining additional privileges. The container image runs as root by default. Which securityContext configuration should be applied to the container to achieve this?

Accepted Answer

securityContext: { runAsUser: 1000, allowPrivilegeEscalation: false }. To run as a non-root user, runAsUser must be set to a non-zero UID. To prevent privilege escalation, allowPrivilegeEscalation must be false. The combination of runAsUser: 1000 and allowPrivilegeEscalation: false achieves both goals. Other options either fail to set a non-root user, enable privilege escalation, or rely on runAsNonRoot without specifying a UID.

Answer

securityContext: { runAsUser: 1000, privileged: true }

Answer

securityContext: { runAsGroup: 1000, allowPrivilegeEscalation: true }

Answer

securityContext: { runAsNonRoot: true, privileged: false }