SOT-001 — CompTIA SecOT+ V1 Quick Review

Quick Review for CompTIA SecOT+ V1 (SOT-001): high-yield OT security concepts, decision rules, common traps, and practice guidance.

Quick Review for CompTIA SecOT+ V1 (SOT-001)

This Quick Review is designed for candidates preparing for CompTIA SecOT+ V1 (SOT-001) who want a focused refresher before moving into topic drills, mock exams, and detailed explanations.

Use it to reinforce the highest-yield ideas: operational technology security priorities, industrial network architecture, asset discovery, segmentation, monitoring, vulnerability management, incident response, and common exam decision traps.

This is IT Mastery review support. It is not affiliated with CompTIA.

Exam Identity

ItemDetail
Vendor / providerCompTIA
Official exam titleCompTIA SecOT+ V1 (SOT-001)
Official exam codeSOT-001
Review focusSecurity of OT, ICS, industrial environments, and supporting IT/OT operations
Best next study stepUse original practice questions to test decisions under scenario pressure

High-Yield Mindset

OT security questions often test whether you can protect systems without disrupting physical processes.

The OT Priority Shift

In many IT environmentsIn many OT environments
Confidentiality is often emphasized firstSafety and availability often dominate
Systems can usually be patched more frequentlyPatching may require testing, outage windows, or vendor approval
Active scanning is commonActive scanning can disrupt fragile devices
Endpoint agents are commonAgents may be unsupported or risky on control systems
Reimaging is routineReimaging may require validated configurations and process owner approval
Data loss is a major concernLoss of view, loss of control, unsafe state, or downtime can be critical

Practical Exam Rule

When a scenario involves production OT:

  1. Protect human safety first.
  2. Preserve process availability and integrity.
  3. Coordinate with operations, engineering, and asset owners.
  4. Prefer passive visibility before intrusive testing.
  5. Use segmentation, compensating controls, and change control when patching is not immediately possible.

Core OT and ICS Terms

TermWhat to remember for SOT-001-style scenarios
OTTechnology that monitors or controls physical processes.
ICSIndustrial control system; broad category including SCADA, DCS, PLCs, RTUs, HMIs, and related systems.
SCADASupervisory control and data acquisition; often geographically distributed.
DCSDistributed control system; commonly used in plants and continuous processes.
PLCProgrammable logic controller; directly controls equipment and logic.
RTURemote terminal unit; common in remote monitoring/control environments.
HMIHuman-machine interface; operator workstation for viewing and controlling processes.
Engineering workstationUsed to program/configure PLCs and control devices; high-value target.
HistorianCollects and stores process data; often bridges OT and enterprise reporting.
SISSafety instrumented system; designed to move process to safe state. Treat as highly critical.
Sensors and actuatorsField-level devices that measure and affect the physical process.
Jump serverControlled access point into OT networks; should be monitored and hardened.
OT DMZBuffer zone between IT and OT networks; reduces direct connectivity.
ConduitControlled communication path between zones.
ZoneGroup of assets with similar trust level, function, or risk.

Purdue Model Quick Review

The Purdue model is a common way to reason about industrial environments. Exact implementations vary, but the concept is high-yield: separate enterprise IT, OT operations, control systems, and field devices.

LevelTypical systemsSecurity focus
Level 0Sensors, actuators, physical processPhysical safety, tamper resistance, reliable signaling
Level 1PLCs, RTUs, I/O controllersControl logic integrity, restricted programming access
Level 2HMIs, engineering workstations, local controlOperator access, endpoint hardening, change control
Level 3Site operations, historians, OT servicesOT authentication, logging, patch coordination, backups
Level 3.5OT DMZ, jump servers, data brokersControlled IT/OT exchange, remote access control
Level 4Enterprise IT systemsBusiness systems, identity, corporate apps
Level 5External/cloud/Internet servicesThird-party access, cloud security, external exposure control

Purdue Model Traps

TrapBetter answer
Allowing direct enterprise-to-PLC accessUse OT DMZ, jump hosts, firewalls, and approved conduits
Treating VLANs as complete security boundariesUse firewall rules, ACLs, monitoring, and segmentation policy
Sending all OT data directly to cloudUse brokered, authenticated, monitored, least-privilege data flows
Giving vendors persistent VPN accessUse time-bound, approved, MFA-protected, logged access
Ignoring historian placementTreat historians as potential IT/OT bridges and monitor them

