Select Two (Multi-Select) Questions

udpSocket

Why it fails: Kubernetes defines exactly three probe handlers: exec, httpGet and tcpSocket. There is no udpSocket handler, since UDP is connectionless and cannot confirm application liveness through a handshake. A UDP service would need an exec command or a TCP health endpoint instead.

Init

Why it fails: Init containers are specialized containers that run sequentially to completion before the main application containers start. They are not a pattern for running alongside; they are a lifecycle construct used for setup tasks like waiting for dependencies, seeding data, or setting permissions. Thus they represent a different kind of multi-container arrangement, not a co-running pattern.

Replicator

Why it fails: Replicator is not a recognized multi-container Pod pattern in Kubernetes. The standard sidecar, adapter, and ambassador patterns are widely referenced in the Kubernetes documentation and CKAD curriculum, but "replicator" is a fabricated term with no defined semantics in the API or best practice literature. Therefore it cannot be a valid answer for patterns that govern multiple containers in a single Pod.

They cannot have resource limits set

Why it fails: This statement is false: init containers fully support resource requests and limits, configured in the same resources field used by regular containers. Limiting their CPU or memory is actually recommended to prevent setup tasks from starving main containers. Moreover, Kubernetes aggregates the highest init container resource request or limit into the Pod's effective resource usage for scheduling and QoS class determination.

They run after the main application containers have started

Why it fails: Init containers run before, not after, the main application containers. The kubelet enforces a strict ordering: all init containers must finish successfully, and only then are the regular containers started. Because main containers may rely on files, network connections, or configuration produced by init containers, they are never scheduled to start while init containers are still executing.

kubectl logs my-pod

Why it fails: The `kubectl logs my-pod` command retrieves the standard output and standard error streams from one or more containers in the pod, not the pod's configuration or state. This is application-level telemetry, which is useful for observing runtime behavior but carries no data about the pod's spec, labels, conditions, container statuses, or events. It therefore cannot serve as a way to get detailed information about the pod object itself.

kubectl exec my-pod -- env

Why it fails: `kubectl exec my-pod -- env` runs the `env` binary inside the pod's primary container, printing only the container's environment variables. This is a container introspection command, not a pod inspection command, and it bypasses the Kubernetes API object entirely. You would see no pod-level details like restart counts, QoS class, node assignment, or events, so it fails to provide detailed pod information.

Readiness probes are only used during initial startup

Why it fails: Readiness probes are not limited to the initial startup window. They start being checked as soon as the container begins, but, unlike the startup probe, they never stop: the kubelet keeps invoking them at every configured interval for the container's entire lifetime. A pod that becomes unready later in its life is still removed from Service endpoints, proving the probe continues beyond the initial phase.

Readiness probes can only be of type httpGet

Why it fails: Readiness probes support multiple handlers, not just httpGet. The kubelet can perform a tcpSocket check by opening a TCP connection to a port, an exec check by running a command inside the container and treating exit code 0 as success, or a grpc check using a gRPC health probe. The httpGet scheme is merely one of the available options and is chosen by adding a handler to the probe spec.

Readiness probes restart the container if they fail

Why it fails: A failing readiness probe does not cause the kubelet to kill or restart the container; restart decisions belong exclusively to liveness probes. If a readiness probe fails, the kubelet simply updates the pod's Ready condition and removes it from the backing endpoints of Services. The container keeps running and the probe continues to be evaluated, so a successful future probe can bring the pod back into rotation without any restart.

Init containers support liveness and readiness probes.

Why it fails: Init containers are not long-running services and therefore do not expose liveness or readiness probes; they simply run to completion. The kubelet judges their health only by exit status: zero means success, non-zero means failure. If a probe was needed to determine readiness, you would put it on the main application container instead.

Init containers share the same filesystem as the application containers by default.

Why it fails: By default each container, whether init or regular, gets its own writable layer and does not see the other's root filesystem. The only way init containers share data with application containers is by mounting the same volume, such as emptyDir or a ConfigMap, into both at explicit paths. The container image filesystems themselves are isolated from each other.

