Application Environment, Configuration and Security practice questions

env: - name: DB_URL value: "postgres://db:5432"

Why wrong: This assignment hardcodes a literal string as the value for DB_URL, completely bypassing the db-config ConfigMap. Even if the string matches the intended value, the environment variable is not sourced from Kubernetes configuration data, so any future updates to the ConfigMap will not be reflected in this pod. It also violates the principle of decoupling configuration from the pod definition, making the manifest less flexible and portable.

envFrom: - configMapRef: name: db-config key: DB_URL

Why wrong: The envFrom field is specifically designed to import all key-value pairs from a ConfigMap as environment variables, not to select a single key. Furthermore, the syntax is invalid: configMapRef only accepts a name field, not a key field, so this manifest would fail Kubernetes API validation. Even if the key field were removed, this approach would inject every entry from db-config into the pod's environment, which is not the intended behavior of setting only DB_URL.

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

Why wrong: This snippet incorrectly uses secretKeyRef, which is meant to reference a Kubernetes Secret, not a ConfigMap. When Kubernetes processes this, it looks for a Secret named db-config, not a ConfigMap, so the reference will fail or inject nothing unless a Secret with that name exists. To pull a value from a ConfigMap, you must use configMapKeyRef instead, as the two resource types are distinct and handled by different API fields.

emptyDir

Why wrong: This volume is created when a pod is assigned to a node and exists only as long as that pod runs on that node. It is intended for ephemeral storage, such as scratch space, and is not designed to expose a file from the host node's filesystem. Even if the file existed in an emptyDir, it would be wiped when the pod is deleted and would not be the actual host file the container needs.

persistentVolumeClaim

Why wrong: A PVC provides a storage abstraction that decouples the pod from the underlying storage backend, so it does not expose a specific file from a specific node's filesystem. While a PVC could be backed by a hostPath-based persistent volume, that would require additional configuration and still would not be a direct reference to a particular host file. The claim is meant for durable, node-independent storage, not for reading an arbitrary file from the cluster node.

configMap

Why wrong: A ConfigMap is specifically for injecting environment variables, command-line arguments, or small configuration files into a container, but it does not provide direct access to a file that already exists on the host node. The data in a ConfigMap is authored separately and stored in etcd, then mounted or passed to the container. It cannot be used to read a file that is managed by the node's operating system, so it is the wrong choice for this scenario.

The API server is not running.

Why wrong: When the API server is unreachable, kubectl typically fails with a connection refused or timeout error rather than an HTTP 403 Forbidden. A 403 indicates the request reached the API server and was authenticated but authorization failed, which is a permissions issue, not an infrastructure outage. So this option is incorrect because the error type itself rules out a down API server.

The RoleBinding is in the wrong namespace.

Why wrong: A RoleBinding is namespaced and grants permissions only within its own namespace. The pod is running in the 'app' namespace, and the RoleBinding is also in 'app', so it correctly applies to that pod's service account. If it were in another namespace, it would have no effect, but that is not the case here, so this cannot be the cause of the 403.

The Role does not include list permission.

Why wrong: A Role grants specific verbs on specific resources; if the verb were missing, the API server would return 403 for that action. However, the role does include the list verb for the required resource, so the authorization check would pass. Since the error persists despite having list permission, this option does not explain the failure.

ResourceQuota

Why wrong: ResourceQuota does not manage network traffic at all; it constrains the total computed resources (CPU, memory) and the number of objects (services, PVCs) that can be created in a namespace. While it can indirectly affect workload scheduling, it cannot filter or block specific client-to-pod connections. Therefore it is wrong for this scenario.

PodSecurityPolicy

Why wrong: PodSecurityPolicy (PSP) enforces security constraints on pod specifications, such as allowed privilege escalation, host namespaces, and volume types. Although PSP was deprecated in Kubernetes 1.21 and replaced by Pod Security Admission, it never had any concept of network rules. Thus it cannot be used to restrict ingress/egress traffic.

RoleBinding

Why wrong: RoleBinding grants RBAC permissions to users, groups, or ServiceAccounts for Kubernetes API resources, like creating deployments or reading secrets. It operates on the control plane and has no effect on the pod data path or network packets. Selecting a RoleBinding would not change the traffic any pod can send or receive.

