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

Question 1

Which two commands can create a ConfigMap from an environment file? (Select TWO.)

Accepted Answer

kubectl create configmap my-config --from-env-file=app.env. `--from-env-file=app.env` is the dedicated flag for creating a ConfigMap from an environment file, where each line in the file is parsed as a key=value pair. Option C is also correct because `--from-file=app.env` creates a ConfigMap with the file's entire contents stored under the filename as the key, which is a valid method even though it does not parse the file as environment variables.

Answer

kubectl create configmap my-config --from-literal=app.env

Answer

kubectl create configmap my-config --from-file=key1=app.env

Answer

kubectl create configmap my-config --from-env=app.env

Question 2

Which kubectl command creates a ConfigMap named 'app-config' from a file 'config.properties'?

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. `kubectl create configmap` with the `--from-file` flag creates a ConfigMap from a file, using the filename as the key and the file content as the value. This is the standard Kubernetes method to import configuration data from a local file into a ConfigMap resource.

Answer

kubectl create configmap app-config --file config.properties

Answer

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

Answer

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

Question 3

A pod runs as user ID 1000. The container image includes a binary that expects to run as root. Which SecurityContext setting can allow the binary to run with root-like privileges while still running the container as non-root?

Accepted Answer

Set securityContext.runAsUser: 0. Setting securityContext.runAsUser:0 overrides the container-level user ID (1000) to 0, running the container as root. This allows the binary to execute with root privileges. The pod-level security context remains unchanged, so other containers can still run as UID 1000. It does not use privileged mode or add capabilities.

Answer

Add the SYS_ADMIN capability under securityContext.capabilities.add

Answer

Set securityContext.privileged: true

Answer

Set securityContext.allowPrivilegeEscalation: true

Question 4

You create a Role named 'pod-reader' in the 'default' namespace with rules to get, list, and watch pods. A ServiceAccount 'app-sa' in the same namespace needs to be bound to this role. Which YAML snippet correctly creates the RoleBinding?

Accepted Answer

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
subjects:
- kind: ServiceAccount
  name: app-sa
  apiGroup: ''
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io. It creates a RoleBinding in the 'default' namespace that binds the ServiceAccount 'app-sa' to the Role 'pod-reader' using the correct 'kind: Role' in the roleRef. The RoleBinding must reference a Role (not a ClusterRole) when the Role exists in the same namespace, and the apiGroup for the roleRef must be 'rbac.authorization.k8s.io'.

Answer

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
subjects:
- kind: ServiceAccount
  name: app-sa
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Answer

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
subjects:
- kind: ServiceAccount
  name: app-sa
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Answer

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Question 5

You want to restrict total memory usage in a namespace to 10 Gi. Which resource should you create?

Accepted Answer

ResourceQuota. A ResourceQuota is the correct Kubernetes object to enforce aggregate resource consumption limits at the namespace level. By defining a ResourceQuota with `spec.hard.memory: 10Gi`, you restrict the total memory requested and used by all pods in that namespace to 10 GiB. This directly meets the requirement to limit total memory usage.

Answer

PodDisruptionBudget

Answer

LimitRange

Answer

NetworkPolicy

Question 6

A pod uses a ServiceAccount with automountServiceAccountToken set to false. The pod still needs to access the Kubernetes API. How can you mount the service account token in this pod?

Accepted Answer

Set automountServiceAccountToken: true in the pod spec. Setting `automountServiceAccountToken: true` in the pod spec overrides the ServiceAccount-level setting of `false`. This allows the pod to mount the service account token automatically, enabling it to authenticate to the Kubernetes API without manual intervention.

Answer

Create a secret with the token and mount it manually

Answer

Use a ConfigMap to store the token

Answer

Set serviceAccountName: default and automountServiceAccountToken: true in the pod spec

Question 7

You want to enforce that all pods in a namespace run with the 'restricted' Pod Security Standard (Pod Security Admission). Which label should you set on the namespace?

Accepted Answer

pod-security.kubernetes.io/enforce=restricted. The `pod-security.kubernetes.io/enforce=restricted` label enforces the 'restricted' Pod Security Standard on the namespace, preventing any pod that violates the restricted policy from being created. This label directly activates Pod Security Admission (PSA) enforcement mode, which blocks non-compliant pods at admission time.

Answer

pod-security.kubernetes.io/warn=restricted

Answer

pod-security.kubernetes.io/enforce=baseline

Answer

pod-security.kubernetes.io/audit=restricted

Question 8

Which command creates an Opaque Secret named 'my-secret' with key 'password' and value 'p@ssw0rd'?

Accepted Answer

kubectl create secret generic my-secret --from-literal=password=p@ssw0rd. `kubectl create secret generic` creates an Opaque secret, and the `--from-literal=key=value` syntax correctly assigns the literal value 'p@ssw0rd' to the key 'password'. This produces a secret with the specified key-value pair.

Answer

kubectl create secret tls my-secret --cert=cert.pem --key=key.pem

Answer

kubectl create secret generic my-secret --from-literal=password