OT Security Decision Rules

Scenario asks for…Prefer…Avoid…
Discovering assets in production OTPassive discovery, network taps/SPAN, configuration reviewAggressive active scanning without approval
Reducing IT-to-OT riskOT DMZ, firewalls, jump servers, strict conduitsFlat networks or direct routing
Vendor maintenance accessMFA, PAM, session recording, time-bound accessShared accounts and always-on VPNs
Vulnerable PLC with no patchSegmentation, firewall rules, vendor guidance, monitoringImmediate untested firmware update
Ransomware resilienceOffline/immutable backups, tested restoration, segmentationBackups reachable from compromised domain
Suspicious OT trafficValidate baseline, compare with process state, involve operationsBlocking blindly and disrupting control
Legacy unsupported systemCompensating controls, isolation, allowlistingAssuming normal IT patch cadence
Engineering workstation compromiseContain carefully, preserve logic/configs, verify controllersReimage without process-owner coordination
New IIoT gatewayCertificate-based auth, least privilege, egress controlUnrestricted outbound Internet access
Incident in active processSafety-first response with operations leadPure IT-only incident playbook

Asset Inventory and Baselines

Asset inventory is foundational because OT environments often contain legacy systems, vendor-managed devices, undocumented connections, and fragile protocols.

What a Good OT Inventory Captures

Inventory fieldWhy it matters
Asset typePLC, HMI, historian, workstation, switch, sensor, gateway
LocationPlant, line, cabinet, remote site, control room
Process criticalityShows safety and production impact
OwnerIdentifies who approves changes
Vendor/model/firmwareSupports vulnerability and supportability checks
Network detailsIP, MAC, VLAN, zone, conduit, protocol use
Software/configurationEnables recovery and change validation
Communication flowsSupports segmentation and anomaly detection
Backup statusConfirms recoverability
Maintenance windowDetermines when changes are possible
DependenciesShows what breaks if a system is isolated

Baseline Concepts

A baseline is the known-normal state of assets, configurations, communications, and process behavior.

High-yield baseline examples:

  • PLC-to-HMI communication patterns
  • Engineering workstation programming activity
  • Historian polling intervals
  • Normal remote access windows
  • Expected protocol commands
  • Usual bandwidth and connection pairs
  • Normal operator login times
  • Approved firmware and logic versions

Common Inventory Mistakes

  • Relying only on spreadsheets that are never reconciled.
  • Using aggressive discovery tools on fragile production networks.
  • Tracking IP addresses but not process criticality.
  • Ignoring temporary vendor connections.
  • Failing to document PLC logic, firmware, and configuration backups.
  • Treating OT assets as if they are owned only by IT.

Industrial Protocols: What to Recognize

You do not need to memorize every packet field to answer many exam scenarios. Focus on the security implications.

Protocol / technologyCommon contextSecurity review point
Modbus / Modbus TCPIndustrial control communicationOften lacks native authentication or encryption in legacy use
DNP3Utilities and remote controlSecure variants may exist, but legacy deployments require protection
EtherNet/IPIndustrial automationSegment and monitor command behavior
PROFINETIndustrial EthernetProtect controller and device communication paths
OPC DALegacy Windows-based data exchangeOften difficult to secure; isolate and control access
OPC UAModern industrial interoperabilityCan support stronger security when configured correctly
IEC 61850Power systems/substationsHigh criticality; protect timing and control messages
BACnetBuilding automationWatch for exposed building systems and weak segmentation
MQTTIIoT messagingSecure broker, authentication, authorization, and TLS matter
Serial protocolsLegacy control systemsMay be bridged to IP; gateway security becomes important
Time sync protocolsProcess coordination and loggingProtect against time manipulation and preserve forensic value

Protocol Trap

If a protocol lacks built-in security, the best answer is usually not “encrypt the PLC” in isolation. The better control is often layered:

  • Segment the network.
  • Restrict allowed communication pairs.
  • Use protocol-aware firewalls or monitoring.
  • Place gateways in controlled zones.
  • Authenticate remote users and systems.
  • Monitor for abnormal commands.
  • Use secure protocol variants where feasible and supported.

Segmentation and Network Architecture

Segmentation limits blast radius and controls who can communicate with critical OT assets.

Strong Segmentation Patterns

