Technical Support Fundamentals

Core Components

• CPU (Central Processing Unit) - the "brain." Fetches, decodes, and executes instructions. Key specs: core count, clock speed (GHz), cache size (L1/L2/L3). More cores = better multitasking; higher GHz = faster per-core execution.
• RAM (Random Access Memory) - volatile, high-speed temporary storage. Programs run here. When RAM is full, the OS spills to slower virtual memory (page file / swap). Current standard: DDR4 or DDR5.
• Storage (HDD / SSD) - non-volatile, permanent storage. SSDs use flash chips (faster, more durable, more expensive per GB). HDDs use spinning magnetic platters (slower, cheaper per GB, more fragile).
• Motherboard - the backbone connecting all components. Contains the chipset, CPU socket, RAM slots, PCIe slots, SATA ports, and I/O headers. The form factor (ATX, Micro-ATX, Mini-ITX) determines case compatibility.
• PSU (Power Supply Unit) - converts wall AC power to regulated DC voltages (+12V, +5V, +3.3V). Wattage must exceed total system draw. 80 Plus rating indicates efficiency (Bronze → Gold → Platinum → Titanium).
• GPU (Graphics Processing Unit) - renders visuals. Integrated GPUs share system RAM; discrete GPUs have dedicated VRAM and a PCIe slot. Essential for displays even on headless servers.

Storage Types Compared

Ports & Connectors

Binary & Number Systems

• Binary (base 2) - computers use 0s and 1s because transistors have two states (on/off). A bit is one binary digit. A byte = 8 bits.
• Hexadecimal (base 16) - digits 0–9 then A–F. One hex digit = 4 bits (a nibble); two hex digits = 1 byte. Used heavily in memory addresses, MAC addresses, and color codes.

Key Terms

Types of Software

What an OS Does

• Process management - starts, schedules, and terminates programs. Decides which process gets CPU time (scheduling algorithms).
• Memory management - allocates RAM to processes and reclaims it when they exit. Handles virtual memory when RAM is full.
• File system management - organizes data on storage into files and directories, controls access permissions.
• Device management - communicates with hardware via drivers; abstracts complexity so applications don't need to know hardware specifics.
• User interface - either a CLI (Command Line Interface) or GUI (Graphical User Interface), or both.
• Security & access control - enforces user accounts, permissions, and authentication.

Major Operating Systems

Software Licensing

Virtual Machines & Hypervisors

• A virtual machine (VM) is a software emulation of a physical computer, running its own OS inside another OS.
• A hypervisor creates and manages VMs, abstracting physical hardware into virtual resources.
• Type 1 (bare-metal): runs directly on hardware, no host OS. Higher performance. Examples: VMware ESXi, Microsoft Hyper-V, KVM.
• Type 2 (hosted): runs on top of an existing OS. Easier to set up. Examples: VirtualBox, VMware Workstation.
• Snapshot: a point-in-time copy of a VM's state - useful for testing or rolling back changes.

Software Versioning

• Semantic versioning: MAJOR.MINOR.PATCH (e.g., 3.11.2). MAJOR = breaking change; MINOR = new feature; PATCH = bug fix.
• LTS (Long-Term Support): a version with extended security updates - preferred for production servers (e.g., Ubuntu 22.04 LTS supported until 2027).
• Keeping software updated patches security vulnerabilities - critical for IT support.

Network Types by Scale

Network Hardware

Physical Media

Network Topologies

IP Addresses - Overview

• Every device on a network needs an IP address to communicate. Like a postal address - unique identifier for routing.
• IPv4: 32-bit, written as four 0–255 numbers separated by dots. ~4.3 billion possible addresses (mostly exhausted).
• IPv6: 128-bit, written in hexadecimal with colons. Virtually unlimited addresses.
• Private IPs (e.g., 192.168.x.x) are used inside a network; a router uses NAT to share one public IP for internet access.
• DHCP automatically assigns IP addresses to devices joining the network so you don't configure them manually.
• DNS translates domain names (google.com) to IP addresses so you don't need to memorize numbers.

The Troubleshooting Methodology (7 Steps)

Asking the Right Questions

• "What changed recently?" - software update, new hardware, configuration change. Most outages have a recent change as the root cause.
• "When did it start / how often does it happen?" - intermittent vs consistent failures point to different causes (heat, memory, network congestion vs hard failure).
• "Does it happen to anyone else?" - determines if it's user-specific, device-specific, or infrastructure-wide.
• "What have you already tried?" - avoids repeating steps and signals what to rule out.
• "Can you reproduce it?" - reproducible bugs are far easier to diagnose.

Troubleshooting Approaches

Support Tiers

Safety & Environmental Considerations

