CompTIA SecOT + SOT-001 (V1) Exam Practice Test 2

A program mode allows uploading changes to a PLC's logic, which is necessary for legitimate maintenance and updates but also represents a higher-risk state if accessed by an unauthorized party, since it permits altering how the physical process is actually controlled. A run mode instead restricts the PLC to executing its existing program without allowing modification, providing a more restrictive and generally safer default operating state for normal production. Managing which mode a PLC is actually in, and restricting who can switch it into program mode, is an important OT-specific hardware security control that has no direct equivalent in typical IT systems.

A historian archives time-stamped historical process values, such as temperature and pressure readings, over time, and reviewing this historian data during an incident investigation can reveal exactly when and how a process began deviating from its normal baseline. This data source is particularly valuable in OT incident investigations because it provides direct insight into the physical process itself, which general IT-style logs alone would not capture. Correlating historian data against network and host logs from the same time period can help investigators build a much fuller picture of how a cyber incident actually translated into physical process impact.

A tabletop exercise is a discussion-based activity where participants talk through their response to a simulated scenario without taking any real technical action on live systems, making it a lower-cost, lower-risk way to test and improve incident response plans and communication compared to a full live simulation. A purple-team exercise instead typically involves active, coordinated offensive and defensive technical activity, which is a different and more hands-on preparedness approach than a purely discussion-based tabletop. Regularly conducting tabletop exercises helps surface gaps in a response plan, such as unclear ownership or missing contact information, well before those gaps could cause delay during an actual incident.

An incident response retainer is a pre-arranged contract with an external firm to provide expert incident response support on short notice, ensuring specialized help is available quickly rather than needing to be sourced and contracted only after an incident has already begun. Mutual aid instead typically refers to informal or formal arrangements with peer organizations, such as through an ISAC, rather than a paid, contracted vendor retainer specifically. Establishing an IRR in advance is a common OT incident preparedness practice, since specialized OT incident response expertise can be scarce and slow to source if an organization only begins looking once an incident is already underway.

ICS4ICS adapts the broader Incident Command System, originally developed for emergency services, specifically for industrial control system environments, providing a structured command hierarchy suited to large-scale, potentially multi-agency OT incident response efforts. The PICERL model instead structures the phases of incident response itself, which is a complementary but distinct framework from ICS4ICS's command and coordination structure. Adopting a structured command framework like ICS4ICS becomes especially valuable during a large incident requiring coordination across many internal teams and potentially external emergency responders.

Mapping software inventory to the broader asset inventory connects exactly which software versions run on each specific device, rather than leaving hardware and software tracked as two disconnected lists that must be manually cross-referenced. This connected view is essential for efficient vulnerability management, since knowing a vulnerability affects a particular software version is only actionable once it can be quickly matched against which specific devices actually run that version. A collection management framework instead addresses how threat intelligence collection priorities are organized, which is a related but distinct concept from mapping software to hardware asset records.

Security validation, or posture checks, confirm a device meets defined security requirements, such as current antivirus and full patching, before it is allowed to connect to the network, which helps prevent an inadequately secured device from introducing risk into the OT environment. Sanitization instead refers to securely wiping data from media, and a write blocker prevents data from being written to forensic evidence during an investigation, both of which are different practices from a pre-connection posture check. Applying posture checks specifically to third-party devices, which the organization does not directly control or manage, is an important control given how much less visibility an organization typically has into an externally owned device's security state.

Exploitability reflects how easily a vulnerability can actually be exploited in practice, which is a key factor distinguishing the easily exploitable vulnerability from the difficult-to-exploit one in this comparison. Exposure reflects how reachable or exposed the affected device actually is, which is why the internet-facing device represents a meaningfully different risk than the isolated, air-gapped device even if the underlying vulnerabilities were otherwise similar in severity. Weighing both factors together, rather than looking at either one alone, produces a more realistic prioritization than assuming every vulnerability with a high severity score deserves equally urgent remediation regardless of actual exploitability and exposure.

