School-district MLOps jobs print cloud training-account API keys into shared CI logs. What control should be applied immediately?
Select an answer to reveal the explanation.
Short Explanation
Keys in shared logs are sticky notes on the glass door of the district data center. Keep secrets in a vault and scrub logs. Longer retention, stuffing keys into metadata, and mass-emailing logs make the leak worse.
Full Explanation
School-district MLOps jobs that print cloud training-account API keys into shared CI logs create immediate credential exposure. The control to apply immediately is secret hygiene that keeps credentials out of pipeline logs and retrieves them from a managed vault with rotation. Keys in shared logs are readable by anyone with log access, by backup systems, and often by third-party observability tools. Once logged, keys may persist far longer than the job that printed them, enabling unauthorized access to training accounts, datasets, and billing.
Increasing log retention so auditors can reread the keys later fails because it amplifies exposure rather than remediating it. Embedding the same keys in model metadata for convenience fails because it spreads secrets into artifacts that may be copied to registries and workstations. Emailing full job logs to a citywide distribution list fails because it multiplies recipients of any leaked secret.
Exam caveat: secret scanning and vault injection are distinct from “more logging for compliance.” Longer retention of secret-bearing logs is an anti-pattern on municipal exams.
Operational check: rotate and revoke any keys that appeared in CI logs; migrate to short-lived vault-issued credentials; enable secret scanners that fail the pipeline on key-like strings; redact historical log indices where feasible under district retention policy.