Application Design and Build practice questions

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

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

restartPolicy: Always, backoffLimit: 6

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

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

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

Set concurrencyPolicy: Allow

Why it fails: This explicitly allows multiple Job objects to run concurrently when the previous one hasn't finished. Since the requirement is to prevent overlapping executions, Allow does the opposite. The CronJob controller will create a new Job every scheduled time regardless of whether a previous Job is still active, leading to concurrent Pods and potential resource contention or race conditions on shared data.

Set startingDeadlineSeconds to a low value

Why it fails: This field only determines how far back the controller will look for missed schedules when the CronJob is out of sync or the CronJob resource is temporarily unavailable. A low value may cause missed runs to be skipped, but it does not influence whether a new Job is created while an older Job is still running. Overlap is governed by concurrencyPolicy, not by starting deadlines.

Set concurrencyPolicy: Replace

Why it fails: With Replace, when a new scheduled run occurs while an existing Job is still running, the controller terminates the running Job and its Pods, then creates a new Job. This deliberately causes a brief overlap or at least an interruption of the previous work, rather than preventing overlap. The requirement is to avoid starting a new Job at all if the previous one is still active, which is the behavior of Forbid, not Replace.

Lifecycle hooks

Why it fails: Lifecycle hooks are tied to a container's own lifecycle, not to inter-container dependencies. The PostStart hook executes after the container is created and runs concurrently with the entrypoint, so it cannot block or precede the main container's start; PreStop runs only during termination. Therefore hooks cannot guarantee that a sidecar is ready before the main application starts.

Readiness probe on the sidecar

Why it fails: Readiness probes only influence which pods receive Service traffic; they do not control when containers are started. All regular containers in a pod are created in parallel by the kubelet, so a sidecar's readiness probe cannot delay the main container's process from launching. It may prevent traffic from reaching the main container, but startup ordering remains unenforced.

Resource limits

Why it fails: Resource limits inform the scheduler for node placement and cause the kubelet to throttle or evict containers under pressure, but they do not introduce any ordering constraints. They do not alter the fact that the kubelet starts all regular containers concurrently when the pod is created, so they cannot order a sidecar ahead of a main application.

Ambassador

Why it fails: The ambassador pattern is a recognized Kubernetes sidecar pattern that acts as a network proxy to handle communication with external services on behalf of the main container. While it is a valid pattern in other contexts, this question asks for exactly two correct answers, and the intended choices are adapter and sidecar. Therefore, ambassador is not selected here, even though it is not an incorrect architectural style.

Init container

Why it fails: Init containers are special containers that run to completion before any app containers start in a pod. They are not sidecars because they do not run concurrently with the main container; they finish their setup tasks and terminate, whereas a sidecar shares the main container's lifecycle and runs throughout its lifetime. Thus they are not a valid pattern for sidecar containers.

Proxy

Why it fails: Proxy is not a recognized Kubernetes design pattern in the official pattern taxonomy. While a proxy container can be used as a sidecar (e.g., ambassador pattern), the term 'proxy' itself describes a generic role, not a specific architectural pattern with established best practices. In official Kubernetes documentation, the named patterns are sidecar, adapter, ambassador, and init container, so proxy is not a valid pattern in this context.

Parallel

Why it fails: Parallel is not a valid concurrencyPolicy value; the accepted values are Allow, Forbid and Replace. Parallel tempts because it accurately describes what Allow does — permitting concurrent Job runs — and mirrors terminology from parallelism settings elsewhere in Kubernetes. The API field itself, however, requires the literal string Allow.

Serial

Why it fails: Serial is not a concurrencyPolicy value; Kubernetes accepts Allow, Forbid and Replace. Serial tempts because it describes Forbid's behaviour of preventing overlapping runs, and resembles scheduling terminology from other systems. The API validates only the three literal strings, so Serial is rejected when the CronJob manifest is applied.

Replace

Why it fails: Replace is not a valid concurrencyPolicy value.

docker build .

Why it fails: This command correctly supplies the build context (the current directory) and will produce an image, but it omits the -t flag entirely. As a result, Docker assigns the default repository and tag (latest) rather than a meaningful tag like myapp:v1, making the image harder to identify, track, or reproduce. Untagged builds can also be overwritten by subsequent builds, so versioning is essential for maintainable workflows.

docker build -t myapp:v1

Why it fails: This command includes the -t flag to name the image myapp:v1, but it fails to provide the build context path as the final argument. Docker requires a build context (e.g., . for the current directory) to know which files to send to the daemon; without it, the CLI raises an error such as 'ERROR: buildx requires exactly 1 argument.' The context is mandatory because the Dockerfile itself and any files copied during the build must come from that directory.

