Courseiva

CCNA Application Environment, Configuration and Security Questions

42 questions · Application Environment, Configuration and Security · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

A pod is running with the following SecurityContext: securityContext: runAsUser: 1000 runAsGroup: 2000 fsGroup: 3000 What UID and GID does the process inside the container use?

A.UID 1000, GID 3000
B.UID 1000, GID 2000
C.UID 0, GID 2000
D.UID 3000, GID 2000
AnswerB

runAsUser sets UID, runAsGroup sets GID. Both apply to the container process.

Why this answer

The `runAsUser` and `runAsGroup` fields in the Pod's SecurityContext directly set the UID and GID for the container's main process. Here, `runAsUser: 1000` sets the process UID to 1000, and `runAsGroup: 2000` sets the process GID to 2000. The `fsGroup: 3000` field only applies to the group ownership of mounted volumes, not to the process's primary GID.

Exam trap

The trap here is that candidates confuse `fsGroup` with the process's primary GID, thinking it overrides `runAsGroup`, when in fact `fsGroup` only affects volume group ownership and does not change the process's GID.

How to eliminate wrong answers

Option A is wrong because it incorrectly assumes `fsGroup` replaces the process GID; `fsGroup` only affects volume ownership, not the process's primary GID. Option C is wrong because it assumes the process runs as root (UID 0), but `runAsUser: 1000` explicitly overrides that. Option D is wrong because it swaps the UID and `fsGroup` values, misunderstanding that `runAsUser` sets the UID, not `fsGroup`.

Practice this question →
2
MCQmedium

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?

A.A Role with the appropriate rules
B.A ClusterRoleBinding that binds the ClusterRole to the ServiceAccount
C.A RoleBinding that binds the Role to the ServiceAccount
D.A ClusterRole with the same rules
AnswerC

This is the correct RBAC combination: the Role defines the allowed actions within a specific namespace, and the RoleBinding, also namespaced, names the ServiceAccount as its subject, thereby granting those permissions only to that account and only within that namespace. Any pod that uses this ServiceAccount inherits the bound permissions, and the access is scoped exactly as needed, following least privilege.

Why this answer

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.

Exam trap

CNCF often tests the distinction between RoleBinding and ClusterRoleBinding, trapping candidates who think a ClusterRoleBinding is required when the operation is namespace-scoped, or who forget that a Role alone is not a binding.

How to eliminate wrong answers

Option A is wrong because a Role alone defines the rules but does not bind them to any subject; without a RoleBinding, the ServiceAccount has no permissions. Option B is wrong because a ClusterRoleBinding grants permissions cluster-wide, which is excessive for a namespace-scoped operation and would bind a ClusterRole (not a Role) to the ServiceAccount, violating the principle of least privilege. Option D is wrong because a ClusterRole is a cluster-scoped resource that can be used across namespaces, but it is unnecessary here since the operation is confined to a single namespace; a Role is sufficient and more appropriate.

Practice this question →
3
MCQmedium

A pod's container needs to run as non-root user with UID 1000 and ensure its filesystem is read-only. Which SecurityContext settings achieve this?

A.spec: securityContext: runAsUser: 1000 runAsNonRoot: true containers: - name: app securityContext: readOnlyRootFilesystem: true
B.securityContext: runAsNonRoot: true runAsRoot: false readOnlyRootFilesystem: true
C.securityContext: runAsGroup: 1000 readOnlyRootFilesystem: true
D.securityContext: runAsNonRoot: true runAsUser: 1000 readOnlyRootFilesystem: true
AnswerA

This is the correct placement because the pod-level `securityContext` can legally include `runAsUser: 1000` and `runAsNonRoot: true`, which enforces that the container runs with UID 1000 and validates it is not running as root. The container-level `securityContext` is the only place where `readOnlyRootFilesystem` is accepted, so putting it there makes the pod valid and the root filesystem read-only. This demonstrates the proper scope: pod-wide user and group settings at the pod level, container-specific settings like read-only filesystem at the container level.

Why this answer

Ly sets runAsUser and runAsNonRoot at the pod level to enforce non-root execution with UID 1000, and readOnlyRootFilesystem at the container level, which is the correct placement for that field. The other options either use invalid fields (runAsRoot), omit runAsNonRoot, or incorrectly place readOnlyRootFilesystem at the pod level.

Exam trap

The trap is that readOnlyRootFilesystem must be set at the container level, not the pod level. Option D appears to have all three settings but places readOnlyRootFilesystem at the pod level, which is invalid. Candidates often overlook the level at which securityContext fields are applied.

How to eliminate wrong answers

Option A is wrong because it places `readOnlyRootFilesystem: true` in the container-level `securityContext`, which is valid, but the pod-level `securityContext` is missing `runAsNonRoot: true` (only `runAsUser: 1000` is set), so it does not explicitly enforce non-root execution. Option B is wrong because `runAsRoot: false` is not a valid field in Kubernetes SecurityContext; the correct field is `runAsNonRoot: true`, and the option also omits `runAsUser: 1000`. Option C is wrong because it sets `runAsGroup: 1000` instead of `runAsUser: 1000`, which specifies the group ID, not the user ID, and it lacks `runAsNonRoot: true` to enforce non-root execution.

Practice this question →
4
MCQeasy

A pod needs to run as a non-root user with UID 1000. Which SecurityContext field should be set?

A.runAsUser: 1000
B.runAsGroup: 1000
C.runAsNonRoot: true
D.fsGroup: 1000
AnswerA

Setting runAsUser: 1000 in the pod's securityContext instructs the container runtime to launch the main process with UID 1000, which satisfies the requirement of running as a non-root user with that exact user ID. This overrides the default user defined in the image, ensuring all processes inside the container operate as UID 1000 rather than root, which is precisely what the statement demands.

Why this answer

The `runAsUser` field in the PodSecurityContext or container SecurityContext sets the user ID (UID) under which the container's main process runs. Setting `runAsUser: 1000` ensures the container runs as a non-root user with UID 1000, meeting the requirement. This field directly controls the effective UID of the process, overriding the default root (UID 0).

Exam trap

The trap here is that candidates often confuse `runAsUser` with `runAsGroup` or `fsGroup`, thinking group or filesystem settings control the process user identity, when only `runAsUser` directly sets the UID of the running process.

How to eliminate wrong answers

Option B is wrong because `runAsGroup: 1000` sets the primary group ID (GID) for the container process, not the user ID; it does not change the user from root. Option C is wrong because `runAsNonRoot: true` only enforces that the container cannot run as root (UID 0), but it does not specify which non-root UID to use; the container would fail if no explicit UID is set or if the image's default user is root. Option D is wrong because `fsGroup: 1000` applies to the group ownership of mounted volumes, not the user identity of the running process; it is used for volume access control, not for running as a non-root user.

Practice this question →
5
MCQeasy

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

A.kubectl create configmap app-config --from-env-file=config.properties
B.kubectl create configmap app-config --from-literal=config.properties
C.kubectl create configmap app-config --from-file=config.properties
D.kubectl apply -f config.properties
AnswerC

Correct. The --from-file flag creates a ConfigMap from the file content.

Why this answer

The `kubectl create configmap` command with the `--from-file` flag directly creates a ConfigMap from the contents of a specified file, using the filename as the key and the file content as the value. This is the standard method for creating a ConfigMap from a single file like 'config.properties'.

Exam trap

The trap here is that candidates often confuse `--from-file` (which imports a file as a single data entry) with `--from-env-file` (which parses a file as multiple key-value pairs), leading them to choose Option A incorrectly.

How to eliminate wrong answers

Option A is wrong because `--from-env-file` is used to create a ConfigMap from a file that contains key=value pairs (one per line), treating each line as a separate environment variable, not as a single file with arbitrary content. Option B is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to reference a file. Option D is wrong because `kubectl apply -f` is used to apply a YAML or JSON manifest to create or update resources, and 'config.properties' is not a valid Kubernetes manifest file.