env: - name: SECRET_KEY valueFrom: configMapKeyRef: name: my-secret key: key

Why wrong: This reference uses configMapKeyRef, which is designed for ConfigMaps, not Secrets. Although the syntax appears similar to secretKeyRef, the API server validates the referenced resource type and will not allow a Secret to be fetched via configMapKeyRef. As a result, this would cause a schema validation error or fail when the named ConfigMap does not exist.

env: - name: SECRET_KEY valueFrom: secretEnvRef: name: my-secret key: key

Why wrong: The field secretEnvRef is not part of the Kubernetes PodSpec API. To inject a specific key from a Secret as an environment variable, the only valid field is secretKeyRef. Because secretEnvRef is an unknown field, the API server would reject the manifest with a strict decoding error, so this is not a valid mounting technique.

envFrom: - configMapRef: name: my-secret

Why wrong: The envFrom construct with configMapRef imports environment variables from a ConfigMap, not from a Secret. To consume a Secret in this manner, you must use secretRef instead. Since configMapRef points to a ConfigMap resource, referencing my-secret would cause the lookup to fail unless a ConfigMap with that exact name exists, which is not the intent.

privileged

Why wrong: The `privileged` field is a boolean in a PodSecurityPolicy that, when true, allows containers to run in privileged mode, granting them all capabilities and host access. It does not directly define a list of capabilities to add or drop, so it is not one of the capability-focused fields the question targets.

readOnlyRootFilesystem

Why wrong: `readOnlyRootFilesystem` is a field in PodSecurityPolicy that forces a container's root filesystem to be mounted read-only, a security hardening measure entirely separate from capability management. It does not influence the Linux capability sets, making it irrelevant to the capability-specific question.

Create a hostPath volume at /etc/config and copy the ConfigMap content to the node.

Why wrong: A hostPath volume bypasses the Kubernetes ConfigMap mechanism entirely, exposing a path on the node's filesystem. The ConfigMap content would have to be manually copied to every node where the pod might schedule, and updates require manual intervention, making it error-prone and non-declarative. Additionally, hostPath volumes are not portable across clusters and pose security risks, so this approach discards all the benefits of ConfigMap-managed configuration.

Use the ConfigMap to set an environment variable CONFIG and have the application read it from the environment.

Why wrong: Injecting a ConfigMap as an environment variable makes the value immutable for the lifetime of the pod. When the ConfigMap changes, the environment variable is not updated; the pod must be deleted and recreated to pick up the new value. This is acceptable for static startup settings but unsuitable for a legacy application that expects to re-read a configuration file, and it also imposes size limits and makes large multi-key configs unwieldy.

Create a ConfigMap volume mount at /etc/config/app.conf using subPath: config.yaml.

Why wrong: Using subPath: config.yaml mounts only a single file from the ConfigMap, but this file becomes a static bind mount that is not updated by the kubelet when the ConfigMap changes. Even if the ConfigMap is edited, the mounted file at /etc/config/app.conf retains the original content until the pod is restarted or recreated. This defeats the purpose of a ConfigMap volume's automatic update behavior, making it effectively read-only after the initial mount.

Set env: - name: DB_PASSWORD valueFrom: configMapKeyRef: name: db-secret key: password

Why wrong: This option incorrectly uses configMapKeyRef to reference a Secret. configMapKeyRef resolves keys from the data field of a ConfigMap resource, not from a Secret. The reference will look for a ConfigMap named 'db-secret' and, if it exists, read its 'password' key; if not, the container will fail to start. To reference a Secret, the valueFrom must contain secretKeyRef instead.

Use envFrom: - secretRef: name: db-secret

Why wrong: By using envFrom with a secretRef, all key-value pairs from the Secret 'db-secret' become environment variables, meaning an env var named 'password' is created because that is the key's name. This does not create DB_PASSWORD, and it also brings in every other key, which may expose more data than intended and could clash with existing env vars. To rename a key to a different variable name, you need explicit env entries with valueFrom.secretKeyRef.

Set env: - name: DB_PASSWORD secretRef: name: db-secret key: password

