Scenario practice questions

You have a pod with two containers: one runs a web server, and the other is a sidecar that logs the web server's output to a central logging system. Which pattern does this represent?

Trap 1: Decorator pattern

The decorator pattern is a classic object-oriented design pattern that dynamically attaches responsibilities to objects, but it is not one of the recognized multi-container pod patterns in Kubernetes. Kubernetes defines three standard sidecar-like patterns: sidecar, ambassador, and adapter. Using 'decorator' would be inaccurate because it refers to class-level composition, not container-level process composition, and it has no specific deployment meaning in a pod spec.

Trap 2: Ambassador pattern

The ambassador pattern uses a proxy container to represent remote services locally, handling network connectivity, authentication, or failover. The ambassador container sits between the main container and the outside world, so the main container always connects to localhost while the ambassador forwards traffic. In a web server pair, unless the second container is specifically proxying or abstracting external connections, calling it an ambassador would be a mischaracterization.

Trap 3: Adapter pattern

The adapter pattern normalizes the main container's output to a standardized interface, often by transforming log formats or metrics so that external systems can consume them consistently. It does not enhance functionality but rather reconciles differences between the main container and the outside world. If the second container merely adds capabilities like TLS termination or request logging without converting output formats, it is a sidecar, not an adapter.

A
Sidecar pattern
The sidecar pattern adds a helper container to the same pod as the main application container. The helper extends or enhances the main container's behavior, such as by collecting logs, forwarding metrics, or managing file synchronization. Both containers share the pod lifecycle, so they start and stop together, and can communicate via localhost or a shared volume. This matches a web server paired with a logging agent or similar enhancement.
B
Decorator pattern
Why it fails: The decorator pattern is a classic object-oriented design pattern that dynamically attaches responsibilities to objects, but it is not one of the recognized multi-container pod patterns in Kubernetes. Kubernetes defines three standard sidecar-like patterns: sidecar, ambassador, and adapter. Using 'decorator' would be inaccurate because it refers to class-level composition, not container-level process composition, and it has no specific deployment meaning in a pod spec.
C
Ambassador pattern
Why it fails: The ambassador pattern uses a proxy container to represent remote services locally, handling network connectivity, authentication, or failover. The ambassador container sits between the main container and the outside world, so the main container always connects to localhost while the ambassador forwards traffic. In a web server pair, unless the second container is specifically proxying or abstracting external connections, calling it an ambassador would be a mischaracterization.
D
Adapter pattern
Why it fails: The adapter pattern normalizes the main container's output to a standardized interface, often by transforming log formats or metrics so that external systems can consume them consistently. It does not enhance functionality but rather reconciles differences between the main container and the outside world. If the second container merely adds capabilities like TLS termination or request logging without converting output formats, it is a sidecar, not an adapter.

Question 2hardmultiple choice

An administrator creates a Pod with an ephemeral container using 'kubectl debug my-pod -it --image=busybox --target=my-container'. The ephemeral container shares the same process namespace as the target container. Which flag enables this?

Trap 1: --container

The --container flag is an option for kubectl exec, used to select which container in a multi-container Pod receives the command; it does not influence how an ephemeral container is wired to existing kernel namespaces. In kubectl debug, --target occupies a similar role but is not an alias: --target shares PID, network, IPC, and UTS namespaces from the chosen container, whereas --container in exec merely scopes where a single command runs. Passing --container to kubectl debug would not establish the required namespace-sharing link and would be interpreted differently or rejected.

Trap 2: --namespace

The --namespace flag is a global kubectl option that sets the Kubernetes namespace—the cluster-scoping API object—used to locate the target Pod, not a Linux process namespace. On Linux, process/PID namespaces are kernel-level isolation mechanisms that can be shared between containers using kubernetes-level flags such as --target or the Pod spec's shareProcessNamespace field. Confusing the Kubernetes 'namespace' concept with the kernel 'namespace' term is a common pitfall, but --namespace only affects API discovery and never changes how the ephemeral container's processes are isolated.