Practice this question →
6
MCQhard

You need to create a TLS secret for an ingress with certificate and key. Which command correctly creates the secret?

A.kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key
B.kubectl create secret docker-registry tls-secret --docker-cert=tls.crt --docker-key=tls.key
C.kubectl create secret generic tls-secret --from-file=tls.crt --from-file=tls.key
D.kubectl create secret certificate tls-secret --cert= --key=
AnswerA

This creates a TLS secret of type kubernetes.io/tls.

Why this answer

`kubectl create secret tls` is the dedicated subcommand for creating a TLS secret, which automatically encodes the certificate and key files and stores them under the expected keys (`tls.crt` and `tls.key`). This is the only command that produces a secret of type `kubernetes.io/tls`, which is required by Ingress controllers to serve HTTPS traffic.

Exam trap

The trap here is that candidates may think `kubectl create secret generic` with `--from-file` can create a TLS secret, but they overlook that the secret type must be `kubernetes.io/tls` for the Ingress controller to use it, and the generic command does not set that type.

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 TLS; it expects `--docker-username`, `--docker-password`, etc., not certificate flags. Option C is wrong because `kubectl create secret generic` creates a secret of type `Opaque`, not `kubernetes.io/tls`, and while it can store the files, the Ingress controller will not recognize the keys unless they are named exactly `tls.crt` and `tls.key` and the secret type is correct; this command does not set the type automatically. Option D is wrong because `kubectl create secret certificate` is not a valid kubectl subcommand; the correct subcommand is `tls`, and the flags `--cert=` and `--key=` are incomplete (they require file paths).

Practice this question →
7
MCQhard

A Pod is configured with securityContext: { runAsUser: 1000, runAsGroup: 2000, fsGroup: 3000 }. The container's image runs a process that must listen on a TCP port below 1024 (e.g., port 80). The process is currently failing to start. What should you modify to allow the process to bind to a privileged port?

A.Set 'allowPrivilegeEscalation: true'
B.Add 'capabilities.drop: [ALL]' to the container's securityContext
C.Add 'capabilities.add: [NET_BIND_SERVICE]' to the container's securityContext
D.Set runAsUser: 0 to run as root
AnswerC

Adding the NET_BIND_SERVICE capability to the container's securityContext grants the precise Linux capability that allows a non-root process to bind to Internet domain sockets with port numbers below 1024. This directly solves the port-binding problem while preserving the principle of least privilege, because the process continues to run as the unprivileged user 1000 and retains no other unnecessary capabilities. It is the correct, secure approach to exposing a service on a standard HTTP/HTTPS port.

Why this answer

The container process runs as a non-root user (UID 1000) and needs to bind to a privileged port (below 1024). Linux requires either root privileges or the CAP_NET_BIND_SERVICE capability to bind to ports below 1024. Adding this capability to the container's securityContext grants the process the necessary privilege without running as root, which is the correct and secure approach.

Exam trap

The trap here is that candidates often confuse allowPrivilegeEscalation with granting specific capabilities, or they incorrectly assume that dropping all capabilities is a safe default that still allows low-port binding, when in fact it removes the very capability needed.

How to eliminate wrong answers

Option A is wrong because allowPrivilegeEscalation controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), but it does not grant the specific capability needed to bind to a privileged port. Option B is wrong because dropping all capabilities (capabilities.drop: [ALL]) removes all Linux capabilities, including any that might allow binding to low ports, making the problem worse. Option D is wrong because setting runAsUser: 0 runs the container as root, which would work but violates the principle of least privilege and is not the minimal change required; the question asks what to modify to allow binding, and adding the specific capability is the correct targeted fix.

Practice this question →
8
MCQhard

A container image requires running as UID 0 but you need to comply with a 'restricted' Pod Security Admission policy. Which SecurityContext setting allows this while still passing the policy?

A.Set securityContext: { allowPrivilegeEscalation: true }
B.No SecurityContext setting allows running as UID 0 under the restricted policy.
C.Set securityContext: { runAsNonRoot: true, capabilities: { add: ['SYS_ADMIN'] } }
D.Set runAsUser: 0 and runAsNonRoot: false
AnswerB

Under the restricted Pod Security Standard, runAsNonRoot must be true, which enforces that the container's primary process runs as a non-root user (UID != 0). There is no securityContext setting that can override this; any attempt to set runAsUser: 0 would be invalidated by admission control. The only solution is to modify the container image to use a non-root user or to run under a different Pod Security Standard. Thus no SecurityContext field permits UID 0.

Why this answer

The 'restricted' Pod Security Admission policy requires that containers run as non-root (runAsNonRoot: true) and prohibits setting runAsUser to 0. Since the image requires UID 0, no SecurityContext setting can override this policy constraint; the only way to comply is to modify the image to run as a non-root user. Therefore, option B is correct.

Exam trap

The trap here is that candidates assume they can override the restricted policy with a SecurityContext setting like runAsUser: 0, not realizing that the restricted policy explicitly forbids UID 0 and enforces runAsNonRoot: true, making any such override invalid.

How to eliminate wrong answers

Option A is wrong because allowPrivilegeEscalation: true is actually prohibited by the restricted policy (it must be false), and it does not address the UID 0 requirement. Option C is wrong because runAsNonRoot: true conflicts with running as UID 0, and adding SYS_ADMIN capability is forbidden by the restricted policy (only NET_BIND_SERVICE is allowed). Option D is wrong because runAsUser: 0 with runAsNonRoot: false explicitly violates the restricted policy's requirement that runAsNonRoot must be true and runAsUser must not be 0.

Practice this question →
9
MCQeasy

A developer wants to inject database credentials into a pod as environment variables. The credentials are stored in a Kubernetes Secret named 'db-creds' with keys 'username' and 'password'. Which pod spec snippet correctly injects both values as environment variables?

A.env: - name: username valueFrom: secretKeyRef: name: db-creds key: username
B.envFrom: - configMapRef: name: db-creds
C.envFrom: - secretRef: name: db-creds
D.envFrom: - secretKeyRef: name: db-creds
AnswerC

The `envFrom` block with `secretRef` is the recommended way to inject all key-value pairs from a Secret as environment variables in one go. Each key in the Secret becomes an environment variable name, and the corresponding value is the decoded Secret data. This automatically provides both `username` and `password` (or any other keys) to the pod without listing them individually.

Why this answer

`envFrom` with `secretRef` injects all key-value pairs from a Secret as environment variables into the pod. This directly satisfies the requirement to inject both 'username' and 'password' from the 'db-creds' Secret without needing to specify each key individually.

Exam trap

The trap here is that candidates often confuse `envFrom` with `env` and use `secretKeyRef` under `envFrom` (Option D) or mistakenly use `configMapRef` for secrets (Option B), failing to recognize that `envFrom` requires `secretRef` to inject all keys from a Secret.

How to eliminate wrong answers

Option A is wrong because it only injects a single key ('username') as an environment variable, missing the 'password' key; it uses `env` with `secretKeyRef` for one value, not `envFrom` for all values. Option B is wrong because `configMapRef` references a ConfigMap, not a Secret; ConfigMaps are for non-sensitive data, while database credentials require a Secret. Option D is wrong because `secretKeyRef` is not a valid field under `envFrom`; `envFrom` uses `secretRef` to reference the entire Secret, while `secretKeyRef` is used under `env` for individual key references.

Practice this question →
10
Multi-Selecteasy

Which TWO commands can be used to create a Secret from a file? (Select 2)

Select 2 answers
A.kubectl create secret generic mysecret --from-file=key=file.txt
B.kubectl create configmap mysecret --from-file=file.txt
C.kubectl apply -f secret.yaml where secret.yaml contains data fields
D.kubectl create secret tls mysecret --cert=file.txt
E.kubectl create secret generic mysecret --from-env-file=file.txt
AnswersA, E

