CCNA Application Environment, Configuration and Security Questions — Page 4 of 4

226

MCQhard

A pod is failing to start. The 'kubectl describe pod' output shows: 'container has runAsNonRoot and image will run as root'. The Dockerfile of the container image does not specify a USER directive. Which action will fix the issue?

A.Set 'runAsGroup: 1000' in the securityContext

B.Add capability 'CAP_SYS_ADMIN' to the container

C.Remove the 'runAsNonRoot: true' line from the pod spec

D.Add 'runAsUser: 1000' to the container's securityContext

AnswerD

Setting runAsUser to a non-zero UID ensures the container runs as a non-root user, satisfying the runAsNonRoot constraint.

Why this answer

Option D is correct because the error 'container has runAsNonRoot and image will run as root' indicates the pod's securityContext enforces runAsNonRoot: true, but the container image runs as root (default user). Adding runAsUser: 1000 explicitly sets the container's user to a non-root UID, satisfying the runAsNonRoot constraint and allowing the pod to start.

Exam trap

CNCF often tests the misconception that runAsGroup or capabilities can override the user identity, but only runAsUser (or a USER directive in the Dockerfile) changes the effective UID to satisfy runAsNonRoot.

How to eliminate wrong answers

Option A is wrong because setting runAsGroup: 1000 only changes the group ID, not the user ID; the container still runs as root (UID 0), which violates runAsNonRoot. Option B is wrong because adding CAP_SYS_ADMIN grants elevated Linux capabilities but does not change the user the container runs as; the container remains root, so runAsNonRoot still fails. Option C is wrong because removing runAsNonRoot: true would bypass the security check, but this is a security downgrade and not the intended fix; the question implies the constraint should be satisfied, not removed.

Practice this question →

227

MCQhard

An administrator creates a Role and RoleBinding in the 'dev' namespace to allow a ServiceAccount 'sa-dev' to list Pods. Which YAML snippet correctly defines the Role?

A.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: {name: pod-reader, namespace: dev} rules: - apiGroups: [""] resources: ["pods"] verbs: ["create"]

B.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: {name: pod-reader, namespace: dev} rules: - apiGroups: ["v1"] resources: ["pods"] verbs: ["list"]

C.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: {name: pod-reader, namespace: dev} rules: - apiGroups: ["apps/v1"] resources: ["pods"] verbs: ["get"]

D.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: {name: pod-reader, namespace: dev} rules: - apiGroups: [""] resources: ["pods"] verbs: ["list"]

AnswerD

Correct apiGroups and verbs for listing pods.

Why this answer

Option D is correct because it uses the empty string `""` for `apiGroups`, which represents the core API group where Pods reside, and specifies the `list` verb to allow listing Pods. This matches the requirement to allow the ServiceAccount 'sa-dev' to list Pods in the 'dev' namespace.

Exam trap

The trap here is that candidates often confuse the core API group with the version string `v1` or mistakenly use `apps/v1` for Pods, and they may also confuse `list` with `get` or `create`, leading to incorrect verb selection.

How to eliminate wrong answers

Option A is wrong because it uses the verb `create` instead of `list`, which would allow creating Pods but not listing them. Option B is wrong because it incorrectly specifies `apiGroups: ["v1"]`; the core API group is represented by an empty string `""`, not `"v1"`. Option C is wrong because it uses `apiGroups: ["apps/v1"]`, which is for resources like Deployments, not Pods (Pods are in the core API group), and the verb `get` does not allow listing.

Practice this question →

228

MCQmedium

A Pod is running in a namespace with a ResourceQuota that sets 'limits.memory: 2Gi'. The pod's container spec has 'resources.limits.memory: 1Gi' and 'resources.requests.memory: 512Mi'. The pod is in 'Running' state but consumes 1.5Gi of memory. What happens?

A.The pod will be evicted by the kubelet due to namespace quota violation

B.The container will continue running because the namespace quota allows up to 2Gi

