# Root cause analysis

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/root-cause-analysis

## Quick definition

Root cause analysis (RCA) is a way to figure out the real reason something went wrong. Instead of just fixing the immediate issue, you dig deeper to find what actually caused it so the problem doesn't come back. IT professionals use RCA to solve network outages, system crashes, and security incidents permanently.

## Simple meaning

Think of root cause analysis like a doctor diagnosing a patient. If someone comes in with a fever, the doctor doesn't just give them medicine to lower the temperature. The doctor runs tests to find out if the fever is caused by a bacterial infection, a virus, or something else. Treating the symptom (the fever) might make the person feel better for a little while, but if the infection isn't treated, the fever will return. Root cause analysis works the same way in IT. When a server crashes or a network goes down, the first instinct is often to restart the system or apply a quick patch. That fixes the symptom for now. But if you don't find out why the server crashed in the first place it will crash again. Root cause analysis means asking a series of "why" questions until you reach the root of the problem. For example, the server crashed because it ran out of memory. Why? Because a memory leak in an application used more and more memory over time. Why was that application updated? Because a developer pushed a change without testing it fully. The root cause is not the memory leak itself but the lack of proper testing before deployment. By finding the real root cause you can implement a lasting fix, such as adding a testing policy, and prevent future crashes. This saves time, money, and frustration in the long run.

## Technical definition

Root cause analysis (RCA) is a structured troubleshooting methodology used in incident response to identify the fundamental origin of an event or failure. In IT and network environments, RCA is applied after an incident has been resolved to prevent recurrence. The process typically follows the ITIL (Information Technology Infrastructure Library) framework for problem management, which distinguishes between incidents (unplanned interruptions) and problems (the underlying cause of one or more incidents). RCA employs several formal techniques. The Five Whys method involves repeatedly asking "why" until the underlying cause is uncovered. For example, a user cannot log in (why? because the authentication server is unreachable; why? because a firewall rule changed; why? because a network administrator made an unapproved modification). The Kepner-Tregoe method uses a systematic approach that includes defining the problem, describing it in terms of identity, location, timing, and magnitude, identifying possible causes, and testing the most likely cause. Fishbone (Ishikawa) diagrams categorize potential causes into groups such as people, processes, technology, and environment, helping teams visualize relationships. In the context of incident response, RCA is documented in a post-incident report that includes a timeline of events, evidence collected, the identified root cause, and remediation steps. Industry standards such as NIST SP 800-61 (Computer Security Incident Handling Guide) emphasize the importance of lessons learned and RCA to improve security posture. In IT certification exams, particularly CompTIA A+, Network+, Security+, Cisco CCNA, and ISC2 SSCP, RCA is often tested as part of the troubleshooting methodology. Candidates must understand that the goal of RCA is not to assign blame but to improve systems. Effective RCA requires accurate data collection, logs from servers and network devices, error messages, and stakeholder interviews. It also relies on understanding the difference between a contributing factor and a root cause. A contributing factor is an element that helped the incident occur but is not the fundamental reason, while the root cause is the deepest cause that, if corrected, prevents recurrence. RCA is documented in a formal problem record within an IT service management (ITSM) system such as ServiceNow or Jira Service Management. The output of RCA drives change management requests to implement permanent fixes, such as code patches, configuration updates, or process improvements.

## Real-life example

