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

Designing a backup strategy plans exactly how and how often a critical device's configuration will be backed up and where those backups will be securely stored, providing a foundation for recovery if the device's configuration is ever lost, corrupted, or maliciously altered. This is distinct from updating firmware, which instead addresses keeping the device's software current, though both activities support overall device resilience in different ways. Having a well-designed, tested backup strategy specifically for critical PLC configurations can dramatically reduce recovery time if a device configuration is ever compromised or accidentally corrupted.

A hot swap replaces a compromised field device with an identical, already-configured and validated spare unit, minimizing downtime compared to rebuilding the original compromised device from scratch during recovery. This technique depends entirely on having genuinely ready, validated spare units available in advance, which is exactly why spare availability is such an important consideration during earlier vulnerability remediation and incident preparedness planning. Having a hot swap option available can dramatically reduce recovery time for a critical field device, compared to the potentially lengthy process of forensically cleaning and re-validating the original compromised hardware before returning it to service.

A purple-team exercise brings offensive and defensive personnel together in real time, with immediate sharing of insights as the offensive side attempts techniques and the defensive side tries to detect and respond, maximizing the learning value compared to a purely offensive test followed by a separate after-the-fact report. A tabletop exercise instead is discussion-based, without any live, real-time technical activity on actual systems, making it a lower-intensity but also lower-fidelity preparedness activity compared to a purple-team exercise. Choosing a purple-team exercise over a standard penetration test reflects a deliberate choice to prioritize immediate collaborative learning over simply identifying vulnerabilities in isolation.

Escalation and notification, specifically external notification to regulators, addresses the legally required reporting of a significant incident to government regulatory bodies within a specific timeframe, which is a distinct obligation from internal escalation within the organization's own chain of command. Mutual aid instead describes receiving assistance from peer organizations, which is a different kind of external relationship from a legally mandated regulatory reporting obligation. Understanding exactly which incidents trigger a regulatory notification requirement, and within what timeframe, is essential compliance knowledge for any OT incident response program operating in a regulated sector.

Containment decisions in OT environments carry physical safety implications that typically do not apply the same way in pure IT incident response, since isolating or disconnecting a device in a physical process could itself trigger a dangerous condition rather than simply cutting off network access. This is exactly why OT incident responders must coordinate closely with operations and safety personnel before taking a containment action that might seem straightforward from a purely IT security perspective. Recognizing this OT-specific nuance during the containment phase, rather than applying generic IT containment playbooks unchanged, is essential to avoid a well-intentioned security action causing a physical safety incident.

Combining automated scanning, manual physical walkthroughs, and passive traffic monitoring reflects a more comprehensive discovery approach, since each individual method has different strengths and blind spots, such as passive monitoring missing devices that never generate observable traffic, or manual walkthroughs missing devices hidden in less obvious locations. Relying on only one discovery method risks systematically missing an entire category of devices that method is simply not well suited to finding. This combined approach still requires ongoing validation and maintenance afterward, since even a thorough initial discovery effort will not stay accurate indefinitely as the environment continues to change.

Geolocation monitors where remote connections are actually originating from geographically, flagging connections from unexpected or high-risk locations for further review, which adds a valuable contextual layer beyond simply verifying that a connection's credentials are technically valid. This is a distinct consideration from whether a connection is persistent or temporary, which instead addresses connection duration and pattern rather than geographic origin. Combining geolocation monitoring with other external connection security measures provides a more complete picture of whether a given remote access attempt looks legitimate or suspicious.

External vulnerability identification comes from outside sources, such as a vendor's public disclosure, providing awareness of vulnerabilities the organization did not have to discover on its own. Internal vulnerability identification instead comes from the organization's own testing and assessment efforts, which can surface vulnerabilities that have not yet been publicly disclosed anywhere, sometimes referred to as zero-day findings from the organization's own perspective. Relying on only one of these two sources, rather than both together, leaves a vulnerability management program with an incomplete picture of the organization's actual exposure.