Internal stakeholder coordination addresses exactly this kind of cross-functional planning, including scheduling planned downtime and confirming spare availability, which is essential in OT environments where patching a critical control system carries operational and safety implications that a similar IT patch typically would not. This differs from version management, which instead tracks which software versions are deployed, rather than coordinating the human and operational logistics of actually applying a remediation. Skipping this coordination step risks a remediation attempt that technically succeeds but causes unplanned downtime or leaves the team without a spare if something goes wrong during the change.

A SIEM centralizes log correlation and alerting across many sources, providing the detection and visibility layer that identifies suspicious activity worth investigating. A SOAR platform instead automates the response workflow once an alert is triggered, such as automatically isolating a host or blocking an indicator, extending beyond detection into orchestrated action. These two tools are complementary and are often deployed together, with the SIEM handling detection and correlation while the SOAR platform handles automating the resulting response actions.

Mapping asset attributes into a centralized configuration management database supports broader visibility and impact analysis, since the CMDB can then show not just a device's own attributes but its relationships to other systems, supporting better-informed change management and incident response decisions. This differs from simply maintaining a standalone device list, since the CMDB's relationship mapping provides valuable context that a flat inventory alone would not. Investing in this kind of CMDB integration pays off especially during incident response, when quickly understanding what else a compromised device connects to can significantly speed up containment decisions.

A jump box, or bastion host, serves as a single, tightly monitored intermediary that administrators must pass through before reaching OT devices, rather than connecting directly from their own workstations, which centralizes logging and access control onto one well-secured chokepoint. SSO instead simplifies authentication across multiple applications but does not itself provide this kind of intermediary access chokepoint. Requiring all OT administrative access to route through a jump box significantly reduces the OT environment's direct exposure to potentially compromised administrator workstations.

ABAC grants or denies access based on a combination of attributes, such as role, time of day, and device, providing more flexible and context-aware access decisions than a role-based model relying on a single fixed role assignment alone. Role-based access control instead grants access purely based on an assigned role, without factoring in additional contextual attributes the way ABAC does. Mandatory access control instead enforces access based on fixed security labels and clearance levels, which is a different model still from the multi-attribute flexibility ABAC provides.

Convergence of IT and OT describes the increasing connection between previously separate industrial control systems and corporate IT networks, often driven by the business value of remote monitoring, analytics, and centralized management. This convergence brings real operational benefits but also introduces IT-style cybersecurity risks into environments that were historically isolated and never designed with those threats in mind. Understanding this convergence trend is foundational to why OT cybersecurity has become such a critical and distinct discipline from traditional IT security.

Room and cabinet security, including cable security, protects network switches, patch panels, and cabling from unauthorized physical tampering by combining physical enclosure locks with restricted room access. Bollards instead are physical barriers designed to prevent vehicle intrusion, and surveillance alone provides monitoring rather than the physical enclosure and access restriction this scenario describes. Protecting distribution frames and cabling specifically matters because physical tampering with these components could allow an attacker to intercept or disrupt network traffic without needing to compromise any device directly.

Deterministic behavior ensures that a given input always produces the exact same, predictable output every time, which is a critical property for safety-related control systems where unpredictable variation in response could have serious physical consequences. Observability instead concerns how easily a system's internal state can be monitored and understood from the outside, which is a related but distinct architectural concern from guaranteeing predictable output behavior. Prioritizing deterministic behavior in OT architecture design reflects the fundamentally different risk profile of control systems compared to typical IT systems, where some variability in response timing is often acceptable.

Hacktivists carry out cyberattacks specifically to advance a political or social cause, distinguishing their motivation from cybercriminals seeking financial gain or nation-state actors conducting espionage. This distinct motivation can shape which targets a hacktivist group chooses and how they publicize an attack, often seeking visibility for their cause rather than covertly maintaining long-term access. Understanding a threat actor's likely motivation helps inform which types of OT targets and attack patterns a security team should be most vigilant about defending against.