Trap 3: --share-process-namespace

The --share-process-namespace flag is actually a field in the Pod specification (spec.shareProcessNamespace) that statically enables a single PID namespace for all containers created within that Pod. It is not a valid kubectl debug command-line flag, and setting it in the Pod spec does not automatically grant an ephemeral container access to existing containers' namespaces; the ephemeral container must still specify --target to join the namespace of a particular existing container. So even though the flag name sounds relevant, it is the wrong interface for dynamically debugging a running Pod.

A
--target
--target is the correct flag because it tells kubectl debug which container within the target Pod should serve as the namespace source for the ephemeral container. Without --target, the ephemeral container is created with its own network and process namespaces, so it cannot see the processes or network interfaces of other containers, severely limiting debugging. The flag's value must match a container name in the Pod spec, and it is supported only in kubectl debug, not in kubectl exec.
B
--container
Why it fails: The --container flag is an option for kubectl exec, used to select which container in a multi-container Pod receives the command; it does not influence how an ephemeral container is wired to existing kernel namespaces. In kubectl debug, --target occupies a similar role but is not an alias: --target shares PID, network, IPC, and UTS namespaces from the chosen container, whereas --container in exec merely scopes where a single command runs. Passing --container to kubectl debug would not establish the required namespace-sharing link and would be interpreted differently or rejected.
C
--namespace
Why it fails: The --namespace flag is a global kubectl option that sets the Kubernetes namespace—the cluster-scoping API object—used to locate the target Pod, not a Linux process namespace. On Linux, process/PID namespaces are kernel-level isolation mechanisms that can be shared between containers using kubernetes-level flags such as --target or the Pod spec's shareProcessNamespace field. Confusing the Kubernetes 'namespace' concept with the kernel 'namespace' term is a common pitfall, but --namespace only affects API discovery and never changes how the ephemeral container's processes are isolated.
D
--share-process-namespace
Why it fails: The --share-process-namespace flag is actually a field in the Pod specification (spec.shareProcessNamespace) that statically enables a single PID namespace for all containers created within that Pod. It is not a valid kubectl debug command-line flag, and setting it in the Pod spec does not automatically grant an ephemeral container access to existing containers' namespaces; the ephemeral container must still specify --target to join the namespace of a particular existing container. So even though the flag name sounds relevant, it is the wrong interface for dynamically debugging a running Pod.

Question 3easymultiple choice

You have a Deployment running a web server that takes 30 seconds to initialize. You want to ensure that the load balancer does not send traffic to the pod until it is ready. Which probe should you configure?

Trap 1: Resource limit

Resource limits define the maximum CPU and memory a container can consume, enforced by the kubelet and the container runtime. They influence scheduling decisions, OOM killer behavior, and throttling, but they have no interaction with the Service's endpoints list or the pod readiness state. A pod exceeding its memory limit may be terminated, but that is a restart/kill action, not a traffic routing action, so it cannot serve as a substitute for a readiness probe.

Trap 2: Startup probe

Startup probes are designed for containers that need extra time to initialize, such as those loading large models or establishing database connections; they run only once and, once successful, stop. However, a successful startup probe merely signals that the container has booted far enough for other probes (liveness and readiness) to take over; it does not itself influence whether the pod receives traffic after startup. For controlling Service routing continuously, a readiness probe is required because it provides an ongoing indication of whether the application can serve requests.

Trap 3: Liveness probe

Liveness probes check whether a container is still running and healthy; if they fail, the kubelet kills and restarts the container according to the restart policy. Crucially, a failing liveness probe does not remove the pod from Service endpoints—the pod continues to receive traffic until the restart actually happens, which could expose users to errors. While liveness probes help self-heal broken containers, they are not a traffic-routing mechanism and cannot replace a readiness probe for determining Service membership.