Init containers have a restart policy of Always.

Why it fails: Init containers are not configured with a restartPolicy of their own; they use the pod's restartPolicy (Always, OnFailure, or Never). If the pod restartPolicy is Never, a failed init container marks the pod Failed, whereas an Always pod would cause the kubelet to restart the init container. Thus the statement misattributes a fixed policy that does not exist for init containers.

Headless Services have a ClusterIP assigned.

Why it fails: Headless Services explicitly set clusterIP: None, meaning they get no virtual IP address at all. Instead, the DNS lookup for the Service returns the individual pod IP addresses, allowing clients to connect directly to specific pod instances. This is essential for StatefulSets where each pod requires a stable network identity. Therefore, the statement that headless Services have a ClusterIP is false.

Services can only expose one port.

Why it fails: A Service definition can include a ports array with multiple entries, each having its own protocol (e.g., TCP, UDP), port, targetPort, and an optional name. This allows one Service to expose multiple endpoints, such as port 80 for HTTP and port 443 for HTTPS, using the same selector. Thus, the claim that Services can only expose one port is incorrect.

retrySeconds

Why it fails: This is not a valid field in Kubernetes probe configuration. The concept of retrying a probe is handled by failureThreshold, which defines the number of consecutive failures needed to mark the probe as failed. There is no "retrySeconds" field; instead, the periodSeconds controls the interval between probe attempts. Trying to set retrySeconds would result in a schema validation error.

intervalSeconds

Why it fails: The correct field name is periodSeconds, not intervalSeconds. periodSeconds defines how often the probe is executed, with a default of 10 seconds and a minimum of 1 second. Using intervalSeconds would be invalid because it doesn't exist in the probe spec, causing a YAML validation failure.

A Service of type ClusterIP is accessible from outside the cluster.

Why it fails: A ClusterIP Service gets a stable virtual IP from the cluster's service CIDR, and kube-proxy programs iptables or IPVS rules so that traffic to that IP is load-balanced to the Service's pods. This virtual IP is only routable inside the cluster's network namespace; it is never announced to external networks, so clients outside the cluster cannot reach it. To expose a ClusterIP Service externally, you must front it with a NodePort, LoadBalancer, or Ingress resource.

A Service of type ExternalName requires a selector to route traffic.

Why it fails: ExternalName is a special Service that returns a CNAME alias to an external DNS name instead of proxying to pods. It deliberately has no selector, and because the Service never creates Endpoints, a selector is not only unnecessary but also meaningless. When a client resolves the Service's DNS name, they get the external domain, so traffic bypasses kube-proxy entirely.

A headless Service has clusterIP set to "0.0.0.0".

Why it fails: A headless Service is configured by setting clusterIP to None, not to 0.0.0.0, because you are explicitly telling Kubernetes not to allocate a virtual IP. Without a clusterIP, the Service does not do load balancing; instead, the DNS A record query returns the IP addresses of the backing pods directly. This pattern is used for stateful applications that need stable network identities or direct pod-to-pod discovery.

volumeMounts: - name: secret-volume mountPath: /etc/secret

Why it fails: Mounting a Secret as a volume exposes all of its keys as files under the specified mount path (here `/etc/secret`), not as environment variables. The container would see a file named `my-key` (or whatever key exists) at `/etc/secret/my-key`, and the application would need to read from the filesystem. While this is a legitimate way to consume Secrets, the question asks specifically about exposing a secret value as an environment variable, so this option does not satisfy that requirement. It is also worth noting that volume mounts are subject to file permissions and require the application to handle file I/O, unlike direct env var injection.

env: - name: MY_SECRET value: "$(MY_SECRET)"