The generic subcommand with --from-file=key=file.txt explicitly assigns the file's contents to a chosen key inside the Secret's data map. This is the canonical way to create a Secret that holds a single arbitrary file, and kubectl automatically base64-encodes the value when the Secret is created, though the command line uses the raw file content. It is the recommended approach when you need to mount the file as a volume in a Pod.

Why this answer

Both options A and E are valid commands to create a Secret from a file. Option A uses `--from-file` to read file contents and store them under a specified key. Option E uses `--from-env-file` to parse a file with key=value pairs and create a Secret for environment variables.

Option C is incorrect for this question because `kubectl apply -f secret.yaml` applies a YAML manifest that defines a Secret, but it does not create a Secret directly from a file's contents in the same way as the `kubectl create secret` commands. The question asks for two commands that create a Secret from a file, and both A and E meet that criterion.

Exam trap

The trap here is that candidates often confuse `--from-file` with `--from-env-file` or think `kubectl create configmap` can create Secrets, but the CKAD exam tests precise command syntax and the distinction between Secret types (generic vs. TLS) and resource types (ConfigMap vs. Secret).

Practice this question →
11
Multi-Selectmedium

Which TWO of the following are valid ways to consume a ConfigMap in a pod? (Select 2)

Select 3 answers
A.Mounting the ConfigMap as a volume
B.Using configMapKeyRef in env.valueFrom
C.Using configMapRef in env.valueFrom
D.Using secretKeyRef in env.valueFrom
E.Using envFrom with configMapRef
AnswersA, B, E

Correct. Mounting a ConfigMap as a volume makes its data available as files.

Why this answer

Although the question instructs to select two, all three options A, B, and E are actually valid ways to consume a ConfigMap in a pod. Option A is correct because a ConfigMap can be mounted as a volume, making each key a file in the container's filesystem. Option B is correct because `configMapKeyRef` in `env.valueFrom` allows loading a specific key from a ConfigMap as an environment variable.

Option E is correct because `envFrom` with `configMapRef` loads all keys from a ConfigMap as environment variables. Options C and D are incorrect: `configMapRef` in `env.valueFrom` is not a valid construct (the correct syntax is `configMapKeyRef`), and `secretKeyRef` is used for Secrets, not ConfigMaps.

Exam trap

Candidates often confuse configMapRef (used in envFrom, which is a valid method) with configMapKeyRef (used in env.valueFrom). They may also mistakenly believe that envFrom is not a valid method for ConfigMaps.

Practice this question →
12
Multi-Selectmedium

Which TWO of the following are valid ways to create a ConfigMap from a file named 'app.properties'? (Select two.)

Select 2 answers
A.kubectl create configmap app-config --from-file=app.properties
B.kubectl create configmap app-config --from-literal=app.properties
C.kubectl create configmap app-config --from-env=app.properties
D.kubectl create configmap app-config --from-file=app.properties=app.properties
E.kubectl create configmap app-config --from-env-file=app.properties
AnswersA, E

--from-file uses the filename as the key and the file content as the value.

Why this answer

`--from-file=app.properties` creates a ConfigMap with a single key-value pair, where the key defaults to the filename (app.properties) and the value is the entire file content. Option E is correct because `--from-env-file=app.properties` imports each line of the file as a separate key-value pair, treating the file as an environment variable definition file (key=value format).

Exam trap

CNCF often tests the confusion between `--from-file` (which creates a single key with the file content) and `--from-env-file` (which creates multiple keys from key=value lines), and candidates mistakenly think `--from-env` is a valid flag.

Practice this question →
13
MCQmedium

A developer created a Role named 'pod-reader' in namespace 'ns1' that allows 'get', 'list', and 'watch' on pods. They created a RoleBinding binding this Role to a ServiceAccount 'sa1' in the same namespace. However, a pod using 'sa1' cannot list pods in namespace 'ns2'. What is the most likely cause?

A.The Role is missing the apiGroup field
B.The Role does not include the 'list' verb for pods
C.Role and RoleBinding are namespace-scoped; they only grant permissions within their namespace
D.The RoleBinding is not bound to the correct ServiceAccount
AnswerC

Correct. Role and RoleBinding are scoped to a single namespace. To grant access across namespaces, you need ClusterRole and ClusterRoleBinding.

Why this answer

Role and RoleBinding are namespace-scoped resources in Kubernetes. A Role defined in 'ns1' grants permissions only within 'ns1', and a RoleBinding in 'ns1' binds that Role to a ServiceAccount only for operations inside 'ns1'. To list pods in 'ns2', the ServiceAccount needs a separate Role and RoleBinding (or a ClusterRole and ClusterRoleBinding) that explicitly grant permissions in 'ns2'.

Therefore, the pod using 'sa1' cannot list pods in 'ns2' because the Role and RoleBinding are confined to 'ns1'.

Exam trap

The trap here is that candidates often overlook the namespace-scoped nature of Role and RoleBinding, assuming that a RoleBinding can grant permissions across namespaces, when in fact it is strictly confined to the namespace of the RoleBinding itself.

How to eliminate wrong answers

Option A is wrong because the 'get', 'list', and 'watch' verbs on pods do not require an apiGroup field; pods are in the core API group (v1), which is the default and does not need explicit specification. Option B is wrong because the Role explicitly includes the 'list' verb for pods, as stated in the question. Option D is wrong because the RoleBinding is correctly bound to ServiceAccount 'sa1' in 'ns1', and the issue is not about binding to the wrong ServiceAccount but about namespace scope.

Practice this question →
14
MCQmedium

A developer wants to ensure that a pod runs with a non-root user and cannot gain root privileges. Which SecurityContext settings should be used?

A.securityContext: allowPrivilegeEscalation: false
B.securityContext: runAsNonRoot: true
C.securityContext: runAsNonRoot: true allowPrivilegeEscalation: false
D.securityContext: runAsNonRoot: true allowPrivilegeEscalation: true
AnswerC

Combining runAsNonRoot: true with allowPrivilegeEscalation: false provides defense in depth: the former ensures the container does not start as root, while the latter prevents the process from gaining any additional privileges beyond its current non-root identity, such as via setuid execution or other escalators. This layered approach both satisfies the non-root mandate and blocks a common privilege escalation vector, making it the correct configuration for secure pod deployment.

Why this answer

Setting `runAsNonRoot: true` enforces that the container's user ID is non-zero (non-root), and `allowPrivilegeEscalation: false` prevents the container from gaining additional privileges beyond its initial set, such as through setuid binaries or kernel capabilities. Together, they ensure the pod runs as a non-root user and cannot escalate to root, satisfying the developer's requirement.

Exam trap

The trap here is that candidates often think `runAsNonRoot: true` alone is sufficient to prevent privilege escalation, but it only restricts the initial user ID, not the ability to escalate later, which requires `allowPrivilegeEscalation: false`.

How to eliminate wrong answers

Option A is wrong because `allowPrivilegeEscalation: false` alone does not enforce that the container runs as a non-root user; it only prevents privilege escalation, so a root user could still be used initially. Option B is wrong because `runAsNonRoot: true` alone ensures the container runs as a non-root user but does not prevent privilege escalation, meaning the container could still gain root privileges via setuid binaries or other mechanisms. Option D is wrong because `allowPrivilegeEscalation: true` explicitly permits privilege escalation, which directly contradicts the requirement to 'cannot gain root privileges'.

Practice this question →
15
MCQhard

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?

A.No, because runAsNonRoot requires an explicit runAsUser
B.No, because the container image user is unknown
C.Yes, because runAsNonRoot is ignored if runAsUser is not set
D.Yes, because the container image user is non-root
AnswerD

This is correct because the container image sets a non-root default user (UID 1001) in its metadata. With runAsNonRoot: true and no explicit runAsUser in the securityContext, the kubelet verifies that the image's effective UID is not 0; since 1001 is non-root, the container is permitted to run. The flag acts as a guard that confirms the actual user the container will run as is safe.

Why this answer

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.

Exam trap