A
Readiness probe
The readiness probe is the correct mechanism because it directly controls whether a pod is added to or removed from the endpoints of a Service. When the probe fails, the kubelet marks the pod as NotReady, and the endpoints controller immediately removes its IP from all backing Services, stopping new traffic. This is essential for deployments where the application needs time to warm up or load data before accepting requests, and it also enables zero-downtime rolling updates by holding back new pods until they are fully operational.
B
Resource limit
Why it fails: Resource limits define the maximum CPU and memory a container can consume, enforced by the kubelet and the container runtime. They influence scheduling decisions, OOM killer behavior, and throttling, but they have no interaction with the Service's endpoints list or the pod readiness state. A pod exceeding its memory limit may be terminated, but that is a restart/kill action, not a traffic routing action, so it cannot serve as a substitute for a readiness probe.
C
Startup probe
Why it fails: Startup probes are designed for containers that need extra time to initialize, such as those loading large models or establishing database connections; they run only once and, once successful, stop. However, a successful startup probe merely signals that the container has booted far enough for other probes (liveness and readiness) to take over; it does not itself influence whether the pod receives traffic after startup. For controlling Service routing continuously, a readiness probe is required because it provides an ongoing indication of whether the application can serve requests.
D
Liveness probe
Why it fails: Liveness probes check whether a container is still running and healthy; if they fail, the kubelet kills and restarts the container according to the restart policy. Crucially, a failing liveness probe does not remove the pod from Service endpoints—the pod continues to receive traffic until the restart actually happens, which could expose users to errors. While liveness probes help self-heal broken containers, they are not a traffic-routing mechanism and cannot replace a readiness probe for determining Service membership.

Question 4mediummultiple choice

You have a multi-container pod with a main container and a sidecar container that collects logs. The sidecar container should start before the main container and must complete initialization tasks before the main container starts. Which type of container should you use for this purpose?

Trap 1: Ephemeral container

Ephemeral containers are temporary containers dynamically injected into an existing pod for interactive debugging or troubleshooting, often when the regular containers are missing tools or are unavailable. They are not part of the pod's startup lifecycle and do not run before the main container; they are added at runtime after the pod is already running. Because they are not defined in the pod's initial startup sequence, they cannot perform initialization tasks that must complete before the main container starts.

Trap 2: Job

A Job is a Kubernetes workload resource that manages a separate set of Pods that run a batch task to completion, but it is not a container type within a pod. A Job creates its own Pods with their own containers, completely decoupled from the pod running the main application. Because it is a distinct resource outside the pod, it cannot run before the main container inside the same pod or gate the startup of that container. Thus, a Job cannot fulfill the requirement of initializing prerequisites within the same pod as the main container.

Trap 3: Regular sidecar container

Regular containers in a pod, including sidecar containers, are all started concurrently when the pod is scheduled; Kubernetes does not guarantee an ordering between them. A regular sidecar (e.g., a logging agent or network proxy) provides supporting services alongside the main container, but it starts in parallel, so it cannot ensure that prerequisites are set up before the main container begins. Unlike init containers, regular sidecars are not designed to run to completion before other containers, and they do not block the main container's startup. Therefore, they are not a valid mechanism for pre-start initialization.

A
Ephemeral container
Why it fails: Ephemeral containers are temporary containers dynamically injected into an existing pod for interactive debugging or troubleshooting, often when the regular containers are missing tools or are unavailable. They are not part of the pod's startup lifecycle and do not run before the main container; they are added at runtime after the pod is already running. Because they are not defined in the pod's initial startup sequence, they cannot perform initialization tasks that must complete before the main container starts.
B
Init container
Init containers are special containers that run to completion sequentially before any regular containers in the pod start. Each init container must finish successfully before the next one begins, and the main container is only started after all init containers have succeeded. This makes them the correct choice for initialization tasks such as setting up volumes, waiting for dependencies, or performing migrations. If an init container fails, it is retried according to the pod's restartPolicy, ensuring the main container never starts prematurely.
C
Job
Why it fails: A Job is a Kubernetes workload resource that manages a separate set of Pods that run a batch task to completion, but it is not a container type within a pod. A Job creates its own Pods with their own containers, completely decoupled from the pod running the main application. Because it is a distinct resource outside the pod, it cannot run before the main container inside the same pod or gate the startup of that container. Thus, a Job cannot fulfill the requirement of initializing prerequisites within the same pod as the main container.
D
Regular sidecar container
Why it fails: Regular containers in a pod, including sidecar containers, are all started concurrently when the pod is scheduled; Kubernetes does not guarantee an ordering between them. A regular sidecar (e.g., a logging agent or network proxy) provides supporting services alongside the main container, but it starts in parallel, so it cannot ensure that prerequisites are set up before the main container begins. Unlike init containers, regular sidecars are not designed to run to completion before other containers, and they do not block the main container's startup. Therefore, they are not a valid mechanism for pre-start initialization.

