Application Environment, Configuration and Security practice questions

To grant permissions to users

Why wrong: Permissions are granted via RBAC (RoleBinding/ClusterRoleBinding) to users or ServiceAccounts.

To define network policies for Pods

Why wrong: Network policies are defined using NetworkPolicy resources.

To store Docker registry credentials

Why wrong: That is the purpose of a Secret of type kubernetes.io/dockerconfigjson.

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

Why wrong: A ClusterRole with a ClusterRoleBinding grants cluster-wide access, which is excessive for namespace-scoped Pod read-only access.

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

Why wrong: A ClusterRole with a RoleBinding grants permissions only in the namespace, but using a ClusterRole for namespace-scoped resources is unnecessary. Option D uses a Role with create permission, not a ClusterRole.

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

Why wrong: A Role with create verb grants write access, which exceeds the required read-only permissions.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

serviceAccountName: my-sa

Why wrong: This specifies which ServiceAccount to use, but does not control automatic mounting.

serviceAccountName: my-sa automountServiceAccountToken: false

Why wrong: While both fields can be specified at the pod spec level, the question asks which field should be set to false. Option C includes both, but setting serviceAccountName is not required to prevent token mounting. The correct field is automountServiceAccountToken alone.

containers: - automountServiceAccountToken: false

Why wrong: The automountServiceAccountToken field is set at the pod level, not container level.

Volume owned by user 2000, group 1000; container runs with user 2000 and group 1000

Why wrong: Incorrect mapping; runAsUser and runAsGroup affect container, fsGroup affects volume.

Volume owned by user 3000, group 2000; container runs with user 1000 and group 3000

Why wrong: runAsUser sets the container's user ID, not the volume's owner.

Volume owned by user 1000, group 3000; container runs with user 1000 and group 2000

Why wrong: The fsGroup sets the volume's group to 2000, not the container's group.

Secrets are always encrypted in etcd

Why wrong: 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 wrong: D is wrong. The maximum size of a Secret is 1 MB (default limit), not 1 GB.

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

Why wrong: This sets a literal value, not from ConfigMap.

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

Why wrong: envFrom imports all keys, not a specific one; syntax also wrong.

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

Why wrong: secretKeyRef is for Secrets, not ConfigMaps.

emptyDir

Why wrong: Ephemeral and not shared across pods.

persistentVolumeClaim

Why wrong: PVCs are for persistent storage, but not tied to a specific node path.

configMap

Why wrong: ConfigMaps are for configuration data, not file access.

The API server is not running.

Why wrong: If API server were down, the error would be connection error, not 403.

The RoleBinding is in the wrong namespace.

Why wrong: RoleBinding is in 'app' namespace, correct.

The Role does not include list permission.

Why wrong: Role includes list, so that is not the issue.

ResourceQuota

Why wrong: ResourceQuota limits resource consumption, not network traffic.

PodSecurityPolicy

Why wrong: PodSecurityPolicy is for security context constraints, not network traffic.

RoleBinding

Why wrong: RoleBinding is for RBAC access to API resources.

runAsNonRoot: true

Why wrong: Prevents root but does not specify UID; container might still run as arbitrary non-root.

fsGroup: 1000

Why wrong: fsGroup sets the group for volume mounts, not the user.

privileged: false

Why wrong: Disables privileged mode but does not change the user.

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

Why wrong: configMapKeyRef is for ConfigMaps, not Secrets.

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

Why wrong: secretEnvRef is not a valid Kubernetes field.

envFrom: - configMapRef: name: my-secret

Why wrong: configMapRef is for ConfigMaps, not Secrets.

privileged

Why wrong: Controls whether privileged containers are allowed, not specific capabilities.

readOnlyRootFilesystem

Why wrong: Makes root filesystem read-only, unrelated to capabilities.

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

Why wrong: hostPath volumes bypass ConfigMap mechanisms, require manual updates, and are not recommended for configuration management.

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

Why wrong: Environment variables from ConfigMaps are not automatically updated when the ConfigMap changes; the Pod must be restarted.

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

Why wrong: subPath mounts prevent automatic updates; the file content is static after initial mount.

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

Why wrong: configMapKeyRef is for ConfigMaps, not Secrets.

Use envFrom: - secretRef: name: db-secret

Why wrong: This creates an environment variable named 'password' (the key name), not DB_PASSWORD.

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

Why wrong: Invalid syntax; env expects valueFrom with secretKeyRef, not secretRef directly.

Mounting a ServiceAccount token as a volume.

Why wrong: ServiceAccount tokens are for authentication, not configuration data injection.

Using a PersistentVolumeClaim to store configuration files.

Why wrong: PersistentVolumeClaims are for persistent storage, not for injecting configuration into Pods.

Referencing a NetworkPolicy in the Pod spec.

Why wrong: NetworkPolicies define network rules and are not used for configuration injection.

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

Why wrong: runAsNonRoot: true only requires that the container user is not 0, which is satisfied by user 1000.

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

Why wrong: Pod-level runAsNonRoot does not override container runAsUser; both must be satisfied.

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

Why wrong: Pod-level runAsNonRoot is not ignored; it is a separate constraint.

Remove `runAsNonRoot: true` from the securityContext to allow the container to run as root.

Why wrong: This would run the container as root, which is insecure and not recommended.

Increase the Pod's resource limits because the error is due to insufficient memory.

Why wrong: The error is about security context, not resources.

Create a PodSecurityPolicy that allows running as root.

Why wrong: This is a cluster-wide change and not the best immediate fix for this single Pod.

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: This is incorrect because the Pod references the ConfigMap, so the ConfigMap must be created first; otherwise, the Pod definition is invalid or incomplete.

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 is incorrect because the Pod manifest must be defined (and saved) before it can be applied; applying an undefined manifest is impossible.

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: This is incorrect because verification can only happen after the ConfigMap and Pod exist; you cannot verify something that hasn't been created yet.