Imagine you are cooking a big meal for your family. You put a pot of water on the stove to boil pasta, but after ten minutes the water is still cold. You check the stove burner and see that it is glowing red, so you assume the burner is working. You try a different pot, but the water still won't boil. You then check the circuit breaker and find that it has tripped. You reset the breaker, and the burner works again. You have fixed the symptom. But the next day, the same thing happens. Now you start a root cause analysis. You ask yourself why the breaker keeps tripping. You notice that the toaster, microwave, and stove are all on the same circuit. When you use them all at once, the circuit overloads. The root cause is that your kitchen has insufficient electrical capacity for all the appliances you use simultaneously. Instead of just resetting the breaker every time you cook, you rearrange your cooking schedule so you don't run the toaster and microwave at the same time as the stove. Or you call an electrician to add a dedicated circuit. In IT, this is exactly what happens with network or server problems. A server might crash repeatedly because it is running out of disk space. The quick fix is to delete a few old log files. But the root cause might be that the log rotation policy was misconfigured, so logs never get archived or deleted automatically. Until you fix the log rotation configuration, you will keep running out of disk space and the server will keep crashing. The real-life cooking analogy makes it clear: treating the symptom is temporary, but finding the root cause prevents the problem from recurring.

## Why it matters

Root cause analysis matters in IT because it directly reduces downtime, operational costs, and security risks. When an IT team only fixes symptoms, problems return repeatedly. Each recurrence wastes technician time, frustrates users, and can lead to lost revenue if critical systems are unavailable. For example, if a database server goes down every two weeks because of a memory leak, and the team simply restarts it each time, the organization loses productivity and risks data corruption. RCA breaks this cycle. By investing a few hours to analyze logs, examine code changes, and interview staff, the team can identify the software bug or configuration error that causes the leak and deploy a permanent patch. Over the course of a year, that one RCA saves dozens of hours of emergency work and prevents multiple outages. RCA also is important for security incident response. When a data breach occurs, finding how the attacker gained access is critical. If the team simply closes the backdoor without understanding that the root cause was weak password policies or unpatched software, the attacker or a different attacker will use a similar method again. Proper RCA, using the Five Whys or a formal incident analysis framework, reveals systemic weaknesses. The organization can then strengthen its overall security posture by implementing multi-factor authentication, regular patching, or employee training. RCA supports compliance with regulations such as HIPAA, PCI DSS, and GDPR, which require organizations to investigate and document security incidents. In terms of career impact, IT professionals who are skilled at RCA are more valuable to employers. They solve problems permanently, not temporarily. Certification exams such as CompTIA A+, Network+, Security+, and Cisco CCNA explicitly test the RCA process within troubleshooting methodology. Understanding RCA helps candidates answer scenario-based questions where they must select the next step after an initial fix or identify what should be done to prevent the problem from recurring.

RCA is not just a technical skill. It is a mindset of continuous improvement. It shifts IT operations from reactive firefighting to proactive problem management. For organizations, it means lower costs and higher reliability. For IT professionals, it is a key competency that demonstrates advanced troubleshooting and critical thinking.

## Why it matters in exams

Root cause analysis is a core topic in several major IT certification exams because it represents best practice in incident response and problem management. In CompTIA A+ (220-1101 and 220-1102), RCA appears within troubleshooting methodology, which is one of the six core domains. Candidates must know the steps of the CompTIA troubleshooting process: identify the problem, establish a theory of probable cause, test the theory, establish a plan of action, implement the solution, verify full system functionality, and document findings. The final documentation step includes the root cause analysis. Exam questions often describe a situation where a technician applied a temporary fix and the problem returned, and the correct answer is to perform root cause analysis to find the underlying issue. In CompTIA Network+ (N10-008), RCA is tested in the network troubleshooting domain, especially for scenarios involving intermittent connectivity, slow performance, or device failure. Questions may ask candidates to interpret traceroute or ping output and then determine what the next step should be, including gathering logs and performing RCA. CompTIA Security+ (SY0-601) covers RCA in the context of incident response. The exam objectives include "lessons learned" and "post-incident report," which explicitly require root cause analysis. Candidates may be asked to order the steps of incident response or to identify what information should be included in the final report. In Cisco CCNA (200-301), troubleshooting is a major part of the exam, especially for routing and switching, wireless, and security issues. RCA is embedded in the structured troubleshooting approach Cisco teaches, which includes gathering information, analyzing data, eliminating possibilities, and isolating the root cause. Cisco exam questions often present a scenario where the candidate must determine the root cause of a network problem based on show commands, debug output, or configuration files. In ISC2 SSCP (Systems Security Certified Practitioner), RCA is part of domain 7 (Incident Response and Recovery). Candidates must understand forensic analysis and root cause determination as part of the incident handling lifecycle. ISACA CISA (Certified Information Systems Auditor) also emphasizes RCA for audit findings and corrective action plans. For all these exams, RCA is tested in multiple ways: multiple-choice questions asking for the definition, ordering steps of the process, scenario-based questions where candidates select the correct root cause from a list, and questions about tools used in RCA such as log analysis, crash dumps, and performance monitoring. The common thread is that exam writers want to ensure that candidates understand the difference between a workaround and a permanent fix. A typical exam trap question might describe a technician who replaced a hard drive that had bad sectors, only to have the new drive fail in the same way. The correct answer is that the root cause was an environmental issue, such as overheating or power supply fluctuations, not the drive itself. Candidates who understand RCA will recognize that replacing the component without investigating why it failed is insufficient.