Question 5hardmultiple choice

The Pod 'myapp' is in CrashLoopBackOff. Based on the exhibit, what is the most likely cause?

Exhibit

Refer to the exhibit.

$ kubectl logs myapp-6b4d9f8c7d-abcde
Error: listening on :8080: bind: address already in use
$ kubectl describe pod myapp-6b4d9f8c7d-abcde | grep -A5 Last State
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Message:      listening on :8080: bind: address already in use

Trap 1: The init container failed to complete.

The init container failed to complete. Init containers run to completion sequentially before any main container starts, and their logs appear under a separate init container log, not the main container's. A failure in an init container would place the pod in an Init:Error or Init:CrashLoopBackOff state, but the log here shows a runtime bind() error from the main application process, which is unrelated to init container execution.

Trap 2: The readiness probe is misconfigured.

The readiness probe is misconfigured. Readiness probe failures only remove the pod from Service endpoints; the container itself continues running and does not crash. An 'address already in use' error occurs during the main process's socket bind at startup, which is a fundamental network conflict, not a misconfiguration of HTTP or TCP probe settings. Probes do not interact with port binding and cannot produce this kind of kernel-level error.

Trap 3: The liveness probe is failing and restarting the container.

The liveness probe is failing and restarting the container. A liveness probe failure causes the kubelet to kill the container and restart it, but the resulting logs show probe timeout, connection refused, or HTTP non-2xx responses, not an 'address already in use' bind error. This error happens during the initial socket creation, before the liveness probe ever runs, and it is a direct consequence of a port conflict, not a health check failure. Restarting due to a liveness probe would not produce this specific system call error.

A
The init container failed to complete.
Why it fails: The init container failed to complete. Init containers run to completion sequentially before any main container starts, and their logs appear under a separate init container log, not the main container's. A failure in an init container would place the pod in an Init:Error or Init:CrashLoopBackOff state, but the log here shows a runtime bind() error from the main application process, which is unrelated to init container execution.
B
The readiness probe is misconfigured.
Why it fails: The readiness probe is misconfigured. Readiness probe failures only remove the pod from Service endpoints; the container itself continues running and does not crash. An 'address already in use' error occurs during the main process's socket bind at startup, which is a fundamental network conflict, not a misconfiguration of HTTP or TCP probe settings. Probes do not interact with port binding and cannot produce this kind of kernel-level error.
C
The container is trying to bind to a port already used by a sidecar or previous instance.
The container is trying to bind to a port already used by a sidecar or previous instance. The error 'address already in use' (EADDRINUSE) indicates that the application's listen() call failed because the port is already occupied in the shared network namespace. In a pod, containers share the same network namespace, so a sidecar bound to the same port would cause this conflict. Additionally, if a previous instance of the pod is still shutting down and holding the socket in TIME_WAIT, a rapid restart can trigger the same bind failure.
D
The liveness probe is failing and restarting the container.
Why it fails: The liveness probe is failing and restarting the container. A liveness probe failure causes the kubelet to kill the container and restart it, but the resulting logs show probe timeout, connection refused, or HTTP non-2xx responses, not an 'address already in use' bind error. This error happens during the initial socket creation, before the liveness probe ever runs, and it is a direct consequence of a port conflict, not a health check failure. Restarting due to a liveness probe would not produce this specific system call error.

