Tools of the Trade

1🖥️ Windows & Linux Command-Line Tools

Windows: ipconfig /all, ping, tracert, nslookup, Resolve-DnsName, Test-NetConnection, netstat -ano, Get-NetTCPConnection, Get-Service, Get-Process, Get-WinEvent, gpresult, whoami, klist (Module 15 covers most of these PowerShell cmdlets in depth). Windows Event Viewer remains essential — System, Application and Security are the three logs you'll open constantly (Module 14, Lesson 3).

Linux: ip addr, ip route, ping, traceroute, dig, nslookup, curl, wget, ss, netstat, ps, top/htop, free, df, du, journalctl, systemctl, dmesg, tail, grep (Module 6's Linux content and Module 14's log-reading content both draw on this exact toolkit).

2📊 Modern Observability & Legacy Technologies

Global organisations widely use monitoring and observability platforms — Splunk, Microsoft Sentinel, Elastic Stack, Datadog, Dynatrace, New Relic, Grafana, Prometheus, Azure Monitor, AWS CloudWatch, Google Cloud Operations, SolarWinds, Zabbix, Nagios — to investigate logs, metrics, traces, alerts, CPU/memory, request latency, authentication activity, network connections and database performance (Module 11 and Module 14 both cover this ecosystem in more depth). Modern troubleshooting increasingly relies on observability rather than manually SSHing into individual boxes.

You'll also work in genuinely older environments — Windows Server 2008/2012-era systems, legacy AD domains, NTLM authentication, older LDAP, RADIUS, mainframe integrations, older Java applications, SOAP web services, FTP/SFTP integrations, old VPN concentrators, on-premises Exchange, legacy Citrix, older UNIX systems, and proprietary hardware appliances. The troubleshooting methodology stays exactly the same regardless of how old the technology underneath is — that consistency is the whole point of this module.

3🔗 HTTP Status Codes & Browser DevTools

HTTP response codes are one of the fastest troubleshooting signals available (Module 13, Lesson 2 covers the full picture): 200 succeeded; 301/302 redirect; 400 malformed request; 401 authentication required or invalid; 403 authenticated but not permitted; 404 resource doesn't exist; 408 request timeout; 429 rate limit exceeded; 500 application/server error; 502 upstream returned an invalid response; 503 service unavailable; 504 upstream failed to respond in time.

Browser DevTools (F12 → Network) let you inspect the request URL, HTTP method, response code, headers, cookies, redirects, request/response payload, and timing directly. For authentication systems specifically, this can reveal SAML redirects, OAuth authorization requests, token requests, API failures, CORS errors, and 401/403 responses — often faster than reading server logs, since you're watching the exact transaction as it happens.

4💻 Using curl for Troubleshooting

curl is one of the most valuable troubleshooting tools there is (Module 13, Lesson 4 covers it as an API-testing tool specifically):

curl https://api.company.com
curl -v https://api.company.com          # verbose
curl -I https://portal.company.com       # headers only
curl -X GET https://api.company.com/users

curl \
-H "Authorization: Bearer TOKEN" \
https://api.company.com/users

Learn to compare a browser request, a Postman request, a curl request, and the actual application's request side by side. If curl succeeds but the application fails, that single comparison tells you something important — the server side is fine, and the problem lives in exactly what the application is doing differently.

5📡 Packet Capture & Log Correlation

Packet captures provide extremely powerful evidence — Wireshark, tcpdump, Microsoft Packet Monitor, and network appliance capture tools. tcpdump -i eth0 port 443; useful Wireshark filters include dns, tcp.port == 443, and ip.addr == 10.10.20.30. Look for the TCP handshake, retransmissions, DNS queries, the TLS handshake, connection resets, and timeouts — a capture can definitively tell you whether the problem is network, firewall, application, or client (Module 3's Wireshark labs are exactly this skill).

Logs become far more useful once correlated across systems (Module 14, Lesson 1). Given a correlation ID like 7f4a2d81, search for it everywhere:

10:01:23 Web Server        Request received
10:01:23 Application Server Authentication request started
10:01:23 Identity Provider  Authentication successful
10:01:24 Application Server Database query initiated
10:01:54 Database           Query timeout

The actual problem — a 30-second database timeout — is now obvious, buried inside what would otherwise have looked like a generic authentication failure from the client's point of view.

Lesson Outcome

You should now be able to reach for the right Windows or Linux command for a given symptom, know when a full observability platform is warranted versus a quick manual check, read HTTP status codes and browser DevTools network traces fluently, use curl to isolate a client-side problem from a server-side one, and use packet captures and correlation IDs to pin down exactly where in a multi-system flow something actually broke. Lesson 4 puts all of this to work on seven realistic, complete scenarios.