• ESD prevention: anti-static wrist strap (grounded), anti-static mat, anti-static bags for components, avoid carpeted areas when working on hardware.
• Electrical safety: always power off and unplug before opening a PSU or working near high-voltage components. Capacitors inside PSUs can hold charge even when unplugged.
• Thermal management: overheating causes performance throttling and component failure. Ensure proper airflow; clean dust filters periodically.
• Cable management: poor cable management restricts airflow and makes troubleshooting harder - not just aesthetic.

Core Customer Service Skills

• Active listening - let the user fully describe the problem before speaking. Don't interrupt or complete their sentences. Paraphrase back to confirm understanding.
• Empathy - acknowledge the user's frustration: "I understand this is disruptive, let's get it sorted." People want to feel heard before they want to be fixed.
• Positive language - reframe negatives. Instead of "I don't know," say "Let me find out." Instead of "That's not possible," say "Here's what we can do."
• Avoid jargon - explain technical issues in terms the user understands. Talking down or over a user's head both erode trust.
• Set expectations - give a realistic timeline. If you don't know, say when you'll follow up. Silence breeds frustration.
• Follow through - do what you said you'd do, when you said you'd do it. If you can't, proactively communicate before the deadline passes.

Ticketing System Lifecycle

SLA - Service Level Agreement

• A formal contract specifying the expected level of service - including response times, resolution times, and uptime guarantees.
• Response time: how quickly the IT team acknowledges the ticket.
• Resolution time: how quickly the issue is fully resolved.
• SLAs are tied to priority levels - critical outages have much tighter SLAs than low-priority requests.
• Breaching an SLA may have financial penalties or reputational consequences - flag at-risk tickets early.

ITIL Concepts - Incident vs Problem vs Change

Documentation Best Practices

• Write for a stranger - your documentation should allow someone who has never seen the system to follow it without asking questions.
• Runbooks / SOPs: step-by-step procedures for common tasks (server restart, new user onboarding, backup restore). Reduces human error and training time.
• Knowledge base articles: solutions to known issues written in plain language - searchable by users for self-service (Tier 0).
• Network diagrams: always keep updated. Tools: draw.io, Lucidchart, Visio.
• Change logs: record every infrastructure change with date, who made it, what changed, and why. Invaluable for incident investigation.

Hardware — the mental model

Every hardware question ultimately comes down to: is the right component present, is it powered, and is it communicating? Run through components in the POST order — CPU → RAM → storage → display.

• RAM vs storage is the single most-tested distinction. RAM = volatile, fast, where programs run. Storage = permanent, slow, where programs live. Slowness with high RAM usage → thrashing (virtual memory). Slowness with low RAM → check CPU, thermals, or disk speed.
• Boot sequence: power on → PSU delivers voltage → motherboard firmware (UEFI/BIOS) runs POST → hands off to OS bootloader → OS loads into RAM. Know where failures can happen at each step.
• Storage speed hierarchy comes up constantly as an upgrade recommendation: NVMe ≫ SATA SSD ≫ HDD. Default to NVMe for OS drives.
• ESD is on the exam and in real life — always ground yourself before touching internal components.

Software & OS — the kernel is the center

• The kernel is the privileged layer between hardware and every running program. All software communicates with it via system calls. This mental model explains why OS crashes affect everything while app crashes usually don't.
• Drivers are the most common hardware fix. Device not working after connecting? Update or reinstall the driver first. Kernel modules on Linux work the same way — loadable, removable without rebooting.
• Licensing categories matter in enterprise: proprietary (pay for a license), open source (GPL = copyleft, MIT/Apache = permissive), freeware (free but closed). The GPL "viral" clause is a real compliance concern for organizations shipping products.
• Hypervisors: Type 1 (bare metal, e.g., ESXi, Hyper-V) for production servers. Type 2 (hosted, e.g., VirtualBox) for desktops and testing. Snapshots are your safety net before risky changes.

Troubleshooting — the methodology is the point

The 7-step methodology isn't just exam content — it's the actual difference between technicians who fix things once and those who fix the same thing every week.

Customer service & ITIL — soft skills are real skills

• Empathy before fixes. A user who feels heard is a user who cooperates. Acknowledge frustration, set expectations, follow through. People remember how they were treated long after they forget what was broken.
• Incident vs Problem vs Change is the core ITIL distinction. Incident = restore service fast (reboot the server). Problem = find out why it keeps crashing. Change = plan and approve the OS upgrade. Confusing these leads to treating symptoms forever.
• SLAs define your accountability. P1 outages have minutes, not hours. Know your priority levels and escalate before the clock runs out — proactive communication beats a missed SLA every time.
• Documentation is institutional memory. A well-written ticket means the next person (including future you) doesn't start from zero. Runbooks and knowledge base articles scale your expertise beyond yourself.

The bigger picture