docker push myapp:v1

Why it fails: The `docker push` command uploads a locally existing image to a container registry (e.g., Docker Hub or a private repository) and does not trigger an image build at all. If the image myapp:v1 does not already exist locally, the push will fail with an error like 'An image does not exist locally with the tag.' This command is intended for distribution after a successful build, not as a substitute for building an image from a Dockerfile.

kubectl apply -f pod.yaml

Why it fails: Wrong: `kubectl apply -f` requires a pre-existing YAML file; it does not create a Pod directly from an image name.

kubectl create pod nginx --image=nginx:latest

Why it fails: Wrong: `kubectl create pod` is not a valid subcommand; the correct imperative command is `kubectl run`.

kubectl run myjob --image=busybox --restart=OnFailure -- sleep 30

Why it fails: `kubectl run` always creates a Pod, not a Job, regardless of the `--restart` flag. In current kubectl versions, `--restart=OnFailure` is not supported with `kubectl run` for creating a Job; that behavior was deprecated.

kubectl create job myjob --image=busybox --command -- sleep 30

Why it fails: The '--command' flag is used with 'kubectl run', not 'kubectl create job'. It causes the command to be treated as a command line instead of an argument list, which is not needed here.

kubectl create job myjob --image=busybox sleep 30

Why it fails: Missing '--' separator before the command; the correct syntax is 'kubectl create job myjob --image=busybox -- sleep 30'.

ADD --from=builder /app/bin /app/

Why it fails: Incorrect. `ADD` without `--from` does not reference a previous stage; it copies from the build context. Additionally, `ADD` is not typically used for copying binaries; `COPY` is preferred.

COPY /app/bin /app/

Why it fails: Incorrect. `COPY` without `--from` attempts to copy from the filesystem, not from a previous stage. This would fail because the binary is only in the builder stage.

COPY --from=0 /app/bin /app/

Why it fails: Incorrect. While `COPY --from=0` is syntactically valid (using the numeric index of the first stage), it is not the best practice. CKAD encourages using stage names for readability and maintainability, making option C the correct choice.

Singleton

Why it fails: Singleton is a design pattern, but not a sidecar pattern in Kubernetes context.

DaemonSet

Why it fails: DaemonSet is a resource type, not a sidecar pattern.

Sidecar

Why it fails: Sidecar is a common pattern where an auxiliary container enhances the main container.

Increase the CPU request for the container

Why it fails: OOMKilled indicates the container exceeded its memory limit, not CPU starvation; increasing the CPU request leaves the memory ceiling unchanged, so the kernel will kill the process again. CPU requests are tempting because resource tuning is the right category, but memory limits and requests are the relevant parameters here.

Delete the namespace and redeploy all workloads

Why it fails: Deleting the namespace destroys all production workloads and data, far exceeding the scope of an OOMKilled container. It is tempting as a clean-slate fix, but the container exceeded its memory limit; raising the memory limit or request in the pod spec addresses the actual cause without collateral damage.

Delete and recreate the pod to clear the crash loop

Why it fails: Recreating the pod reuses the same memory limit, so the container will be OOMKilled again once it reaches the ceiling. It is tempting as a quick reset, but CrashLoopBackOff stems from the memory limit being too low; the pod spec must be amended to raise memory.

Init containers cannot have resource limits.

Why it fails: Init containers fully support the same resource model as regular containers — you can specify both requests and limits under resources in the initContainers array. A common subtlety is that the maximum of any init container's resource requests is considered when calculating the Pod's effective resource requirements for scheduling, but resource limits are absolutely allowed.

If an init container fails, it is not restarted.

Why it fails: This statement is incorrect because a failed init container is not permanently abandoned. Kubernetes subjects init container failures to the Pod's restartPolicy: if restartPolicy is Always or OnFailure, the kubelet restarts the failed init container (and may restart the entire Pod) until it exits successfully; only when restartPolicy is Never is it left in a Failed state.

Init containers can run concurrently with the main application containers.

Why it fails: Init containers and application containers never overlap in the Pod's lifecycle. All init containers must reach completion before the kubelet starts any regular container in the Pod, so there is no period during which an init container and a main application container are executing concurrently.

docker build -t myapp:v1

Why it fails: This command lacks the required build context positional argument. 'docker build' expects a path (or URL) as its final argument; without it, the CLI aborts with an error such as 'ERROR: requires at least 1 argument'. Even though the -t flag is correctly formed, the missing dot means Docker has no directory from which to read the Dockerfile, so the build cannot start.

docker build . -name myapp:v1