Why it fails: This option uses the `value:` field with a literal string `"$(MY_SECRET)"`, which does not trigger any Kubernetes expansion mechanism. Kubernetes does NOT perform substitution inside `value` or `valueFrom` fields; the `$(VAR)` syntax is only expanded by the shell inside container `command` or `args`, not within pod spec env definitions. Moreover, even if `MY_SECRET` were set elsewhere in the environment, this would simply assign the literal five-character string `$(MY_SECRET)` to the variable, not the secret's value. To reference a Secret, you must use `valueFrom.secretKeyRef` or the `envFrom` approach.

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

Why it fails: This option incorrectly uses `configMapKeyRef` to source from a Secret. The `configMapKeyRef` field is specifically designed to reference ConfigMaps, not Secrets; referencing a Secret with it will fail with an error like `Error from server: object 'my-secret' not found` or a type mismatch, because the API expects a ConfigMap resource. Even though the YAML structure looks similar to the correct `secretKeyRef`, the `configMapKeyRef` keyword tells the kubelet to look for a ConfigMap, and a Secret cannot fulfill that expectation. Always use `secretKeyRef` when sourcing from a Secret — mixing the two reference types is a common mistake.

If no NetworkPolicy selects a pod, then that pod is isolated and traffic is denied

Why it fails: The default Kubernetes behavior is permissive: if no NetworkPolicy selects a pod, all inbound and outbound traffic is permitted. A pod only becomes isolated when a NetworkPolicy explicitly selects it, at which point traffic not allowed by the policy is denied. This statement incorrectly assumes a default-deny model, but in the absence of a policy, the pod is not isolated at all.

NetworkPolicy is only applicable to Services

Why it fails: NetworkPolicy operates directly on pods identified by label selectors, not on Service objects. Services are Kubernetes resources that provide stable IPs and DNS names for a set of pods, but they do not sit in the network path; NetworkPolicy rules apply to the pod's network interface, regardless of whether a Service fronts it. Even if you write a rule that references a Service, the actual enforcement is against the back-end pods matched by the Service's selector.

NetworkPolicy is a cluster-scoped resource

Why it fails: NetworkPolicy is namespaced: it resides in a specific namespace and its podSelector can only match pods in that same namespace. Unlike cluster-scoped resources such as ClusterRole or PersistentVolume, a NetworkPolicy cannot span namespaces or select pods from another namespace. This per-namespace scope is essential for isolating applications and enforcing tenant security boundaries.

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

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

retryIntervalSeconds

Why it fails: retryIntervalSeconds is not a valid Kubernetes probe parameter. The probe spec (livenessProbe, readinessProbe, startupProbe) has no retry field; instead, the kubelet continuously evaluates probe results across periods, and consecutive failures are handled by failureThreshold. This term resembles retry logic from external tools like Argo Rollouts, but it does not exist in the core API.

cooldownSeconds

Why it fails: cooldownSeconds is not a valid Kubernetes probe parameter. This is not part of the Probe spec; Kubernetes uses failureThreshold and successThreshold to determine how many consecutive failures or successes are required to change container state. Cooldown is a concept found in autoscalers or other controllers, but it is not a field in the probe configuration.

kubernetes.io/configmap

Why it fails: The value `kubernetes.io/configmap` is not a Secret type at all—ConfigMaps are a separate API object with `kind: ConfigMap`, and their data is not base64-encoded or intended for sensitive information. Kubernetes defines Secret types only under the `kubernetes.io/` prefix for specific credentials or configuration data, and the valid types are `Opaque`, `kubernetes.io/tls`, `kubernetes.io/basic-auth`, `kubernetes.io/ssh-auth`, `kubernetes.io/dockerconfigjson`, `kubernetes.io/dockercfg`, `kubernetes.io/service-account-token`, and `bootstrap.kubernetes.io/token`. A claim like this one typically arises from conflating the `configmap` subcommand with Secret types, but the API server would reject it as an invalid type, defaulting to Opaque.

kubernetes.io/tls-key

