Application Design and Build practice questions

ExternalName

Why wrong: ExternalName maps a service to a DNS name (like an alias) by returning a CNAME record, with no selectors and no defined ports. It doesn't route traffic to pods or provide any port mapping, so a Deployment's pod IPs and container ports can never be reached through it. Therefore it cannot expose the 'web app' workload to clients, making it an invalid choice for this scenario.

ClusterIP

Why wrong: ClusterIP is the default Service type that assigns a stable virtual IP from the cluster's internal pool, load-balancing traffic to pod endpoints only within the cluster network. It is inaccessible from outside the cluster unless you add a NodePort, LoadBalancer, ingress controller, or port-forward, none of which are present. Thus a ClusterIP Service alone cannot provide external access to the web app, even though it is useful for internal communication.

LoadBalancer

Why wrong: LoadBalancer extends NodePort by requesting an external load balancer from the cloud provider (e.g., AWS ELB, GCP LB) via the service's 'type' field. On-premises or bare-metal clusters without a cloud controller manager cannot provision an external LB, and the service often remains in 'Pending' or merely falls back to NodePort behavior without actually creating a routable LB. Since the developer needs a reliable way to expose the deployment externally in a generic environment, LoadBalancer is only appropriate when a cloud provider integration is guaranteed, making it wrong in this unspecified context.

kubectl create configmap my-config --from-file=app.properties

Why wrong: Correct. The `--from-file` flag creates a ConfigMap with a single entry where the key is the filename (app.properties) and the value is the entire file content. This matches the requirement that the ConfigMap keys match the file content, meaning the file is stored as one key-value pair with the filename as the key.

kubectl create configmap my-config --from-literal=app.properties

Why wrong: The --from-literal flag is designed to create ConfigMaps from explicit key=value pairs written inline in the command, not from files. Supplying only 'app.properties' without an '=' sign is invalid syntax for this flag, and kubectl will reject it because it cannot parse the input as a literal. Even if it were syntactically accepted, it would simply create a literal key with an empty value, never reading the contents of the app.properties file. Therefore, this command does not satisfy the requirement of storing file content under a key.

cat app.properties | kubectl create configmap my-config --from-file=-

Why wrong: Incorrect. Piping the file content with `--from-file=-` reads from stdin, but the syntax is incorrect. It would create a ConfigMap with a single key named '-' and the value as the file content, not keys matching the file content.

Secrets cannot be used as environment variables.

Why wrong: Secrets can absolutely be used as environment variables. For example, you can reference a secret key using `valueFrom.secretKeyRef` or inject every key from a secret as an environment variable with `envFrom`. The idea that secrets cannot be used this way is false; this is one of the most common ways to consume secret values in a Pod.

Secrets are always encrypted at rest by default.

Why wrong: Secrets are not encrypted at rest by default. When you create a Secret, Kubernetes stores it in etcd as plaintext, often as the raw secret data that is only base64-encoded for display. To encrypt Secrets at rest, you must explicitly configure a KMS provider or a custom encryption configuration in the API server, and this also requires enabling the `EncryptionAtRest` feature with the appropriate provider.

Secrets are limited to 1KB in size.

Why wrong: The size limit for a Secret is 1 megabyte (1MB), not 1KB. Kubernetes imposes a 1MB limit on the total size of a Secret object, which includes the data itself along with any metadata. This limit exists to prevent etcd from being overwhelmed by enormous objects, but your typical Kubernetes Secrets are nowhere near that size, so the 1KB limitation is a myth.

The application requires rolling updates.

Why wrong: Rolling updates are not a StatefulSet-exclusive capability. Deployments also support rolling updates, with configurable maxSurge and maxUnavailable parameters, and StatefulSets have their own ordered, partition-based rolling update strategy. Since both controllers provide this feature, the mere requirement of rolling updates does not justify choosing a StatefulSet over a Deployment.

The application cannot be scaled down.

Why wrong: A StatefulSet can absolutely be scaled down; this is not a limitation of the controller. When scaled down, pods are terminated in reverse ordinal order (highest index first), which is a deliberate, safe process for stateful applications. Therefore, the claim that an application cannot be scaled down is not a valid reason to use a StatefulSet, because scaling down is fully supported.

restartPolicy: Always, backoffLimit: 6

