CCSP Cloud Application Security Practice Question
A DevOps team wants to prevent insecure code from being deployed to production. Which gate should be implemented in the CI/CD pipeline?
⚠ Common exam trap
ISC2 often tests the misconception that any security activity after deployment (like penetration testing or manual review) can serve as a preventive gate, when in fact only automated checks with failure conditions integrated into the pipeline can block insecure code before it reaches production.
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
✓
Automated security scanning with failure conditions
Automated security scanning with failure conditions (option A) is the correct gate because it enforces security checks directly within the CI/CD pipeline, preventing any code that fails static application security testing (SAST) or software composition analysis (SCA) from progressing to production. This shift-left approach ensures that vulnerabilities are caught before deployment, aligning with DevSecOps principles and reducing risk.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Automated security scanning with failure conditions
Why this is correct
Automated security scanning with failure conditions blocks the pipeline when vulnerabilities are detected, directly preventing insecure code from reaching production. This satisfies the stem's deployment-prevention constraint by enforcing a hard gate rather than advisory reporting, ensuring builds fail before artefacts are promoted.
- ✗
Run penetration testing after release
Why it's wrong here
Penetration testing runs after release, so insecure code has already reached production; it cannot act as a gate. It is tempting because pen testing finds real vulnerabilities, and would be correct as a periodic assurance activity on deployed systems rather than a pre-deployment control.
- ✗
Dependency scanning only on weekly basis
Why it's wrong here
Weekly dependency scanning leaves an eight-day window in which a vulnerable build can reach production, and it inspects only third-party libraries, not first-party code. It is tempting because scheduled scanning suits periodic compliance reporting on stable artefacts, but a deployment gate must run per-commit and block the pipeline.
- ✗
Manual code review after deployment
Why it's wrong here
Reviewing after deployment cannot prevent insecure code reaching production, since the release has already occurred; the gate must block the pipeline before release. It is tempting because manual review genuinely catches logic and design flaws that automated tooling misses, and it belongs earlier, as a pre-merge approval step.
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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.