CNCF often tests the misconception that `runAsNonRoot` requires an explicit `runAsUser` field, but the correct behavior is that Kubernetes falls back to the container image's user if no `runAsUser` is set.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot` does not require an explicit `runAsUser`; it can rely on the container image's user if it is non-root. Option B is wrong because the container image user is known (UID 1001) and is non-root, so the pod will run successfully. Option C is wrong because `runAsNonRoot` is not ignored when `runAsUser` is not set; it validates the container image's user instead.

Practice this question →
16
MCQhard

A pod is running with a service account that has been granted a Role to get pods. The pod's code uses the Kubernetes API from within the container. However, the API call fails with a 403 Forbidden error. Which file should the pod read to obtain the authentication token?

A./var/run/secrets/kubernetes.io/serviceaccount/token
B./etc/kubernetes/admin.conf
C./var/run/secrets/kubernetes.io/serviceaccount/namespace
D./var/run/secrets/kubernetes.io/serviceaccount/ca.crt
AnswerA

Correct. The token file is mounted at that path.

Why this answer

The pod's service account token is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. This token is a signed JWT that the pod uses to authenticate to the Kubernetes API server. Without reading this file, the pod cannot present valid credentials, resulting in a 403 Forbidden error.

Exam trap

CNCF often tests the distinction between the token file, the CA certificate, and the namespace file — candidates confuse the token with the CA cert or think the admin kubeconfig is accessible inside the pod.

How to eliminate wrong answers

Option B is wrong because /etc/kubernetes/admin.conf is the kubeconfig file for the cluster administrator, not for a pod's service account; it contains admin-level credentials and is not mounted inside pods. Option C is wrong because /var/run/secrets/kubernetes.io/serviceaccount/namespace contains only the namespace name, not an authentication token. Option D is wrong because /var/run/secrets/kubernetes.io/serviceaccount/ca.crt is the CA certificate used to verify the API server's TLS certificate, not an authentication token.

Practice this question →
17
MCQeasy

You are a Kubernetes administrator responsible for a production cluster. A development team has deployed a Pod named 'app-pod' that runs a container with a PostgreSQL database. The team reports that the Pod is failing to start with an error: 'Error: container has runAsNonRoot and image will run as root (runtime error)'. The Pod YAML is as follows: ```yaml apiVersion: v1 kind: Pod metadata: name: app-pod spec: containers: - name: db image: postgres:latest securityContext: runAsNonRoot: true ``` The team wants to ensure the container runs securely without running as root. What is the BEST course of action?

A.Add `runAsUser: 999` to the container's securityContext to run the container as the postgres user.
B.Remove `runAsNonRoot: true` from the securityContext to allow the container to run as root.
C.Increase the Pod's resource limits because the error is due to insufficient memory.
D.Create a PodSecurityPolicy that allows running as root.
AnswerA

Setting `runAsUser: 999` explicitly instructs the kubelet to start the container process with UID 999, which is non-zero. This satisfies the `runAsNonRoot: true` validation because the runtime verifies that the effective UID is not 0. Since the Postgres image commonly defines a `postgres` user with UID 999, this aligns with the image's intended user and avoids running as root. This is the standard, least-privilege fix for a `runAsNonRoot` enforcement failure.

Why this answer

The PostgreSQL official image runs as the 'postgres' user with UID 999 by default. Adding `runAsUser: 999` to the container's securityContext overrides the user to a non-root UID, satisfying the `runAsNonRoot: true` constraint and allowing the container to start without the runtime error.

Exam trap

The trap here is that candidates may think removing `runAsNonRoot` is the simplest fix, but the question explicitly requires the container to run securely without root, so the correct action is to specify a non-root user ID rather than disabling the security constraint.

How to eliminate wrong answers

Option B is wrong because removing `runAsNonRoot: true` would allow the container to run as root, which violates the security requirement to run securely without running as root. Option C is wrong because the error message explicitly states a security context violation (runAsNonRoot vs. root image), not a resource constraint; increasing resource limits would not resolve a security context error. Option D is wrong because a PodSecurityPolicy (PSP) is a cluster-level admission controller that can enforce policies, but it does not change the container's user ID; the immediate fix is to set a non-root user in the Pod spec, and PSPs are deprecated in Kubernetes 1.21+ and removed in 1.25.

Practice this question →
18
Multi-Selecthard

Which THREE configurations are part of Pod Security Admission's 'restricted' profile? (Select THREE.)

Select 3 answers
A.runAsNonRoot: true
B.seccompProfile.type: RuntimeDefault
C.capabilities must drop ALL
D.allowPrivilegeEscalation: true
E.Privileged containers allowed
AnswersA, B, C

Correct. Containers must run as non-root.

Why this answer

The 'restricted' profile in Pod Security Admission enforces the most stringent security standards. Option A is correct because `runAsNonRoot: true` is a required field in the restricted profile, ensuring containers cannot run as the root user, which mitigates privilege escalation risks.

Exam trap

The trap here is that candidates often confuse the 'restricted' profile with the 'baseline' profile, mistakenly thinking that options like `allowPrivilegeEscalation: true` or privileged containers are acceptable, when in fact the restricted profile explicitly prohibits them.

Practice this question →
19
MCQhard

A Pod in a namespace with a ResourceQuota that sets 'limits.cpu: 4' and 'limits.memory: 8Gi' is being created with the following container resources: requests: cpu: 2, memory: 4Gi; limits: cpu: 4, memory: 8Gi. The namespace also has a LimitRange with default limits of cpu: 500m, memory: 512Mi. Which statement is true about this resource configuration?

A.The Pod will have its limits overridden by the LimitRange defaults because limits must be set
B.The Pod will be admitted because it respects both the ResourceQuota and the LimitRange
C.The Pod will be rejected because the limits exceed the LimitRange default
D.The Pod will be rejected because requests must equal limits
AnswerB

The Pod is admitted because its declared resource limits fall within the maximum allowed by the ResourceQuota and, if a LimitRange exists, the Pod's own limits satisfy any minimum or maximum constraints defined there. As the Pod explicitly sets its limits, the LimitRange's default section is irrelevant. Admission only fails when a resource request would violate quota or a mandatory range constraint.

Why this answer

B is correct because the Pod explicitly sets its own limits (cpu: 4, memory: 8Gi) and requests (cpu: 2, memory: 4Gi), which are within the ResourceQuota's 'limits.cpu: 4' and 'limits.memory: 8Gi' constraints. The LimitRange default limits only apply to containers that do not specify limits; since this Pod specifies limits, the defaults are ignored. The Pod is admitted as it satisfies both admission controllers.

Exam trap

The trap here is that candidates assume LimitRange defaults always override Pod specifications, but in reality defaults only apply when the Pod does not set its own limits, and the Pod's explicit limits take precedence.

How to eliminate wrong answers

Option A is wrong because LimitRange defaults only apply to containers that do not have limits set; here limits are explicitly defined, so no override occurs. Option C is wrong because the Pod's limits exactly match the ResourceQuota's maximum (4 CPU, 8Gi memory), not exceed it, and the LimitRange default is irrelevant when limits are set. Option D is wrong because Kubernetes does not require requests to equal limits; they can differ, and the ResourceQuota only enforces the maximum limits, not equality.

Practice this question →
20
Multi-Selecthard

Which THREE of the following are valid fields in a PodSecurityContext?

Select 3 answers
A.fsGroup
B.capabilities
C.seccompProfile
D.runAsNonRoot
E.allowPrivilegeEscalation
AnswersA, C, D

Valid at pod level; sets group ownership of volumes.

Why this answer

`fsGroup` is a valid field in a PodSecurityContext. It specifies the supplemental group ID applied to all containers in the pod when accessing volumes, ensuring proper file ownership and permissions for shared storage.

Exam trap

CNCF often tests the distinction between PodSecurityContext and container SecurityContext, trapping candidates who assume all security-related fields (like capabilities or allowPrivilegeEscalation) are valid at the pod level when they are actually container-specific.