Question 6hardmultiple choice

You are deploying a Pod that contains two containers: a web server and a file sync agent. The file sync agent needs to run as long as the web server is running and should share the same network namespace. Which design pattern does this represent?

Trap 1: Adapter pattern

The adapter pattern is used to normalize interfaces between the main container and an external system, not to run a co-located auxiliary service. An adapter container typically transforms data formats or protocol payloads so that the primary application can speak to a broader ecosystem. Because the question describes a second container providing ongoing supporting functionality rather than converting data or interfaces, the adapter pattern does not fit here.

Trap 2: Ambassador pattern

The ambassador pattern assigns a local proxy container to mediate all traffic between the main container and external systems, abstracting network topology and connection management. It does not add auxiliary features like logging, monitoring, or health reporting directly; instead, it focuses solely on interactions with services outside the pod. Since the described second container is meant to be a general-purpose helper alongside the web container, not a network gateway, the ambassador pattern is incorrect.

Trap 3: Init container pattern

Init containers are special containers that run to completion sequentially before any regular container in the pod starts, then they are terminated and their resources are reclaimed. They are designed for setup tasks such as waiting for dependent services, populating shared volumes, or performing configuration checks, not for long-running support processes. Because the question states the pod contains two containers (a web container and another), those two must be running concurrently, which contradicts the init container's lifecycle of finishing before the main application starts.

A
Adapter pattern
Why it fails: The adapter pattern is used to normalize interfaces between the main container and an external system, not to run a co-located auxiliary service. An adapter container typically transforms data formats or protocol payloads so that the primary application can speak to a broader ecosystem. Because the question describes a second container providing ongoing supporting functionality rather than converting data or interfaces, the adapter pattern does not fit here.
B
Ambassador pattern
Why it fails: The ambassador pattern assigns a local proxy container to mediate all traffic between the main container and external systems, abstracting network topology and connection management. It does not add auxiliary features like logging, monitoring, or health reporting directly; instead, it focuses solely on interactions with services outside the pod. Since the described second container is meant to be a general-purpose helper alongside the web container, not a network gateway, the ambassador pattern is incorrect.
C
Init container pattern
Why it fails: Init containers are special containers that run to completion sequentially before any regular container in the pod starts, then they are terminated and their resources are reclaimed. They are designed for setup tasks such as waiting for dependent services, populating shared volumes, or performing configuration checks, not for long-running support processes. Because the question states the pod contains two containers (a web container and another), those two must be running concurrently, which contradicts the init container's lifecycle of finishing before the main application starts.
D
Sidecar pattern
The sidecar pattern is precisely the design where an additional container is deployed in the same Pod alongside the main application container to augment its capabilities without changing its code. Sidecars share the Pod lifecycle and can provide functionality such as log collection, metrics scraping, health endpoints, or service mesh traffic handling. This matches the described scenario of a web container being paired with a supporting service, making the sidecar pattern the correct answer.

Question 7hardmultiple choice

You have a Deployment called 'web-deploy' with 3 replicas. One of the pods is not receiving traffic, but it shows 'Running' and passes its liveness probe. The readiness probe is configured as a TCP socket check on port 8080. You verify that the application is listening on port 8080. What is a likely reason the pod is not receiving traffic?

Trap 1: The service is configured to use a different port

A Service routes traffic to pods via label selectors and port mappings: `port` is the Service's listening port and `targetPort` directs traffic to the pod's actual port. If these do not match the containerized application's listening port, kube-proxy forwards requests to a closed port, producing connection refusals or timeouts for all clients. However, such a mismatch is a static configuration defect that exists independently of pod readiness; it would not cause a readiness probe to report success when the app is unready. The scenario's root cause is the probe's shallow check, not the Service's port configuration.