The remediation timeline specifically addresses when a patch or fix will actually be applied, balancing the vulnerability's urgency against planned production schedules and other operational constraints, which is a distinct coordination element from confirming spare parts or backup availability. Spare and backup availability instead address whether replacement components or recovery data would be ready if something goes wrong during the change, which is a related but separate consideration from simply agreeing on timing. Establishing a clear, jointly agreed remediation timeline helps prevent the common friction between security urgency and operational scheduling constraints from stalling a needed fix indefinitely.

Network and boundary data includes sources like packet captures, firewall logs, and switch logs collected at network boundaries, providing visibility into traffic crossing between network segments or entering and leaving the environment. This differs from host and security data, which instead focuses on data generated by individual endpoints, such as authentication logs or EDR alerts, rather than network-level traffic and boundary device logs. Recognizing which data category a given log source falls into helps an analyst know where to look first depending on whether an investigation concerns network-level activity or specific host behavior.

After discovery identifies a device, creation establishes its initial record in the asset inventory, capturing the key attributes known at that time. Validation and maintenance then periodically confirm the recorded information remains accurate and update it whenever something changes, since an asset inventory that is created once and never revisited quickly becomes stale and unreliable as devices are reconfigured, replaced, or repurposed over time. Treating asset inventory as an ongoing lifecycle, rather than a one-time project, is essential for maintaining an inventory that security operations can actually trust and rely on.

An OT-aware IPS/IDS is specifically designed to understand industrial protocols like Modbus and DNP3, allowing it to detect anomalous or malicious activity within the actual industrial protocol traffic itself, rather than only recognizing generic IT-style network patterns that a standard IT-focused tool would be limited to. A generic IT firewall or standard antivirus product typically lacks this specialized protocol awareness, meaning it might completely miss a malicious command embedded within legitimate-looking industrial protocol traffic. Deploying genuinely OT-aware monitoring tools, rather than assuming generic IT security tools provide adequate visibility, is an essential architectural decision for effective OT network security.

Code signing and verification checks a cryptographic signature before allowing software to execute, confirming the code has not been tampered with since it was signed by a trusted source. Mandatory access control instead enforces access based on fixed security labels and classification levels, which even an administrator cannot casually override, providing a stricter and more rigid access model than discretionary or role-based approaches. Both practices provide strong integrity and access assurances, but they address different concerns: one verifies software has not been altered, and the other strictly enforces who can access what regardless of administrative convenience.

SCADA systems are specifically suited to monitoring and controlling remote field equipment across widely distributed geographic sites, such as a pipeline spanning hundreds of miles, communicating back to a central control room over long-distance communication links. A DCS instead is typically used within a single, tightly clustered facility, such as a refinery or chemical plant, where the controlled processes are physically close together rather than geographically dispersed. Recognizing which control system architecture fits a given operational context helps explain why different industries and use cases often standardize on different control system types.

Bollards are sturdy vertical posts specifically designed to prevent vehicle intrusion, protecting critical infrastructure like a substation from a vehicle ramming attack that could cause significant physical damage to sensitive equipment. Turnstiles instead control pedestrian foot traffic through a specific point, which is a completely different physical security concern from stopping a vehicle-based threat. Recognizing that physical security controls must address different threat types, from unauthorized pedestrian entry to vehicle ramming, helps ensure a facility's physical security design does not have gaps simply because one type of threat was overlooked.

Recoverability specifically addresses how quickly and reliably a system can be restored to normal operation after a failure, within a defined, acceptable timeframe, which is a distinct resilience characteristic from redundancy, which instead addresses having duplicate components ready to take over rather than needing restoration in the first place. Endurance instead addresses how long a system can continue operating under degraded conditions, which is again a related but distinct resilience characteristic. Designing explicitly for recoverability, rather than only for redundancy or endurance, ensures a realistic and tested restoration plan exists for scenarios where a failure does actually occur despite other resilience measures.