Why wrong: This option places secretRef directly as a key within an env item, which is invalid PodSpec syntax. Inside a container env entry, the only allowed ways to inject a value are the literal 'value' field or the 'valueFrom' field; 'secretRef' is not a recognized key, so the API server will reject the manifest. Even if it were accepted, it lacks the 'key: password' pairing under a proper valueFrom.secretKeyRef, so it would not map the secret to DB_PASSWORD.

Mounting a ServiceAccount token as a volume.

Why wrong: ServiceAccount tokens are short-lived JSON Web Tokens that authenticate a pod to the Kubernetes API server, so mounting one grants an identity rather than providing application settings. They are typically injected via projected volumes for workloads like controllers that need to talk to the API. Configuration data, in contrast, belongs in ConfigMaps or Secrets, making this an authentication mechanism, not a configuration-injection mechanism.

Using a PersistentVolumeClaim to store configuration files.

Why wrong: A PersistentVolumeClaim is an abstraction for requesting storage resources from a StorageClass or persistent volume, and while a pod could mount a PVC containing files, the cluster must first provision and attach the volume. This is not a configuration-injection mechanism; it is persistent storage management. Relying on PVCs for config couples your workload to storage infrastructure and creates unnecessary operational burden, unlike ConfigMaps or Secrets that exist specifically to deliver configuration data.

Referencing a NetworkPolicy in the Pod spec.

Why wrong: A NetworkPolicy is a namespaced Kubernetes networking object that governs allowed ingress and egress traffic between pods, and it is never referenced inside a Pod spec. Pods are associated with NetworkPolicies through their labels, but the policy itself only lives in the networking layer. Trying to place a NetworkPolicy in a Pod spec has no meaning and does nothing to deliver configuration data into the container.

The Pod will fail to start because runAsNonRoot conflicts with the container's runAsUser.

Why wrong: runAsNonRoot: true does not conflict with a container user of 1000; it only requires that the effective UID is non-zero. Since runAsUser: 1000 is explicitly set, the kubelet's validation passes and the Pod starts normally. There is no contradiction because non-root simply means not UID 0, and 1000 satisfies that condition.

The container runs as user 1000, but the Pod-level runAsNonRoot overrides the container's runAsUser to enforce non-root.

Why wrong: The Pod-level runAsNonRoot is not an override that changes the container's UID; it is a separate constraint that must be satisfied in addition to the container's own securityContext values. The container still runs as user 1000, and the kubelet validates that this is non-root. Distinct security fields from different levels are merged, not overwritten, so the statement's cause-and-effect is incorrect.

The container runs as root because the Pod-level runAsNonRoot is ignored when container-level capabilities are set.

Why wrong: Pod-level runAsNonRoot is never ignored; it is enforced by the kubelet at container startup, and if the container were to run as root, the Pod would be rejected. Adding capabilities such as NET_ADMIN only grants Linux-specific permissions and does not change the effective UID of the container process. Therefore the premise that capabilities override the non-root mandate is false and would result in a failure, not a root-running container.

Step 1: Define Pod YAML with volume and volumeMount, Step 2: Create ConfigMap from file, Step 3: Apply the Pod manifest, Step 4: Verify the ConfigMap mount in the Pod

Why wrong: Because the Pod's volume definition references the ConfigMap by name, the ConfigMap must already be present in the cluster for the volume to resolve; authoring the YAML first forces you to reference an object that may not exist yet, and if you apply at that point the Pod is rejected. Even if you later create the ConfigMap before applying, this order is fragile: any key names used in the volumeMount must match data that already exists, so the safer, correct practice is to create the ConfigMap first to establish the file names and keys. The exam sequence expects the dependency to be satisfied before the manifest is written, not after.

Step 1: Create ConfigMap from file, Step 2: Apply the Pod manifest, Step 3: Define Pod YAML with volume and volumeMount, Step 4: Verify the ConfigMap mount in the Pod

Why wrong: This order is impossible to execute as written: `kubectl apply -f pod.yaml` (Step 2) requires the YAML file to already exist on disk, but Step 3 defines the manifest after the apply command has already run. You cannot submit a manifest that hasn't been authored yet, because kubectl reads the file or stdin at apply time and sends it to the API server; with no file present the command errors immediately. Defining the Pod YAML after the apply step inverts the logical dependency—the manifest is the input to the apply command, so it must be written first.