Why it fails: The string `kubernetes.io/tls-key` is not a valid Kubernetes Secret type because the built-in type for TLS material is simply `kubernetes.io/tls`, and the private key itself is a data key (`tls.key`) inside that secret, not a separate type. Kubernetes does not prefix Secret type names with a hyphenated component like `-key`; any unrecognized type is treated as an Opaque secret, which would not be properly handled by the Ingress controller expecting the TLS-specific type.

kubernetes.io/ssh-key

Why it fails: There is no `kubernetes.io/ssh-key` Secret type; the correct built-in type for SSH authentication credentials is `kubernetes.io/ssh-auth`, which expects a single `ssh-privatekey` data key. The suffix `-key` is misleading because it confuses the type name with the data key convention used by `kubernetes.io/tls` (where the key is a data field, not the type). Kubernetes only recognizes the exact string `kubernetes.io/ssh-auth`, and using a non-existent type would cause the secret to be treated as Opaque, losing any type-specific behavior.

As environment variables using env with valueFrom.configMapKeyRef

Why it fails: Setting an individual environment variable with env.valueFrom.configMapKeyRef points to a ConfigMap key, not a Secret. Kubernetes uses secretKeyRef for pulling a specific key from a Secret into an env var, so this approach fails to access secret data and is not a valid consumption method.

As a command-line argument using $(DB_PASSWORD)

Why it fails: The $(DB_PASSWORD) syntax in container arguments is expanded from environment variables that already exist in the container, but it cannot directly reference a Secret object. To use a Secret value in a command or argument, the Secret must first be exposed either as an environment variable via secretKeyRef or as a mounted file—there is no direct path from a Secret to the command line.

As an imagePullSecrets entry

Why it fails: imagePullSecrets is a Pod-level field used to authenticate to private container registries when pulling images. It references a Secret of type kubernetes.io/dockerconfigjson and only serves as a credential for the image pull operation—it never exposes the Secret data inside the container as environment variables or files. Therefore, it is not a valid way for an application to consume Secret data.

Selectors are used to identify a single object based on its labels.

Why it fails: Incorrect. Label selectors are designed to match a set of objects that share label values, not to identify a single object. For example, a selector with 'app=frontend' selects all Pods with that label, possibly many. Even if a label happens to be unique, the selector mechanism is set-based; object identity is provided by name and UID, not labels.

Selectors must be defined in the resource definition itself.

Why it fails: Incorrect. Selectors are not a required field in every resource definition. Fundamental objects like ConfigMaps and Secrets do not define selectors; selectors appear in higher-level constructs such as Services, Deployments, and NetworkPolicies to link them to their targets. In fact, many resources can be created with no selector at all.

Labels cannot be added after an object is created.

Why it fails: Incorrect. Labels are not immutable; they can be attached or modified after object creation using the kubectl label command. This design lets teams retrofit organizational or routing metadata onto live resources without recreating them, and label changes take effect immediately for controllers and services.

kubectl edit deployment/myapp and change the image field

Why it fails: Although kubectl edit can modify the image by opening the Deployment's live configuration in a text editor, it is an interactive, manual process rather than a direct command-line update method. The command does not accept the new image as an argument; it requires the user to locate and change the field themselves, which is not suitable for scripting or automation. Therefore, it does not qualify as a valid method for this question.

kubectl rollout image deployment/myapp mycontainer=nginx:1.21

Why it fails: kubectl rollout image is not a valid kubectl subcommand; the kubectl rollout command is reserved for managing deployment history, status, undo, pause, and resume. The correct imperative command to update a container image is kubectl set image deployment/myapp mycontainer=nginx:1.21. Since the specified command does not exist, it cannot update the Deployment.

kubectl create -f deployment.yaml

Why it fails: kubectl create -f deployment.yaml is an imperative creation command that only works for resources that do not already exist. If the Deployment is already running, this command fails with an AlreadyExists error and does not modify the existing Deployment. Updates require a replacement method like kubectl replace or an imperative update like kubectl set image.

ConfigMaps are immutable and cannot be updated after creation

