Lab 1: The Case of the Sluggish Device
Your team gets a slow, unreliable laptop and the readings that came with it. Use a structured troubleshooting process to find the root cause, choose and test a fix, and then teach someone else how you did it in a device recovery walkthrough.
At a glance
- Time: 3 class periods (45 min) plus recording time
- Team size: 4 (one role each)
- Book lessons: 1.1 and 1.2 (review 1.3 and 1.4 for the prevention step)
- Deliverable: device recovery walkthrough (video, narrated screen recording, or annotated slides)
Learning objectives
- 1.1.A Explain how to troubleshoot common device and network issues.
- 1.1.B Identify likely root causes of a device issue using diagnostic tools and techniques.
- 1.1.C Determine an appropriate solution to resolve a device issue.
- 1.2.B Determine strategies to improve speed, reliability, or performance.
The situation
It is the weekend. A classmate needs to finish a project and wants to stream a show afterward, but the laptop is crawling: apps lag, videos buffer, and sometimes it misbehaves in ways the owner cannot explain. Your team is the help desk. You need to restore the laptop quickly, and you need to show your work so that the owner could follow the same steps next time.
Starter files
Your teacher assigns your team one case card. Every case has a different root cause, so do not copy another team's answer.
- Case card A: device readings (.txt)
- Case card B: device readings (.txt)
- Case card C: device readings (.txt)
- Case card D: device readings (.txt)
- AI assistant suggestions for all four cases (.txt)
- Walkthrough planner and team log (Word)
Want to use a real device instead?
With your teacher's permission, you can recreate your case on a school lab laptop: open Task Manager (Windows: Ctrl+Shift+Esc) or Activity Monitor (Mac), check storage in Settings, and runping 8.8.8.8 in a terminal. Use only school devices you are allowed to use, and never change settings on a device you do not own or have permission to work on.Team roles
Keeps the team on the plan and the clock, makes sure every requirement is covered, and makes the final call when the team is split. Owns the team log.
Reads the evidence (readings, logs, command output), compares values with the thresholds from the book, and states what each piece of evidence shows.
Plans and carries out the configuration or fix in the simulator or on the device, and runs the verification tests.
Builds the deliverable, keeps diagrams and tables consistent, and records how the team used and checked AI.
Walkthrough
Part 1: Gather information (Day 1, 15 min)
- Read the user report on your case card out loud. As a team, list every symptom in your planner: what is slow, when it started, and where the device is.
- Decide whether a simple, well-known fix should be tried before full diagnosis (restart, close apps, reconnect). Write down which one you would try first and why. Ask your teacher for the result of that quick fix.
- If the quick fix does not restore function, keep going. If it does, you must still verify it in Part 4.
Part 2: Read the diagnostic data (Day 1, 20 min)
- Fill in the readings table in your planner: CPU, RAM, storage (calculate the percent free), Wi-Fi signal, ping results, temperature, and error messages.
- Mark each reading normal or problem using the thresholds from Lesson 1.1: CPU or RAM sustained above 80–90%, storage below 10% free, a weak signal, ping over 100 ms or more than 1–2% loss, and temperature warnings.
- Write a theory of probable cause in one sentence that names the evidence, for example: "The processor is overloaded because CPU has been above 90% for 20 minutes and one process is using 78%." Some cases have more than one cause. Look carefully.
Part 3: Work with AI, then decide (Day 2, 20 min)
- Open the AI assistant suggestions file and find your case. The AI saw only the user report, not your readings.
- For each suggestion, decide keep, test first, or reject, and justify it with a reading. Note anything the AI got wrong or overcomplicated.
- Rank your possible solutions from simplest and cheapest to most complex and expensive. Choose the one you will implement first.
Part 4: Implement and verify (Day 2, 20 min)
- Write the exact steps you would take to implement your solution (for example, "Open Task Manager, select CloudSync Helper, choose End task").
- Tell your teacher which solution you implemented. Your teacher will hand you the readings taken after your fix.
- Compare the new readings with the old ones. Is functionality restored? If not, the root cause may have been misidentified, or there may be a second issue. Return to Part 2 or Part 3, document what you learned, and try the next solution.
Part 5: Build the device recovery walkthrough (Day 3)
Create a walkthrough that someone outside your team could follow step by step. It can be a narrated screen recording, a demonstration video, or an annotated slide deck. Include:
- Initial observations and any early troubleshooting steps (Part 1)
- The diagnostic data, with the readings that pointed to the cause (Part 2)
- The potential solutions you considered, including what you kept and rejected from the AI (Part 3)
- The steps taken to implement the chosen solution (Part 4)
- Verification that functionality was restored, with before-and-after readings (Part 4)
- Two suggestions for avoiding or troubleshooting a similar issue in the future, including one security habit from Lessons 1.3–1.4
Deliverable rubric
| Criterion | Points |
|---|---|
| Process. Walkthrough follows the troubleshooting process in order: information, quick fix, diagnosis, theory, solution, implementation, verification. | 4 |
| Evidence. Root cause is correct and is supported by at least two specific readings with their thresholds. | 4 |
| Solution. Solutions are ranked simple to complex; the chosen solution matches the cause; implementation steps are exact enough to repeat. | 4 |
| Verification. Before-and-after readings show restored function. If the first fix failed, the walkthrough shows how the team continued. | 3 |
| AI evaluation. Each AI suggestion is kept, tested, or rejected with a reason tied to the data. | 3 |
| Prevention. Two realistic suggestions for the future, one of them a security habit. | 2 |
| Collaboration. Team log shows each role's contributions and how the team decided. | 2 |
| Communication. Clear, accurate vocabulary; an outside viewer could follow it. | 2 |
| Total | 24 |