Exercise 3: An Overrunning Backup CronJob With Default concurrencyPolicy — Possible Solution ==================================================================== What happens by default: The default `concurrencyPolicy` is `Allow`, per the chapter -- "runs can overlap." This means when the next scheduled run's trigger time arrives while the previous night's backup Job is STILL running, the CronJob simply creates a SECOND, entirely new Job alongside the first one -- both Jobs, and therefore both sets of backup pods, run CONCURRENTLY, completely independently of each other, with no awareness of one another at all. Why this is a real problem specifically for a backup job: Per the chapter, "for a job that genuinely shouldn't run twice concurrently (a backup writing to the same target, for instance), this can cause real data corruption or resource contention." Two backup processes running at the same time, both potentially reading from the same database and both potentially writing to the same backup destination/file, can produce a range of real problems: a corrupted or incomplete backup file if both processes write to the same target simultaneously, doubled resource consumption (CPU, memory, database connection load, network bandwidth) at exactly the moment the system is already under strain from the first, still-running backup, or -- depending on how the backup tool itself behaves under concurrent execution -- an outright failure of one or both runs. This is a genuinely more serious category of problem than simply "wasted resources" -- an actual data-integrity risk on the backup file itself, undermining the entire point of having a reliable backup in the first place. What concurrencyPolicy setting would prevent it: `Forbid`. Per the chapter, this setting "skip[s] the new run if the previous is still going" -- meaning if the previous night's backup Job is still executing when the next scheduled time arrives, the CronJob simply does NOT create a new Job at all for that cycle, waiting until the current one finishes before the schedule can trigger again. This directly eliminates the possibility of two backup Jobs ever running concurrently against the same target. (Note: `Replace` would be the wrong choice here specifically -- it would CANCEL the still-running, possibly nearly-complete backup and start a fresh one, potentially wasting the work already done and still risking an interrupted, incomplete backup file being left behind. `Forbid` is the safer choice for this specific scenario.) WHY THIS WORKS AS AN ANSWER ------------------------------ This applies the chapter's own default-behavior description (Allow) directly to the scenario, explains the SPECIFIC real-world consequence (data corruption/resource contention on a backup target) rather than a vague "it could be bad," and selects `Forbid` specifically over the other named alternative (`Replace`), explaining why `Replace` would actually be the wrong fix for this particular kind of job.