PatternPurpose
OT DMZPrevents direct IT-to-OT communication
Jump serverCentralizes and logs administrative access
Firewall between zonesEnforces allowed conduits
Data diode / unidirectional gatewayAllows one-way data flow where appropriate
Separate identity boundaryReduces enterprise domain compromise impact
Remote access brokerControls vendor and engineer sessions
Industrial IDS sensorMonitors traffic without disrupting operations
Management networkSeparates administration from process control traffic
Egress allowlistingPrevents uncontrolled outbound connections
Network access controlHelps restrict unauthorized devices where feasible

Segmentation Decision Path

    flowchart TD
	    A[Need communication between IT and OT?] --> B{Is it required for operations?}
	    B -- No --> C[Deny by default]
	    B -- Yes --> D{Can data flow be one-way?}
	    D -- Yes --> E[Use broker, data diode, or controlled publish path]
	    D -- No --> F[Use OT DMZ or jump host]
	    F --> G[Apply MFA, least privilege, logging]
	    G --> H[Restrict ports, protocols, source, destination]
	    H --> I[Monitor and review periodically]

Segmentation Traps

  • “Flat but firewalled at the perimeter” is not enough.
  • VLANs help organize traffic but do not replace policy enforcement.
  • Remote access should not land directly on controllers.
  • Engineering workstations need extra protection because they can change control logic.
  • Historians and reporting servers can become pivot points.
  • Temporary vendor access often becomes permanent if not governed.

Identity, Access, and Privileged Operations

OT access control must balance accountability, safety, and operational continuity.

ControlOT-specific review point
MFAStrongly preferred for remote and privileged access
PAMControls and records privileged sessions
RBACAssigns access by role: operator, engineer, vendor, admin
Least privilegeUsers get only the access needed for their function
Named accountsImprove accountability compared with shared accounts
Break-glass accountsMust be protected, documented, monitored, and tested
Session recordingUseful for vendor and privileged access review
Time-bound accessReduces risk from standing privileges
Account reviewRemoves stale vendor, contractor, and former employee access
Password vaultingHelps protect privileged credentials

Exam Trap: Shared Accounts

Shared accounts are common in older OT environments, but they reduce accountability. If a scenario asks for the best security improvement, prefer named accounts, role-based access, MFA, and logging where operationally feasible.

Vulnerability and Patch Management

OT vulnerability management is risk-based. The goal is not simply to patch fastest; it is to reduce risk without causing unsafe or unplanned disruption.

OT Vulnerability Workflow

  1. Identify affected assets.
  2. Confirm process criticality and exposure.
  3. Check vendor guidance and compatibility.
  4. Test patches or firmware in a lab when possible.
  5. Schedule maintenance windows.
  6. Apply compensating controls if patching must wait.
  7. Monitor for exploitation.
  8. Document risk acceptance if required.
  9. Validate operation after the change.

Risk Factors to Combine

FactorWhy it matters
ExploitabilityIs there a working exploit or active exploitation?
ExposureIs the asset reachable from untrusted networks?
Process criticalityWould compromise affect safety or production?
Compensating controlsSegmentation may reduce immediate risk
Vendor supportUnsupported patches can break systems
Maintenance windowDetermines feasible remediation timing
Asset roleEngineering workstations and historians may be high-value pivots
Recovery capabilityBackups and spares affect response options

Vulnerability Management Traps

MistakeBetter approach
“Patch immediately” for all OT devicesUse tested, scheduled, risk-based patching
Ignoring vulnerable assets because they are internalAssess lateral movement and insider risk
Using only CVSSAdd exposure, exploitability, and process impact
Scanning production with default toolsUse passive discovery or approved safe scans
Applying vendor firmware without validationTest and coordinate with operations
Forgetting compensating controlsUse isolation, ACLs, monitoring, and virtual patching

Monitoring, Detection, and Logging

OT monitoring should detect abnormal behavior while preserving availability.

High-Value Data Sources

SourceWhat it can reveal
Passive network sensorsNew devices, unusual protocols, unexpected commands
Firewall logsBlocked attempts, policy violations, remote access activity
Jump server logsAdministrative sessions and file transfers
HMI logsOperator actions and abnormal access
Engineering workstation logsLogic changes, project downloads, programming activity
Historian logsData collection anomalies and access patterns
Domain/authentication logsCredential attacks and lateral movement
Endpoint logsMalware, unauthorized tools, USB use
Backup logsFailed backups or tampering
Physical access logsCorrelation with cabinet or control room activity

Detection Examples