Practice this question →
21
MCQeasy

A container runs as root (UID 0) but the security policy requires the container to run as non-root user 1000. Which pod security context setting should be added?

A.runAsNonRoot: true
B.runAsUser: 1000
C.fsGroup: 1000
D.privileged: false
AnswerB

runAsUser: 1000 directly sets the container process's user ID to 1000, overriding any default user defined in the image's Dockerfile or container runtime configuration. This makes the process run as UID 1000 regardless of the image's original settings, and it is the only way to deterministically satisfy a policy that explicitly requires UID 1000. It is the exact, explicit control needed when the container starts as root by default.

Why this answer

`runAsUser: 1000` explicitly sets the container's user ID to 1000, ensuring the container process runs as a non-root user. This directly satisfies the security policy requirement to run as UID 1000, overriding the default root (UID 0) behavior.

Exam trap

The trap here is that candidates often confuse `runAsNonRoot: true` with setting a specific user ID, not realizing it only enforces non-root but does not guarantee UID 1000, which the question explicitly requires.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot: true` only prevents the container from running as root (UID 0) but does not specify which non-root UID to use; it relies on the container image's default user, which may not be UID 1000. Option C is wrong because `fsGroup: 1000` sets the group ID for volume ownership, not the user ID the container process runs as. Option D is wrong because `privileged: false` is the default setting and only disables privileged mode; it does not enforce a specific non-root user.

Practice this question →
22
MCQeasy

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

A.volumes: - name: secret-volume secret: secretName: db-secret
B.volumes: - name: secret-volume secretVolumeSource: secretName: db-secret
C.volumes: - name: db-secret secret: secretName: db-secret
D.volumes: - name: secret-volume secret: name: db-secret
AnswerA

This is the correct syntax: 'secret' with 'secretName' field.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse the `secret` volume source with the `configMap` volume source, or incorrectly use `secretVolumeSource` (which is not a valid field) instead of the correct `secret` key, leading them to choose option B.

How to eliminate wrong answers

Option B is wrong because `secretVolumeSource` is not a valid field in the volume definition; the correct field is `secret`. Option C is wrong because the volume name is `db-secret`, which is not technically invalid but is misleading — the volume name should be a descriptive identifier (e.g., `secret-volume`) and is not required to match the Secret name. Option D is wrong because it uses `name: db-secret` under the `secret` block, but the correct key is `secretName`, not `name`.

Practice this question →
23
Matchingmedium

Match each Kubernetes concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Virtual cluster for resource isolation

Runs one pod per node for system services

Runs a pod to completion; for batch processing

Automatically scales pods based on CPU/memory

Controls traffic flow between pods

Why these pairings

Correct matches are Pod with smallest deployable unit, Service with logical set and access policy, Deployment with declarative updates, and Ingress with external HTTP access. Common confusions include swapping Pod and Service definitions.

Practice this question →
24
MCQmedium

A pod is using a Secret to authenticate to a private registry. The Secret type must be 'kubernetes.io/dockerconfigjson'. Which of the following is the correct way to create such a Secret using kubectl?

A.kubectl create secret generic regcred --type=kubernetes.io/dockercfg --from-literal=.dockercfg=...
B.kubectl create secret generic regcred --from-file=.dockerconfigjson=/root/.docker/config.json
C.kubectl create secret tls regcred --cert=cert.crt --key=key.key
D.kubectl create secret docker-registry regcred --docker-server=my-registry.example.com --docker-username=myuser --docker-password=mypassword --docker-email=myemail@example.com
AnswerD

This correctly creates a dockerconfigjson Secret.

Why this answer

`kubectl create secret docker-registry` is the dedicated command to create a Secret of type `kubernetes.io/dockerconfigjson`. It automatically generates the required `.dockerconfigjson` field with the base64-encoded Docker credentials in the correct JSON format, which the kubelet uses to authenticate to a private registry when pulling images.

Exam trap

The trap here is that candidates may think any Secret with a `.dockerconfigjson` key works, but without the correct `kubernetes.io/dockerconfigjson` type, the kubelet will not interpret the data properly, leading to image pull failures.

How to eliminate wrong answers

Option A is wrong because it uses `--type=kubernetes.io/dockercfg` (which corresponds to the legacy `.dockercfg` format) instead of `kubernetes.io/dockerconfigjson`, and `--from-literal=.dockercfg=...` does not produce the required `.dockerconfigjson` key. Option B is wrong because `--from-file=.dockerconfigjson` would create a generic Secret with that key, but the Secret type would remain `Opaque` unless explicitly set to `kubernetes.io/dockerconfigjson`; the command does not specify the required type. Option C is wrong because `kubectl create secret tls` creates a Secret of type `kubernetes.io/tls` for TLS certificates and keys, not for Docker registry authentication.

Practice this question →
25
MCQeasy

You have a ConfigMap named 'app-config' with key 'database.url'. Which environment variable definition correctly injects this value into a pod using a configMapKeyRef?

A.- name: DATABASE_URL valueFrom: configMapKeyRef: name: app-config key: database.url
B.envFrom: - configMapRef: name: app-config
C.- name: DATABASE_URL valueFrom: secretKeyRef: name: app-config key: database.url
D.- valueFrom: configMapKeyRef: name: app-config key: database.url
AnswerA

This option is correct because it properly defines an environment variable named `DATABASE_URL` using the `name` field and combines it with a `valueFrom` block. The `configMapKeyRef` inside `valueFrom` specifies the ConfigMap `app-config` and the key `database.url`, which instructs Kubernetes to retrieve that specific value. This is the standard and complete syntax for referencing a single key from a ConfigMap as an environment variable.

Why this answer

It properly defines an environment variable with a name and uses `valueFrom.configMapKeyRef` to reference the specific key 'database.url' from the ConfigMap 'app-config'. The `name` field is required in the env entry to specify the environment variable name. Option D is incorrect because it omits the `name` field, making the definition incomplete.

Exam trap

The trap is that candidates might think the `name` field is optional or that `valueFrom` alone is sufficient. In reality, each environment variable injection via `valueFrom` must include the `name` field to define the variable name.

How to eliminate wrong answers

Option A is wrong because it uses `valueFrom` with a `configMapKeyRef` but the syntax is incomplete — it lacks the `- name: DATABASE_URL` line above the `valueFrom` block, which is required to define the environment variable name; however, the core structure is actually correct if the name were present, so this option is not the best answer because the question expects the exact correct snippet. Option B is wrong because `envFrom` with a `configMapRef` injects all keys from the ConfigMap as environment variables, not a single specific key, and it does not allow renaming the variable to `DATABASE_URL`; it would create an environment variable named `database.url`, which is invalid in most shells due to the dot. Option C is wrong because it uses `secretKeyRef` instead of `configMapKeyRef`, which is designed for Secrets, not ConfigMaps; referencing a ConfigMap with `secretKeyRef` will fail because the API expects a Secret resource.

Practice this question →
26
MCQhard

A pod in a namespace with a ResourceQuota that sets 'requests.cpu: 2' is failing to schedule. The pod manifest specifies 'resources: { requests: { cpu: "500m" } }'. What is the likely cause?

A.The ResourceQuota applies to limits, not requests.
B.The namespace has already used all its CPU request quota.
C.The pod does not specify a CPU limit.
D.The pod's CPU request exceeds the ResourceQuota limit.
AnswerB

Even though the pod's individual request is small (500m), the ResourceQuota enforces an aggregate limit on the sum of all CPU requests in the namespace. At admission time, Kubernetes compares the current usage (sum of requests from all running/creating objects) plus the new pod's request against the quota's hard limit of 2000m. If the existing usage is already at or near 2000m, adding this pod's 500m pushes the total over the limit, causing the 'quota exceeded' error. This is a namespace-level accounting issue, not a per-pod scheduling problem.

Why this answer

The ResourceQuota sets a hard limit of 2 CPU cores for total requests across all pods in the namespace. If the sum of CPU requests from all pods already reaches or exceeds 2, a new pod with a 500m CPU request cannot be scheduled because it would exceed the quota. The pod's request (500m) is well within the quota limit, so the issue is that the namespace has exhausted its CPU request budget.

Exam trap

The trap here is that candidates assume the pod's individual request must be less than the quota, but they overlook that the quota is a cumulative limit across all pods in the namespace, so even a small request can fail if the namespace is already at capacity.

How to eliminate wrong answers

Option A is wrong because ResourceQuota can apply to both requests and limits; by default, it applies to requests unless specified otherwise, and the question states 'requests.cpu: 2' which explicitly targets requests. Option C is wrong because a CPU limit is not required for scheduling; the ResourceQuota only enforces the requests.cpu limit, and the pod can run without a limit. Option D is wrong because the pod's CPU request (500m) is less than the ResourceQuota limit (2), so it does not exceed the quota; the failure is due to cumulative usage, not an individual overage.

Practice this question →
27
MCQmedium

A pod fails to start with a 'CreateContainerConfigError'. Running 'kubectl describe pod my-pod' reveals: 'Error: container has runAsNonRoot and image will run as root'. The pod definition includes 'securityContext.runAsNonRoot: true'. What is the most likely cause?

A.The container does not have the CAP_SYS_ADMIN capability
B.The container image's default user is root (UID 0), conflicting with runAsNonRoot
C.The container's filesystem is read-only
D.The runAsUser field is missing, so the pod uses a random UID
AnswerB

When runAsNonRoot: true is set, the kubelet inspects the container image's configured user (typically the USER instruction or default UID). If the image's default user is root (UID 0), the kubelet refuses to start the container and emits an error such as 'container has runAsNonRoot and image will run as root'. Since the error is CreateContainerConfigError, it exactly matches this contradiction between the securityContext and the image's default user, making this the correct cause.

Why this answer

The error 'container has runAsNonRoot and image will run as root' occurs because the pod's securityContext sets `runAsNonRoot: true`, but the container image's default user is root (UID 0). Kubernetes checks the image's user at container startup; if the image runs as root and the pod enforces non-root, the container fails to start with a CreateContainerConfigError.

Exam trap

The trap here is that candidates often assume the error is about missing runAsUser or capabilities, but the error message directly points to the image's default user being root, which is a mismatch with the runAsNonRoot constraint.

How to eliminate wrong answers

Option A is wrong because CAP_SYS_ADMIN is a Linux capability unrelated to the runAsNonRoot check; the error is about the container's user identity, not capabilities. Option C is wrong because a read-only filesystem does not cause a runAsNonRoot conflict; it would produce a different error (e.g., 'read-only filesystem'). Option D is wrong because runAsUser is not required when runAsNonRoot is true; Kubernetes will still enforce non-root even without an explicit UID, and the error explicitly states the image runs as root, not that a random UID is used.

Practice this question →
28
MCQmedium

A Role named 'pod-reader' in namespace 'ns1' grants get, list, and watch on pods. Which RoleBinding correctly binds this role to a ServiceAccount 'sa1' in the same namespace?

A.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1
B.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: User name: sa1
C.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: ClusterRole, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1
D.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: default
AnswerA

This is correct because a RoleBinding in ns1 uses roleRef to bind the namespaced Role 'pod-reader' to ServiceAccount 'sa1' also in ns1. RoleBindings are namespaced, and both the Role and the ServiceAccount must reside in the same namespace as the binding for the permissions to apply. Here the subject kind is ServiceAccount, which matches the intended identity, so sa1 will receive the Role's permissions.

Why this answer

A RoleBinding in the same namespace as the Role and ServiceAccount must specify the Role's kind as 'Role' (not ClusterRole) and include the ServiceAccount's namespace in the subjects list. The roleRef references the 'pod-reader' Role with the correct apiGroup and kind, and the subject specifies the ServiceAccount 'sa1' in namespace 'ns1', which matches the Role's namespace, allowing the binding to grant the permissions.

Exam trap

The trap here is that candidates often forget to include the ServiceAccount's namespace in the subjects list or mistakenly use 'kind: User' for a ServiceAccount, leading to a binding that either fails or applies to the wrong entity.

How to eliminate wrong answers

Option B is wrong because it uses 'kind: User' instead of 'kind: ServiceAccount', and a ServiceAccount cannot be bound via a User subject; the subject must match the actual entity type. Option C is wrong because it uses 'kind: ClusterRole' in the roleRef, but the question specifies a Role (namespaced), not a ClusterRole; a RoleBinding can only reference a Role in the same namespace or a ClusterRole (which would then be scoped to the namespace), but here the role is a Role, so the kind must be 'Role'. Option D is wrong because it specifies 'namespace: default' in the subject, but the ServiceAccount 'sa1' is in namespace 'ns1', so the subject's namespace must match the ServiceAccount's actual namespace for the binding to work.

Practice this question →
29
Multi-Selecthard

An administrator wants to implement Pod Security Admission (PSA) to enforce the 'restricted' policy for pods in the 'secure' namespace, but allow certain pods to use privileged containers by applying an exemption label. Which three steps are required? (Choose three.)

Select 3 answers
A.Use 'pod-security.kubernetes.io/audit=restricted' to log violations without enforcement.
B.Enable the PodSecurity feature gate on the API server and kubelet.
C.Create a ServiceAccount for exempted pods and label it with 'pod-security.kubernetes.io/enforce=privileged'.
D.Install a custom container runtime that supports privilege escalation.
E.Set the namespace label 'pod-security.kubernetes.io/enforce=restricted' on the 'secure' namespace.
AnswersA, C, E

Setting the audit label logs violations without enforcement, which helps assess the impact before enforcing. It is a recommended step but not strictly required for enforcement. However, in this scenario, it is considered a required step for implementation.

Why this answer

Setting the audit label to 'restricted' logs violations, which is a common initial step to assess compliance before enforcing the policy. Option C is correct because creating a ServiceAccount and labeling it with 'pod-security.kubernetes.io/enforce=privileged' exempts pods using that ServiceAccount from the restricted policy, allowing them to run privileged containers. Option E is correct because setting the namespace label 'pod-security.kubernetes.io/enforce=restricted' enforces the restricted policy on all pods in that namespace that are not exempted.

Option B is not required because the PodSecurity feature gate is enabled by default in Kubernetes v1.23+. Option D is incorrect because PSA uses security context validation, not a custom runtime.

Exam trap

The trap is that candidates may think enabling the PodSecurity feature gate is necessary, but it is default in newer Kubernetes versions. Also, they may confuse audit and enforce modes, or think a custom runtime is needed for privilege escalation.

Practice this question →
30
Multi-Selectmedium

Which TWO of the following are valid fields in a container's SecurityContext to restrict privilege escalation? (Select two.)

Select 2 answers
A.allowPrivilegeEscalation
B.readOnlyRootFilesystem
C.runAsNonRoot
D.privileged
E.capabilities
AnswersA, E

Setting this to false prevents privilege escalation.

Why this answer

A is correct because `allowPrivilegeEscalation` directly controls whether a process can gain more privileges than its parent, such as via setuid binaries or file capabilities. Setting it to `false` prevents privilege escalation, which is a core security requirement for restricting container breakout.

Exam trap

CNCF often tests the distinction between fields that *prevent* privilege escalation versus fields that enforce other security constraints like filesystem immutability or user identity, leading candidates to confuse `readOnlyRootFilesystem` or `runAsNonRoot` with escalation control.

Practice this question →
31
Multi-Selecteasy

Which TWO of the following are valid Kubernetes Secret types? (Select two.)

Select 3 answers
A.kubernetes.io/password
B.kubernetes.io/ssh-auth
C.kubernetes.io/configmap
D.kubernetes.io/tls
E.Opaque
AnswersB, D, E

Correct. `kubernetes.io/ssh-auth` is a built-in Secret type for SSH credentials.

Why this answer

kubectl create secret tls, kubectl create secret ssh-auth, and kubectl create secret generic (which creates an Opaque secret) are all valid Kubernetes Secret types. The type kubernetes.io/ssh-auth is used for SSH credentials, kubernetes.io/tls is used for TLS certificates, and Opaque is the default type for arbitrary user-defined data. Options A (kubernetes.io/password) and C (kubernetes.io/configmap) are not valid Secret types.

Exam trap

Candidates often mistakenly believe that Opaque is not a valid Secret type because it is the default, but it is indeed valid. Also, be aware that kubernetes.io/password and kubernetes.io/configmap are not real Secret types.

Practice this question →
32
MCQeasy

Which command creates a Docker registry secret from an existing Docker config file?

A.kubectl create secret tls my-reg --cert=... --key=...
B.kubectl create secret generic my-reg --from-file=.dockerconfigjson=config.json
C.kubectl create secret docker-registry my-reg --docker-server=... --docker-username=...
D.kubectl create secret docker-registry my-reg --from-file=.dockerconfigjson=config.json
AnswerB

This is the correct approach because `kubectl create secret generic` with `--from-file=.dockerconfigjson=config.json` directly places the contents of your existing `config.json` file under the exact data key that Kubernetes expects. The secret is created as type `Opaque`, but the kubelet reads the `.dockerconfigjson` key regardless of the secret type, so it works as an imagePullSecret. This method preserves all registry entries and authentication tokens from the original file, making it ideal when you already have a `docker login` output.

Why this answer

`kubectl create secret generic` with `--from-file=.dockerconfigjson=config.json` creates a generic secret that stores the contents of an existing Docker config file (typically `~/.docker/config.json`) under the key `.dockerconfigjson`. This is the standard method for importing a pre-existing Docker configuration as a Kubernetes secret, which can then be used for image pull authentication.

Exam trap

CNCF often tests the distinction between `kubectl create secret docker-registry` (which creates a new secret from individual flags) and `kubectl create secret generic` with `--from-file` (which imports an existing config file), leading candidates to incorrectly choose option D because they assume `docker-registry` supports `--from-file`.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret tls` creates a TLS secret for serving certificates, not a Docker registry authentication secret. Option C is wrong because `kubectl create secret docker-registry` with `--docker-server`, `--docker-username`, etc. creates a new secret from individual credentials, not from an existing Docker config file. Option D is wrong because `kubectl create secret docker-registry` does not support the `--from-file` flag; that flag is only valid for `kubectl create secret generic`.