Trap 2: The pod's node is cordoned

Cordoning a node sets it as unschedulable, meaning the scheduler will not place any new Pods there and existing pods are allowed to continue running. It does not affect the health or readiness of a Pod that is already running on that node, nor does it change probe behavior. If the node were truly cordoned and the pod was subsequently evicted, the replacement would remain Pending, but the described pod is Running and passing probes, ruling out cordoning as the cause. Thus cordoning cannot explain why readiness succeeds while the application is not actually ready.

Trap 3: The liveness probe is failing and restarting the container

A liveness probe determines whether to restart a container by signaling the kubelet to kill and restart it upon repeated failures. If this probe were failing, the container would be in a restart loop or CrashLoopBackOff state, and the pod would not be `Running` and ready; instead it would show restarts and potentially `Running` but with failing liveness. The given situation explicitly indicates the liveness probe passes and the container is Running, so the fault is not liveness. This option is wrong because the symptom misrepresents the probe's role: liveness checks process health, while readiness checks serviceability, and the issue lies in a readiness check that is too lenient.

A
The service is configured to use a different port
Why it fails: A Service routes traffic to pods via label selectors and port mappings: `port` is the Service's listening port and `targetPort` directs traffic to the pod's actual port. If these do not match the containerized application's listening port, kube-proxy forwards requests to a closed port, producing connection refusals or timeouts for all clients. However, such a mismatch is a static configuration defect that exists independently of pod readiness; it would not cause a readiness probe to report success when the app is unready. The scenario's root cause is the probe's shallow check, not the Service's port configuration.
B
The pod's node is cordoned
Why it fails: Cordoning a node sets it as unschedulable, meaning the scheduler will not place any new Pods there and existing pods are allowed to continue running. It does not affect the health or readiness of a Pod that is already running on that node, nor does it change probe behavior. If the node were truly cordoned and the pod was subsequently evicted, the replacement would remain Pending, but the described pod is Running and passing probes, ruling out cordoning as the cause. Thus cordoning cannot explain why readiness succeeds while the application is not actually ready.
C
The liveness probe is failing and restarting the container
Why it fails: A liveness probe determines whether to restart a container by signaling the kubelet to kill and restart it upon repeated failures. If this probe were failing, the container would be in a restart loop or CrashLoopBackOff state, and the pod would not be `Running` and ready; instead it would show restarts and potentially `Running` but with failing liveness. The given situation explicitly indicates the liveness probe passes and the container is Running, so the fault is not liveness. This option is wrong because the symptom misrepresents the probe's role: liveness checks process health, while readiness checks serviceability, and the issue lies in a readiness check that is too lenient.
D
The readiness probe is succeeding even though the application is not truly ready, because TCP check only verifies the port is open
A TCP readiness probe only opens a raw socket connection to the specified port; it reports success if the TCP handshake completes, regardless of what the application does after that. For a web application, the server process may accept the connection and even return a 503 or a placeholder page while still initializing, causing the probe to pass prematurely. This makes the probe an insufficient indicator of true readiness; the pod is added to the Service's endpoints even though it cannot serve valid HTTP responses. Therefore the correct fix is to use an HTTP or exec probe that validates the application's own health endpoint.

Question 8easymultiple choice

Which Kubernetes API version is used for creating a CronJob?

Trap 1: batch/v1beta1

The batch/v1beta1 API version was the original way to define CronJobs, but it has been deprecated since Kubernetes 1.21 and is no longer served in 1.25 or later. Using it on a modern cluster causes your manifest to be rejected by the API server because the version has been removed, so it cannot create a CronJob in current Kubernetes. Always specify batch/v1 for new and existing CronJob definitions.

Trap 2: cron/v1

There is no such API group as cron in Kubernetes; the API groups are defined in the core or registered extensions like batch, apps, and networking. A manifest with apiVersion: cron/v1 and kind: CronJob is invalid because the API server has no route for that group, resulting in an error like no matches for kind CronJob in version cron/v1. The Cron part of the resource name does not translate into an API group.

