Application Design and Build
This domain tests whether you can assemble a workload that runs correctly the first time: images, Pod composition, batch workloads, and storage.
Images
Know how imagePullPolicy interacts with tags. Always is the default only when the tag is latest or omitted; any other tag defaults to IfNotPresent. Trap: pushing a new image under an existing tag and expecting the node to pick it up - it will reuse the cached image. Bump the tag or set imagePullPolicy: Always. For multi-stage builds, the final stage copies build output with COPY --from=builder /app/bin /usr/local/bin/app, keeping the runtime image small.
Multi-container Pods
initContainers run sequentially to completion before app containers start. Trap: an init container that never exits leaves the Pod stuck at Init:0/1; the app containers never launch and kubectl logs on the app container fails. Sidecars run alongside the main container and can be added as native sidecars with restartPolicy: Always on the container (newer clusters).
Jobs and CronJobs
Set restartPolicy: Never or OnFailure - Always is rejected. Tune backoffLimit, completions, and parallelism. CronJobs use a five-field schedule plus concurrencyPolicy and startingDeadlineSeconds.
Storage
emptyDir dies with the Pod; configMap/secret volumes update on change; persistentVolumeClaim volumes survive. subPath mounts a single file instead of shadowing a directory.
Worked example: a Job that must run exactly 4 times with at most 2 Pods concurrently uses completions: 4, parallelism: 2, restartPolicy: OnFailure, and backoffLimit: 3.
Rule of thumb: if a Pod is stuck before Running, look at init containers, image pulls, and volume mounts - in that order.