A public-health training job pulls an unsigned base container image from a public registry during the build. What supply-chain control should MLOps enforce?
Select an answer to reveal the explanation.
Short Explanation
An unsigned public base image is a mystery casserole in the cafeteria line — you do not know what went in. Use signed, approved images from a trusted registry. “Latest,” skipped scans, and laptop-only builds weaken the supply chain.
Full Explanation
A public-health training job that pulls an unsigned base container image from a public registry during the build is a supply-chain failure. MLOps should allow only signed, approved training images from a trusted registry. Compromised or trojanized base images can implant malware, reverse shells, or credential stealers into every subsequent civic training run, affecting PHI-adjacent workloads and shared GPU fleets. Trust starts with image provenance, signature verification, and an allowlist of approved bases—not with opportunistic public pulls.
Pinning every image tag to “latest” for automatic freshness fails because floating tags maximize surprise and undermine reproducibility and attestation. Disabling container scanning to speed overnight jobs fails because it removes detection of known vulnerable or malicious layers. Building training images on developer laptops with no registry fails because it fragments provenance, bypasses centralized policy, and often reintroduces unsigned, unscanned bases.
Exam caveat: public-health contexts raise the stakes but the control pattern matches general ML supply-chain security—signed images, trusted registries, scanning—not speed or convenience shortcuts.
Operational check: configure the build to pull only from the municipal trusted registry with signature verification enabled; deny “latest”; require scan-pass status before image use; audit recent public-health training jobs for any residual public unsigned pulls.