Step 1: Verify the ConfigMap mount in the Pod, Step 2: Create ConfigMap from file, Step 3: Define Pod YAML with volume and volumeMount, Step 4: Apply the Pod manifest

Why wrong: Verification is an observation step that can only be performed after the ConfigMap and the Pod both exist; at the point Step 1 runs, there is no ConfigMap and no Pod, so `kubectl get`/`describe`/`exec` would report NotFound and the mount path would not exist. The container with the `volumeMount` hasn't been scheduled or started, so there is no filesystem to inspect. Correct validation happens only after apply: you can exec into the container, run `ls` on the mountPath, or `kubectl describe pod` to confirm the volume is mounted, all of which are impossible before resource creation.

Step 1: Scale the Deployment to 5 replicas. Step 2: Watch the Pods being created. Step 3: Confirm the number of replicas is 5. Step 4: Inspect events for any errors. (Omit checking current state.)

Why wrong: Omitting the initial check of the deployment's current state means you have no baseline, so you cannot tell whether a crash-looping or pending pod was already present before you scaled or was caused by scaling. If the deployment already had 5 replicas, scaling to 5 is a no-op that wastes time, and without that baseline you might assume the command caused a change that never happened. Worse, if there were pre-existing errors, you would see them after scaling and wrongly blame your action. A proper workflow always starts with observation of the starting state before applying any change.

Step 1: Check current state. Step 2: Immediately confirm the number of replicas (without scaling). Step 3: Scale the Deployment. Step 4: Watch Pods. Step 5: Inspect events.

Why wrong: Confirming the replica count before scaling is premature because it will simply show the old count, giving you no useful information since you haven't yet changed anything. After that you scale, then watch, then confirm—but you've already wasted a step and, more importantly, skipped the meaningful baseline check that should happen before scaling. The correct order is to check current state first (to establish the baseline), then scale, then watch the rollout, then verify the new count, then inspect events for errors. Placing the confirmation before the scale action breaks the cause-and-effect logic of monitoring the change.

Step 1: Watch Pods continuously. Step 2: Scale the Deployment. Step 3: Check current state. Step 4: Confirm the number of replicas. Step 5: Inspect events.

Why wrong: Watching pods before running kubectl scale is pointless because no new pods will appear, so you'll be idly watching a static list and might even miss the exact moment the scale command triggers new creations if you're not paying attention. Checking the current state after scaling is backwards: the state has already been changed by the scale operation, so you cannot determine what was present before or whether any observed issues are pre-existing or introduced by scaling. The baseline check must happen first, and the watch must start after the scale command is issued to catch the rollout event stream. This sequence conflates the observation and verification steps, making it impossible to accurately monitor the effect of your action.

Readiness probe: Checks if container is running and restarts it on failure

Why wrong: Conflating a readiness probe with a restart mechanism is a common error: readiness only controls whether a pod is a Service backend, and it never kills the container. The behavior described here — 'container is running and restarts it on failure' — precisely matches the liveness probe, which is defined by the kubelet's decision to stop and recreate the pod based on the restartPolicy. Therefore, labeling this as readiness misattributes the probe's purpose and would lead someone to use a liveness check where a routing gate is needed.

Startup probe: Checks if container is ready to serve traffic

Why wrong: This definition assigns the readiness probe's job to the startup probe. A startup probe does not assess traffic-readiness; it merely verifies that the application process has completed its initialization sequence (e.g., connected to dependencies or loaded configuration). After the startup probe succeeds, the kubelet hands off to the liveness and readiness probes for ongoing checks. Saying it checks if a container can serve traffic confuses phase-gating with service membership, which is the readiness probe's responsibility.

kubectl create configmap app-config --from-env-file=APP_COLOR=blue

Why wrong: --from-env-file flag is designed to read environment variables from a file containing newline-separated KEY=VALUE lines, not from an inline string. When you pass APP_COLOR=blue, kubectl interprets the entire string as a file path (or looks for a file literally named 'APP_COLOR=blue'), which fails with a 'no such file' error. To use this flag correctly, you would need to supply a path to an existing env file, e.g., --from-env-file=config.env.