ObservationPossible concern
PLC programming outside maintenance windowUnauthorized logic change
New device communicating with controllersRogue device or undocumented vendor access
HMI connecting to InternetMisconfiguration or compromise
Repeated failed logins to jump hostCredential attack
Historian sending unusual outbound trafficData exfiltration or pivot
Broadcast storm or traffic spikeMisconfiguration, loop, DoS, or malware
Controller mode changePotential process impact
Disabled security agentEvasion or unauthorized change
Time drift across systemsLogging/forensics problem or time-source issue

Monitoring Trap

Do not treat every anomaly as an immediate reason to block traffic. In OT, blocking the wrong flow can disrupt operations. The better answer is usually to validate with operations, check the baseline, assess safety impact, then contain carefully.

Incident Response in OT Environments

OT incident response must be planned with operations and engineering teams before an incident occurs.

OT Incident Priorities

  1. Protect life and safety.
  2. Stabilize the physical process.
  3. Preserve visibility and control.
  4. Contain the cyber incident.
  5. Preserve evidence where feasible.
  6. Recover using validated configurations.
  7. Review lessons learned and improve controls.

OT Incident Response Table

PhaseHigh-yield actions
PreparationPlaybooks, contacts, backups, spares, tabletop exercises, vendor procedures
DetectionCorrelate cyber alerts with process anomalies
AnalysisDetermine affected assets, process impact, and attack path
ContainmentSegment carefully; avoid unsafe shutdowns
EradicationRemove malware, close access paths, reset credentials
RecoveryRestore from known-good backups; validate logic and process state
Lessons learnedUpdate baselines, rules, diagrams, training, and controls

Common Incident Mistakes

  • Rebooting controllers without understanding process impact.
  • Disconnecting systems without preserving operator visibility.
  • Letting IT responders act without operations coordination.
  • Assuming ransomware only affects business systems.
  • Forgetting to verify PLC logic and firmware integrity.
  • Restoring from backups that were never tested.
  • Ignoring vendor remote access as an entry path.
  • Failing to preserve logs from jump servers, firewalls, and engineering workstations.

Ransomware and Malware Resilience

Ransomware scenarios are high-yield because they test segmentation, backup, identity, and recovery decisions.

Strong Ransomware Controls

ControlWhy it matters
Network segmentationLimits spread from IT into OT
MFAReduces credential-based access
Offline or immutable backupsPrevents attackers from encrypting backups
Tested restorationConfirms recovery is realistic
Application allowlistingHelps control what can run on OT endpoints
Email and web controlsReduces initial infection risk
EDR where compatibleImproves detection on supported systems
Least privilegeLimits damage from compromised accounts
Disable unnecessary servicesReduces attack surface
Incident playbooksSpeeds safe response

Backup Review Points

Backups should include more than ordinary files:

  • PLC logic
  • HMI configurations
  • Engineering workstation projects
  • Historian configurations
  • Firewall and switch configurations
  • Server images where appropriate
  • License keys and vendor installation media
  • Golden images for supported endpoints
  • Documentation for restore order and dependencies

Supply Chain, Vendor, and Third-Party Risk

OT environments often depend on vendors for maintenance, firmware, proprietary tools, and remote support.

RiskControl
Persistent vendor VPNTime-bound access with approval and MFA
Shared vendor credentialsNamed accounts and session logging
Unverified firmwareVendor validation, integrity checks, change control
Contractor laptop connects to OTControlled access, scanning, jump host, no direct access
Remote support toolsApproved tools only, monitored sessions
Poor asset ownershipContracts and procedures defining responsibilities
Untracked changesFormal change management and configuration records
Unsupported devicesRisk register, compensating controls, lifecycle planning

Vendor Access Trap

The easiest operational answer is often “let the vendor connect directly.” The safer exam answer is controlled vendor access through approved channels, with least privilege, MFA, logging, time limits, and operations approval.

Physical and Environmental Security

OT security is not only network security. Physical access to cabinets, ports, controllers, sensors, and engineering stations can create cyber and safety risk.

AreaReview focus
Control roomsBadge access, visitor control, locked consoles
CabinetsLocks, tamper evidence, port security
Field devicesProtection from tampering and environmental damage
USB portsRemovable media control and scanning stations
Network closetsSwitch access, spare port control, cable management
Remote sitesPhysical inspections, cameras, alarms, secure enclosures
Power and HVACAvailability and environmental reliability
Safety systemsExtra change control and strict access

