Lesson 5: Cross-Platform Technician Practical

A real support queue does not organize itself by certification objective.

It definitely does not promise that every endpoint is Windows.

You get a symptom, a requirement, and whatever evidence the system gives you.

The first professional move is to identify the platform and keep your assumptions inside that platform's architecture.

Ticket 1: the operating system still works but support ended

Evidence:

endpoint: boots normally
legacy application: still works
vendor security support: ended
current application/browser support: disappearing

Is the computer broken?

Not in the narrow sense.

Is the support problem solved?

No.

The system now carries lifecycle risk.

A defensible plan compares application migration, endpoint replacement, bounded virtualization, restricted exposure, and retirement timing.

"It still boots" is not a lifecycle strategy.

Ticket 2: removable drive works on one OS but not another

Evidence:

physical drive: detected on both systems
hardware errors: none supplied
filesystem: APFS
macOS: mounts normally
Windows: cannot use volume as required

Do not replace the drive.

The hardware path is already working.

The filesystem and platform compatibility boundary explains the different behavior.

Now protect the data and choose a supported transfer or filesystem strategy.

Do not format first.

Robotnix service-diagnosis simulation
Everything here is local simulated state. Type 'help' for the evidence path.

$ systemctl --user status sensor-api
● sensor-api.service - Sensor API
   Active: failed
   Result: exit-code

$ journalctl --user -u sensor-api
sensor-api[511]: config error: PORT must be a number
systemd[1000]: sensor-api.service: Main process exited, status=1/FAILURE

$ cat service.env
PORT=abc

$ cp service.env.fixed service.env
Copied known-good bounded configuration.

$ systemctl --user restart sensor-api
sensor-api restarted.

Ticket 3: macOS package cannot install

Evidence:

package: approved .pkg
macOS: supported
current user: standard account
organization: managed device
software policy: admin/MDM deployment required

The failed boundary is installation authority.

Do not bypass management.

Use the approved administration or MDM path, then verify the application actually performs its required function.

Ticket 4: macOS disk appears in Disk Utility but not Finder

Evidence:

physical device: detected
Disk Utility: sees disk/container
Finder: no mounted usable volume
important data: may exist

A total USB detection failure becomes weak.

The incident moves toward volume state, filesystem, mounting, or integrity.

Do not initialize or erase until the data requirement is known.

Ticket 5: Linux name resolution fails on one client

Evidence:

ip: valid address and route
ping documentation IP: succeeds
dig configured resolver: fails
/etc/resolv.conf: wrong resolver in supplied state
other clients: normal

The last proven-good boundary is IP connectivity.

Client resolver configuration becomes strong.

But do not blindly edit /etc/resolv.conf until you know whether another network or resolver service owns and regenerates it.

The platform's management model matters.

Ticket 6: Linux file exists but user cannot edit it

Evidence:

file: exists
filesystem: mounted read/write
owner: root
group: support
mode: -rw-r-----
current user: not owner, not in support group

Storage is healthy.

The user is authenticated.

The permission and ownership model denies the write.

Do not use chmod 777.

Decide which identity should have access and make the narrowest justified change.

Ticket 7: Linux application says no space left

Evidence:

df: root filesystem 98% full
du: one application log/cache tree is dominant

Do not reinstall the application.

Understand what owns the growing data and the approved retention or cleanup behavior.

Then verify free space, retest the application, and investigate why the growth happened.

Otherwise the "fix" may buy only a few more days.

Ticket 8: application requirements do not match the endpoint

Requirements:

64-bit supported OS
16 GB RAM
dedicated supported GPU
4 GB VRAM

Endpoint:

64-bit OS: yes
RAM: 8 GB
GPU: integrated only

The system fails multiple application requirements.

Document all of them.

Do not reduce the diagnosis to the first setup error message.

Ticket 9: cloud sign-in works, application says no entitlement

Evidence:

cloud identity: synchronized
authentication: successful
required service license: unassigned

Authentication is already proven.

The failed boundary is licensing or entitlement.

Resetting the password solves a problem the evidence says you do not have.

Ticket 10: videoconference cannot use the camera

Evidence:

camera: works in another application
conference service: reachable
user: authenticated
target application: camera permission disabled

The camera hardware and at least one local driver path work.

The failure is application/privacy configuration.

Do not replace the webcam.

Ticket 11: ChromeOS receives a Windows installer

Evidence:

endpoint: ChromeOS
vendor package: Windows .exe
supported ChromeOS desktop package: none
approved browser/SaaS version: available

The user asked for the application function.

They did not ask you to prove you can force a Windows executable onto an unsupported platform.

Use the supported delivery model that satisfies the requirement.

The goal is not to look technical. The goal is to make the system work and remain supportable.

Ticket 12: synchronized file disappears everywhere

Evidence:

user deletes file on one synchronized endpoint
cloud sync: propagates deletion
other endpoints: file disappears
independent backup/version recovery: available in supplied scenario

Synchronization worked.

Now use the supported recovery or version-history mechanism.

Do not describe synchronization itself as the failure when it performed its configured job.

Build five cross-platform service records

Choose at least five tickets across at least three platform families.

Document:

platform
user-visible symptom / requirement
filesystem / application / service involved
last proven-good boundary
first failed or uncertain boundary
platform-appropriate tool / evidence surface
strongest explanation
competing explanation
policy / data / privilege risk
smallest justified correction or escalation
verification of the original requirement
remaining uncertainty

Your records should demonstrate that you can change tools without changing reasoning discipline.

What transfers across platforms

The exact commands and interfaces change.

These habits do not:

identify before changing
preserve data
separate observation from inference
respect permissions and policy
use the platform's actual management model
choose the smallest useful tool
verify the user's required function
record what remains unknown

Operating-systems block complete

Weeks 11 and 12 now connect:

Windows edition + deployment + tools + policy
                ↓
OS family + filesystem + lifecycle
                ↓
macOS native support model
                ↓
Linux files + permissions + packages + services
                ↓
application requirements + cloud identity/licensing
                ↓
cross-platform diagnosis

A technician who only knows one interface will struggle as soon as the interface changes.

A technician who understands system boundaries can move between platforms.

Next we enter security, where the same discipline matters even more because a careless "fix" can remove the control that was protecting the system.