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

Question 1

A developer needs to create a Kubernetes Secret for Docker registry authentication. The registry URL is 'myregistry.io', username 'user', password 'pass', email 'user@example.com'. Which command creates this Secret?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

kubectl create secret docker-registry regcred --docker-server=myregistry.io --docker-username=user --docker-password=pass --docker-email=user@example.com. `kubectl create secret docker-registry` is the dedicated command for creating a Docker registry authentication secret, which automatically encodes the provided credentials into a `.dockerconfigjson` format. This secret type is specifically designed for pulling images from private registries, and the flags `--docker-server`, `--docker-username`, `--docker-password`, and `--docker-email` match the required fields for registry authentication.

Answer

kubectl create secret tls regcred --cert=cert --key=key

Answer

kubectl create secret generic regcred --from-literal=username=user --from-literal=password=pass

Answer

kubectl create secret registry regcred --server=myregistry.io --username=user --password=pass

Question 2

A pod uses a ServiceAccount 'my-sa' with a RoleBinding that grants get and list on pods. The pod makes an API call to list pods in its own namespace. Which RBAC resource is necessary?

Accepted Answer

A RoleBinding that binds the Role to the ServiceAccount. The pod uses a ServiceAccount 'my-sa' and the API call is to list pods in its own namespace. A RoleBinding binds a Role (which contains the rules) to a ServiceAccount within a specific namespace, granting the permissions only in that namespace. Since the operation is namespace-scoped and the Role already has the necessary get and list rules, a RoleBinding is the minimal and correct RBAC resource to associate the Role with the ServiceAccount.

Answer

A Role with the appropriate rules

Answer

A ClusterRoleBinding that binds the ClusterRole to the ServiceAccount

Answer

A ClusterRole with the same rules

Question 3

Which two statements about ConfigMaps and Secrets are correct? (Select TWO.)

Accepted Answer

Secrets store data in base64-encoded form, while ConfigMaps store plaintext. Secrets store data as base64-encoded strings, which is not encryption but a simple encoding that obscures the data. ConfigMaps store data in plaintext (UTF-8) without any encoding. This distinction is fundamental: base64 encoding is reversible and provides no security, while plaintext is human-readable.

Answer

ConfigMaps are immutable and cannot be updated after creation

Answer

ConfigMaps are suitable for storing sensitive data like passwords

Answer

Secrets are encrypted at rest by default in Kubernetes

Question 4

Which three security contexts can be set at the pod level (as opposed to container level)? (Select THREE.)

Accepted Answer

fsGroup. B is correct because `fsGroup` is a Pod-level security context field that applies a supplemental group ID to all containers in the Pod, ensuring that volumes mounted with that group ownership are accessible. It is set under `spec.securityContext.fsGroup`, not at the container level, making it a Pod-scoped setting.

Answer

readOnlyRootFilesystem

Answer

capabilities

Question 5

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 6

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 7

A pod needs to mount a Secret named 'db-secret' as a volume at /etc/secret. Which volume mount definition is correct?

Accepted Answer

volumes:
- name: secret-volume
  secret:
    secretName: db-secret. It uses the proper `secret` key under the `volumes` field to reference a Secret object by its `secretName`. When this volume is mounted at `/etc/secret`, Kubernetes automatically creates a file for each key in the Secret, with the file content being the decoded value of the key. This is the standard syntax for mounting a Secret as a volume.

Answer

volumes:
- name: secret-volume
  secretVolumeSource:
    secretName: db-secret

Answer

volumes:
- name: db-secret
  secret:
    secretName: db-secret

Answer

volumes:
- name: secret-volume
  secret:
    name: db-secret

Question 8

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 9

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 10

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 11

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 12

A pod's container has securityContext with runAsNonRoot: true but no runAsUser set. The container image has a user 'appuser' with UID 1001. Will the pod run successfully?

Accepted Answer

Yes, because the container image user is non-root. When `runAsNonRoot: true` is set in the pod's security context without an explicit `runAsUser`, Kubernetes checks the container image's user (as defined in the Dockerfile `USER` directive). If that user is non-root (UID 1001 in this case), the container runs as that user, satisfying the non-root requirement. The pod will start successfully because the image user is non-root, and no explicit `runAsUser` is required.

Answer

No, because runAsNonRoot requires an explicit runAsUser

Answer

No, because the container image user is unknown

Answer

Yes, because runAsNonRoot is ignored if runAsUser is not set

Question 13

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 14

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 15

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