Hard Difficulty Questions

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

Why wrong: This uses configMapKeyRef, but the resource is a Secret, not a ConfigMap.

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

Why wrong: The name field should reference the secret name, not the key. The key field specifies the key within the secret.

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

Why wrong: This mounts the secret as a file, not as an environment variable.

runAsUser: 1000

Why wrong: This sets the user ID but does not affect filesystem write permissions.

capabilities: drop: ["ALL"]

Why wrong: This drops all capabilities but does not make the filesystem read-only.

allowPrivilegeEscalation: false

Why wrong: This prevents privilege escalation but does not make the filesystem read-only.

appArmorProfile

Why wrong: AppArmor is a separate LSM; seccomp is not configured via appArmorProfile.

seLinuxOptions

Why wrong: SELinux options are for SELinux, not seccomp.

seccomp

Why wrong: There is no seccomp field; the correct field is seccompProfile.

env: - name: DB_PORT valueFrom: configMapKeyRef: name: env-config key: DB_PORT envFrom: - configMapRef: name: env-config

Why wrong: This sets DB_PORT individually, but then envFrom loads all keys including DB_PORT, which would overwrite? Actually, envFrom does not override env if the key already exists? The documentation says envFrom keys are not added if the key already exists in env. So DB_PORT would keep its value. But this does not set DATABASE_HOST.

envFrom: - configMapRef: name: env-config env: - name: DATABASE_HOST value: DB_HOST

Why wrong: The value of DATABASE_HOST would be the literal string 'DB_HOST', not the value from the ConfigMap.

envFrom: - configMapRef: name: env-config prefix: DATABASE_

Why wrong: This would prefix all keys, resulting in DATABASE_DB_HOST and DATABASE_DB_PORT, not DATABASE_HOST.

Set 'allowPrivilegeEscalation: true'

Why wrong: Incorrect. allowPrivilegeEscalation controls whether a process can gain more privileges than its parent, but does not directly allow binding to privileged ports.

Add 'capabilities.drop: [ALL]' to the container's securityContext

Why wrong: Incorrect. Dropping all capabilities would further restrict the process, making it unable to bind to any port.

Set runAsUser: 0 to run as root

Why wrong: Incorrect. Running as root violates security best practices and may not be allowed by Pod Security Admission. The question implies seeking a more secure solution.

PodDisruptionBudget

Why wrong: PodDisruptionBudget controls voluntary disruptions, not resource limits.

NetworkPolicy

Why wrong: NetworkPolicy controls network traffic, not resource limits.

ResourceQuota

Why wrong: ResourceQuota limits total resource consumption across all pods, not per pod.

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

Why wrong: hostPath mounts a host directory, not a secret.

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

Why wrong: configMap is for ConfigMaps, not Secrets.

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

Why wrong: emptyDir is an empty temporary directory, not populated with secret data.

Add a 'securityContext' field to the Pod template with 'runAsUser: 1000'

Why wrong: While this may be part of compliance, it is not a step for enforcement; it's a specific configuration.

Set the label 'pod-security.kubernetes.io/enforce=baseline' on the namespace

Why wrong: Baseline is less restrictive than restricted.

Set the label 'pod-security.kubernetes.io/warn=restricted' on the namespace

Why wrong: The warn label only warns but does not enforce.

seccomp: type: RuntimeDefault

Why wrong: Incorrect. The correct field is 'seccompProfile', not 'seccomp'.

capabilities: add: [SECCOMP]

Why wrong: Incorrect. There is no SECCOMP capability. Seccomp is configured via seccompProfile, not capabilities.

securityContext: seccomp: type: Unconfined

Why wrong: Incorrect. The field name is 'seccompProfile' and 'Unconfined' disables seccomp, which may not be desired.

The pod's CPU request exceeds the remaining quota.

Why wrong: It also exceeds, but the limit also exceeds and typically limit quota is more restrictive.

The pod's memory request is not set.

Why wrong: No memory quota is mentioned, so it's not the issue.

The namespace does not have a LimitRange set.

Why wrong: LimitRange is not required for ResourceQuota to work.

kubectl label namespace my-ns psp=restricted

Why wrong: PSP is deprecated; the correct label is pod-security.kubernetes.io/enforce.

kubectl annotate namespace my-ns pod-security.kubernetes.io/enforce=restricted

Why wrong: It must be a label, not an annotation.

kubectl label namespace my-ns pod-security.kubernetes.io/audit=restricted

Why wrong: That sets audit mode, not enforce.

runAsUser: 1000

Why wrong: Required to set the user ID.

readOnlyRootFilesystem: true

Why wrong: Required to make the filesystem read-only.

allowPrivilegeEscalation: false

Why wrong: Required to prevent privilege escalation.

Create a new Secret of type kubernetes.io/dockerconfigjson

Why wrong: That secret type is for Docker registry credentials.

The application cannot access the API; the setting is final

Why wrong: You can still manually mount the token via a volume.

Add a ConfigMap with the token

Why wrong: ConfigMaps cannot store service account tokens.

The ResourceQuota applies to limits, not requests.

Why wrong: The question states the ResourceQuota sets 'requests.cpu', so it applies to requests.

The pod does not specify a CPU limit.

Why wrong: ResourceQuota can be based on requests or limits; here it is on requests. The pod has a request, so this is not the issue. Also, missing a limit does not cause quota exceeded errors.

The pod's CPU request exceeds the ResourceQuota limit.

Why wrong: The pod requests 500m, which is less than the quota of 2 (2000m). The individual request is not exceeding the quota.

Remove runAsNonRoot: true from securityContext

Why wrong: This would allow running as root, but the question likely expects a non-root solution.

Add fsGroup: 1000

Why wrong: fsGroup sets group ownership of volumes, not the user the container runs as.

Set allowPrivilegeEscalation: false

Why wrong: This does not change the user ID.

Set securityContext: { allowPrivilegeEscalation: true }

Why wrong: allowPrivilegeEscalation must be false in restricted policy, and this does not address the UID requirement.

Set securityContext: { runAsNonRoot: true, capabilities: { add: ['SYS_ADMIN'] } }

Why wrong: Adding SYS_ADMIN is not allowed under restricted policy, and runAsNonRoot: true still prevents running as root.

Set runAsUser: 0 and runAsNonRoot: false

Why wrong: The restricted policy requires runAsNonRoot: true, so setting it to false will cause the pod to be rejected.

grpc

Why wrong: grpc probe uses gRPC health checking protocol.

exec

Why wrong: Exec runs a command inside the container.

httpGet

Why wrong: This checks HTTP response, not just port open.

The pod will be restarted by the kubelet

Why wrong: Readiness probe failure does not restart the pod; liveness probe failure does.

The Deployment will create a new pod to maintain 3 replicas

Why wrong: The pod is still running, so the ReplicaSet count remains 3.

The pod will be terminated gracefully

Why wrong: No termination occurs due to readiness probe failure.

The readiness probe is misconfigured and is shutting down the pod

Why wrong: Readiness probes do not shut down pods; they only control service traffic.

The liveness probe is using the wrong HTTP endpoint

Why wrong: The probe is exec, not HTTP. The endpoint is irrelevant.

The probe timeoutSeconds is set too low, causing the probe to fail before the command completes

Why wrong: If the command times out, the probe fails, but the most likely issue is the missing file.

lifecycle.preStop.exec.command with sleep 60

Why wrong: A preStop hook can delay termination but the grace period is separate.

livenessProbe.initialDelaySeconds: 60

Why wrong: This delays the first liveness probe, not termination.

resources.limits.cpu

Why wrong: Resource limits have no effect on termination.