The Colonial Pipeline incident is a well-known example of an indirect impact event, where a ransomware attack against corporate IT systems led the organization to proactively shut down pipeline operations as a precaution, even though the OT systems were not themselves directly compromised. This differs from a direct impact event like Stuxnet, where the attack specifically targeted and directly damaged OT equipment itself. Indirect impact events illustrate that OT operations can be significantly disrupted even when an attack never actually touches the OT environment directly, simply because of the operational and safety precautions a compromised IT environment forces an organization to take.

OSINT gathers information from publicly available sources, such as news articles, social media, and public forums, without requiring access to restricted or classified systems, making it broadly accessible compared to more specialized intelligence types. Signals intelligence instead involves intercepting electronic communications or signals, which requires specialized technical collection capability rather than simply reviewing publicly available information. OSINT is often a valuable and cost-effective starting point for threat intelligence gathering, since a surprising amount of useful information about potential adversaries and their tactics is genuinely available through public sources.

Residual risk is the risk that remains after controls have been applied, reflecting the reality that most controls reduce risk rather than eliminate it entirely, especially in OT environments where full remediation is often constrained by safety certification or vendor support limitations. Inherited risk instead refers to risk an organization takes on from an external source, such as a vendor or supply chain partner, which is a different concept from the residual risk left over after applying the organization's own controls. Explicitly tracking and accepting residual risk, rather than assuming a control fully eliminates a vulnerability, supports more honest and accurate risk reporting to leadership.

Penetration testing actively attempts to breach a network using realistic attacker techniques, generally with the goal of identifying exploitable vulnerabilities across the environment broadly. Adversarial emulation instead specifically emulates the known tactics, techniques, and procedures of a particular threat group, testing whether the organization's detection and response capabilities would actually catch that specific type of adversary. Both methods provide valuable, though different, insight: penetration testing broadly identifies exploitable weaknesses, while adversarial emulation tests readiness against a specific, realistic threat profile.

Cybersecurity documentation spans a hierarchy from high-level policies down to detailed standard operating procedures, with processes and standards typically occupying the middle ground between broad policy direction and specific step-by-step task instructions. A risk registry instead tracks specific identified risks, and a road map outlines planned future program improvements, both of which are distinct program management elements from the documentation hierarchy itself. Maintaining this full hierarchy, rather than jumping straight from policy to individual task execution, ensures there is a clear, traceable path from high-level intent down to specific operational practice.

Business continuity planning focuses on how critical operational functions will continue during a disruption, which is a broader operational concern than technical system restoration alone. Disaster recovery instead focuses more specifically on the technical steps needed to restore systems after a disaster has already occurred, which is a narrower, more technically focused subset of the broader continuity planning effort. Both are explicitly recognized governance considerations under operational and business objectives, working together to ensure an organization can both keep functioning during a crisis and technically recover afterward.

An RTOS, or real-time operating system, guarantees that critical tasks complete within strict, predictable time constraints, which is essential for control system devices where a delayed response to a safety-critical condition could have serious physical consequences. This differs from a commodity or general-purpose operating system, which does not provide the same deterministic timing guarantees and is therefore poorly suited to safety-critical real-time control tasks. Recognizing which legacy or modern devices in an OT environment rely on an RTOS helps inform both patching considerations and how much timing-related risk a given change might introduce.

Ladder logic is a graphical control logic notation that resembles electrical relay circuits, with rungs representing the logical conditions that must be satisfied for a given output to activate, making it intuitive for engineers with an electrical background. Structured text instead uses a more traditional text-based programming syntax, and sequential function blocks organize logic into sequential steps and transitions, both of which are alternative control logic formats to ladder logic's relay-inspired visual style. Recognizing which control logic format a given PLC program uses is important context for anyone reviewing or troubleshooting that program's actual behavior.