Why wrong: For a Kubernetes Job, the restartPolicy field explicitly disallows the value Always; the API server rejects a Job manifest that specifies it because jobs are designed to run to completion, not to remain running. Setting backoffLimit to 6 is irrelevant here since the Job is invalid from the start, and even if it were accepted, the behavior would match a Deployment's restart semantics, which do not guarantee a single execution.

restartPolicy: Never, backoffLimit: 0

Why wrong: With restartPolicy: Never, the Job controller creates a new Pod for each retry, but backoffLimit: 0 means no retry Pod will ever be scheduled after the first attempt fails. This configuration does technically make the Job a single-attempt workload, but it is a risky approach: any transient error, such as a node restart or image pull issue, will immediately fail the Job with no chance for recovery, whereas 'run exactly once' typically implies a single successful execution, not a single attempt.

restartPolicy: Always, backoffLimit: 0

Why wrong: This configuration is invalid for Jobs because restartPolicy: Always is only allowed for controllers like Deployments and ReplicaSets, which are meant to keep Pods running continuously. Jobs require restartPolicy to be either Never or OnFailure so that a completed Pod is not restarted, and backoffLimit: 0 only amplifies the problem by setting zero retries, but the manifest would be rejected before any of those semantics can be applied.

ConfigMap updates are not propagated to mounted volumes.

Why wrong: This statement is false: when a ConfigMap is consumed through a mounted volume, the kubelet actively watches or periodically refreshes the ConfigMap and rewrites the projected files. A change to the ConfigMap object does eventually appear in the volume, so the problem is only timing, not a lack of propagation. The delay comes from the kubelet's sync loop, not from an immutable design.

The pods must be recreated after a ConfigMap update to see the changes.

Why wrong: This misconception ignores a key Kubernetes behavior: for volume-based ConfigMap usage, the kubelet updates the projected files without restarting or recreating the pod. A restart is only required when the ConfigMap is injected via environment variables, because environment variables are fixed at container start. Therefore, saying pods must be recreated after every update is too broad and false for mounted volumes.

ConfigMaps are immutable and cannot be updated.

Why wrong: ConfigMaps are mutable by default; the API accepts updates to their `data` field at any time, and the updated values eventually reach consumers. Immutability is an optional feature enabled by setting `immutable: true` in the ConfigMap spec, after which the object cannot be modified or deleted. The original statement treats an available opt-in as a default behavior, making it incorrect.

1. Define the Deployment in YAML, 2. Modify the YAML for the update, 3. Apply the YAML using kubectl apply

Why wrong: This order skips the initial apply, so the Deployment is never created before the update step. Without a pre-existing Deployment, `kubectl apply` on the modified YAML would simply create a Deployment from scratch with the updated spec, not perform a controlled rolling update from a previous version. In a real rollout workflow you must establish the original manifest as the baseline by applying it first; otherwise the deployment history and the ability to roll back to the previous revision are lost.

1. Define the Deployment in YAML, 2. Apply the YAML using kubectl apply, 3. Delete the existing Pods manually, 4. Re-apply the modified YAML using kubectl apply

Why wrong: Manually deleting Pods in this sequence is redundant and harmful because the Deployment controller continuously reconciles the actual state to the desired state. If you delete Pods before re-applying the modified YAML, the ReplicaSet will immediately recreate Pods using the old template, causing unnecessary churn and potential downtime. Once you re-apply the modified Deployment YAML, Kubernetes automatically triggers a rolling update that replaces Pods in a controlled manner with zero manual intervention.

1. Apply an empty or placeholder YAML, 2. Define the Deployment in YAML, 3. Modify the YAML for the update, 4. Re-apply the YAML using kubectl apply

Why wrong: Applying an empty or placeholder YAML before defining the actual Deployment is invalid and will not result in a usable resource. `kubectl apply` requires a complete manifest containing `apiVersion`, `kind`, `metadata`, and a valid spec; an empty file fails validation, while a placeholder with a resource kind but no meaningful spec would create an incomplete object or be rejected by the API server. The proper sequence must begin with writing the fully defined Deployment YAML, and then applying it; you cannot apply a resource that you have not yet specified.

Define the Service manifest, retrieve the NodePort, create the Deployment, apply the Service, then access externally.

