Documentation & Change Management

Why This Objective Carries Weight

Domain 4, Operational Procedures, is 21% of the CompTIA A+ Core 2 (220-1202) exam, behind Operating Systems and Security (28% each) and Software Troubleshooting (23%). The current V15 series (Core 1 220-1201 and Core 2 220-1202) launched March 25, 2025; each exam delivers a maximum of 90 questions in 90 minutes, and Core 2 passes at 700 on a 900-point scale. Objectives 4.1 (documentation, ticketing and asset management) and 4.2 (change management) are process-based: learn the purpose of each document and step, not a product name.

Documentation Types to Know

V15 objective 4.1 names incident reports, standard operating procedures, onboarding and off-boarding checklists, service-level agreements and knowledge base articles; the acceptable use policy and regulatory compliance requirements sit under objective 4.6. Learn the document and what it answers.

Trap: A topology diagram shows the network; an asset inventory lists the devices. Each scenario points to one best artifact.

The Change-Management Flow

Objective 4.2 lists the change-management items (documented business processes, request forms, purpose and scope of the change, risk analysis, change board approvals, end-user acceptance and more) as bullets, not as a numbered order. NIST SP 800-128's configuration change control steps give a defensible order: request, analyze, test, approve, implement, verify, close.

1. Submit a change request (request form) describing the purpose and scope of the change, the change type, the planned date and time, and the affected systems/impact.
2. Risk analysis — assign a risk level (low/medium/high).
3. Test in a sandbox and prepare the rollback plan (and backup plan).
4. Change board approval — the board reviews the request, the risk analysis and the test results, then approves, denies, or defers.
5. Implement the approved change in a scheduled maintenance window, with affected users notified.
6. Verify the change and get end-user acceptance — the people who use the system confirm it works for them.
7. Document the result and close the request.

Backout (Rollback) Plan

Every approved change must include a backout plan — the predefined steps to return the system to its prior working state if the change fails. Changes are validated in a sandbox/test environment first, never directly in production.

Ticketing Systems and Asset Management

A ticketing system records the problem description, progress notes, and problem resolution; closed tickets become knowledge base entries. Asset management tracks hardware/software via an inventory list, asset tags/IDs, assigned users, warranty and license status, and a procurement life cycle (procure → deploy → maintain → retire/decommission with secure data destruction).

• Database/asset tags — barcodes or RFID tied to a central record.
• Warranty tracking — avoids paying for repairs still under coverage.
• Licensing — keeps the org compliant and audit-ready.

Worked example: A help-desk tech resolves a recurring printer spooler crash. Correct A+ behavior: update the ticket with detailed progress notes and the resolution, then publish a KB article so the next technician resolves it in minutes — turning one fix into reusable documentation.

Scenario Practice for Objectives 4.1 and 4.2

Objectives 4.1 and 4.2 both begin "Given a scenario", so practice with short workplace scenarios that ask which document, step, or artifact fits. Read each stem for the outcome the scenario wants. If the scenario wants consistency for a repeated task, the answer is a standard operating procedure. If it wants a way to look up a known fix quickly, the answer is a knowledge base article. If it asks what to capture after a security event, the answer is an incident report. (A network topology diagram, which the V15 A+ objectives do not list by name, is what shows how a network is wired.)

Practice translating each scenario into the one artifact that fits it.

For change-management scenarios, check three things: the existence of an approval body before work begins, the requirement to document scope and risk, and the presence of a backout plan before production. A common distractor is an answer that implements the change immediately because it is urgent. Even an emergency change still requires a documented request and a review after the fact, so "just make the change" is never the best answer.

Another frequent distractor skips the maintenance window and applies the change during business hours; the correct response schedules the work for a low-impact window and notifies affected users first.

Asset Management in Practice

For asset management, expect questions that test the difference between simply owning hardware and tracking it through its full life cycle. A device that is purchased but never tagged or entered into the inventory database is effectively invisible to the organization, which creates security, warranty, and licensing gaps. The procurement life cycle moves an asset from acquisition, through deployment to an assigned user, into a maintenance phase, and finally to retirement and decommissioning, where data destruction and certified disposal close the loop.

CompTIA expects you to connect each phase to the record-keeping that supports it: a purchase order at acquisition, an asset tag and assigned user at deployment, warranty and license data during maintenance, and a documented wipe-and-recycle action at retirement. Knowing that the asset database, not a spreadsheet on one technician's laptop, is the authoritative source of truth is the recurring theme.