Why it fails: ConfigMaps are not immutable by default; they are mutable and can be updated at any time using `kubectl edit` or `kubectl apply`. When a ConfigMap is updated and mounted as a volume, the kubelet periodically syncs the data, and containers see the new content with a delay (typically a few seconds to a minute). However, if the ConfigMap is consumed through environment variables, changes will not take effect until the pod is restarted because environment variables are set only during container startup.

ConfigMaps are suitable for storing sensitive data like passwords

Why it fails: ConfigMaps are explicitly designed for non-sensitive configuration data, such as application settings, feature flags, or configuration files. Storing passwords or API keys in a ConfigMap exposes them as plaintext in the API server and etcd, with no additional security layer—unlike Secrets, which are meant to be handled with care and can be protected with RBAC and encryption at rest. Using ConfigMaps for sensitive data bypasses Kubernetes' intended separation of concerns and violates security best practices.

Secrets are encrypted at rest by default in Kubernetes

Why it fails: Kubernetes does not encrypt Secrets at rest by default; they are stored in base64-encoded plaintext inside etcd, and anyone with etcd access or readable API privileges can decode them. To enable encryption at rest, administrators must configure the `EncryptionConfiguration` resource with a provider such as `aescbc` or a KMS plugin, and set the appropriate `--encryption-provider-config` flag on the API server. Without this configuration, Secrets are not meaningfully protected at rest.

Init containers run in parallel with regular containers.

Why it fails: This statement is false because init containers are explicitly executed in a separate phase that precedes the regular containers; regular containers are only started after all init containers have completed successfully. There is no overlap in execution: an init container and a regular container cannot be running simultaneously in the same pod. Moreover, even among init containers themselves, they run sequentially rather than in parallel, so concurrency is not a feature of init containers.

Init containers must use the same image as the main container.

Why it fails: This statement is incorrect because Kubernetes allows each init container to use a different image, and there is no requirement for it to match the image of the main container. This flexibility is intentional—init containers often use lightweight or specialized images (e.g., busybox, a curl image, or a custom utility) to perform setup tasks while the main container uses its own runtime image. The pod spec can list multiple init containers with totally different images, and that is perfectly valid.

Init containers cannot access volumes shared with regular containers.

Why it fails: This statement is false because init containers share the same pod-level volumes as regular containers, since they are part of the same pod definition. By mounting the same volume in an init container, you can pre-populate files, set permissions, or fetch data that the main container will later use—this is a common pattern. The pod spec allows you to declare volumes and then mount them in both initContainers and containers, so there is no restriction on volume access for init containers.

The kube-dns service is responsible for DNS resolution

Why it fails: The kube-dns service is not the component that performs DNS resolution; it is a ClusterIP service that points to the CoreDNS pods. CoreDNS is the actual DNS server that handles queries, while the kube-dns service exists for backward compatibility so that applications can resolve cluster-internal names. Saying the service itself is responsible conflates a stable network endpoint with the workload that implements the DNS feature.

Pods with hostNetwork: true automatically get DNS entries

Why it fails: Pods that run with `hostNetwork: true` share the node's network namespace and therefore do not receive a unique pod IP from the cluster CIDR. Because Kubernetes DNS does not have a pod IP to format into an A record, it does not automatically create a DNS entry for these pods. They can still use DNS as clients, but they are not discoverable via a pod-specific DNS name unless you manually assign a `hostname` and `subdomain` and attach them to a headless service.

A pod's DNS name is always 'pod-ip.namespace.pod.cluster.local'

Why it fails: Pod DNS records use the pod IP with dots replaced by dashes, for example `10-0-0-1.default.pod.cluster.local`, so the literal string `pod-ip` is never part of the name. These records are only created when the pod has a specified `hostname` and `subdomain` and belongs to a non-headless service; many pods do not have an A record at all. Therefore the statement's claim that the DNS name is 'always' this format is false, as most pods rely on service DNS names rather than their own.