Why wrong: This sequence attempts to retrieve the NodePort from the Service before the Service has been applied to the cluster. Retrieval (e.g., `kubectl get svc`) queries the live cluster state, and a manifest alone does not allocate a NodePort or create a Service object. Additionally, creating the Deployment only after defining the Service inverts the typical dependency: while a Service can technically be defined before its backing Pods exist, the intended workflow is to ensure the workload is running first, then expose it. The correct sequence must apply the Service before querying its allocated port.

Create the Deployment, apply the Service manifest, define the Service manifest, retrieve the NodePort, then access externally.

Why wrong: Applying a manifest before defining it is nonsensical in a declarative workflow: `kubectl apply -f` requires a valid manifest file as input, and merely defining it afterward cannot retroactively create the Service. Even if you interchanged the definition and apply steps, the NodePort should only be retrieved after the apply succeeds, because the port is assigned by the control plane at creation time. This sequence also omits the logical step of checking that the Deployment's Pods are ready before exposing, but the primary flaw is the reversed define/apply ordering.

Create the Deployment, define the Service manifest, retrieve the NodePort, apply the Service, then access externally.

Why wrong: This sequence correctly creates the Deployment and defines the Service manifest, but it retrieves the NodePort before applying the Service. The NodePort is not a static attribute of the manifest; it is dynamically allocated and stored in the Service's status when the Service is created in the cluster. Until `kubectl apply -f service.yaml` runs, the Service object does not exist, so any retrieval command fails or returns nothing. Only after the apply can you query the Service and obtain the `nodePort`, then construct the external URL.

Pod: Provides load-balanced access to a set of Pods

Why wrong: This statement is incorrect because a Pod is not a networking abstraction; it is a workload host that runs containers. Load-balanced access to a group of Pods is the job of a Service, which provides a virtual IP and distributes traffic to matching Pod endpoints. A Pod itself only has its own ephemeral IP and exposes no built-in load-balancing behavior.

Service: Manages rolling updates of Pods

Why wrong: This statement is incorrect because Services only route traffic to existing Pods and do not manage Pod lifecycles or rollout mechanics. Rolling updates—incrementally replacing old Pod versions with new ones while keeping the application available—are handled by Deployments (or ReplicaSet through a Deployment) using the configured update strategy. Services simply continue to send traffic to whichever Pods match their selector during the update.

ClusterIP: Exposes the service externally via a cloud load balancer.

Why wrong: This description mistakenly attributes LoadBalancer behavior to ClusterIP. A LoadBalancer type provisions an external cloud load balancer (e.g., AWS ELB, GCP LB) that forwards traffic to the service's NodePort or ClusterIP, giving a public IP. ClusterIP never creates external endpoints; it remains internal-only.

NodePort: Exposes the service on a cluster-internal IP only.

Why wrong: This statement confuses NodePort with ClusterIP because it omits the external access aspect. NodePort is built on top of ClusterIP but also opens a high-port on every node, making the service reachable from outside the cluster. A service that only has an internal IP and no node-level port exposure is a ClusterIP, not a NodePort.

Combine all RUN commands into a single layer

Why wrong: Combining all RUN commands into a single layer reduces the number of intermediate layers but does nothing to remove the Go toolchain, compilers, or system packages that were installed during the build. In fact, using a single RUN instruction can make caching worse because any change invalidates the entire layer, and the accumulated build dependencies remain permanently in that layer. This approach only optimizes layer metadata, not the actual disk footprint of the final image.

Add a .dockerignore file to exclude unnecessary files

Why wrong: Adding a .dockerignore file trims the build context sent to the Docker daemon, which speeds up the COPY of source code, but it has no effect on the size of the base image or the dependencies pulled in during the build. The dominant contributor to image size is usually the base image (like golang:latest) and the build tools, not the source files. The .dockerignore only prevents unwanted files from being copied; it cannot strip out the compiler, linker, or installed libraries that are already baked into the image layers.

Use a smaller base image like alpine:3.19

Why wrong: Switching to a smaller base image like alpine:3.19 reduces the OS layer, but you will still have to install the Go toolchain and any build dependencies on top of that base image, which adds significant size. More importantly, if you use alpine as the final image and keep all the build tools, the image remains bloated and retains a shell and package manager. The real win comes from using an alpine-based build stage and then copying the static binary to a scratch final stage, which is a multi-stage approach, not just a base image swap.

Run a sidecar proxy alongside the main container

