Application Environment, Configuration and Security practice questions

The API server is not running.

Why it fails: 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 it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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 it fails: 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.

pod-security.kubernetes.io/warn: restricted

Why it fails: 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 it fails: 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 it fails: 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.

emptyDir volume

Why it fails: An emptyDir volume starts as an empty directory and its contents are tied directly to the pod's lifecycle; it is intended for scratch space, temporary files, or sharing data between containers in the same pod. It has no connection to ConfigMaps, cannot be populated from ConfigMap data, and its contents are completely lost if the pod is deleted or restarted, so it does not satisfy the requirement to mount a ConfigMap as a volume.

projected volume with configMap source

Why it fails: Projected volumes do support automatic updates when the source data changes, but they are typically used for combining multiple sources (e.g., ConfigMaps, Secrets) into a single volume. For mounting a single ConfigMap, a configMap volume is the simpler and more direct choice.

downwardAPI volume

Why it fails: A downwardAPI volume exposes pod-level metadata such as labels, annotations, resource limits, and environment information as files inside the container, not arbitrary ConfigMap data. While it can be used to mount mountable ConfigMaps via a projected volume, a standalone downwardAPI volume is solely for metadata, so it does not provide a way to mount a ConfigMap's contents.

A ClusterRole with rules for pods (get, list, watch) and a ClusterRoleBinding to the ServiceAccount

Why it fails: A ClusterRoleBinding grants the ServiceAccount pod access across every namespace, exceeding the required single-namespace scope. It is tempting because it is the quickest way to attach permissions, and would be correct for granting cluster-wide read access, such as to a monitoring ServiceAccount needing pods everywhere.

A ClusterRole with rules for pods (get, list, watch) and a RoleBinding to the ServiceAccount

Why it fails: A ClusterRole grants cluster-wide permissions, so binding it here exceeds the namespace-scoped requirement; a namespaced Role suffices. It is tempting because ClusterRoles are reusable across namespaces, and would be correct when the same pod permissions must apply in multiple namespaces via separate RoleBindings.

A Role with rules for pods (get, list, watch, create) and a RoleBinding to the ServiceAccount

Why it fails: Including create in the Role grants write capability, contradicting the read-only requirement; get, list and watch alone are needed. It is tempting because create is often grouped with pod verbs, and would be correct when the ServiceAccount must launch pods, not merely observe them.

The Pod will run but with root user, ignoring the setting

Why it fails: Incorrect. The `runAsNonRoot: true` setting enforces that the container must not run as root; it is not ignored. The container will fail to start, not run as root.

The Pod will not be created and you will see an error about securityContext violation

Why it fails: Incorrect. The Pod object is still created; the failure occurs at runtime when the container tries to start. The Pod is not rejected at admission time.

The Pod will run with root but the container will be killed by a security policy

Why it fails: Incorrect. There is no security policy that kills the container after it runs; the container fails to start due to the security context, not after starting.

Using envFrom with secretRef

Why it fails: Incorrect. `secretRef` is used for Secrets, not ConfigMaps. To inject all keys from a ConfigMap, you need `configMapRef`.

Using env with value directly set to a key name

Why it fails: Incorrect. You cannot directly set an environment variable to a key name; you must use `valueFrom.configMapKeyRef` or `envFrom`.

Using envFrom to inject all keys as environment variables

Why it fails: Incorrect in the context of this question. Although `envFrom` with `configMapRef` is a valid method, the question asks for exactly two correct answers, and the intended pair is B and C. Selecting E would make three correct answers, which violates the 'Select TWO' instruction.

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

Why it fails: configMapKeyRef is used to pull values from ConfigMap objects, not Secrets, so the reference to db-secret would fail because no such ConfigMap exists. Secret data is stored differently (base64 encoded) and accessed via secretKeyRef; mixing these Kinds causes the API to look in the wrong resource namespace. Even if a ConfigMap named db-secret existed, it would not contain the password key from the Secret, so this snippet cannot inject the correct value.

Opaque

Why it fails: The `Opaque` type is the default secret type for arbitrary user-defined data, such as configuration values or passwords created with `--from-literal` or `--from-file` without any special flags. Because the command in question includes both `--cert` and `--key`, Kubernetes overrides the default and uses the TLS-specific type instead. If those flags were omitted, the resulting secret would indeed be `Opaque`, but their presence changes the type. Therefore, `Opaque` is not the correct type for this command.