C.The container will be OOMKilled because it exceeds its own memory limit of 1Gi

D.The pod will be throttled by the kernel to stay within 1Gi

AnswerC

Correct. The container's limit is 1Gi. Exceeding that triggers OOMKill.

Why this answer

The container has a hard memory limit of 1Gi set in its resources.limits.memory. When the container's memory usage exceeds this limit (1.5Gi > 1Gi), the Linux kernel's OOM killer terminates the container process. The namespace ResourceQuota of 2Gi is not violated because the pod's limit (1Gi) is within the quota, so the kubelet does not evict the pod.

Exam trap

The trap here is that candidates confuse namespace-level ResourceQuota enforcement with container-level memory limit enforcement, assuming the quota's higher value allows the container to exceed its own limit.

How to eliminate wrong answers

Option A is wrong because the namespace quota sets a limit of 2Gi, and the pod's configured limit of 1Gi is within that quota; the kubelet only evicts pods when the total usage exceeds the quota, not when a single container exceeds its own limit. Option B is wrong because the container cannot continue running when it exceeds its own hard memory limit of 1Gi; the kernel enforces the container's limit independently of the namespace quota. Option D is wrong because memory is not throttled like CPU; exceeding a memory limit triggers an OOM kill, not throttling.

Practice this question →

229

MCQeasy

A Secret of type kubernetes.io/tls requires two data keys. What are they?

A.ca.crt and tls.key

B.certificate and key

C.cert.crt and cert.key

D.tls.crt and tls.key

AnswerD

Correct according to Kubernetes documentation.

Why this answer

Kubernetes requires that a Secret of type `kubernetes.io/tls` contain exactly two data keys: `tls.crt` for the TLS certificate and `tls.key` for the private key. This is mandated by the Kubernetes API specification for TLS secrets, which are used to secure ingress and other TLS-terminated endpoints.

Exam trap

The trap here is that candidates often confuse the required key names with common file extensions or generic terms like `certificate` and `key`, but Kubernetes enforces the exact keys `tls.crt` and `tls.key` for TLS secrets.

How to eliminate wrong answers

Option A is wrong because `ca.crt` is an optional key for a CA certificate, not a required key for a TLS secret; the required keys are `tls.crt` and `tls.key`. Option B is wrong because `certificate` and `key` are generic names that do not match the exact key names (`tls.crt` and `tls.key`) required by the Kubernetes API for TLS secrets. Option C is wrong because `cert.crt` and `cert.key` are not the standard key names; Kubernetes specifically expects `tls.crt` and `tls.key` as defined in the Secret type `kubernetes.io/tls`.

Practice this question →

230

Multi-Selectmedium

Which TWO of the following are valid ways to consume a Secret named 'db-secret' in a Pod? (Choose two.)

Select 2 answers

A.As environment variables using env with valueFrom.configMapKeyRef

B.As environment variables using envFrom with secretRef

C.As a command-line argument using $(DB_PASSWORD)

D.As files mounted via a volume with secret.secretName

E.As an imagePullSecrets entry

AnswersB, D

Correct.

Why this answer

Option B is correct because `envFrom` with `secretRef` allows a Pod to consume all key-value pairs from a Secret named 'db-secret' as environment variables. This is a standard Kubernetes feature for injecting Secret data into containers without needing to specify each key individually.

Exam trap

CNCF often tests the distinction between `configMapKeyRef` and `secretKeyRef` — candidates mistakenly use `configMapKeyRef` for Secrets because both are key-value stores, but Secrets require `secretKeyRef` for individual key injection.

Practice this question →

231

MCQmedium

You need to create a Secret of type kubernetes.io/tls for use with an Ingress. Which kubectl command should you use?

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

B.kubectl create secret docker-registry my-tls --docker-username=user --docker-password=pass

C.kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem

D.kubectl create secret tls my-tls --from-file=tls.crt --from-file=tls.key

AnswerA