Why wrong: A sidecar proxy is a regular container that runs concurrently with the main application container for the entire life of the pod, intercepting or forwarding traffic. An init container, by contrast, runs to completion and exits before any main containers begin, so it cannot serve as a continuously available proxy. This option confuses the long-running sidecar pattern with the short-lived, sequential init container phase.

Provide a health check endpoint for the main container

Why wrong: Health checks are implemented via readiness, liveness, and startup probes declared in a container's own spec, usually the main application container. Init containers run before the main container starts and have already terminated by the time probes are evaluated, so they cannot serve an endpoint or act as a health monitor for the main process. Probes are about ongoing runtime health, whereas init containers are purely about startup prerequisites.

Collect logs and metrics from the main container

Why wrong: Collecting logs and metrics from the main container is a classic sidecar container responsibility: a long-running helper that shares the pod's network and filesystem and continuously streams or aggregates data. An init container exits immediately after its setup steps, so it cannot persistently observe or export logs and metrics from the main application. This option describes a sidecar pattern, not the init container lifecycle.

apps/v1

Why wrong: apps/v1 is the API group for controller-managed workload objects such as Deployments, StatefulSets, and DaemonSets, all of which rely on a ReplicaSet or similar controller to maintain desired state. The pod created by `kubectl run ... --restart=Never` is a standalone Pod with no controller managing it, so its manifest must use `apiVersion: v1` and `kind: Pod`. Selecting apps/v1 would imply a Deployment or StatefulSet, which is not what this command generates.

batch/v1

Why wrong: batch/v1 is the API group reserved for Job and CronJob objects, which run containers to completion under a retry/backoff policy. Although some kubectl versions can generate Jobs with restart policies like OnFailure or Never, the `--restart=Never` flag specifically tells kubectl to generate a single Pod, not a Job. A Job object would appear as `kind: Job` with `apiVersion: batch/v1`, but here the command output is a Pod, so this group is wrong.

networking.k8s.io/v1

Why wrong: networking.k8s.io/v1 is the API group for network configuration resources such as Ingress, IngressClass, and NetworkPolicy, which define routing and pod-network access rules. `kubectl run` is meant to launch an application workload object, not a network rule, so its output never contains `apiVersion: networking.k8s.io/v1`. Associating the generated Pod with this group would be a categorical mistake because Pods are the workload itself, not a declaration about traffic between workloads.

Jobs will never overlap because the schedule is too frequent

Why wrong: This option is incorrect because a schedule interval shorter than the job's runtime does not prevent overlap; it actually guarantees overlap attempts. The CronJob controller triggers a new Job every 5 minutes regardless of whether the previous Job has completed. Since Replace policy is configured, the controller will forcibly terminate the prior Job at that point, so overlap is actively resolved, not avoided by the frequency itself.

The job will be skipped if the previous one hasn't finished

Why wrong: This behavior belongs to concurrencyPolicy: Forbid, not Replace. With Forbid, the controller skips the newly scheduled run if the previous Job is still running, leaving the old Job untouched. Replace, by contrast, never skips a schedule; it instead cancels and replaces the running Job so the new run proceeds immediately.

Jobs will overlap, with up to two jobs running concurrently

Why wrong: This is false because Replace is designed to eliminate overlap entirely, not limit it to two. The controller terminates the currently running Job before creating the next one, so at most one Job exists at a time. Allowing up to two concurrent Jobs would be the result of concurrencyPolicy: Allow, but even that policy does not impose a fixed maximum — it permits unbounded concurrency, not a cap of two.

docker image build --name myapp:v1 .

Why wrong: The `docker image build` subcommand is a valid alias for `docker build`, but the `--name` flag is not a recognized parameter for the build command; naming an image is done with `--tag` or `-t`. Additionally, the positional argument `.` specifies the build context, which is correct, but without a valid tag flag the command would fail because `--name` is interpreted as an unknown flag.

docker build myapp:v1 .

Why wrong: The `docker build myapp:v1 .` command is missing the `-t` flag. In Docker's build command, the first positional argument is always the build context path, not the image name. Here, `myapp:v1` would be interpreted as the context, and the `.` becomes a second positional argument, leading to an error or an attempt to use a non-existent directory as the build context.

docker tag myapp:v1 .