kubernetes.io/dockerconfigjson

Why it fails: The `kubernetes.io/dockerconfigjson` type is reserved for secrets that hold a Docker configuration file (`.dockerconfigjson`) used to authenticate to container registries. Such secrets are typically created with `kubectl create secret docker-registry`, not with the generic command, because none of the generic flags like `--cert` or `--key` can produce a Docker config. Since the command is `kubectl create secret generic tls secret` with no registry-related flags, the type cannot be `dockerconfigjson`. This type is for a completely different authentication domain.

kubernetes.io/ssh-auth

Why it fails: The `kubernetes.io/ssh-auth` type is designed for SSH private keys used in SSH authentication, and it is created with the `--ssh-key` flag (or by providing an `ssh-privatekey` file via `--from-file`). The `--cert` and `--key` flags in the given command refer to a TLS certificate and its private key, not an SSH key pair. As a result, Kubernetes sets the type to `kubernetes.io/tls` rather than `ssh-auth`. SSH auth secrets require specific data keys like `ssh-privatekey`, which are not present here.

The pod's CPU request exceeds the remaining quota.

Why it fails: The pod's CPU request may also exceed the remaining requests.cpu quota in this overstated pod, but that alone does not explain the admission failure when the limit is the larger value and the limits.cpu quota is the first binding constraint. ResourceQuota checks each resource dimension independently, and a batch to reject the pod can name multiple constraints; however, the decisive dimension here is the CPU limit, because the request is a subset of the limit and the limit is what pushes the namespace clearly over the configured cap.

The pod's memory request is not set.

Why it fails: A missing memory request is irrelevant because the ResourceQuota in this scenario only defines CPU quotas; no memory quota is specified, so the admission controller has no memory constraint to evaluate. Pods must not set optional resource fields for every dimension, and Kubernetes does not require a memory request unless a memory quota or LimitRange forces a default. The rejection is entirely attributable to the CPU limit, not to memory.

The namespace does not have a LimitRange set.

Why it fails: ResourceQuota functions independently of LimitRange: LimitRange assigns per-pod/container defaults and enforces min/max constraints, while ResourceQuota is a namespace-wide aggregate budget. The absence of a LimitRange does not weaken ResourceQuota enforcement; a pod that explicitly sets its CPU limit is still checked against the quota. If no LimitRange exists, the only edge case is that a pod with no CPU request/limit would also fail the request/limit quota, but that is not this pod's problem.

envFrom: - secretRef: name: my-config

Why it fails: The `envFrom` field with `secretRef` is valid only for injecting a Secret's data as environment variables, not for a ConfigMap. In Kubernetes pod specs, the `secretRef` key points to a Secret object in the same namespace, and using it with a ConfigMap name like `my-config` would silently fail or produce no environment variables because the referenced object is not a Secret. To consume a ConfigMap via environment variables, the correct key is `configMapRef` within the same `envFrom` field, which directly binds all key-value pairs from the named ConfigMap.

volumes: - name: config-vol configMap: configMapName: my-config

Why it fails: In a ConfigMap volume source, the mandatory field that identifies the ConfigMap object is `name`, not `configMapName`. The `configMap` entry under `volumes` accepts both `name` (the ConfigMap to mount) and optional `items` for selective key mapping; `configMapName` is simply not a recognized field in the Kubernetes schema. As a result, a pod spec using `configMapName` would fail API validation and the volume would never be created, so this is not a valid way to consume a ConfigMap.

An environment variable file

Why it fails: An environment variable file is not a separate source category because the CLI's `--from-env-file` option still reads from a file and simply parses `KEY=VALUE` lines as a special format. The underlying source is a file, so it duplicates the "file" source type rather than introducing an independent source. In the context of this question, it is invalid as a distinct choice because the valid sources are file and literal key-value pairs.

A directory

Why it fails: A directory cannot be passed to `kubectl create configmap` as a source flag; there is no `--from-directory` option. Although `--from-file` can point to a directory and will expand it into multiple entries, the actual source option is still `--from-file`, and the files inside the directory are the real inputs. A bare directory is therefore not a valid source type for creating a ConfigMap.