Secure Configuration and Hardening

Hardening in OT should be tested and coordinated. A technically “secure” setting can cause downtime if it breaks vendor support or process communication.

High-Yield Hardening Areas

AreaExamples
ServicesDisable unused services, ports, and protocols
AccountsRemove default accounts, enforce least privilege
PasswordsChange defaults, vault privileged credentials
Remote accessDisable unauthorized tools, require MFA
Host firewallRestrict inbound/outbound traffic
Application controlAllow approved software only
LoggingEnable useful audit trails
Time syncCentralized, reliable time source
Removable mediaControl, scan, and log use
Configuration backupsStore known-good versions securely

Hardening Trap

Do not harden production OT by applying generic server baselines without testing. Use vendor-supported baselines, lab validation, change control, and rollback plans.

Cloud, IIoT, and Edge Connectivity

Modern OT environments may send operational data to cloud platforms, analytics systems, or remote monitoring services. These connections increase value and risk.

AreaKey review point
Edge gatewayHarden, patch, monitor, and restrict access
Cloud identityUse least privilege and strong authentication
CertificatesManage lifecycle and protect private keys
APIsAuthenticate, authorize, log, and rate-limit
MQTT brokerSecure topics, credentials, and TLS
Data flowSend only required data to approved destinations
Egress filteringPrevent arbitrary outbound connections
Device onboardingVerify identity before trust
Remote managementUse approved tools and logging
Data classificationUnderstand operational sensitivity

Cloud/IIoT Trap

Do not assume outbound-only traffic is automatically safe. Malware and compromised devices often use outbound channels. Control destinations, authenticate systems, inspect where feasible, and monitor behavior.

Governance, Risk, and Documentation

Governance questions usually ask who approves decisions, how risk is documented, and how controls are sustained.

Useful Governance Artifacts

ArtifactPurpose
Network diagramsShow zones, conduits, and dependencies
Asset inventorySupports risk, patching, and response
Risk registerTracks accepted and mitigated risks
Change recordsProve what changed, when, and why
Access reviewsRemove stale or excessive access
Incident playbooksGuide coordinated response
Backup and recovery plansSupport restoration
Vendor access proceduresControl third-party risk
Maintenance schedulesAlign security work with operations
Training recordsShow staff readiness

Framework Awareness

Candidates should recognize that OT security programs often reference industry frameworks and guidance, such as NIST Cybersecurity Framework concepts, NIST SP 800-82-style ICS guidance, and IEC 62443-style zone/conduit thinking. For exam scenarios, focus less on memorizing framework labels and more on applying the control logic correctly.

Common SOT-001 Candidate Traps

TrapWhy it is wrongBetter thinking
Applying IT playbooks directly to OTCan disrupt physical processesAdapt response to safety and operations
Patching first in every scenarioPatches may break control systemsTest, schedule, and use compensating controls
Active scanning production networksMay crash fragile devicesPrefer passive discovery or approved scans
Treating confidentiality as always highestOT often prioritizes safety and availabilityMatch control to process risk
Ignoring engineering workstationsThey can alter controller logicHarden, monitor, and restrict access
Trusting internal networksFlat OT networks are riskySegment and monitor east-west traffic
Leaving vendor VPN always onPersistent access increases attack surfaceTime-bound, MFA-protected, logged access
Assuming backups are goodUntested backups may failTest restores and protect backups
Using shared admin accountsNo accountabilityNamed accounts, PAM, session recording
Blocking traffic without analysisCould stop productionValidate with baseline and operations
Forgetting physical accessLocal access can bypass network controlsSecure cabinets, ports, and control rooms
Overlooking time syncLogs become hard to correlateMaintain reliable time synchronization
Monitoring only IT logsOT-specific events are missedInclude PLC/HMI/jump/industrial network data
Assuming VLAN equals segmentationVLANs are not policy by themselvesEnforce rules with firewalls/ACLs
Ignoring cloud egressOutbound paths can be abusedAllowlist, authenticate, monitor

Quick Scenario Practice Patterns

Use these patterns when working through original practice questions.

Scenario 1: Unknown Devices on OT Network

Best reasoning:

  1. Do not immediately scan aggressively.
  2. Check passive monitoring, switch MAC tables, and network diagrams.
  3. Identify owner, location, and communication flows.
  4. Validate with operations.
  5. Quarantine or restrict only after assessing process impact.
  6. Update inventory and monitoring rules.

