easyMultiple Choice
CCSP Practice Question: Which practice helps prevent hardcoded cloud…
Which practice helps prevent hardcoded cloud credentials from being committed to source code repositories?
⚠ Common exam trap
The trap is treating .gitignore or environment variables as sufficient controls — candidates assume 'not in the repo' equals 'not hardcoded,' but the exam wants the control that structurally removes secrets from the codebase entirely.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Implementing secrets management with a vault service
A secrets management vault (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) stores credentials outside the codebase and injects them at runtime, so no secret ever exists in the repository. This directly prevents hardcoded credentials from being committed because developers never need to embed them in source files. Vault services also provide rotation, auditing, and access control, which are not achievable with file-based approaches.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Implementing secrets management with a vault service
Why this is correct
A vault service stores credentials outside the repository and injects them at runtime, so no secret ever enters commit history. This directly satisfies the stem's constraint by removing hardcoded values from source code, and rotation invalidates any credential previously exposed.
- ✗
Using environment variables for all configuration
Why it's wrong here
Environment variables hold configuration at runtime but can still be hardcoded in scripts, Dockerfiles or CI definitions and committed. It tempts because twelve-factor configuration is a real improvement over inline literals, yet it is correct only when values are injected from a secret manager, not written into tracked files.
- ✗
Storing credentials in a configuration file with restricted permissions
Why it's wrong here
A restricted-permission configuration file still stores the credential in the repository, so cloning exposes it; it only narrows who reads it on a host. Configuration files suit environment-specific settings injected at deploy time. Preventing commits requires secret scanning or a managed identity/vault reference, not file permissions.
- ✗
Using a .gitignore file to exclude credential files
Why it's wrong here
A .gitignore entry only stops untracked files being staged; a credential already tracked, or added with git add -f, is still committed and pushed. It tempts because ignoring local config files is a genuine hygiene measure, but it is correct only for files that never enter version control.
Go deeper
Related to this question
About these practice questions
One of 934 original CCSP practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISC2 exam blueprint
This CCSP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CCSP exam.