A Secret

Why it fails: A Secret cannot be used as a source for a ConfigMap because ConfigMaps and Secrets are distinct API resources with different storage and access semantics. ConfigMaps are intended for non-confidential configuration data, while Secrets are encoded (Base64) and designed for sensitive information. There is no `kubectl` mechanism for directly converting a Secret into a ConfigMap; you would have to extract and re-enter the data as file or literal sources.

env: - name: DEBUG valueFrom: configMapKeyRef: name: app-config key: DEBUG

Why it fails: This snippet individually maps the single environment variable DEBUG to the DEBUG key in the ConfigMap. It does not inject the remaining keys; you would need one such block per config key. Because the developer wants to load all keys from app-config, this is an incomplete solution. Using envFrom is the proper way to consume the whole ConfigMap.

envFrom: - secretRef: name: app-config

Why it fails: Although the syntax mirrors a ConfigMap import, secretRef strictly targets a Secret object, not a ConfigMap. Pointing it at app-config would cause the Pod to fail on creation because the referenced resource does not exist as a Secret. Even if it resolved, the secret type is for sensitive data; for non-sensitive app configuration you must use configMapRef.

env: - configMapRef: name: app-config

Why it fails: Within the env array, each entry requires an explicit name field; configMapRef is not permitted as a direct entry under env. The only place configMapRef can appear is inside an envFrom block. Therefore this invalid YAML would be rejected by the Kubernetes API server before the Pod is ever created.

Same as A but subjects: - kind: Group name: app-sa

Why it fails: Using kind: Group with name app-sa is invalid because app-sa is a ServiceAccount, not a group. Kubernetes RBAC distinguishes three subject kinds: User, Group, and ServiceAccount, and each behaves differently. A ServiceAccount subject must use kind: ServiceAccount; referencing it as a Group means the binding will never match the service account's identity, so app-sa will receive no pod permissions from this RoleBinding.

Same as A but subjects: - kind: User name: app-sa

Why it fails: Setting kind: User with name app-sa is also incorrect because service accounts are not User subjects. User subjects typically represent human users or external processes authenticated via certificates or tokens, while ServiceAccount subjects represent in-cluster identities used by pods. The RoleBinding would attempt to bind the Role to a User named app-sa, which does not correspond to the actual ServiceAccount, so the intended SA would not gain the get, list, or watch permissions on pods.

Same as A but RoleBinding uses kind: ClusterRole

Why it fails: Changing the roleRef to kind: ClusterRole in the RoleBinding is wrong in this context because the manifest defines a namespaced Role named pod-reader, not a ClusterRole. The roleRef kind must exactly match the type of the referenced object; pointing to kind: ClusterRole would either fail because no such ClusterRole exists or, if one existed, it would bind that cluster-scoped role instead of the intended Role. While a RoleBinding can legally reference a ClusterRole to grant permissions in one namespace, the YAML here defines a Role, so the roleRef kind must be Role to honor the original definition.

kubernetes.io/password

Why it fails: Incorrect. `kubernetes.io/password` is not a valid Kubernetes Secret type. Valid types include Opaque, kubernetes.io/tls, kubernetes.io/ssh-auth, etc.

kubernetes.io/configmap

Why it fails: Incorrect. `kubernetes.io/configmap` is not a valid Secret type; ConfigMaps are a separate resource.

ALL

Why it fails: ALL is not a Linux capability but a wildcard token that refers to every capability in the kernel's capability set. In a pod's securityContext, `capabilities.drop: ["ALL"]` removes all capabilities before the container starts, but ALL itself has no capability number or permission granularity. Because the question asks which specific capabilities are commonly dropped, ALL cannot be counted as one of the three; it is the aggregate mechanism used to drop many capabilities at once.

CHOWN

Why it fails: CHOWN is a low-privilege capability that allows a process to change the owner and group of files; it is included in a container's default capability set and is almost always retained, even in hardened or restricted configurations. Unlike the other options, dropping CHOWN would break basic file ownership operations for application workloads, so security profiles do not commonly strip it. Therefore CHOWN is not one of the three capabilities typically dropped, making it the incorrect choice here.