Indicators of compromise encompass a broad range of observable artifacts, including file hashes, malicious IP addresses, and suspicious domain names, that can be used to detect the presence of a known threat or campaign within an environment. Effectively operationalizing IOCs requires integrating them into detection tools like a SIEM or IDS, so that a match against a known-bad hash or domain actually triggers an alert rather than simply sitting unused in a threat intelligence platform. Recognizing the range of IOC types, beyond just file hashes, helps a security team build more comprehensive detection coverage against a given known threat.

TRISIS specifically targeted a safety instrumented system, attempting to disable the safety functions that would have otherwise prevented a catastrophic physical event, representing one of the most alarming direct-impact OT incidents specifically because it targeted safety systems themselves rather than only production control systems. Maersk and SolarWinds instead are commonly cited indirect-impact events, where broader IT compromise caused operational disruption without specifically targeting safety instrumented systems the way TRISIS did. TRISIS is frequently cited as a landmark event precisely because it demonstrated adversary intent and capability to specifically target the safety layer, not just production control, in an industrial environment.

Measurement and signature intelligence identifies devices or activities based on distinctive technical characteristics, such as unique electromagnetic emissions or physical signatures, rather than intercepting the content of communications the way signals intelligence does. Human intelligence instead relies on information gathered through interpersonal sources, which is a fundamentally different collection method from analyzing technical emissions or signatures. Recognizing measurement and signature intelligence as a distinct intelligence type highlights how varied threat intelligence collection methods can be, extending well beyond simply monitoring network traffic or public information.

Internal auditing is conducted by an organization's own internal team, reviewing compliance with the organization's own policies using people who already understand the internal environment well. External auditing instead is conducted by an independent outside firm, providing an objective, third-party assessment that is often specifically required to satisfy regulatory or contractual obligations. Both audit types provide valuable oversight, but they serve different purposes: internal audits support ongoing internal compliance monitoring, while external audits provide independent assurance to outside parties like regulators.

Supply chain risk applies to hardware vendors, since a compromised vendor could introduce risk through tampered or vulnerable physical components before a device ever reaches the customer's environment. Supply chain risk equally applies to software vendors, since a compromised vendor could introduce risk through malicious or vulnerable code embedded in software or delivered through a seemingly routine update, as several historical indirect-impact incidents have demonstrated. Assuming supply chain risk ends once a product has been purchased and deployed overlooks the ongoing risk that future updates or vendor-provided services could still introduce, which is why this remains an ongoing risk management concern rather than a one-time evaluation.

A maturity assessment evaluates a program's current capabilities against a defined maturity model, typically describing progressive levels of sophistication a program can achieve over time. A benchmark instead compares an organization's specific practices against industry peers, providing external, comparative context rather than measuring against an abstract maturity scale. Both provide valuable but different perspectives, one measuring progress against a defined internal standard, and the other measuring standing relative to how comparable organizations are actually performing.

Legal requirements represent a governance driver where specific controls are mandated by law or regulation for a given industry sector, independent of whether an organization's own internal risk assessment would have identified that exact same requirement on its own. This differs from reliability or business safety drivers, which instead stem from the organization's own operational and safety priorities rather than an externally imposed legal mandate. Recognizing legal requirements as a distinct governance driver helps explain why an organization might implement a specific control even if its own risk assessment alone would not have prioritized it as highly.

A hypervisor is the software layer specifically responsible for creating and running virtual machines on a single physical server, allowing modern OT environments to consolidate what might once have required many separate physical servers onto fewer, more efficiently utilized machines. This virtualization trend, including virtual PLCs and virtualized switching, represents a significant shift from the traditional legacy, hardware-per-function approach common in older OT environments. Understanding hypervisor-based virtualization is increasingly important for OT security, since a compromised hypervisor could potentially affect every virtual machine running on top of it simultaneously.

The process variable is the actual measured value the control system continuously monitors, such as the current temperature, while the set point is the desired target value the system is trying to achieve or maintain. The control loop continuously compares the process variable against the set point, adjusting an output like a heating element to minimize the difference between the two. Understanding this fundamental relationship between process variable and set point is foundational to understanding how virtually any basic control loop actually functions.