## How it appears in exam questions

Root cause analysis appears in IT certification exam questions in several distinct patterns. The most common is the scenario-based multiple-choice question where a problem is described, a technician performs a fix, but the problem recurs. The question then asks what the technician should do next. The correct answer is usually to perform root cause analysis to identify the underlying cause. For example, a question might describe a server that crashes every few days, and the technician restarts it each time. The exam asks: 'What is the next step the technician should take?' The correct answer is to examine system logs to find the root cause. A variation of this question gives multiple possible root causes and asks you to select the most likely one based on evidence. To answer correctly, you must eliminate causes that do not match the symptoms. Another pattern is the ordering question, where the exam asks you to place the steps of incident response or troubleshooting in the correct order. In CompTIA Security+ and Network+, you may need to sequence steps such as 'identify the problem,' 'establish a theory of probable cause,' 'test the theory,' 'implement a solution,' 'verify functionality,' and 'perform root cause analysis in the final documentation phase.' Some exams, particularly Cisco CCNA, include simulation questions where you are given a network topology, a set of symptoms (e.g., users in one VLAN cannot access a server), and outputs from show commands or ping tests. You must analyze the outputs to identify the root cause, such as a misconfiguration of a VLAN interface or a missing static route. Then you must select the corrective configuration command. In those simulations, understanding RCA helps you systematically eliminate possible causes. Another question pattern involves interpreting data from logs or monitoring tools. For example, a question might show a server's CPU usage graph, a memory plot, and an event log entry. The event log shows a system crash. The question asks: 'Based on the data, what is the root cause of the crash?' The correct answer links the high memory usage just before the crash to an application memory leak. In the ISC2 SSCP exam, RCA questions often appear in the context of the incident response process. A scenario might describe a data breach, the containment steps taken, and then ask what must happen before the incident can be closed. The correct answer is to perform root cause analysis and create a lessons-learned report. Finally, some questions test the difference between a root cause and a contributing factor. The exam might list several issues found during an investigation and ask which one is the root cause. For instance, a server failed because a power supply burned out (contributing factor), but the real root cause was that the server's temperature sensor failed, so it did not warn the administrator that the fan was broken. To excel in these questions, candidates must practice systematic troubleshooting and understand that RCA is about prevention, not just repair.

## Example scenario