A LimitRange can be applied to the entire cluster.

Why it fails: LimitRange is a namespaced resource; it resides in a specific namespace and its constraints apply only to pods created in that namespace. It cannot be used to enforce limits cluster-wide. Cluster-scoped admission limits would instead be implemented with multiple LimitRanges applied to all namespaces or via an admission webhook; a single LimitRange object never spans across namespaces.

A LimitRange can set a default CPU limit for pods.

Why it fails: The default CPU limit in a LimitRange applies to individual containers, not to a pod as a whole, because Kubernetes resource limits are always set per container. A LimitRange has no field for a pod-level default; if a pod has multiple containers, each gets its own default limit when not independently specified. The notion of a 'pod limit' is a common misunderstanding—pods are only a grouping, and resource enforcement happens at the container level.

A LimitRange can limit the total number of pods in a namespace.

Why it fails: LimitRange only constrains resource requests, limits, and their ratios for individual containers or pods in a namespace; it has no concept of counting objects. The number of pods in a namespace is limited by a ResourceQuota with `count/pods`, not by a LimitRange. Trying to use a LimitRange for pod count would fail because the LimitRange schema does not include count fields, and the API server would reject such a definition.

A pod with securityContext.capabilities.add: ["NET_ADMIN"]

Why it fails: The restricted profile requires all Linux capabilities to be dropped using capabilities.drop: ['ALL'] and forbids any capability to be added. Specifying capabilities.add: ['NET_ADMIN'] grants a privileged capability that permits network configuration tasks such as modifying routing tables and firewall rules, which is explicitly disallowed under the restricted policy and would cause the admission controller to reject the pod.

A pod with no securityContext specified

Why it fails: Omitting securityContext entirely means the pod inherits the default behavior, where the container runs with the root user (UID 0) and root filesystem writes are allowed. Restricted policy demands an explicit runAsNonRoot: true setting; without any securityContext, the admission controller cannot verify the runAsNonRoot requirement and therefore denies the pod.

A pod with securityContext.privileged: true

Why it fails: Setting securityContext.privileged: true creates a privileged container that bypasses all kernel security isolation, gaining access to all host devices and capabilities. The restricted profile explicitly forbids privileged containers, and this setting alone triggers immediate rejection because it is considered a direct violation of the most basic security boundary.

Secrets are always encrypted in etcd

Why it fails: B is wrong. Secrets are not encrypted in etcd by default; encryption at rest must be configured separately.

The maximum size of a Secret is 1 MB

Why it fails: D is wrong. The maximum size of a Secret is 1 MB (default limit), not 1 GB.

readOnlyRootFilesystem: false

Why it fails: Setting `readOnlyRootFilesystem: false` only allows the container's root filesystem to be writable, which is the default and unrelated to network port binding. The crash loop's "permission denied" error occurs during `bind()` to port 8080, a network operation, not a filesystem write operation. Even if the filesystem were read-only, an application would typically fail with a write error when trying to create files, not with a bind permission error. Therefore, this option has no bearing on the problem and does not address the root cause.

capabilities.add: ["NET_BIND_SERVICE"]

Why it fails: Adding the `NET_BIND_SERVICE` capability grants a process the permission to bind to privileged ports (those numbered below 1024), but port 8080 is a non-privileged port that any ordinary process can bind to without special capabilities. The error occurs because the current user lacks sufficient privileges to bind to even a high port, which is typically due to running as a non-root user or having a security context that drops all capabilities. Adding a capability that only covers privileged ports does not address the actual permission failure, making this option ineffective.

seccompProfile: type: RuntimeDefault

Why it fails: The seccompProfile RuntimeDefault applies the container runtime's default seccomp profile, which filters restricted system calls, but binding a socket to a high-numbered port like 8080 only requires standard syscalls (`socket`, `bind`, `listen`) that are explicitly allowed by the default profile. The observed "permission denied" error is not a seccomp denial; seccomp returns `EPERM` for forbidden syscalls, but the default profile deliberately permits common network operations. Thus, changing seccomp will not resolve the issue, as the failure originates from an authorization layer higher in the stack, such as process capabilities or user ID restrictions.