Exam objective 4.4 for the CompTIA A+ Core 2 (220-1202) exam asks you to apply documentation, change management, and IT lifecycle best practices in a given scenario. In short, this chapter teaches you how to keep an IT environment from descending into chaos when something breaks or needs upgrading. These three concepts form the backbone of every professional IT department, and the exam will test whether you know the correct process, not just the theory.
Jump to a section
A simple way to picture Documentation, Change Management, and Lifecycle
Because you never just start demolishing a wall without checking the blueprints first, a single unapproved change to an IT system can cascade into a total outage.
Imagine you own a house. You decide you want to move a load-bearing wall to make an open-plan kitchen. You do not just grab a sledgehammer and start swinging. First, you check the original building plans (documentation) to see where the electrical wiring and plumbing run. You submit a formal request to the city council for a permit (change management). The council reviews your plan, checks that the new beam is strong enough, and approves it. Only then do you hire a contractor. During the work, a pipe springs a leak. Because you have the plans, you know exactly which valve to shut off. The project finishes on time, and you update the house plans to show the new wall position.
Now imagine you skip the permit. You swing the sledgehammer, hit a gas pipe, and the whole street needs evacuating. IT works the same way. A server upgrade without a documented change plan is the digital equivalent of that gas leak. Change management is the permit process. Documentation is the updated house plans. The IT lifecycle is knowing the roof needs replacing every 20 years before it starts leaking on your server room.
Let us break down the three pillars of this objective: documentation, change management, and the IT lifecycle. These are not separate topics; they are three parts of one continuous workflow that keeps technology reliable and secure.
Documentation is the written record of an IT system. It includes network diagrams (a map of how computers, printers, and servers connect), password lists (stored securely), configuration settings (how a device is set up), and standard operating procedures (SOPs), which are step-by-step instructions for common tasks like resetting a user’s password or installing a printer. Without documentation, when the person who set up a server leaves the company, their knowledge leaves with them. That is called a single point of failure. Documentation turns tribal knowledge into institutional knowledge. The most common types of IT documentation are asset management (a list of every device the company owns, including serial numbers and warranty dates), change documentation (a log of every modification made to a system), and knowledge base articles (a searchable library of solutions to common problems).
Change management is the formal process for making changes to an IT environment. It exists to answer one question: who approved this? The goal is to minimise risk. A change management process typically includes these stages:
A request for change (RFC) is submitted, describing what the change is, why it is needed, and the expected outcome.
The change is reviewed by a change advisory board (CAB), a group of stakeholders (managers, security experts, and technical leads) who assess the risk.
The change is approved, rejected, or sent back for more information.
The change is implemented during a scheduled maintenance window (a time when downtime is acceptable).
After implementation, the change is documented and reviewed to confirm it worked correctly. This is called a post-implementation review (PIR).
The IT lifecycle is the idea that every piece of technology has a beginning, a middle, and an end. This is often broken into six stages: planning (identifying a need), acquisition (buying or leasing the equipment), deployment (installing and configuring it), operation (daily use and maintenance), maintenance (applying patches and firmware updates), and retirement (disposal or recycling). The lifecycle concept ensures that IT does not just keep buying new servers forever without decommissioning old ones. A common exam scenario involves end-of-life (EOL) software — software that the vendor no longer supports. Continuing to use EOL software is a security risk because no security patches are released. The lifecycle dictates that you must migrate to a supported version or a new product.
Why does this matter? In a real business, thousands of changes happen every year — password resets, software updates, new hardware installs. Without change management, a simple update could accidentally take down the email server for the whole company. Without documentation, nobody knows how to fix it. Without a lifecycle, you are running ancient, unpatched software that hackers love. The CompTIA A+ exam tests your ability to read a scenario about a company with no documentation and identify the correct first step: create a document. It tests your ability to spot a change that bypassed the approval process. And it tests your understanding of why you must retire old technology on a schedule.
Identify the need for change
This is the planning stage. A business requirement arises, such as a new security patch or a hardware upgrade. The IT technician does not act yet — they document the requirement.
Submit a Request for Change (RFC)
The technician writes an RFC detailing the change, the reason, the risk level, and a rollback plan (how to undo the change if it fails). This formal document starts the approval process.
Change Advisory Board (CAB) review
The CAB meets (or votes remotely) to assess the risk, impact, and cost. They either approve, reject, or request more information. High-risk changes may require a test in a sandbox environment first.
Implement the change
After approval, the technician implements the change during a scheduled maintenance window. They follow the tested steps from the RFC and document the actual outcome, including any issues encountered.
Conduct a Post-Implementation Review (PIR)
After a set period (often a few days or a week), the technician and CAB review whether the change achieved its goal without negative side effects. Lessons learned are documented to improve future changes.
Update documentation and retire old assets
The final step is to update all relevant documentation — network diagrams, asset lists, SOPs — to reflect the change. If the change replaced old hardware, that equipment enters the retirement phase of the IT lifecycle and is securely disposed of.
You work as a junior IT technician for a small company called GreenLeaf Logistics that has 50 employees. One Monday morning, the finance manager, Sarah, reports that her accounting software will not open. She gets an error message saying the application ‘has stopped working for security reasons’. She needs the software to process payroll by end of day. What do you do?
First, you check the documentation. You look up the company’s application database, which is a spreadsheet listing every installed application, who uses it, the version number, and the support contact. You see that the accounting software, FinBooks 2019, reached its end-of-life (EOL) date two months ago. The vendor stopped issuing security updates. This is not a one-off glitch — it is a lifecycle problem.
Next, you check the change log. There is no record of any change to FinBooks 2019. But when you talk to the network administrator, she admits she disabled the software’s internet access yesterday because security software flagged it as a risk. She made this change without submitting a request for change (RFC) because she was in a hurry. This is a violation of change management. Your next step is to escalate the issue. You open a ticket in the help desk system, documenting exactly what the network admin did. You inform the finance manager that a workaround is needed temporarily.
Now you must propose a proper plan. You submit an RFC to upgrade to FinBooks 2024, the supported version. The change advisory board (CAB) meets and approves the upgrade, scheduling it for the weekend so payroll is not interrupted. You download the new version and run it in a test environment (a sandbox) first to confirm it works with Sarah’s data. After the successful upgrade, you update the documentation — the application database now shows FinBooks 2024, and you write a knowledge base article about the new version. You also create a standard operating procedure (SOP) for any future changes to finance applications: all changes must go through the CAB and be recorded in the change log.
In this scenario, you used
Documentation: to identify the EOL software and find the vendor contact.
Change management: to reject the unauthorised change and submit a proper RFC.
IT lifecycle: to recognise that EOL software must be replaced, not patched.
This is how IT professionals prevent fires rather than just fighting them. The exam will give you similar scenarios and ask you to choose the correct procedure from a list of options.
CompTIA 220-1202 tests objective 4.4 with scenario-based multiple-choice questions. You will read a short paragraph about an IT problem, and you must select the best next step. They rarely ask for a definition. They ask: what should the technician do FIRST?
The exam loves the following concepts:
The types of documentation: network diagrams, SOPs, asset management lists, and knowledge base articles. A common trap is giving you a scenario where a technician needs to reset a user’s password. The correct answer might be ‘check the SOP for password resets’, not ‘call the user’ or ‘guess the answer’.
The change management process: specifically, the order of steps. They will test whether you know that a request for change (RFC) comes before implementation, and that a post-implementation review (PIR) comes after. A trap question might list ‘test the change in production first’ as an option. That is wrong — you test in a sandbox environment first.
IT lifecycle stages: planning, acquisition, deployment, operation, maintenance, and retirement. They often test end-of-life (EOL) and end-of-service-life (EOSL). EOL means the product is still usable but no longer sold. EOSL means the vendor no longer provides support. A common question: a server is at EOSL. What should the technician do? The correct answer is ‘replace it’, not ‘reinstall the operating system’.
Change advisory board (CAB): who belongs to it and what it does. They might ask: which group approves high-risk changes? The CAB.
Maintenance windows: understanding that critical changes happen outside business hours.
The difference between a standard change (low risk, pre-approved, e.g., resetting a password) and an emergency change (high risk, approved by a smaller group quickly, e.g., patching a zero-day vulnerability).
Traps to watch out for:
They give a scenario where the documentation is missing. Many students pick ‘just fix it’ as the answer. The correct answer is ‘create documentation first’.
They give a scenario where a change was made without approval. The impulse is to reverse the change immediately. The correct answer is to document the unauthorised change and escalate to management.
They list ‘schedule a maintenance window’ as the first step. It is not the first step — the first step is to submit an RFC.
Key definitions to memorise:
RFC: a formal request to make a change.
CAB: the committee that approves or rejects changes.
EOL: the vendor stops selling the product.
EOSL: the vendor stops supporting the product.
PIR: the review after a change to confirm success or identify lessons learned.
Maintenance window: a scheduled period when changes are allowed and downtime is planned.
Documentation turns individual knowledge (tribal knowledge) into permanent institutional knowledge that survives staff turnover.
A request for change (RFC) must be submitted, reviewed by the CAB, and approved before any change is implemented.
End-of-life (EOL) software is no longer sold; end-of-service-life (EOSL) software is no longer supported — both require a replacement plan.
The IT lifecycle includes retirement: old equipment must be securely wiped and disposed of to prevent data breaches.
An emergency change bypasses the normal CAB process but still requires rapid approval from a designated emergency change manager.
A post-implementation review (PIR) captures lessons learned after every change to improve future processes.
Standard changes, like a password reset, are pre-approved and do not need a full CAB meeting.
A network diagram must be kept up to date because outdated documentation is worse than no documentation — it actively misleads troubleshooting efforts.
These come up on the exam all the time. Here's how to tell them apart.
Standard Change
Low risk and pre-approved by the CAB in advance.
Does not require a full CAB meeting to implement.
Examples include password resets and routine patch updates.
Emergency Change
High risk and requires immediate action.
Approved by a designated emergency change manager, not the full CAB.
Examples include patching a zero-day vulnerability or restoring a failed server.
End-of-Life (EOL)
Product is no longer sold by the vendor.
May still receive limited support or bug fixes for a period.
Users can still operate the product, but no new features are added.
End-of-Service-Life (EOSL)
Product is no longer supported by the vendor.
No security patches, updates, or technical support are available.
Continuing to use the product poses a security risk and may violate compliance.
RFC (Request for Change)
Proactive — submitted before a change is made.
Includes a risk assessment and rollback plan.
Requires CAB approval for high-risk changes.
Incident Ticket
Reactive — created after a problem is reported.
Describes a fault or outage that needs resolution.
May lead to a change, but the ticket itself is not a change request.
Asset Management Documentation
Lists every device, its serial number, warranty, and location.
Tracks the financial and lifecycle status of hardware and software.
Used for procurement, audits, and insurance.
Network Diagram
Shows the logical or physical connections between devices.
Helps technicians understand traffic flow and dependencies.
Used for troubleshooting connectivity issues and planning upgrades.
Mistake
Documentation is only needed for large companies with hundreds of devices.
Correct
Documentation is essential for any organisation with more than one device. Even a home office benefits from a list of passwords and a network diagram.
Beginners think documentation is optional overhead. They do not yet understand that undocumented environments cause massive time loss when troubleshooting.
Mistake
Change management is just bureaucracy that slows down IT work.
Correct
Change management prevents outages and security incidents. A properly managed change process reduces the risk of downtime and ensures that everyone knows what changed and why.
People who have never experienced a catastrophic outage caused by an unapproved change see change management as pointless paperwork. Experience teaches the opposite.
Mistake
The IT lifecycle is just about buying new hardware every few years.
Correct
The lifecycle includes planning, acquisition, deployment, operation, maintenance, and retirement. It covers software and services, not just hardware, and includes decommissioning and secure data disposal.
The word ‘lifecycle’ sounds like procurement to beginners. They overlook the retirement phase, which is critical for security and compliance.
Mistake
Once software is installed and working, you never need to touch it in its lifecycle until it breaks.
Correct
Software requires ongoing maintenance, including security patches and feature updates. The maintenance phase of the lifecycle demands regular attention, not neglect.
Non-IT people are used to buying a toaster and using it until it stops working. IT systems are not like toasters — they require constant care.
Mistake
A change advisory board (CAB) is only for huge, expensive changes like replacing a server.
Correct
A CAB should review any change that carries a risk, including minor software updates that could affect multiple users. The risk, not the cost, determines whether CAB approval is needed.
Beginners assume CAB reviews are only for major projects. But an unauthorised minor patch can break a critical application just as easily.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
End-of-life (EOL) means the vendor no longer sells the product but may still provide limited support. End-of-service-life (EOSL) means the vendor no longer offers any support, including security patches.
Yes, but standard changes (like password resets) are pre-approved and documented in the ticket system. You do not need a full CAB meeting for them, but you still log the action for auditing purposes.
If an unauthorised change causes an outage, it is classified as an unapproved change and could lead to disciplinary action. It also means there is no rollback plan, making recovery harder.
The CAB typically includes IT managers, security specialists, system administrators, and representatives from affected business units, such as finance or HR.
Documentation should be updated immediately after any change to the network. A common best practice is to audit network documentation quarterly to catch any undocumented changes.
A maintenance window is a scheduled period, usually outside normal business hours, when planned changes can be made with an acceptable risk of downtime. It is approved by management.
You've finished Documentation, Change Management, and Lifecycle. Continue through the 220-1202 study guide to build a complete picture of the exam.
Done with this chapter?