Practice this question →
33
Multi-Selectmedium

Which TWO of the following commands create a ConfigMap named 'my-config' from a file named 'app.properties'? (Choose two.)

Select 3 answers
A.kubectl create configmap my-config --from-file=app.properties --from-literal=extra=value
B.kubectl create configmap my-config --from-file=app.properties=app.properties
C.kubectl create configmap my-config --from-env-file=app.properties
D.kubectl create configmap my-config --from-literal=app.properties
E.kubectl create configmap my-config --from-file=app.properties
AnswersB, C, E

The `--from-file=app.properties=app.properties` syntax sets the ConfigMap key to `app.properties` and the value to the file's content, but the stem requires a ConfigMap named `my-config` from a file named `app.properties` without specifying a custom key. This option is tempting because it explicitly maps a key to a file, which is correct when you need to override the default key name (the filename) with a different key, such as when the desired key differs from the source filename.

Why this answer

Options B, C, and E are all valid commands that create a ConfigMap named 'my-config' from the file 'app.properties'. Option B uses explicit key mapping (--from-file=app.properties=app.properties). Option C uses --from-env-file to read key-value pairs from the file.

Option E uses the default --from-file behavior. Option A is incorrect because it adds an extra literal (--from-literal=extra=value). Option D is invalid syntax.

