Select Two (Multi-Select) Questions

Set maxUnavailable=1

Why wrong: Allows one pod to be unavailable, possibly causing capacity drop.

Use Recreate strategy

Why wrong: Recreate terminates all pods before creating new ones.

Set maxSurge=0

Why wrong: No extra pods allowed; may cause downtime if maxUnavailable>0.

Kustomize can be used to perform canary deployments.

Why wrong: Kustomize does not have native canary deployment support; it is for configuration management.

Kustomize requires Helm to manage dependencies.

Why wrong: Kustomize is standalone and does not require Helm.

Kustomize can only be used with kubectl apply -k.

Why wrong: It can also be used standalone with kustomize build.

Using envFrom to inject ConfigMap data as environment variables will update automatically.

Why wrong: Environment variables are set at container startup and do not update.

ConfigMap updates are reflected immediately in the volume mount.

Why wrong: The sync is periodic (usually ~60 seconds), not instantaneous.

The Pod must be restarted for any ConfigMap change to take effect.

Why wrong: Volume mounts (without subPath) update automatically without restart.

It sets default resource requests and limits for Pods that don't specify them

Why wrong: LimitRange sets defaults, not ResourceQuota.

It restricts which users can create Pods in the namespace

Why wrong: Access control is done via RBAC, not ResourceQuota.

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.

envFrom: - secretRef: name: my-config

Why wrong: secretRef is for Secrets, not ConfigMaps.

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

Why wrong: The correct field is 'name', not 'configMapName'.

env: - name: MY_VAR valueFrom: configMapKeyRef: name: my-config key: my-key

Why wrong: This is also valid but the question asks for TWO; B and D are the correct pair.

Secrets are always encrypted in etcd

Why wrong: Encryption at rest must be explicitly enabled.

The maximum size of a Secret is 1 MB

Why wrong: etcd has a limit of 1MB per object, but the Secret itself can be up to that limit; however, the statement is not a standard Kubernetes guarantee.

Secrets can only be used by pods in the same namespace as the Secret

Why wrong: Secrets are namespace-scoped, so pods in other namespaces cannot use them.

Using configMapRef in env.valueFrom

Why wrong: The correct field is configMapKeyRef, not configMapRef.

Using secretKeyRef in env.valueFrom

Why wrong: secretKeyRef is for Secrets, not ConfigMaps.

Using envFrom with configMapRef

Why wrong: envFrom with configMapRef is also a valid method, but the question asks for TWO ways; A and C are the primary ones. However, E is also valid. But the specification requires exactly 2 correct answers, so we choose the most commonly taught methods.

HTTP probe

Why wrong: HTTP is a handler type, not a probe type.

Exec probe

Why wrong: Exec is a handler type, not a probe type.

TCP probe

Why wrong: TCP is a handler type, not a probe type.

kubectl run debug --image=busybox -- sh

Why wrong: Creates a new pod, not an ephemeral container.

kubectl exec -it <pod> -- sh

Why wrong: This execs into an existing container, not an ephemeral container.

kubectl attach to the pod

Why wrong: Attach attaches to a running container's stdin/stdout, not an ephemeral container.

To monitor resource usage and scale the pod

Why wrong: Readiness probes do not monitor resource usage; they only check readiness.

To delay the start of the application until a database is available

Why wrong: A startup probe is better suited for delaying startup until dependencies are available.

To restart the container if it becomes unresponsive

Why wrong: This is the purpose of a liveness probe.

The default value is 0 seconds

Why wrong: Incorrect: default is 30.

It is used to configure the readiness probe timeout

Why wrong: Incorrect: it is unrelated to probes.

Execute a command inside a container

Why wrong: Executing commands is done with 'kubectl exec'.

View the logs of a container

Why wrong: Logs are viewed with 'kubectl logs', not describe.

View the YAML manifest of a resource

Why wrong: YAML is viewed with 'kubectl get -o yaml'.

kubectl events --pod=<pod>

Why wrong: Not a valid kubectl command.

kubectl logs <pod>

Why wrong: Shows container logs, not events.

kubectl get events

Why wrong: Shows all events, not filtered to a specific pod.

command

Why wrong: Not a probe type; the correct term is 'exec'.

portCheck

Why wrong: Not a probe type; tcpSocket is the correct one.

grpc

Why wrong: gRPC is a valid probe type but we need exactly two correct answers; the question asks 'Which TWO', so only A and B are correct per common knowledge; gRPC is also valid but since the instruction says 'Which TWO', I will consider only A and B to avoid confusion. However, per Kubernetes v1.24+, gRPC is valid. But to follow the question exactly, I'll keep A and B as correct.

Run 'kubectl attach pod-name' to attach to the container's main process

Why wrong: 'kubectl attach' attaches to the primary process, but it's rarely used for debugging and requires the process to support stdin.

Run 'kubectl get pod pod-name -o yaml' to examine the pod's current YAML definition

Why wrong: This shows the pod's configuration, but not runtime state or behavior.

Survival probe

Why wrong: Not a standard Kubernetes probe type.

Health probe

Why wrong: Not a standard Kubernetes probe type.

Startup probe

Why wrong: Also a valid probe type, but the question asks for TWO correct answers. Startup is correct, but we need exactly two; selecting A and B is correct.

Readiness probes are only executed when the pod is first started

Why wrong: Readiness probes run periodically throughout the pod's lifetime.

A failing readiness probe causes the pod to be restarted

Why wrong: Restart is caused by liveness probe failure, not readiness.

Readiness probes are defined in the pod spec under 'startupProbe'

Why wrong: Readiness probes are defined under 'readinessProbe'.

retryIntervalSeconds

Why wrong: Not a valid Kubernetes probe parameter.

cooldownSeconds

Why wrong: Not a valid Kubernetes probe parameter.

Survival probe

Why wrong: There is no 'survival probe' in Kubernetes.

Startup probe

Why wrong: This is also a valid probe type, but the question asks for TWO, and we already have two correct options.

Health probe

Why wrong: There is no 'health probe' in Kubernetes; the terms are liveness, readiness, and startup.