Question 30
Domain 2: Application Deployment and WorkloadsWhich Kubernetes CronJob configuration runs every minute using the busybox image and ensures any job that starts more than 17 seconds late is skipped?
Correct answer: A
Explanation
A CronJob scheduled as "* * * * *" runs every minute, and using the "busybox" image matches the required container. Setting "startingDeadlineSeconds: 17" enforces the rule that a job starting more than 17 seconds late is skipped, which is exactly how Kubernetes defines the deadline for missed starts.
Why each option is right or wrong
A. Create a CronJob with schedule "* * * * *", container image busybox, command ["/bin/sh", "-c", "date; echo Hello from the Kubernetes cluster"], and startingDeadlineSeconds: 17
Kubernetes CronJobs use standard cron syntax, so the expression "* * * * *" schedules execution once per minute under the CronJob controller. The missed-start cutoff is governed by `startingDeadlineSeconds` in the CronJob API (`batch/v1`), and setting it to `17` means any run that cannot begin within 17 seconds of its scheduled time is treated as failed to start and is not created. The `busybox` image is the minimal container required here, and the shell command shown is the canonical test payload used to verify the job executes on schedule.
B. Create a Deployment with replicas: 1, image busybox, command ["date; echo Hello from the Kubernetes cluster"], and activeDeadlineSeconds: 17
C. Create a Job with image busybox, schedule "* * * * *", command ["/bin/sh", "-c", "date; echo Hello from the Kubernetes cluster"], and backoffLimit: 17
D. Create a CronJob with schedule "*/1 * * * *", image busybox, command ["/bin/sh", "-c", "date && echo Hello from the Kubernetes cluster"], and ttlSecondsAfterFinished: 17