Answer

kubectl create secret generic my-secret --from-literal=p@ssw0rd=password

Question 9

You deploy a pod with resource requests: cpu: 500m, memory: 256Mi and limits: cpu: 1, memory: 512Mi. The container tries to allocate 600Mi of memory. What happens?

Accepted Answer

The container is OOMKilled because it exceeds the memory limit. The container's memory allocation of 600Mi exceeds its configured memory limit of 512Mi. Kubernetes enforces memory limits using the cgroup memory controller; when a container attempts to allocate more memory than its limit, the kernel's Out-Of-Memory (OOM) killer terminates the container process. This results in the container being OOMKilled, as recorded in the pod status.

Answer

The container runs normally, but memory usage is throttled

Answer

The container runs normally because requests are the only constraints

Answer

The container is evicted from the node

Question 10

A pod has securityContext with capabilities.add: ['NET_ADMIN'] and capabilities.drop: ['ALL']. What effective capabilities does the container have?

Accepted Answer

Only NET_ADMIN. When a container's securityContext specifies both `capabilities.drop: ['ALL']` and `capabilities.add: ['NET_ADMIN']`, the `drop: ['ALL']` first removes all capabilities, and then `add: ['NET_ADMIN']` adds back only the NET_ADMIN capability. The final effective set is exactly `[NET_ADMIN]`. This is the intended Kubernetes behavior: `drop` is processed before `add` within the same container spec.

Answer

No capabilities

Answer

All capabilities

Answer

All capabilities except NET_ADMIN

Question 11

You want to set environment variable 'DB_URL' in a pod from the key 'url' in ConfigMap 'db-config'. Which YAML snippet is correct?

Accepted Answer

env:
- name: DB_URL
  valueFrom:
    configMapKeyRef:
      name: db-config
      key: url. It uses the `configMapKeyRef` field under `valueFrom` to inject a specific key ('url') from a ConfigMap ('db-config') into the environment variable 'DB_URL'. This is the precise syntax required to reference a single key from a ConfigMap in a pod's environment variable definition.

Answer

envFrom:
- configMapRef:
    name: db-config

Answer

env:
- name: DB_URL
  valueFrom:
    secretKeyRef:
      name: db-config
      key: url

Answer

env:
- name: DB_URL
  valueFrom:
    configMap:
      name: db-config
      key: url

Question 12

A pod is failing to start with error 'container has runAsNonRoot and image will run as root'. The container image runs as root. Which change allows the pod to run?

Accepted Answer

Set runAsUser to a non-zero UID, e.g., 1000. The error 'container has runAsNonRoot and image will run as root' indicates that the pod's securityContext has runAsNonRoot: true, but the container image runs as root (UID 0). To satisfy the runAsNonRoot constraint, you must override the container's user to a non-zero UID by setting runAsUser to a non-zero value (e.g., 1000). This forces the container to run as a non-root user, resolving the conflict.

Answer

Remove runAsNonRoot: true from securityContext

Answer

Add fsGroup: 1000

Answer

Set allowPrivilegeEscalation: false

Question 13

Which THREE of the following are valid fields in a PodSecurityContext (pod-level securityContext)? (Select 3)

Accepted Answer

runAsUser. `runAsUser` is a valid field in a PodSecurityContext that sets the user ID (UID) for all containers in the pod, overriding any container-level `securityContext.runAsUser`. This is defined in the Kubernetes API under `PodSecurityContext` and is commonly used to enforce non-root execution.

Answer

readOnlyRootFilesystem

Answer

capabilities

Question 14

You have created a ServiceAccount named 'my-sa' in namespace 'default'. You want a Pod to use this ServiceAccount. Which Pod spec field is correct?

Accepted Answer

serviceAccountName: my-sa. The `serviceAccountName` field in a Pod spec is the standard way to assign a specific ServiceAccount to a Pod. When this field is set to `my-sa`, the Pod will use the token and permissions associated with that ServiceAccount for API authentication and authorization.

Answer

spec.securityContext.serviceAccount: my-sa

Answer

serviceAccount: my-sa

Answer

automountServiceAccountToken: false

Question 15

A ClusterRole named 'secret-reader' grants get, list, watch on secrets in all namespaces. A RoleBinding in namespace 'app' binds this ClusterRole to a ServiceAccount 'app-sa'. Which of the following is true about the effective permissions of 'app-sa'?

Accepted Answer

The ServiceAccount can read secrets only in namespace 'app'. A RoleBinding can only grant permissions within its own namespace, even when it references a ClusterRole. Since the RoleBinding is in namespace 'app', the ServiceAccount 'app-sa' receives the permissions defined in the 'secret-reader' ClusterRole, but scoped only to namespace 'app'. Therefore, it can read secrets only in namespace 'app', not in all namespaces.

Answer

The ServiceAccount can read secrets in all namespaces

Answer

The RoleBinding is invalid because ClusterRole cannot be used with RoleBinding

Answer

The ServiceAccount can read secrets only in the default namespace