A medium-sized company runs a web server that hosts its e-commerce site. On Monday morning, customers start reporting that the website is very slow and sometimes times out. The IT help desk receives several calls. The junior technician checks the server and sees that the CPU usage is at 95%. He restarts the web server service, and the CPU drops to 20%. He tells the users the problem is fixed. On Tuesday, the same thing happens. CPU usage spikes again, the website slows, and the technician restarts the service. On Wednesday, it happens again. This time, the senior system administrator takes over and decides to perform a root cause analysis. She first collects performance data from the server over the past week. She notices that the CPU spike happens at exactly 10:00 AM each day. She checks the scheduled tasks on the server and finds that a database backup job runs at 10:00 AM. The backup job uses a lot of CPU and disk resources. She then checks the backup logs and sees that the backup job is failing partway through each day, leaving processes running that consume memory and CPU. Why is the backup failing? She looks at the backup configuration and sees that the backup destination is a network drive that is almost full. The backup writes data until the drive is 100% full, then it fails but does not clean up its temporary files. The root cause is that the destination drive runs out of space, causing the backup to fail and leave orphaned processes that accumulate over time. The senior admin frees up space on the destination drive, adjusts the backup script to clean up temporary files on failure, and adds a monitoring alert for disk space on the backup destination. After these changes, the CPU never spikes again, and the website stays fast. This scenario illustrates how RCA goes beyond restarting services to find the true underlying issue: a full backup drive and an incomplete cleanup routine.

## Common mistakes

- **Mistake:** Treating a symptom as the root cause
  - Why it is wrong: If you only fix the symptom, the underlying cause remains and the problem will recur. For example, deleting a corrupted file only addresses the effect, not the reason the file became corrupted.
  - Fix: Always ask 'why' multiple times until you reach a cause that, when fixed, prevents the problem from happening again.
- **Mistake:** Stopping at the first obvious cause
  - Why it is wrong: The first cause you find is often a contributing factor, not the root cause. For example, if a network switch fails, replacing it might seem enough, but the root cause could be an overheating server room.
  - Fix: Use the Five Whys technique to dig deeper beyond the immediate failure.
- **Mistake:** Blaming human error without investigating systemic issues
  - Why it is wrong: Saying 'the administrator made a mistake' is rarely the root cause. The real cause may be lack of training, poor documentation, or a change management process that did not require review.
  - Fix: Focus on the process, not the person. Ask: 'What in the system allowed this error to happen?'
- **Mistake:** Failing to document the RCA process
  - Why it is wrong: Without documentation, the knowledge gained is lost. If the same problem happens six months later, the team will have to perform RCA again from scratch.
  - Fix: Always write a post-incident report that includes the root cause, evidence, and corrective actions. Store it in your knowledge base.
- **Mistake:** Jumping to conclusions without enough data
  - Why it is wrong: Guessing the root cause without examining logs, metrics, or evidence often leads to incorrect fixes that waste time and may cause additional issues.
  - Fix: Gather data from multiple sources (logs, monitoring tools, user reports) before forming a hypothesis. Test your hypothesis before implementing a permanent fix.

## Exam trap

{"trap":"The exam describes a technician who finds a corrupted file and replaces it, solving the immediate issue. The question asks: 'What should the technician do next?' Many candidates select 'nothing, the problem is solved' because they see the symptom fixed.","why_learners_choose_it":"Learners focus on the immediate result (the error stopped) without understanding the need to prevent recurrence. They think the troubleshooting process is complete once the visible symptom is gone.","how_to_avoid_it":"Remember that the CompTIA and other exam troubleshooting methodologies require documentation and root cause analysis as the final step. Even if the immediate fix works, you must identify why the file became corrupted in the first place to prevent it from happening again."}

## Commonly confused with