kubectl create configmap app-config --from-literal=APP_COLOR:blue

Why wrong: The --from-literal flag strictly requires an equals sign (=) to separate the key from the value; using a colon breaks the expected parser format. When you write APP_COLOR:blue, kubectl sees a string without '=', so it cannot split it into a valid key-value pair and either raises an invalid argument error or treats the whole string as a key with an empty value. Always remember the required delimiter is '=', not ':', for inline literals.

kubectl create configmap app-config --from-file=APP_COLOR=blue

Why wrong: --from-file expects a file path (or a key=filepath mapping), not an inline literal value. In the argument APP_COLOR=blue, kubectl interprets 'APP_COLOR' as the desired key and 'blue' as the file path from which to read the value. Because no file named 'blue' exists in the current directory, the command fails with a file-not-found error. This flag is meant for importing file contents as config data, not for setting scalar values directly.

env: - name: SECRET_DATA valueFrom: configMapKeyRef: name: mysecret key: password

Why wrong: This option incorrectly uses configMapKeyRef to reference a Secret. Even though the name field is set to 'mysecret', configMapKeyRef only resolves keys from ConfigMap resources; Kubernetes will look for a ConfigMap named 'mysecret' and fail or return nothing, since the actual resource is a Secret. Secret data must be accessed with secretKeyRef, which is the correct key reference for Secrets.

env: - name: SECRET_DATA valueFrom: secretKeyRef: name: password key: mysecret

Why wrong: This option swaps the name and key fields incorrectly. In secretKeyRef, 'name' must be the name of the Secret object (e.g., 'mysecret'), and 'key' must be the key inside that Secret (e.g., 'password'). Here, Kubernetes would attempt to find a Secret named 'password' and then expect a key 'mysecret' inside it, which does not match the actual Secret and key, so the env var would not be populated correctly.

volumeMounts: - name: secret-volume mountPath: /etc/secret volumes: - name: secret-volume secret: secretName: mysecret items: - key: password path: secret.txt

Why wrong: While this option does mount the Secret as files, it uses a volume mount, not an environment variable. The volume correctly references the Secret with secretName: 'mysecret' and maps the 'password' key to a file path, but the question specifically requires injecting the secret into an environment variable, which is done via env and secretKeyRef. A volume mount exposes the data as a file in the container's filesystem, not as an env var, so it does not meet the requirement.

resources: requests: cpu: 250 limits: memory: 512M

Why wrong: This sets cpu to 250, which without a suffix is interpreted as 250 whole CPU cores, not 250 millicores. Additionally, memory uses '512M'; while 'M' is a valid decimal SI suffix (megabytes), the 'B' is not part of Kubernetes' resource quantity grammar, and the intended amount should use 'Mi' for mebibytes.

resources: requests: cpu: 250 limits: memory: 512MB

Why wrong: The cpu value of 250 is again 250 full cores, a grossly oversized request for most containers. The memory '512MB' is also invalid because Kubernetes does not recognize the 'B' suffix; resource quantities use plain 'M' (megabytes) or 'Mi' (mebibytes), not 'MB'.

resources: requests: cpu: 0.25 limits: memory: 512MB

Why wrong: The cpu request of 0.25 is valid and equals 250 millicores, so the problem is not with cpu. The memory limit '512MB' is non-standard: Kubernetes resource quantities do not accept 'MB'; use 'Mi' for mebibytes or 'M' for megabytes, with '512Mi' being the correct representation for this example.

kubectl create secret generic db-secret --from-file=password=p@ss

Why wrong: The --from-file flag expects a path to an existing file, not an inline literal value. In this command, kubectl interprets 'password=p@ss' as a file named 'p@ss' with key 'password', so it will fail because no such file exists. To create a generic secret with a literal password, you must use --from-literal instead. This is the fundamental difference between reading file contents and specifying a direct value.

kubectl create secret tls db-secret --from-literal=password=p@ss