Why wrong: The `docker tag myapp:v1 .` command is intended for tagging an existing image, not for building one. It requires a source image reference (e.g., `myapp:latest`) and a new tag (e.g., `myapp:v1`) as arguments, but the `.` is not a valid image reference and does not serve as a build context either. This command would fail because there is no image named `.` and no build process is triggered.

spec.ttlSecondsAfterFinished: 3

Why wrong: The ttlSecondsAfterFinished field tells the Kubernetes TTL controller how long to keep a Job around after it completes, after which the Job and its Pods are automatically deleted. It has no effect on scheduling, concurrency, or the number of Pods created while the Job runs. Because it only governs post-completion cleanup, setting it to 3 cannot cause three Pods to be created.

spec.backoffLimit: 3

Why wrong: backoffLimit controls how many retries the Job controller will make before it marks the Job as failed; when a Pod fails, the controller waits an increasing backoff period and creates a replacement pod, up to this limit. It is about failure handling and fault tolerance, not the desired number of concurrent Pods. Setting backoffLimit: 3 only permits three failed attempts total, so it does not create three simultaneous Pods.

spec.completions: 3

Why wrong: spec.completions defines how many successful Pod completions are required before the entire Job is considered complete; it is a target count, not a concurrency limit. With completions: 3, the Job controller could still run one Pod at a time if parallelism is left at the default of 1, so it does not ensure three Pods run in parallel. Parallelism, not completions, determines how many Pods run at the same moment.

CMD always runs, ENTRYPOINT can be overridden

Why wrong: This is backwards. In Docker, the ENTRYPOINT is the fixed executable that always runs as the container's main process, while CMD supplies default arguments that are passed to that ENTRYPOINT. You can override CMD entirely by appending arguments to `docker run <image> <args>`, but you cannot override ENTRYPOINT that way; you must use the `--entrypoint` flag. Therefore CMD does not 'always run' as a separate command—it only fills in parameters when you don't supply your own.

There is no difference; they are interchangeable

Why wrong: CMD and ENTRYPOINT are not interchangeable; each plays a distinct role in container lifecycle. ENTRYPOINT defines the executable that is launched as PID 1, while CMD provides default arguments to that executable (or becomes the command itself only when no ENTRYPOINT is set). Furthermore, `docker run` arguments replace CMD but are appended to ENTRYPOINT, so swapping one for the other changes override behavior. They can be used together to build a predictable image API, which interchangeable directives would not allow.

CMD is used for shell form, ENTRYPOINT for exec form

Why wrong: Both CMD and ENTRYPOINT support both shell form and exec form; the choice of form is orthogonal to which instruction you are writing. Shell form (e.g., `ENTRYPOINT nginx -g 'daemon off;'`) invokes a shell wrapper, while exec form (e.g., `CMD ["nginx", "-g", "daemon off;"]`) runs the process directly. The difference matters for signal handling and process termination (PID 1), not for whether the keyword is CMD or ENTRYPOINT. You can mix forms across the two instructions without changing their fundamental roles.

The Job is retried indefinitely

Why wrong: Setting backoffLimit: 0 in a Job spec declares that the controller may attempt a Pod creation zero times after the first failure. When the single Pod fails, the controller increments the Job's failure counter to 1, immediately exceeds the allowed limit, and therefore does not schedule any replacement Pod or retry loop. An indefinite retry would require backoffLimit to be unset or a positive value, so this behavior is impossible with this configuration.

The pod is restarted until it succeeds

Why wrong: A Job's restart semantics operate at the Pod level: the controller creates new Pods to replace failed ones, while the container restartPolicy is normally Never or OnFailure for Jobs. With backoffLimit: 0, after the first Pod fails the Job controller refuses to create another Pod, so there is no loop of Pod recreations. The kubelet may restart the container only if the Pod's restartPolicy permits, but that does not make the Job retry the Pod until success; the controller's retry budget is already exhausted.

A new pod is created automatically

Why wrong: With backoffLimit: 0, the Job controller's retry algorithm determines that no additional attempts are allowed, so it does not generate a replacement Pod for the failed one. Automatic creation of a new Pod would require the current retry count to be less than the configured limit, but the first failure already matches that limit. Consequently, only the original failed Pod exists and the Job transitions to Failed rather than scheduling new work.

--container

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

--namespace

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

--share-process-namespace

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

batch/v1beta1

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

cron/v1

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

apps/v1

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