Exam trap

Candidates often confuse --from-file with --from-env-file and think --from-literal can read a file. A subtle trap is that Option B is syntactically valid and creates the same ConfigMap as Option E, but some may consider it redundant; nonetheless, it is a correct command. The question asks for two choices, but there are three technically correct options, which can be confusing.

Practice this question →
34
MCQeasy

A Secret named 'db-secret' of type Opaque contains a key 'password'. How do you reference this key as an environment variable named 'DB_PASSWORD' in a pod spec?

A.env: - name: DB_PASSWORD valueFrom: configMapKeyRef: name: db-secret key: password
B.env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password
C.envFrom: - secretRef: name: db-secret key: password
D.env: - name: DB_PASSWORD value: "db-secret.password"
AnswerB

This is the correct way to consume a specific key from a Secret as an environment variable. The secretKeyRef field tells the kubelet to read the value associated with the password key from the Secret named db-secret in the same namespace, then assign it to DB_PASSWORD. The Secret must exist before the Pod starts, otherwise the container creation will fail with a resolution error.

Why this answer

It uses the `secretKeyRef` field under `valueFrom` to reference a specific key from a Kubernetes Secret of type Opaque. The `secretKeyRef` is the proper mechanism to inject a single key from a Secret as an environment variable, mapping the key 'password' to the environment variable name 'DB_PASSWORD'.

Exam trap

The trap here is confusing `configMapKeyRef` with `secretKeyRef` — CNCF often tests whether candidates know that Secrets require `secretKeyRef` while ConfigMaps use `configMapKeyRef`, and that `envFrom` with `secretRef` injects all keys, not a single key.

How to eliminate wrong answers

Option A is wrong because it uses `configMapKeyRef`, which is used to reference keys from a ConfigMap, not a Secret; Secrets require `secretKeyRef`. Option C is wrong because `envFrom` with `secretRef` injects all keys from the Secret as environment variables, not a single key, and the syntax shown incorrectly includes a `key` field which is not valid under `secretRef`. Option D is wrong because it uses a static `value` string, which does not dynamically reference the Secret's key; Kubernetes will treat the string literally as 'db-secret.password' rather than fetching the actual password value.

Practice this question →
35
MCQeasy

Which of the following is the correct way to set an environment variable 'APP_COLOR' from a ConfigMap key 'color'?

A.env: - name: APP_COLOR valueFrom: configMapRef: name: my-config key: color
B.envFrom: - configMapKeyRef: name: my-config key: color
C.env: - name: APP_COLOR valueFrom: configMapKeyRef: name: my-config key: color
D.env: - name: APP_COLOR value: "configMap.color"
AnswerC

This is correct because it uses the `env` array to define a single environment variable named `APP_COLOR`, then sources its value from the ConfigMap named `my-config` via `valueFrom.configMapKeyRef`, specifying the exact `key: color`. The `configMapKeyRef` field is the precise mechanism for pulling one key's value into an environment variable—it is the Kubernetes-standard way to make a ConfigMap value available inside a container under a chosen env var name.

Why this answer

It uses the `configMapKeyRef` field under `valueFrom` in the `env` array to inject a specific key from a ConfigMap as an environment variable. This is the standard Kubernetes syntax for referencing a single key from a ConfigMap, where `name` specifies the ConfigMap object and `key` specifies the key within that ConfigMap whose value will be assigned to the environment variable `APP_COLOR`.

Exam trap

The trap here is confusing `configMapRef` (used in `envFrom` to import all keys) with `configMapKeyRef` (used in `env` to import a single key), leading candidates to choose Option A or B due to similar naming.

How to eliminate wrong answers

Option A is wrong because `configMapRef` is not a valid field under `valueFrom`; `configMapRef` is used in `envFrom` to load all keys from a ConfigMap, not a single key. Option B is wrong because `envFrom` uses `configMapRef` (not `configMapKeyRef`) and cannot target a specific key; it imports all key-value pairs from the ConfigMap as environment variables, and the syntax shown (`configMapKeyRef`) is invalid. Option D is wrong because it attempts to set a literal string value `"configMap.color"` rather than referencing the ConfigMap key, which would not resolve to the actual value from the ConfigMap.