Scenario 2: Critical PLC Vulnerability Announced

Best reasoning:

  1. Identify affected PLCs and exposure.
  2. Review vendor guidance.
  3. Determine process criticality.
  4. Test patch or firmware where possible.
  5. Apply segmentation or firewall restrictions immediately if needed.
  6. Schedule maintenance window.
  7. Monitor for exploit indicators.
  8. Document residual risk.

Scenario 3: Vendor Needs Emergency Access

Best reasoning:

  1. Confirm business and operational need.
  2. Use approved remote access path.
  3. Require MFA and named account.
  4. Limit access to required systems.
  5. Record or log session.
  6. Set expiration time.
  7. Review changes afterward.

Scenario 4: Ransomware in Enterprise IT

Best reasoning:

  1. Assume possible OT risk until validated.
  2. Block unnecessary IT/OT paths.
  3. Confirm OT backups and monitoring.
  4. Review domain trust and shared credentials.
  5. Increase monitoring of jump hosts, historians, and remote access.
  6. Coordinate with operations before isolation decisions.

Scenario 5: Suspicious PLC Logic Change

Best reasoning:

  1. Involve operations and engineering immediately.
  2. Assess safety and process impact.
  3. Preserve logs and project files.
  4. Compare logic to known-good backup.
  5. Identify account and access path used.
  6. Contain compromised credentials or workstation.
  7. Restore validated logic if required.

Fast Review Tables

Best Control by Goal

GoalStrong candidate answer
Reduce IT/OT pivotingOT DMZ and strict conduits
Secure vendor accessMFA, PAM, time-bound access, logging
Discover assets safelyPassive monitoring and documentation review
Protect unsupported systemsIsolation and compensating controls
Detect abnormal control trafficIndustrial protocol-aware monitoring
Recover from ransomwareOffline/immutable tested backups
Control PLC logic changesEngineering workstation security and change management
Prevent rogue devicesPhysical security, port control, NAC where feasible
Improve accountabilityNamed accounts and session logs
Reduce cloud connection riskEgress allowlisting and strong device identity

“Best First Step” Clues

If the question says…Think…
Production line is runningSafety and operations coordination first
Legacy PLCs are unstableAvoid intrusive scanning or unsupported agents
Vendor must troubleshoot remotelyControlled, logged, time-limited access
No accurate inventory existsBuild passive inventory and baseline
Flat OT networkSegment into zones and conduits
Patch unavailableCompensating controls and monitoring
Unknown traffic appearsCompare to baseline and validate owner
Ransomware detected in ITProtect IT/OT boundary immediately
Operator lost viewPrioritize visibility and safe process state
Controller behavior changedValidate logic/configuration integrity

How to Use This Quick Review With a Question Bank

For efficient SOT-001 preparation:

  1. Review the tables above for 20–30 minutes.
  2. Start with topic drills on OT architecture, asset inventory, segmentation, and incident response.
  3. After each missed question, write down the decision rule you missed.
  4. Use original practice questions to force scenario-based judgment, not memorization.
  5. Move to mixed sets only after your weak topics are improving.
  6. Use detailed explanations to compare your reasoning with the safest operational answer.
  7. Finish with timed mock exams to practice pacing and decision confidence.

Final Readiness Checklist

Before you sit for CompTIA SecOT+ V1 (SOT-001), confirm that you can explain:

  • Why OT security prioritizes safety, availability, and process integrity.
  • How the Purdue model supports segmentation decisions.
  • Why passive discovery is often preferred in production OT.
  • How to secure vendor remote access.
  • How to handle vulnerabilities when immediate patching is unsafe.
  • What makes engineering workstations high-value targets.
  • How an OT DMZ reduces IT/OT pivot risk.
  • What data sources support OT detection and response.
  • How ransomware can affect OT even if it starts in IT.
  • Why tested backups must include configurations and control logic.
  • How to coordinate incident response with operations and engineering.
  • Why compensating controls are central to legacy OT security.

Practical Next Step

Use this Quick Review as your final refresher, then move into IT Mastery practice: start with targeted topic drills, review the detailed explanations for every miss, and build up to full mixed question bank sessions before attempting mock exams.

Continue in IT Mastery

Use this Quick Review as a final concept map, then move into IT Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original IT Mastery practice items; they are not official CompTIA questions, copied live-exam content, or exam dumps.

Browse Certification Practice Tests by Exam Family