Why it fails: The flag '-name' is not recognized by the Docker build command; the correct flag for naming the resulting image is '-t' (or '--tag'). When Docker parses '-name myapp:v1', it tries to validate '-name' as an unknown option and fails before any build processing occurs. Even though the context '.' is present, the invalid flag is a hard error, so this command cannot work.

docker image build --tag myapp:v1

Why it fails: While 'docker image build' is a valid alias for 'docker build', this command still omits the mandatory build context argument. The '--tag' flag is equivalent to '-t', but without a trailing path (like '.'), Docker has no context to send to the daemon. Consequently, the build fails for exactly the same structural reason as any missing-context invocation, regardless of which subcommand alias is used.

startupProbe

Why it fails: A startupProbe only tells kubelet when the application inside a container has finished initializing so that liveness/readiness probes can begin. It does not influence the order in which containers are started — in a multi-container pod, all regular containers are scheduled and launched at the same time, even if one has a slow startup probe. Therefore it cannot make the web server wait for the database.

lifecycle.preStop

Why it fails: The lifecycle.preStop hook is executed after a pod has been told to terminate and before SIGTERM is delivered, giving the container a chance to clean up; it runs when containers are already up and running. It has no effect at pod creation time and certainly cannot reorder the initial startup sequence of containers. Thus it is irrelevant for making a dependency start first.

restartPolicy: Always

Why it fails: The restartPolicy: Always setting governs what kubelet does after a container exits — it restarts that container regardless of its exit code. It does not define any startup dependency or order between containers; all containers in the pod are still started concurrently when the pod is scheduled. Therefore changing restart policy would not make one container wait for another at initial startup.

kubectl debug web-pod --copy-to=debug-pod --image=busybox

Why it fails: This copies the pod into a new one, leaving the original untouched, so it cannot inspect the failing container's live state. It suits reproducing a pod's spec for iterative changes. Attaching to the running pod requires kubectl debug with --target or an ephemeral container on web-pod itself.

kubectl attach web-pod

Why it fails: kubectl attach connects to a container already running inside web-pod; it cannot inject a new debug container, and it fails outright if the container lacks a TTY or has exited. It is tempting because attaching sounds like joining a running pod, but ephemeral debugging requires kubectl debug with an --image and --target.

kubectl run debug --image=busybox -it

Why it fails: kubectl run creates a brand-new standalone pod rather than attaching an ephemeral container to web-pod, so it never joins the target's namespaces or process space. It is tempting because it does launch a debugging image interactively, which suits debugging a fresh pod, but the correct command is kubectl debug with --target.

.spec.jobTemplate.spec.template.spec.restartPolicy

Why it fails: The path .spec.jobTemplate.spec.template.spec.restartPolicy descends all the way into the Pod template wrapped by the Job template, so this is a PodSpec field rather than a direct field on CronJobSpec. CronJobSpec's own top-level schema contains only scheduling controls and Job template configuration, not Pod-level restart behavior. Because the question asks for fields valid in a cronjob spec, this nested path cannot be selected.

.spec.jobTemplate.spec.parallelism

Why it fails: The parallelism property belongs to JobSpec, and in a CronJob it appears nested at .spec.jobTemplate.spec.parallelism, not as a direct member of CronJobSpec. Although you are free to set parallelism in the jobTemplate to control how many Pods the resulting Job runs concurrently, the direct top-level CronJob fields are limited to schedule, concurrencyPolicy, startingDeadlineSeconds, suspend, and the two history limits. Selecting this option is incorrect because it is a Job-level field accessed through the template, not a field directly under the CronJob's spec.

Increase the CPU request for the container

Why it fails: Raising the CPU request only affects CPU scheduling guarantees and the CPU cgroup weight, not the container's memory cgroup limit. Since OOMKilled is triggered by the kernel when the container's memory usage exceeds its memory limit, altering CPU parameters has no effect on the memory cgroup that enforces the limit, so the container will continue to be OOM-killed.

Delete and recreate the pod to clear the crash loop

Why it fails: Deleting and recreating the pod does not change its resource specification; the ReplicaSet or Deployment controller will immediately create a replacement pod with the same memory limit. The new container will again exceed that limit during startup or normal operation and again be OOM-killed, so the crash loop backoff will simply start anew rather than being resolved.

Delete the namespace and redeploy all workloads

Why it fails: Deleting the production namespace would destroy every workload, service, configmap, secret, and persistent volume claim in it, causing a much larger outage than the single pod's crash loop. It does not fix the underlying memory limit issue, because any pod recreated afterwards would still specify the original limiting resource values, and the action is completely disproportionate for a problem that can be resolved by a targeted pod spec update.