Lesson 5: Domain 3 Technician Practical

No objective labels today.

A real help-desk queue does not tell you which chapter contains the answer.

You get a user report, a little evidence, and a system that may cross Windows, mobile, security, hardware, networking, and policy at the same time.

Your job is to locate the first failed boundary without allowing one dramatic symptom to erase everything that still works.

Use one incident model

For every ticket:

user report
   ↓
baseline / last known-good state
   ↓
scope
   ↓
recent change
   ↓
last proven-good boundary
   ↓
first failed / uncertain boundary
   ↓
evidence source
   ↓
strongest theory + alternative
   ↓
containment or controlled correction
   ↓
rollback / recovery
   ↓
verify original requirement
   ↓
remaining uncertainty

The objective category comes after you understand the incident, not before.

Ticket A: firmware sees the SSD, but no OS is found

Evidence:

firmware: SSD detected
boot: no operating system found
recent change: storage repartitioned yesterday

The SSD is physically visible to firmware.

That weakens a total drive-detection failure.

The recent partitioning change moves the investigation toward:

• boot partition state;
• bootloader;
• boot order;
• partition layout;
• operating-system installation.

Do not replace the drive until the boot-state evidence earns that conclusion.

Ticket B: Windows sign-in takes four minutes

Evidence:

profile: roaming/domain
network latency to profile/identity services: high
local CPU: normal
local storage: normal
local test profile: fast

The slow-profile path is stronger than a general hardware-performance problem.

Useful next evidence may involve profile size, login script timing, policy processing, or network service latency.

Replacing the SSD because login is slow ignores the local-profile comparison.

Ticket C: one mobile app cannot update

Evidence:

Wi-Fi: associated
other applications: use network normally
affected app: update fails
free storage: nearly exhausted

Network-wide troubleshooting is weak because other applications already prove the connection works well enough for them.

Storage/update requirements deserve attention first.

The repair should remain at app and storage scope unless broader evidence appears.

Ticket D: high mobile data use after unofficial app installation

Evidence:

battery drain: increased
background network use: high
new app: unofficial source
permissions: broad
traffic contents: unknown

This is a legitimate mobile-security concern.

It is not proof that the app stole a particular file or credential.

Use policy-approved containment and management, preserve evidence, and escalate if data-exposure indicators appear.

The claim should remain no larger than the evidence.

Ticket E: fake antivirus warnings on a PC

Evidence:

approved endpoint protection: healthy/current
warnings: browser notifications
other Windows security surfaces: no matching alert

The browser notification or site-permission boundary is the strongest first scope.

Do not purchase the advertised cleaner.

Do not disable the real security product.

Correct the browser state, update and scan under policy, then verify that the warnings stop while legitimate protection remains active.

Ticket F: Windows service will not start

Evidence:

OS: otherwise stable
service: fails at startup
Event Viewer: configuration/dependency error
recent change: service configuration edited

Stay at service and configuration scope.

A Windows reinstall would be enormous compared with the evidence.

Restore the documented service configuration or dependency under the approved procedure, then verify the function the service actually supports.

Ticket G: USB devices work separately but not all together

Evidence:

all devices individually: work
all connected: controller resource warning
device power: present
one device moved to another controller group: warning clears

This is not a dead USB port.

The pattern supports controller resource allocation as the failing boundary.

The controlled change already gave you evidence.

Use it.

Ticket H: mobile screen will not rotate

Evidence:

rotation lock: enabled
orientation sensor: passes supplied test
application: supports rotation

The setting is doing exactly what it was configured to do.

Do not replace display hardware.

Correct rotation lock and verify the screen rotates in a supported app.

Simple does not mean unprofessional. It means you found the right boundary.

Ticket I: personal files renamed and inaccessible

Evidence:

many files: renamed / inaccessible
ransom-style note: present
network shares: mounted
incident-response escalation: available

This crosses the security-response boundary.

Priorities:

• isolate according to policy;
• protect shared resources;
• preserve evidence and recovery state;
• escalate.

Do not reconnect shares to test them.

Do not delete the note.

Do not spend the first hour trying to identify the exact malware family while the environment may still be exposed.

Ticket J: Windows clock resets after complete power loss

Evidence:

Windows time: wrong after full power loss
network time: corrects it while running
firmware clock: also resets

The evidence points earlier than Windows.

Firmware/RTC/CMOS state becomes stronger than a browser or certificate diagnosis.

Could bad time later cause certificate or authentication errors?

Yes.

That would make those symptoms secondary effects of the clock problem.

Ticket K: browser certificate warning after clock drift

Evidence:

device time: one year wrong
browser: certificate date warning
same site on correctly timed device: normal

The warning is real.

The certificate may still be valid.

Correct and verify the device's time source first, then revisit certificate validation.

Do not teach users to click through trust warnings because you think you know the cause.

Ticket L: phone has no internet after management-profile change

Evidence:

Wi-Fi: associated
IP/gateway: valid
new VPN/content-filter profile: installed
failure: began immediately after profile update

This looks like a mobile-security configuration problem more than a radio failure.

The profile may be broken while the device is otherwise healthy.

Work with the policy/management owner rather than deleting the management profile on a real corporate device.

Ticket M: Windows application crashes and low-memory warning appears

Evidence:

application: memory-heavy
Windows: low-memory warning
Task Manager: memory 98%
other applications: slow but running

The crash may be an effect of resource pressure rather than application corruption.

Reduce or understand the memory demand, then retest.

Reinstalling the app before addressing the measured bottleneck is weak troubleshooting.

Ticket N: browser redirection on one profile only

Evidence:

profile A: redirects
profile B: normal
unknown extension: installed in profile A
Windows networking: normal

The browser-profile scope is very strong.

Correct that scope first and run the approved security verification.

Do not reimage the computer because one profile has a bad extension.

Build six complete technician records

Choose at least six tickets, including:

• two Windows OS cases;
• one mobile OS/application case;
• one mobile security case;
• one PC security case;
• one mixed-boundary case.

For each document:

user-visible symptom
baseline / last known-good state
recent change
scope
last proven-good boundary
first failed / uncertain boundary
selected evidence source
strongest theory
alternative theory
containment if required
controlled correction or escalation
rollback / data-recovery concern
verification of the original requirement
remaining uncertainty
objective category only after diagnosis

Defend one incident

Explain one ticket using this structure:

The user reported...

The evidence proves...

The first boundary I cannot prove is...

My strongest theory is... because...

The competing theory is weaker because...

My next action is...

The action is limited to this scope because...

I would verify the original requirement by...

I still cannot claim...

That final sentence matters.

A technician should know where certainty ends.

What Week 15 should leave you with

The software troubleshooting domain is not four lists of symptoms.

It is one method applied across different systems:

Windows
mobile OS / apps
mobile security
PC security
        ↓
scope + evidence + recent change
        ↓
controlled correction or containment
        ↓
recovery + verification + documentation

The system changes.

The reasoning discipline does not.

Next we move into Operational Procedures, where the technical fix is only part of the job. Communication, safety, documentation, backup, change control, and recovery decide whether the repair is professional.