- **Root cause analysis vs Troubleshooting:** Troubleshooting is the overall process of identifying and resolving a problem. Root cause analysis is a specific part of that process that happens after the problem is resolved, focusing on prevention. Troubleshooting includes immediate fixes; RCA seeks the deeper cause. (Example: If your internet goes out, troubleshooting might restart the router. RCA would investigate why the router failed (e.g., power surge) and install a surge protector.)
- **Root cause analysis vs Diagnostic:** Diagnostic is the process of identifying what is wrong currently. RCA goes further to find out why it went wrong in the first place. Diagnostic is like a doctor running a blood test. RCA is like figuring out that your diet caused the condition. (Example: Diagnostic shows the hard drive has bad sectors. RCA determines that the server was located in a dusty, hot room that damaged the drives over time.)
- **Root cause analysis vs Workaround:** A workaround is a temporary fix that bypasses the problem but does not address the underlying cause. RCA aims to eliminate the problem entirely so no workaround is needed. A workaround is a crutch; RCA is the cure. (Example: Workaround: reboot the server every Monday to clear the memory leak. RCA: patch the application that leaks memory.)
- **Root cause analysis vs Lessons Learned:** Lessons learned is the broader process of documenting what went well and what could be improved after an incident. Root cause analysis is one input into lessons learned. Lessons learned includes RCA but also covers team communication, tool effectiveness, and process improvements. (Example: After an outage, RCA identifies a misconfigured firewall. Lessons learned document includes that the firewall change was not reviewed, and recommends a peer review process for future changes.)

## Step-by-step breakdown

1. **Define the problem clearly** — Write down what happened, when, where, and the impact. For example, 'The email server was unreachable from 9:00 AM to 9:15 AM, affecting 300 users.' A clear problem statement focuses the investigation and prevents scope creep.
2. **Collect all available data** — Gather logs from servers, network devices, and applications. Collect error messages, performance metrics, and user reports. The more data you have, the more accurate your analysis will be. Missing data can lead to incorrect conclusions.
3. **Identify contributing factors** — List every factor that contributed to the incident. These are not the root cause but elements that helped create the conditions. For example, a server crash might have contributing factors such as recent configuration change, high traffic, and expired SSL certificate.
4. **Apply the Five Whys or other analysis technique** — Start with the problem statement and ask 'why' repeatedly. Each answer becomes the new problem until you reach a cause that is clearly the root. For example: Why did the server crash? Because it ran out of memory. Why? Because a process had a memory leak. Why? Because the developer did not test the latest update. The root cause is lack of testing, not the memory leak itself.
5. **Identify the true root cause** — The root cause must be a specific, correctable condition. If you cannot think of a way to prevent it, you have not reached the true root cause. For example, 'human error' is not a root cause because you cannot prevent humans from making mistakes; 'lack of automated validation checks' is a root cause that can be fixed.
6. **Propose and implement corrective actions** — Design a permanent fix that addresses the root cause. This could be a configuration change, a software patch, a new policy, or an automated monitoring alert. Implement the fix through your change management process.
7. **Document the findings and share the lessons** — Write a post-incident report that includes the problem description, timeline, data collected, root cause, corrective actions taken, and any additional recommendations. Share it with relevant teams to prevent similar issues elsewhere.

## Practical mini-lesson

Root cause analysis is a critical skill for IT professionals because it transforms reactive troubleshooting into proactive problem management. In practice, RCA is not a one-size-fits-all process. It must be tailored to the environment and severity of the incident. For a critical service outage, a formal RCA might involve a team meeting, detailed log analysis, and a written report. For a minor issue, a quick Five Whys exercise might suffice. The key is that every incident, regardless of size, should trigger some level of RCA. The most common practical approach is the Five Whys. Let's walk through a realistic example. A web application returns a 500 error to users. Step 1: The server log shows an 'OutOfMemoryError'. Why? Because the JVM heap is exhausted. Why? Because a query to the database returns 10 million rows instead of 10. Why? Because a new release removed the pagination logic. Why? Because the developer did not realize the impact of removing pagination. Why? Because there was no code review required for that module. The root cause is the lack of a code review process for changes affecting database queries. The corrective action is to implement mandatory peer review for all database-related code changes. In a practical IT environment, professionals should also be aware of RCA tools and frameworks. ITIL v4 recommends that problem management use RCA to identify the root cause of problems, which then leads to known error records and workarounds if a permanent fix is not immediately possible. In DevOps and SRE (Site Reliability Engineering) environments, RCA is often called a 'postmortem' or 'incident review.' The goal is blameless analysis. The focus is on improving systems, not finding who to blame. Tools like PagerDuty, ServiceNow, and Atlassian Jira Service Management have built-in workflows for documenting RCA. Common pitfalls in practical RCA include confirmation bias (looking for evidence that supports your initial guess), anchoring (fixating on the first possible cause you find), and analysis paralysis (spending too much time analyzing a minor issue). The best practitioners use a structured method, gather data from multiple independent sources, and involve team members with diverse perspectives. After implementing the corrective action, it is essential to monitor the system for a period to confirm the problem does not recur. If it does, the RCA was incomplete and must be revisited. Finally, RCA is not only for failures. It can also be applied to identify the root cause of a success so you can replicate it. For example, if a deployment went unusually smoothly, RCA can reveal the practices that made it successful.

