Operational procedures

A technician who can repair anything but skips the procedure around the repair is a liability, not an asset, and this domain is where that discipline lives. Operational procedures is not about diagnosing a fault or configuring a system; it is the set of professional habits that decide whether the work is safe, reversible, documented, and lawful. The model that ties the whole domain together is that every job puts three things at risk, and each subtopic protects one of them: the production system you are changing, the people and rules around the work (your own safety, the customer, and the law), and the data that cannot be recreated once it is lost. At 21% this is the smallest of the four domains in CompTIA's Core 2 objectives, but that is still roughly one question in five, and they are among the easiest points on the exam once you recognize which of the three you are being asked to protect. The trap that runs through the entire domain is the fast answer that just fixes it: implementing a change with no approval or backout plan, opening a case while the power supply still holds charge, or wiping a disk before a verified backup exists.

The domain unfolds in three parts, and they map one-to-one onto what a task puts at risk. Change management protects the production system: before anything goes live you document the change's purpose and scope, analyze its risk, obtain the change board's approval and end-user acceptance, test in a sandbox, and write a backout (rollback) plan back to the last known-good state; this subtopic also owns the operational documents that are the team's memory (tickets, the knowledge base, asset management, network topology diagrams, and standard operating procedures, or SOPs). Safety and communication protects the people and the conduct around the work: de-energize and unplug before you open a device and ground yourself against ESD (electrostatic discharge), but never near a CRT (cathode-ray tube) or PSU (power supply unit); the environmental controls around the equipment, meaning the named power anomalies and the UPS-versus-surge-protector choice, temperature, humidity, and airflow, and the lawful disposal of batteries, toner, and CRTs with the Safety Data Sheet (SDS) as the handling reference; and then the human and legal side of the job, professional communication, customer privacy, software licensing, regulated data such as PII (personally identifiable information) and PHI (protected health information), incident response and the documented, unbroken record of who handled evidence, when, and why (the chain of custody), and choosing a least-privilege remote-access tool, among others. Backup and recovery protects the data itself: you set the backup type and frequency from the business's RPO (recovery point objective) and RTO (recovery time objective), keep copies under the 3-2-1 rule (three copies, on two kinds of media, with one off-site), and prove the design with a periodic test restore. Read each scenario for what it endangers, then reach for the matching subtopic.

The instinct this domain rewards, across all three subtopics, is procedure over improvisation. When a stem offers a fast fix and a by-the-book path that both technically resolve the issue, the correct answer is almost always the one that documents the work, obtains approval, protects the person, or preserves a way back. Safety outranks convenience without exception: you never open a CRT or a power supply, and you never expose RDP (Remote Desktop Protocol) directly to the internet when a VPN (virtual private network) and multi-factor authentication are available. Anything that cannot be undone, or that destroys evidence or the only copy of data, is the distractor the question is built around, so when you are unsure, name which of the three you are protecting and pick the option that protects it most cautiously.