How should you manage sensitive data in a committed pipeline file?

WHAT THIS TESTS: This question tests whether you understand that a Git repository is an untrusted boundary for sensitive credentials and whether you know the modern hierarchy for secrets management in CI/CD. Interviewers want to see that you distinguish between version-controlled pipeline definitions and runtime secret injection, and that you can compare the security guarantees of external secrets managers against native CI/CD variables.

A GOOD ANSWER COVERS: A strong response follows four steps in order. First, state unequivocally that API keys, passwords, and tokens must never be hardcoded into a pipeline YAML file that is committed to Git. Second, explain that the preferred solution is to store sensitive data in an external secrets manager such as HashiCorp Vault, Azure Key Vault, or Google Cloud Secret Manager, and then retrieve those secrets at runtime through native GitLab integrations. Third, acknowledge that CI/CD variables are a less secure fallback because their values live in project or group settings, can be overridden by subsequent pipeline runs or misconfigurations, and may be exposed in logs; if a secrets manager is unavailable, you should still mask, hide, and protect those variables. Fourth, mention that non-sensitive parameters should be passed via typed CI/CD inputs rather than variables, because inputs provide type-safe validation, explicit contracts, and scoped availability that reduce the attack surface.

COMMON WRONG ANSWERS: The biggest red flag is suggesting that encrypting secrets and committing them to the repository is an acceptable primary strategy, because it still places ciphertext inside version control where it can be exfiltrated and attacked offline. Another red flag is treating masked or protected CI/CD variables as equivalent to a dedicated secrets manager, which ignores the override and visibility risks inherent in project settings. A third red flag is recommending the use of plain variables for parameter passing without mentioning the newer typed inputs.

LIKELY FOLLOW-UPS: An interviewer might ask how you would rotate a secret that is currently stored in a CI/CD variable, or how you would audit which pipeline jobs accessed a given credential. They might also ask you to compare the threat model of a secrets manager that uses dynamic short-lived tokens versus static variables, or how you would prevent a malicious merge request from exfiltrating secrets via a pipeline job.

ONE CONCRETE EXAMPLE: Suppose a pipeline needs a production database password. Instead of writing DB_PASSWORD: prod-secret in the committed gitlab-ci.yml, you configure a Vault integration and reference the secret in the job script. The pipeline authenticates to Vault at runtime, fetches the current password, and injects it as an ephemeral environment variable that is never written to disk in the repository. If Vault is unavailable, you store the password as a protected and masked CI/CD variable at the project level, restrict it to protected branches, and pass any non-sensitive configuration like environment names through typed CI/CD inputs rather than variables.