Correct. This creates a TLS secret with the provided certificate and key.

Why this answer

Option A is correct because `kubectl create secret tls` is the dedicated command for creating a TLS secret, which automatically stores the certificate and key under the expected keys `tls.crt` and `tls.key` respectively. This secret type (`kubernetes.io/tls`) is required by Ingress controllers to serve HTTPS traffic, and the command directly accepts `--cert` and `--key` flags for the PEM-encoded files.

Exam trap

The trap here is that candidates confuse the `--from-file` pattern (used with `generic` secrets) with the `tls` subcommand, or mistakenly think any secret containing a cert and key will work for Ingress, when in fact the secret must be of type `kubernetes.io/tls` with the exact keys `tls.crt` and `tls.key`.

How to eliminate wrong answers

Option B is wrong because `kubectl create secret docker-registry` creates a secret of type `kubernetes.io/dockerconfigjson` for container registry authentication, not for TLS certificates. Option C is wrong because `kubectl create secret generic` creates a generic Opaque secret, which stores files as arbitrary keys (e.g., `cert.pem` and `key.pem`) but does not set the required `tls.crt` and `tls.key` keys, and the type will not be `kubernetes.io/tls`, so Ingress will not recognize it. Option D is wrong because `kubectl create secret tls` does not accept `--from-file` flags; it requires the `--cert` and `--key` flags to correctly populate the secret's data fields.

Practice this question →

232

Multi-Selecthard

Which THREE of the following are valid fields in a LimitRange resource to enforce resource constraints at the container level? (Choose three.)

Select 3 answers

A.min

B.defaultRequest

C.default

D.maxLimitRequestRatio

AnswersA, B, C

Minimum resource requests/limits for containers.

Why this answer

Option A is correct because `min` is a valid field in a LimitRange resource that specifies the minimum amount of resources (CPU or memory) a container can request or consume. This constraint is enforced at the container level, ensuring no container uses less than the defined minimum.

Exam trap

The trap here is that `maxLimitRequestRatio` is a valid LimitRange field, but candidates often confuse it with a direct constraint like `min` or `default`, leading them to select it as one of the three correct answers when the question specifically expects `min`, `defaultRequest`, and `default`.

Practice this question →

233

MCQhard

You have a pod that needs to mount a Secret as a volume. The Secret has keys 'username' and 'password'. How should the volumes and volumeMounts be configured to mount the secret at /etc/secret with each key as a file?

A.volumes: - name: secret-vol hostPath: path: /etc/secret containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret

B.volumes: - name: secret-vol configMap: name: my-secret containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret

C.volumes: - name: secret-vol emptyDir: {} containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret

D.volumes: - name: secret-vol secret: secretName: my-secret containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret

AnswerD

Standard way to mount a secret as a volume.

Why this answer

Option D is correct because it uses the `secret` volume type with `secretName: my-secret`, which mounts the specified Kubernetes Secret as a volume. When mounted at `/etc/secret`, each key in the Secret (e.g., 'username' and 'password') becomes a file in that directory, with the file name matching the key and the file content being the decoded value of the key. This is the standard method for exposing Secret data as files in a pod.

Exam trap

The trap here is that candidates may confuse the `secret` volume type with `configMap` (Option B) or incorrectly assume that `hostPath` (Option A) can be used to reference a Secret, when in fact only the `secret` volume type with the correct `secretName` field will mount the Secret's keys as files.

How to eliminate wrong answers

Option A is wrong because `hostPath` mounts a directory from the host node's filesystem, not a Kubernetes Secret; it does not provide the Secret's key-value pairs as files. Option B is wrong because `configMap` is used for ConfigMaps, not Secrets; while the syntax is similar, Secrets require the `secret` volume type to properly handle base64-encoded data and access control. Option C is wrong because `emptyDir` creates an empty temporary directory that is shared between containers; it does not inject any Secret data into the pod.

Practice this question →