ISC2 CC Security Operations Practice Question
A security engineer is designing a patch management process. Which TWO steps are part of the standard patch lifecycle? (Select TWO)
⚠ Common exam trap
CC often tests the patch lifecycle steps, and candidates may incorrectly include vulnerability disclosure or immediate deployment as steps; the trap is confusing triggers or emergency actions with standard lifecycle phases.
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
✓
Testing the patch in a staging environment
Option C (Testing the patch in a staging environment) is correct because the standard patch lifecycle includes a validation phase where patches are applied to a representative non-production environment to verify functionality, compatibility, and absence of regressions before wide deployment. Option D (Deploying the patch to production systems after approval) is correct because the lifecycle's deployment phase requires formal change approval and controlled rollout to production, often staged in rings or waves to limit blast radius. Option A is not part of the patch lifecycle itself; vulnerability disclosure is an input from the vulnerability management/research process that may trigger patching but is not a lifecycle step. Option B is incorrect because decommissioning a system is a risk remediation alternative, not a patch lifecycle step. Option E is incorrect because immediately deploying patches to all systems bypasses testing and approval, violating change management and increasing the risk of outages or failed patches.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Vulnerability disclosure by researcher
Why it's wrong here
Researcher disclosure precedes vendor awareness and occurs outside the patch lifecycle, which begins with identification and ends with deployment and verification. It is tempting because disclosure often triggers patching, but the lifecycle itself covers detection, prioritisation, testing, deployment and validation of vendor-supplied fixes.
- ✗
Decommissioning the vulnerable system
Why it's wrong here
Decommissioning removes a system from service rather than remediating it, so it sits outside the patch lifecycle of identify, assess, test, deploy and verify. It is tempting as an alternative to patching unsupported systems, but that is risk treatment, not a patch management step.
- ✓
Testing the patch in a staging environment
Why this is correct
Staging validation installs the patch in a non-production environment to confirm it remediates the vulnerability without breaking applications. This is a recognised patch lifecycle step, satisfying the stem's requirement for a standard lifecycle activity performed before production deployment.
- ✓
Deploying the patch to production systems after approval
Why this is correct
Deployment pushes the approved patch to production systems, the stage where remediation actually reaches live assets. This is a recognised patch lifecycle step, satisfying the stem's requirement for a standard lifecycle activity following approval and testing.
- ✗
Immediately deploying patches to all systems
Why it's wrong here
Skipping testing and staged rollout, immediate deployment to all systems is not a lifecycle step but a risky shortcut that can propagate faulty patches enterprise-wide. It is tempting because rapid remediation reduces exposure windows, and it would suit emergency out-of-band fixes for actively exploited zero-days after validation.
Quick reference
AAA Protocol Comparison
| Protocol | Port(s) | Encryption | Transport | Primary Use |
|---|---|---|---|---|
| RADIUS | 1812 / 1813 | Password only | UDP | Network access control |
| TACACS+ | 49 | Full packet | TCP | Device administration |
| Diameter | 3868 | Full session | TCP / SCTP | Carrier / mobile networks |
| 802.1X | — | EAP-based | Layer 2 | Port-based access control |
TACACS+ encrypts the entire packet; RADIUS only encrypts the password field — a key exam distinction.
Go deeper
Related to this question
Learn chapter
Incident Response and Management
Key term
Vulnerability
A vulnerability is a weakness in a system, network, or software that could be exploited by a threat to cause harm or unauthorized access.
Key term
Patch management
Patch management is the process of identifying, acquiring, testing, and deploying software updates (patches) to fix vulnerabilities, bugs, or improve performance in IT systems.
About these practice questions
Courseiva writes every CC question from scratch — 989 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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 CC 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 CC exam.