Prices shown are a USD base. Your local-market price is calculated at checkout in your own currency, plus any local sales tax.
What is inside
20 chapters, in the order the interviews tend to ask them:
The service catalogue and what an SLA does not cover
Ticket lifecycle, categories and priority
ITIL practices and which ones are worth adopting
Shift handover, runbooks and on-call documentation
Windows workstation and Windows Server administration
Linux administration and systemd units
Active Directory, groups, Group Policy and identity
Networking fundamentals, DNS, DHCP and VLANs
Wi-Fi design and wireless troubleshooting
Switches, routers, firewalls and remote access VPN
Microsoft 365 and Exchange administration
Endpoint protection, patching and vulnerability management
Monitoring, event logs and the three logs that matter
Backup, restore and proving a restore works
Storage, shares, NTFS permissions and effective access
Printers, print queues and peripherals
Hardware, imaging and the build versus buy decision
The knowledge base that reduces repeat tickets
Client communication and the escalation conversation
Capacity planning, service reporting and the metrics that matter
How the answers are built
Each chapter opens with the checklist the question is really testing. A few from this pack:
A catalogue entry needs a name, a one line description, a scope boundary, measurable targets, a price with a unit and a review date, because anything without a scope boundary becomes an unbounded promise.
Intake should capture who is affected, what changed, when it started and what has already been tried, because every later decision depends on those four facts.
ITIL 4 describes practices rather than processes, so adopting it means choosing which practices to run and how much formality each one needs.
A handover covers open incidents and their current state, watch items for the next few hours, and anything the departing engineer could not finish, in that order.
Server Manager is the entry point for adding roles rather than for day to day management, so a server built entirely through its dialogs is a server nobody else can maintain.
The unit file is the honest record of how a service starts, so fixing a service by editing a start up script leaves the next engineer guessing.
Questions this pack covers
What actually has to be in a service catalogue entry before it can be sold?
How is a service level agreement different from the contract it sits inside?
What information does a ticket need at intake before an engineer can act on it?
What is the difference between a category and a priority on a ticket?
What is the actual point of incident management as a practice, if you already handle incidents?
How is a change request different from an incident?
What three things must every shift handover actually contain?
Why is a runbook written during an incident worth more than one written calmly afterwards?
Each one is answered in full in the pack, with the reasoning written out rather than a bullet list.
