A healthcare software vendor must keep pipeline run history and published build outputs for seven years to satisfy an audit rule. The platform team wants that enforced consistently for every pipeline in one Azure DevOps project. Where should the retention rule live?
Show answer and explanation
Answer: A
Azure DevOps retention policies are set at the project level, where administrators define how long pipeline runs and their artifacts are kept. Organization-wide policy limits constrain what a project can set, which gives central control. Pipeline YAML can request a retention value, but it cannot exceed what the project policy allows, so the central setting is what ensures consistency across pipelines. Comments have no effect on retention, and manual copies or file shares sit outside the pipeline run lifecycle.
Why the other options are wrong
- B. A comment in a pipeline file is documentation only and does not change how long Azure DevOps keeps runs or artifacts. Compliance needs an enforced setting, not a reminder that engineers may overlook.
- C. A monthly copy script is a manual, fragile workaround that is not tied to the pipeline's own retention lifecycle. Copies stored on a laptop also create uncontrolled data stores that are hard to audit.
- D. A file share mounted by agents sits entirely outside Azure DevOps retention, so nothing in the pipeline enforces how long outputs persist. The rule would depend on whoever maintains that share.