## Memory tip

Ask 'Why?' five times to reach the root cause, the fifth why usually reveals the systemic issue you can fix.

## FAQ

**What is the difference between a root cause and a contributing factor?**

A root cause is the deepest cause that, if removed, prevents the problem from recurring. A contributing factor is an element that helped the problem happen but is not the fundamental reason. For example, a loose cable (contributing factor) might cause a network drop, but the root cause could be that the cable was not properly secured during installation.

**How many 'whys' do I need to ask in the Five Whys method?**

There is no fixed number. The name 'Five Whys' is a guideline. You should keep asking 'why' until you reach a cause that is actionable and can be fixed permanently. Sometimes three whys are enough; sometimes you need seven.

**Is root cause analysis only for major incidents?**

No, RCA is valuable for any recurring issue, even small ones. Performing a quick RCA on a minor repeated problem saves time in the long run. For example, if a printer jams every week, a quick RCA might reveal that the wrong paper type is being used, which is an easy permanent fix.

**What tools can help with root cause analysis?**

Log analysis tools like Splunk, ELK Stack (Elasticsearch, Logstash, Kibana), and Graylog help gather data. IT service management platforms like ServiceNow and Jira have built-in RCA templates. Monitoring tools like Nagios, Zabbix, and Grafana provide performance data. For complex systems, application performance monitoring (APM) tools like New Relic can pinpoint code-level issues.

**Can root cause analysis be performed before the incident is resolved?**

In most methodologies, RCA is performed after the immediate incident is resolved and the system is stable. The priority is to restore service first. However, some preliminary data gathering can begin during resolution to preserve evidence that might be lost, such as logs that are rotated automatically.

**What is a blameless postmortem?**

A blameless postmortem is an RCA approach where the focus is on system improvements, not assigning blame to individuals. It encourages honest reporting of mistakes and weaknesses. This is common in DevOps and SRE cultures. The goal is to learn from incidents and make the system more resilient.

## Summary

Root cause analysis is a systematic method used in IT to identify the fundamental cause of a problem, rather than just fixing its symptoms. By applying techniques such as the Five Whys, fishbone diagrams, or Kepner-Tregoe, IT professionals can uncover the true source of incidents like server crashes, network outages, or security breaches. The goal is to implement permanent fixes that prevent recurrence, reducing downtime and operational costs. In certification exams for CompTIA A+, Network+, Security+, Cisco CCNA, and ISC2 SSCP, RCA is a core concept within troubleshooting methodology and incident response. Exam questions test your ability to distinguish between a symptom, a contributing factor, and a root cause, as well as your understanding of the correct steps to follow after an immediate fix. The key takeaway for exam preparation is to always think one level deeper. When you see a question that describes a technician restarting a service or replacing a component, ask yourself whether the problem could recur. If so, the correct next step is to perform root cause analysis. In real-world IT practice, mastering RCA transforms you from a firefighter who repeatedly resolves the same issues into a problem solver who makes systems more reliable. It is a skill that saves time, money, and frustration, and it is highly valued by employers and certification bodies alike.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/root-cause-analysis