CompTIA N10-009 Life-Cycle Management & Decommissioning Guide

Lifecycle-management questions are risk-and-support questions. CompTIA is usually testing whether you understand that a device is not safe or supportable forever just because it still powers on. Planning replacement, support windows, and clean retirement is part of network operations, not optional admin work.

EOS / EOL: End of support or end of life, the point where a vendor stops supporting or selling a product.

Asset inventory: A maintained record of devices, software, versions, ownership, and lifecycle state.

What CompTIA is really testing

The strongest answers usually separate:

• older but still supported equipment from unsupported equipment
• replacement planning from emergency failure response
• ordinary patching from full refresh or decommission work
• physical removal from access, config, and data cleanup

A device lifecycle is an operations loop

    flowchart LR
	  A["Deploy and document"] --> B["Patch and support"]
	  B --> C["Track vendor lifecycle state"]
	  C --> D["Refresh or replace"]
	  D --> E["Decommission and clean up"]

What to notice:

• lifecycle work starts at deployment, not at retirement
• vendor support state affects risk and planning
• decommissioning has technical cleanup steps, not just physical removal

Small lifecycle record example

1asset:
2  hostname: dist-sw-02
3  os_version: 17.3
4  support_state: nearing-eos
5  replacement_target: q4-refresh
6  decommission_checks:
7    - backup archived
8    - credentials removed
9    - inventory updated

What to notice:

• lifecycle state should be visible before an emergency
• replacement planning is easier when support status is tracked centrally
• decommissioning includes records and access cleanup

Why unsupported equipment matters so much

CompTIA often rewards the answer that sees the real risk:

• unsupported gear may not get security patches
• hardware failure may be harder to remediate
• old platforms can block standardization and recovery planning

That does not mean every older device must be ripped out immediately, but it does mean lifecycle risk has to be managed explicitly.

Common traps

• keeping unsupported gear just because it still powers on
• forgetting backup and rollback implications during replacement
• failing to remove configs, credentials, or inventory records during retirement
• treating refresh work as a problem for “later” with no tracking

What strong answers usually do

• track support state before it becomes a crisis
• connect replacement timing to risk, patchability, and supportability
• include data, access, and documentation cleanup in decommissioning
• treat lifecycle planning as normal operations discipline

Decision order that usually wins

Treat lifecycle questions as operational-risk questions. First, decide whether the issue is aging hardware, loss of vendor support, or an actual retirement event. Second, choose the control that matches the lifecycle point: refresh planning for aging gear, patch/support validation for near-end-of-support gear, and access cleanup plus inventory updates for decommissioned gear. The weak answer is usually “just unplug it” because Network+ expects records, backups, and permissions to be handled as part of the lifecycle.

Quiz

Continue with 3.3 Change Management to keep the domain flow intact.