Why wrong: The tls subcommand is exclusively for storing TLS certificates and private keys, and it requires the --cert and --key flags. It does not support --from-literal at all, so this command would be rejected by kubectl. Even if you provided the correct flags, the secret type would be 'kubernetes.io/tls' with mandatory tls.crt and tls.key data, which is not appropriate for a plain database password. The Opaque type is meant for arbitrary user data.

kubectl create secret docker-registry db-secret --from-literal=password=p@ss

Why wrong: The docker-registry subcommand creates a secret of type 'kubernetes.io/dockerconfigjson', intended specifically for Docker registry credentials. This subcommand does not accept --from-literal; instead it uses --docker-username, --docker-password, and --docker-server flags. Using --from-literal here would fail, and even with the right flags, the secret data structure is a Docker config JSON, not a simple password. Generic secrets are the only type that can store a raw password literal.

The pod is using the default service account instead of 'my-sa'

Why wrong: A pod uses whichever service account is named in its spec. Since the pod manifest explicitly sets serviceAccountName: my-sa, the default 'default' SA is never used; Kubernetes projects that SA's token into the pod. To confirm, inspect `spec.serviceAccountName` in the pod's YAML. Thus, this cannot explain RBAC failure, because the intended SA is active.

RoleBindings cannot grant access to list pods

Why wrong: RoleBindings can contain any rule that a Role defines, including the verb 'list' on the 'pods' resource. The RBAC API treats list, get, watch, create, update, patch, delete as ordinary verbs. A RoleBinding simply links the Role to a subject; it does not filter or reject verbs. So there is no technical limitation preventing a RoleBinding from granting list pod access.

The pod has automountServiceAccountToken set to false

Why wrong: Kubernetes automatically mounts a service account token unless the pod sets automountServiceAccountToken: false. By default, this field is true, so the token is present. Setting it to false would prevent the pod's client from authenticating to the API, yielding authentication errors rather than RBAC permission denied errors. This is a misdiagnosis because the symptom described likely involves an authorization decision, which requires a valid token anyway.

PodSecurityPolicy

Why wrong: PodSecurityPolicy is deprecated and completely removed in Kubernetes v1.25, so it cannot be used in current clusters. Even when available, it only governed security context fields like privileged, capabilities, and SELinux settings; it never validated CPU or memory requests and limits for pods or containers. Thus it is entirely incapable of enforcing resource minimums or maximums.

LimitRange with limits: - max: memory: 128Mi min: memory: 100Mi

Why wrong: This LimitRange definition is invalid because the declared max memory of 128Mi is less than the min memory of 100Mi; Kubernetes admission will reject the resource as the max must be greater than or equal to the min. Additionally, the desired upper bound is 1Gi, not 128Mi, so even if the configuration were accepted, it would not satisfy the requirement. A correctly structured LimitRange would specify min and max values in the correct order.

ResourceQuota

Why wrong: ResourceQuota aggregates resource usage across an entire namespace, capping the total CPU and memory that all pods can collectively consume. It cannot enforce any per-pod or per-container lower or upper bound, so individual pods could specify extremely high or low requests as long as the overall quota is not exceeded. For guaranteeing each pod's resource envelope, a LimitRange is required.

pod-security.kubernetes.io/warn: restricted

Why wrong: The `warn: restricted` mode only produces a warning message to the user when a pod violates the Restricted policy, but the pod is still created. It does not block or reject anything, so it is purely informational and cannot enforce the policy. Because the administrator needs to guarantee that non-compliant pods never run, `warn` is insufficient and incorrect.

pod-security.kubernetes.io/audit: restricted

Why wrong: The `audit: restricted` mode writes an audit log entry whenever a pod violates the Restricted policy, but it does not warn the user or stop the pod from being created. This mode is useful for detecting and recording violations after the fact, but it has no enforcement capability. Thus, it fails to meet the administrator's goal of rejecting non-compliant pods.

pod-security.kubernetes.io/enforce: restricted

Why wrong: This option is an exact duplicate of the correct answer. In a multiple-choice scenario, a repeated answer choice is not treated as a separate correct option; even though the label itself is valid, it is intentionally listed as a distractor. Recognizing that the same configuration appears twice means the test expects you to choose only one of them, and this duplicate is marked wrong because it adds no new valid solution.