Trap 3: apps/v1

apps/v1 is a workload API group used for higher-level controllers such as Deployments, StatefulSets, DaemonSets, and ReplicaSets, none of which cover scheduled execution. CronJob is specifically part of the batch API group because, like Job, it exists to create one or more pods for finite, completable work rather than long-running services. Using apiVersion: apps/v1 with kind: CronJob will fail validation since apps/v1 does not define a CronJob resource.

A
batch/v1beta1
Why it fails: The batch/v1beta1 API version was the original way to define CronJobs, but it has been deprecated since Kubernetes 1.21 and is no longer served in 1.25 or later. Using it on a modern cluster causes your manifest to be rejected by the API server because the version has been removed, so it cannot create a CronJob in current Kubernetes. Always specify batch/v1 for new and existing CronJob definitions.
B
batch/v1
batch/v1 is the stable API version for CronJob, promoted to GA in Kubernetes 1.21. It is the only currently served version, so any CronJob manifest must use apiVersion: batch/v1, kind: CronJob. This indicates that the resource is a controller in the batch group that creates Jobs on a schedule.
C
cron/v1
Why it fails: There is no such API group as cron in Kubernetes; the API groups are defined in the core or registered extensions like batch, apps, and networking. A manifest with apiVersion: cron/v1 and kind: CronJob is invalid because the API server has no route for that group, resulting in an error like no matches for kind CronJob in version cron/v1. The Cron part of the resource name does not translate into an API group.
D
apps/v1
Why it fails: apps/v1 is a workload API group used for higher-level controllers such as Deployments, StatefulSets, DaemonSets, and ReplicaSets, none of which cover scheduled execution. CronJob is specifically part of the batch API group because, like Job, it exists to create one or more pods for finite, completable work rather than long-running services. Using apiVersion: apps/v1 with kind: CronJob will fail validation since apps/v1 does not define a CronJob resource.

Question 9mediummulti select

Which TWO of the following are valid ways to expose a container port in a pod spec?

Trap 1: spec.containers[].hostPort

spec.containers[].hostPort is invalid because hostPort is not a top-level field of a container spec; it is only recognized when nested inside the ports list. Placing it directly under the container would cause a schema validation error, as the Kubernetes API expects a ports array with each entry containing fields like containerPort and optionally hostPort.

Trap 2: spec.containers[].containerPort

spec.containers[].containerPort is invalid because containerPort is likewise a field inside the ports array entry, not a direct child of the container object. It merely records the port the container listens on and is informational; by itself it does not expose the container to external traffic—that requires a Service or an associated hostPort.

Trap 3: EXPOSE 8080 in Dockerfile

EXPOSE 8080 in the Dockerfile is invalid because Dockerfile EXPOSE is only a declaration of intended ports and does not publish or expose them in Kubernetes. The pod specification governs actual networking; Kubernetes ignores EXPOSE directives and relies on the ports defined in the container manifest to configure Service routing and host mappings.

A
spec.containers[].ports[].hostPort
spec.containers[].ports[].hostPort is valid because it explicitly maps a container port to a port on the host node's network interface, enabling external traffic to reach the container via the node's IP without requiring a separate Service object. This field must be nested inside a port entry, alongside containerPort, and comes with operational caveats such as port conflicts and node scheduling constraints.
B
spec.containers[].hostPort
Why it fails: spec.containers[].hostPort is invalid because hostPort is not a top-level field of a container spec; it is only recognized when nested inside the ports list. Placing it directly under the container would cause a schema validation error, as the Kubernetes API expects a ports array with each entry containing fields like containerPort and optionally hostPort.
C
spec.containers[].containerPort
Why it fails: spec.containers[].containerPort is invalid because containerPort is likewise a field inside the ports array entry, not a direct child of the container object. It merely records the port the container listens on and is informational; by itself it does not expose the container to external traffic—that requires a Service or an associated hostPort.
D
EXPOSE 8080 in Dockerfile
Why it fails: EXPOSE 8080 in the Dockerfile is invalid because Dockerfile EXPOSE is only a declaration of intended ports and does not publish or expose them in Kubernetes. The pod specification governs actual networking; Kubernetes ignores EXPOSE directives and relies on the ports defined in the container manifest to configure Service routing and host mappings.
E
spec.containers[].ports[].containerPort
spec.containers[].ports[].containerPort is valid because it declares the port number on which the container listens inside its network namespace. This declaration is essential for a Service to select and route traffic to the correct pod, and it provides useful metadata for debugging and documentation even though it does not, by itself, open access to the outside world.