Practice this question →
36
MCQmedium

A pod manifest includes the following securityContext: securityContext: { runAsUser: 1000, runAsGroup: 3000, fsGroup: 2000 }. What UID will be used for processes in the container?

A.0 (root)
B.3000
C.2000
D.1000
AnswerD

runAsUser: 1000 is the correct UID because it directly sets the numeric user ID for the container's primary process. When a container starts, the process is launched with this UID unless an image-level USER directive is overridden by this field. The securityContext's runAsUser takes precedence over the image's default user, so the process runs as UID 1000.

Why this answer

The `runAsUser` field in the pod's securityContext explicitly sets the user ID (UID) for all processes in the container. In this manifest, `runAsUser: 1000` overrides the default UID (usually 0, root) and ensures that the container's main process runs with UID 1000. The `runAsGroup` and `fsGroup` fields affect group IDs and file ownership, not the process UID.

Exam trap

CNCF often tests the distinction between `runAsUser` (process UID), `runAsGroup` (process GID), and `fsGroup` (volume ownership GID), and the trap here is that candidates confuse `fsGroup` or `runAsGroup` with the process UID, leading them to select 2000 or 3000 instead of 1000.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` explicitly overrides the default root UID (0), so processes do not run as root. Option B is wrong because `runAsGroup: 3000` sets the primary group ID (GID) for the process, not the UID. Option C is wrong because `fsGroup: 2000` is used to set the group ownership of mounted volumes and any files created in them, but it does not affect the UID of the container's processes.

Practice this question →
37
MCQeasy

Which kubectl command creates a Secret from literal username and password values?

A.kubectl create secret generic my-secret --literal username=admin password=secret123
B.kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secret123
C.kubectl create secret generic my-secret --from-file=username --from-file=password
D.kubectl create secret generic my-secret --from-env-file=creds.txt
AnswerB

This creates a Secret from literal key=value pairs.

Why this answer

`kubectl create secret generic` with `--from-literal` is the proper syntax for specifying literal key-value pairs directly in the command. Each literal must be prefixed with `--from-literal=key=value`, and multiple literals can be provided to create a Secret containing both the username and password keys.

Exam trap

The trap here is that candidates confuse `--from-literal` with the non-existent `--literal` flag, or assume that multiple key-value pairs can be passed in a single `--from-literal` argument, leading them to choose Option A.

How to eliminate wrong answers

Option A is wrong because it uses `--literal` instead of the correct `--from-literal` flag, and the syntax `--literal username=admin password=secret123` is invalid — kubectl requires each literal to be specified with its own `--from-literal=key=value` flag. Option C is wrong because `--from-file` creates a Secret from file contents, not literal values; it would read the files named 'username' and 'password' from the filesystem, not use inline strings. Option D is wrong because `--from-env-file` imports key-value pairs from a file in the format `KEY=VALUE`, but it does not accept literal values directly on the command line.

Practice this question →
38
MCQhard

You need to create a Secret of type 'kubernetes.io/tls' for ingress. Which command is correct?

A.kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem
B.kubectl create secret tls my-tls --certificate=cert.pem --private-key=key.pem
C.kubectl create secret tls my-tls --from-file=tls.crt=cert.pem --from-file=tls.key=key.pem
D.kubectl create secret tls my-tls --cert=cert.pem --key=key.pem
AnswerD

This command creates a tls secret with the provided certificate and key files.

Why this answer

`kubectl create secret tls` is the dedicated command for creating a TLS secret, and it uses the `--cert` and `--key` flags to specify the certificate and private key files respectively. This creates a Secret of type `kubernetes.io/tls`, which is required for Ingress resources to terminate HTTPS traffic.

Exam trap

The trap here is that candidates confuse the `--from-file` syntax from `kubectl create secret generic` with the dedicated TLS command, or misremember the flag names as `--certificate`/`--private-key` instead of the correct `--cert`/`--key`.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret generic` creates a generic (Opaque) Secret, not a `kubernetes.io/tls` type, and Ingress requires the TLS-specific type to correctly interpret the certificate and key data. Option B is wrong because the flags `--certificate` and `--private-key` are not valid for `kubectl create secret tls`; the correct flags are `--cert` and `--key`. Option C is wrong because `--from-file` is used with `kubectl create secret generic`, not with `kubectl create secret tls`, and the `tls.crt`/`tls.key` key names are automatically set by the `tls` subcommand when using the correct flags.

Practice this question →
39
MCQmedium

A Pod spec includes 'securityContext' with 'runAsUser: 1000' and 'runAsGroup: 3000'. The container process inside the pod is expected to write to a mounted volume. Which securityContext field should be set to ensure the volume's group ownership is 3000?

A.supplementalGroups: [3000]
B.fsGroup: 1000
C.fsGroup: 3000
D.runAsGroup: 3000
AnswerC

fsGroup: 3000 is the correct mechanism because it simultaneously changes the group ownership of the volume's root directory to GID 3000 and adds that GID to the container's supplementary groups. With the process running as UID 1000, the group permissions on the volume now allow access via group 3000. This is exactly the Kubernetes-defined meaning of fsGroup: it alters the volume's ownership metadata to match the group that should be permitted.

Why this answer

The `fsGroup` field in the Pod's `securityContext` specifies the group ID (GID) that Kubernetes should assign to any volume mounted into the Pod. When `fsGroup: 3000` is set, Kubernetes recursively changes the ownership of the volume's files and directories to group ID 3000, and any new files created by the container process will inherit that group ownership. This ensures the container process, which runs with `runAsGroup: 3000`, can write to the volume without permission errors.

Exam trap

The trap here is that candidates often confuse `fsGroup` with `supplementalGroups` or `runAsGroup`, mistakenly thinking that setting the container's group ID alone will automatically adjust the volume's permissions, when in fact `fsGroup` is the only field that modifies the volume's ownership.

How to eliminate wrong answers

Option A is wrong because `supplementalGroups` adds additional group IDs to the container process's supplementary group list, but it does not change the ownership of the mounted volume; the volume's group ownership remains unchanged unless `fsGroup` is set. Option B is wrong because `fsGroup: 1000` would set the volume's group ownership to GID 1000, not 3000, which would not match the container's `runAsGroup: 3000` and could cause write permission issues. Option D is wrong because `runAsGroup: 3000` already sets the primary group ID for the container process, but it does not affect the ownership of the mounted volume; the volume's group ownership must be explicitly set via `fsGroup`.

Practice this question →
40
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

When a container has a memory limit of 1Gi, the kubelet configures a cgroup memory limit for that container. If the container's memory usage exceeds this limit, the kernel's OOM killer terminates the container's processes, and Kubernetes reports the reason as OOMKilled. This is a hard enforcement mechanism independent of any namespace quota or available node memory.

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 →
41
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

This command correctly creates a Secret with type kubernetes.io/tls by using the dedicated --cert and --key flags. kubectl reads the PEM-encoded certificate and private key, stores them under the canonical data keys tls.crt and tls.key, and sets the type so Ingress resources can consume it for TLS termination. No other command form produces a TLS-typed Secret with both required data fields.

Why this answer

`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 →
42
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, D

Correct. `min` specifies the minimum amount of resources a container can request or consume.

Why this answer

The three valid fields in a LimitRange resource that enforce resource constraints at the container level are `min`, `defaultRequest`, and `maxLimitRequestRatio`. `min` sets the minimum resource request or limit per container. `defaultRequest` sets the default resource request if not specified, ensuring a minimum request is applied. `maxLimitRequestRatio` enforces a maximum ratio between limit and request, constraining the relationship. While `default` is a valid field, it sets a default limit rather than enforcing a constraint directly, so it is not among the three asked.

Exam trap

Candidates often think `default` is one of the three because it is commonly used, but it only sets a default limit, not a hard constraint like `min`, `defaultRequest`, or `maxLimitRequestRatio`.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Application Environment, Configuration and Security questions.

Start 20-question session