Question 10mediummultiple choice

You want to use Kustomize to apply a patch to a Deployment in the 'overlays/production' directory. Which command should you run from the kustomization directory?

Trap 1: kubectl create -k overlays/production/

The `-k` flag is a kustomize-specific option that exists only on `kubectl apply`, not on `kubectl create`. `kubectl create` is an imperative command for creating resources from raw files or stdin, and while it supports `-f`, it has no built-in kustomize integration. Running `kubectl create -k overlays/production/` would fail with an error because the flag is unrecognized, so it cannot apply the kustomization as intended.

Trap 2: kustomize build overlays/production/ | kubectl apply -f -

While this pipeline does work—`kustomize build` renders the patched resources and `kubectl apply -f -` applies them from stdin—it is not a single command, which violates the question's implicit constraint. The pipe also introduces an extra step and requires the `kustomize` binary to be installed separately, whereas the integrated `kubectl apply -k` is simpler and more maintainable. The question asks for the best way to apply a kustomization, and using `-k` is more direct and idiomatic than manually building and piping.

Trap 3: kubectl apply -f overlays/production/

The `-f` flag treats the directory as a collection of raw YAML files, not as a kustomization root. When you run `kubectl apply -f overlays/production/`, kubectl will ignore `kustomization.yaml` and instead attempt to apply any regular YAML files in that directory, which usually do not exist or are just base files—so the patches defined in the overlay will never be applied. This command does not invoke kustomize at all, so it fails to apply the patch to the deployment as requested.

A
kubectl create -k overlays/production/
Why it fails: The `-k` flag is a kustomize-specific option that exists only on `kubectl apply`, not on `kubectl create`. `kubectl create` is an imperative command for creating resources from raw files or stdin, and while it supports `-f`, it has no built-in kustomize integration. Running `kubectl create -k overlays/production/` would fail with an error because the flag is unrecognized, so it cannot apply the kustomization as intended.
B
kubectl apply -k overlays/production/
`kubectl apply -k overlays/production/` is the correct declarative approach because the `-k` flag tells kubectl to treat the directory as a kustomization root, build the resource set defined in `kustomization.yaml`, and send the resulting resources to the API server for apply. It is a single command that natively leverages the kustomize build process inside kubectl, exactly matching the requirement to use kustomize to patch a deployment. This is the canonical way to apply an overlay in modern kubectl without extra tools or piping.
C
kustomize build overlays/production/ | kubectl apply -f -
Why it fails: While this pipeline does work—`kustomize build` renders the patched resources and `kubectl apply -f -` applies them from stdin—it is not a single command, which violates the question's implicit constraint. The pipe also introduces an extra step and requires the `kustomize` binary to be installed separately, whereas the integrated `kubectl apply -k` is simpler and more maintainable. The question asks for the best way to apply a kustomization, and using `-k` is more direct and idiomatic than manually building and piping.
D
kubectl apply -f overlays/production/
Why it fails: The `-f` flag treats the directory as a collection of raw YAML files, not as a kustomization root. When you run `kubectl apply -f overlays/production/`, kubectl will ignore `kustomization.yaml` and instead attempt to apply any regular YAML files in that directory, which usually do not exist or are just base files—so the patches defined in the overlay will never be applied. This command does not invoke kustomize at all, so it fails to apply the patch to the deployment as requested.