SSCP practice questions with explanations: a free 60-item practice test weighted to the 2025 outline

Selecting a technically-sound remediation that violates reporting or preservation requirements, such as altering logs during an active audit, constitutes evidence destruction. While the script performs standard cleanup, running it during an audit conflicts with governance.

1. AChange approval may be an issue, but the bigger problem is that records under audit were wiped.
2. BDisk I/O is a minor operational effect, not a governance or evidence concern.
3. CCorrect: overwriting security logs and removing quarantined samples during an active audit destroys evidence that must be preserved.
4. DWhether the script was approved matters less than what it did: it erased records that had to be kept.

More below: why each option is right or wrong — scroll this panel

In a System Security Plan (SSP), controls must be declared with accurate status labels. When a control is deployed to some but not all required assets (like 80% of workstations), it must be recorded as 'partially implemented' or 'implemented with deficiencies.' It cannot be claimed as fully implemented, nor is it entirely 'not implemented.' The documentation must also include the level of confidence and evidence of the partial state.

1. ANot implemented misstates the 80% already in place; the status should show partial coverage.
2. BClaiming full implementation hides the 20% gap and misleads assessors.
3. CCorrect: the control is partially implemented; the SSP records the gap with evidence, and the gap is tracked to closure.
4. DA rollout in progress does not exempt a control from assessment.

More below: why each option is right or wrong — scroll this panel

Passive network analysis and configuration reviews are ideal for fragile legacy environments. OT and SCADA systems can be disrupted by active scanning, risking severe operational consequences. Passive techniques identify vulnerabilities without disruptive traffic. Active scans, endpoint agents, penetration testing, and intrusive discovery probes are dangerous here, as they generate unexpected traffic or consume excessive resources that can easily crash delicate legacy hardware.

1. AAutomated penetration testing sends active traffic that can crash fragile controllers.
2. BEven credentialed scans send active probes that legacy OT devices may not tolerate.
3. CCorrect: passive traffic analysis and configuration review find weaknesses without sending anything that could disrupt fragile control systems.
4. DAgents on legacy nodes risk instability and are often unsupported by OT vendors.

More below: why each option is right or wrong — scroll this panel

Treatment decisions must choose and document risk responses while mapping required controls to applicable regulations. Because the privacy regulation explicitly mandates encryption at rest, the institution must implement encryption to maintain compliance, overriding other alternative mitigation strategies.

1. ACorrect: when a regulation mandates encryption at rest, mitigation through that control is required; compliance overrides a cost-benefit choice.
2. BDLP at the perimeter may reduce leakage but does not meet an explicit encryption-at-rest mandate.
3. CInsurance can transfer financial loss, but it cannot transfer the legal duty to encrypt.
4. DRisk acceptance is not available when a regulation mandates the control.

More below: why each option is right or wrong — scroll this panel

Not correlating access grants to asset ownership prevents holding parties accountable for unauthorized changes. If IAM systems are unlinked to CMDB ownership records, identifying the business owner responsible for a rogue change becomes impossible.

1. ACorrect: if access grants and change records are not tied to named asset owners, nobody can say which department made or owned the change.
2. BDetection quality does not establish who is accountable for a change.
3. CDirectory use is a design choice; the gap is linking changes to owners.
4. DLog retention matters, but even complete logs need ownership mapping for accountability.

More below: why each option is right or wrong — scroll this panel

To properly inherit controls in a cloud environment, the organization cannot merely assume they are working, nor does it necessarily have to test the vendor's physical boundaries or duplicate the control. Instead, the inheriting entity must verify that the provider demonstrates, through verifiable evidence, that the control is implemented, monitored, and meets the required assurance needs. A generic contract does not provide specific control implementation evidence.

1. ADuplicating the control defeats the point of inheriting it.
2. BAssuming defaults work is exactly what inheritance must not rely on.
3. CA generic SLA does not prove the specific control is implemented.
4. DCorrect: to inherit a provider control you need documented evidence that the provider implements and monitors it.

More below: why each option is right or wrong — scroll this panel

Administrators must classify drifts by severity and business impact. Low-risk drifts follow documented workflows, but high-risk or widespread drifts require escalation to change advisory processes before automated remediation.

1. AQuarantining every drift disrupts operations, even for low-risk changes.
2. BCorrect: triage drifts by business impact and risk, and route high-risk ones through change advisory instead of blanket action.
3. CBlanket reverting may undo changes that were needed or approved.
4. DDrift is a configuration issue; waiting for vendor patches does not address it.

More below: why each option is right or wrong — scroll this panel

Evidence artifacts like vulnerability scans must be systematically maintained for compliance. Indexing them in a dedicated repository allows auditors to quickly locate verifiable proof of control implementation. Informal emails or temporary files fail to support a seamless external assessment.

1. ACorrect: indexing scans in the evidence repository lets assessors find proof of control operation quickly.
2. BDeleting reports destroys the evidence assessors will ask for.
3. CPaper copies spread among engineers are hard to control and not an evidence process.
4. DInformal summaries lack the detail and traceability of the original reports.

More below: why each option is right or wrong — scroll this panel

When dealing with a systemic or recurring issue, such as widespread input validation failures, a Plan of Action and Milestones (POA&M) must document the identified weaknesses, assigned owner, targeted dates, and the root cause. Identifying and documenting the root cause (e.g., lack of developer training or a flawed shared library) ensures that the remediation actions address the core problem rather than just temporarily patching the symptoms.

1. ACrash addresses are debugging detail, not what prevents recurrence across applications.
2. BSource code is not part of a POA&M entry.
3. CCorrect: a systemic failure needs its root cause recorded, such as a missing shared validation library or training, so the fix stops recurrence.
4. DAuditor schedules have nothing to do with fixing the weakness.

More below: why each option is right or wrong — scroll this panel

Organizations must integrate privileged access controls with change management so elevated privileges required to implement a change are logged, approved, and automatically revoked after completion. Linking Privileged Access Management (PAM) workflows to ITIL change tickets ensures access is strictly time-bound to the approved implementation window.

1. AVulnerability scanning does not grant or revoke privileges.
2. BPipeline monitoring watches builds, not administrators' privileged access.
3. CAn annual review is far too slow to remove access after one maintenance window.
4. DCorrect: tying PAM to change tickets grants elevation for the approved window and revokes it automatically when the change closes.

More below: why each option is right or wrong — scroll this panel

Automating event correlation with HR ensures any mismatch (e.g., active accounts for terminated users) is detected.

1. ACorrect: a closed loop reconciles HR terminations against live accounts automatically, so any revocation that failed downstream is detected.
2. BBlocking external federation misses internal and local accounts and does not verify revocation everywhere.
3. CTime-of-day limits restrict when active users log in; they do not remove a leaver's access.
4. DDeleting data breaks retention requirements and still does not prove access was revoked.

More below: why each option is right or wrong — scroll this panel

This staged offboarding prevents immediate unauthorized access while retaining critical account metadata and logs for forensic or audit needs. Deleting the account immediately destroys potential evidence. Changing passwords leaves the account unnecessarily active. Archiving data while purging the directory object removes essential identity context. Indefinite retention violates data minimization and creates directory clutter.

1. APurging the account removes identity records and logs that investigations or legal holds may need.
2. BCorrect: disabling cuts access at once while keeping the account and its audit trail until the retention period ends.
3. CImmediate deletion stops access but destroys evidence and audit linkage.
4. DAn active account with a new password can still be misused; it should be disabled.

More below: why each option is right or wrong — scroll this panel

A common pitfall in modern access control architectures is relying on non-authoritative or stale attribute sources. If the authoritative HR directory terminates an employee, but the local VPN directory synchronization is delayed or stale, the Policy Decision Point will evaluate outdated attributes and incorrectly grant access.

1. ACorrect: if the access decision reads a stale or non-authoritative directory, the leaver still looks active and authenticates.
2. BMissing logs hurt the investigation but do not explain why access succeeded.
3. CRole-over-identity evaluation is vague and would not explain a terminated account still authenticating.
4. DMAC labels are not part of a typical corporate VPN decision, and nothing points to a bypass.

More below: why each option is right or wrong — scroll this panel

Parameterization (merging ABAC with RBAC) resolves conflicts by dynamically restricting access based on attributes (e.g., Department), enforcing boundaries without role proliferation.

1. ADAC hands control to owners, making separation of duties harder to enforce.
2. BCorrect: parameterized roles plus attributes such as department add conditions to fewer roles, removing conflicts without new roles.
3. CMAC is a heavy, rigid model for this problem and a costly replacement.
4. DDepartmental groups decentralize control and make conflicts harder to see.

More below: why each option is right or wrong — scroll this panel

By design, stateless JWTs cannot be natively revoked before expiration because the server does not track them. To enable rapid session termination, the architecture must add a stateful component, such as a token blocklist checked at each request. Increasing key sizes, changing encryption algorithms, securing tokens in cookies, or requiring continuous MFA do not alter the stateless nature of JWTs or allow demand-based revocation.

1. AKey size does not let the server cancel a token already issued.
2. BCorrect: stateless JWTs stay valid until expiry, so a server-side revocation list checked on each request is needed to cut sessions.
3. CSecure cookies protect token transport but cannot invalidate a stolen token.
4. DSignature type does not change the fact that issued tokens cannot be revoked.

More below: why each option is right or wrong — scroll this panel

This KPI measures how quickly an organization revokes access once an employee leaves. Reducing this metric limits lingering insider access. Recording privileged sessions monitors active administrators. Alerts for excessive permissions relate to active users holding unnecessary access. MFA ratios track authentication health. Periodic recertifications are not responsive enough for immediate termination risks.

1. AMFA success rates say nothing about how fast leavers lose access.
2. BSession recording helps investigations but does not measure offboarding.
3. CAlert volume reflects noise as much as risk and does not measure offboarding speed.
4. DCorrect: time-to-deprovision directly measures how long a leaver keeps access, the exposure this control targets.

More below: why each option is right or wrong — scroll this panel

Vendor tests occur in pristine environments. Manual laborers often have worn, calloused, or dirty fingerprints, leading to high False Rejection Rates (FRR). Secondary factors, storage architectures, encryption, and digital certificates affect system access or network connectivity, not the physical biometric template matching process.

1. AEncryption settings do not affect whether a fingerprint matches.
2. BExpired certificates would cause system errors, not higher rejection of some users.
3. CCorrect: lab tests use clean, cooperative subjects; worn or dirty fingerprints of manual workers raise the false rejection rate.
4. DA second factor adds a step but does not explain the higher rejections.

More below: why each option is right or wrong — scroll this panel

Deploying local Policy Decision Points (PDP) near the edge Policy Enforcement Points (PEP) with cached attributes minimizes network latency for distributed networks. The PEP intercepts requests, while the local PDP evaluates attributes quickly. Centralizing either the PDP or PEP introduces significant WAN latency, and routing all edge requests to a central directory degrades performance.

1. APEPs enforce decisions; caching at a single central PEP does not cut latency for remote sites.
2. BA central PDP still makes every remote request travel far for each decision.
3. CSending every request to the central directory maximizes latency and creates a single point of failure.
4. DCorrect: local PDPs with cached attributes beside edge PEPs decide quickly and keep working if the central directory is slow.

More below: why each option is right or wrong — scroll this panel

Argon2id is a memory-hard adaptive Key Derivation Function (KDF) that resists GPU-based offline cracking. Unique per-password salts prevent precomputed attacks. General-purpose hashes like SHA-256 and SHA-512 are fast and vulnerable to GPU acceleration. Optimizing for minimal memory consumption removes protections against parallel GPU cracking. Bcrypt is acceptable for legacy systems but lacks the robust memory-hard properties of Argon2id.

1. ACorrect: Argon2id is memory-hard and tunable, making GPU cracking costly, and unique salts defeat precomputed tables.
2. BSHA-512 is fast by design, which helps GPU crackers; a pepper does not fix that.
3. CA global salt allows one precomputation for all users, and SHA-256 is fast.
4. DPBKDF2 tuned for low memory is easy to parallelize on GPUs.

More below: why each option is right or wrong — scroll this panel

Defenders must test rules and map new intelligence against historical data. A retrospective log hunt ensures the evasion technique wasn't already successfully utilized.

1. AAwareness training does nothing to show whether the new technique was already used against you; it is not an immediate operational step.
2. BA backup preserves state but reveals nothing about compromise, and one taken now could capture an attacker's foothold.
3. CCorrect: hunting back through historical logs for the new technique shows whether the environment was breached before any detection existed.
4. DA policy edit is slow administrative work, and an evasion technique is behaviour, not just a list of domains to block.

More below: why each option is right or wrong — scroll this panel

Treating every finding as immediately exploitable without verification is a pitfall. If a vulnerable module is disabled, the flaw cannot be exploited.

1. AAuto-restart is resilience after a crash; the vulnerable code would still be reachable.
2. BCorrect: if the vulnerable module is disabled in the running configuration, the flaw is unreachable, so the finding is a practical false positive.
3. CChanging default credentials does not fix a code execution flaw in the interface itself.
4. DSession limits address resource exhaustion, not remote code execution.

More below: why each option is right or wrong — scroll this panel

Designing detection rules that combine multiple disparate signals (e.g., anomalous process spawn + remote command execution + suspicious network destination) greatly improves precision. By using logical correlation across different log types, analysts can reliably identify an attack sequence while avoiding false positives triggered by isolated events.

1. ASeparate rules keep each signal's noise and lose the correlation that defines lateral movement.
2. BAdmins run command prompts constantly; alerting on every one floods analysts with false positives.
3. CCorrect: correlating an anomalous process spawn with a suspicious remote destination matches the attack sequence and cuts false positives.
4. DFailed logins are common and usually benign; containing on each one is noisy and disruptive.

More below: why each option is right or wrong — scroll this panel

A practical prioritization approach dictates filtering vulnerabilities with active exploitation on critical, internet-facing assets first. Asset exposure strongly influences real-world exploitability, overriding the raw CVSS base score. The portals face the internet and carry immediate risk, whereas the administrative servers, despite a higher theoretical CVSS score, are internal and less exposed. Basing decisions entirely on vendor schedules or raw CVSS scores is a vulnerability management pitfall.

1. ACorrect: internet exposure makes the portals reachable by anyone, so their practical risk outranks a higher base score on internal servers.
2. BThe stem gives no evidence about compensating controls; if internal servers lacked them, that would argue for patching them sooner.
3. CA patch existed, since the portals were patched within 24 hours; the delay was a choice.
4. DA base score measures severity, not likelihood; a high CVSS does not guarantee exploitation.

More below: why each option is right or wrong — scroll this panel

CVSS describes inherent technical characteristics but omits environment-specific and adversary activity context. Integrating operational tags, such as actively exploited, with CVSS produces accurate priority buckets. A medium-severity vulnerability that is actively exploited in the wild presents a much higher immediate, tangible risk than theoretical or physically constrained vulnerabilities.

1. ANo public exploit and an internal location make this lower priority despite the high score.
2. BRequiring physical access sharply reduces practical risk.
3. CA theoretical, internal-only issue can wait behind one being exploited now.
4. DCorrect: active exploitation in the wild outweighs a higher base score; a medium flaw under attack is the most urgent.

More below: why each option is right or wrong — scroll this panel

A common pitfall in detection engineering is mapping a rule to a broad tactic (the adversary's conceptual goal, such as Lateral Movement) rather than a specific technique (the concrete method, like SMB lateral movement). Tactics generate massive noise, whereas techniques provide actionable, targeted detection logic.

1. ASpecific registry keys are narrow indicators and usually precise.
2. BCorrect: a rule written at tactic level matches lots of normal activity; technique-level logic is far more precise.
3. CKnown-bad IP lists are narrow, so they miss things rather than over-alert.
4. DFile hash rules are highly specific and rarely cause false positives.

More below: why each option is right or wrong — scroll this panel

Converting Threat Intelligence into concrete detection rules requires extracting actionable parameters, such as the specific adversary technique and the necessary endpoint telemetry sources.

1. ACommunications planning is incident response, not detection engineering.
2. BOrigin and motivation give context but cannot be detected in endpoint logs.
3. CVictim lists do not translate into detection logic.
4. DCorrect: a rule needs the concrete technique, such as PowerShell download cradles, and the telemetry that shows it, such as script block or process logs.

More below: why each option is right or wrong — scroll this panel

High-fidelity telemetry tied directly to the technique is preferred. Parent-child process relationships and API monitoring observe execution behavior on the host directly. Network traffic, web requests, and static hash signatures do not accurately model host-level memory or process manipulation.

1. AProcess injection happens inside the host; network inspection does not see it.
2. BCorrect: injection shows up as unusual process relationships and API calls, such as writing into another process's memory, in endpoint telemetry.
3. CInbound web volume does not reveal code injected into processes.
4. DPacket capture shows network traffic, not in-memory injection.

More below: why each option is right or wrong — scroll this panel

To detect low-and-slow attacks, analysts must use extended time windows to capture spaced-out attempts. Combining this with count thresholds and contextual enrichment raises the signal-to-noise ratio and prevents false positives from rapid lockouts. Narrow windows miss slow attacks. Alerting on single failures creates excessive noise. Discarding logs removes necessary visibility, and eliminating enrichment prevents differentiating malicious activity from benign errors.

1. ANarrow windows miss attempts spread over hours, the essence of low-and-slow.
2. BAlerting on every failed login floods analysts with false positives.
3. CDiscarding authentication logs removes the very data needed.
4. DCorrect: long windows catch spaced-out attempts, thresholds filter normal failures, and enrichment adds context.

More below: why each option is right or wrong — scroll this panel

The RTO is 4 hours, and the threshold is 50% (2 hours). Containment took 3.5 hours (08:00 to 11:30), breaching the threshold. Ignoring this leads to under-escalation. The playbook specifically dictates executive escalation.

1. ANo RTO breach occurred: containment came at 3.5 hours, inside the 4-hour RTO; what was crossed is the 2-hour escalation threshold.
2. BCorrect: 50% of a 4-hour RTO is 2 hours; containment took 3.5 hours, so the playbook requires executive escalation.
3. CContainment is done and the RTO is not exceeded; failover is not what this playbook trigger calls for.
4. DThe playbook ties escalation to containment time, which already passed the threshold; waiting for eradication is under-escalation.

More below: why each option is right or wrong — scroll this panel

Creating reports with screenshots or outputs that lack provenance metadata (such as who produced them, the specific tool and version used, and the exact time) invites severe admissibility challenges. Visual clarity cannot substitute for verifiable administrative and technical provenance in a legal setting.

1. AOpen-source tools are routinely accepted when their use is documented and repeatable.
2. BEncryption protects evidence integrity; it is not a reason to exclude it.
3. CCorrect: screenshots without provenance (who captured them, with which tool and version, when) cannot be authenticated and invite challenge.
4. DNo standard 24-hour submission window governs admissibility.

More below: why each option is right or wrong — scroll this panel

A common Business Impact Analysis (BIA) pitfall during disaster recovery execution is prioritizing systems based on how easily or quickly they can be technically restored (e.g., simple internal file servers) rather than strictly following the business-impact-driven prioritization matrix that puts critical, revenue-generating functions first.

1. ADifferential backups restore fine; backup type does not explain the wrong recovery order.
2. BDeclaring a disaster matters, but staff did recover systems; the problem is which ones came first.
3. CEven a mis-set MTD would be a BIA error, not a runbook violation; the failure was restoring easy systems before the revenue-critical one.
4. DCorrect: the revenue system should have come first; restoring easy internal servers first means recovery was ordered by convenience, not business impact.

More below: why each option is right or wrong — scroll this panel

Eradication removes malicious artifacts (such as deleting registry keys, removing malware files, or wiping compromised accounts), while recovery restores services to acceptable levels while validating integrity.

1. ACorrect: eradication removes the attacker's artifacts, such as malicious registry keys and files, from the system.
2. BRestoring from a clean backup returns the system to service, which is recovery.
3. CWatching for unusual traffic after restoration is post-recovery monitoring.
4. DReconnecting the server to production is a recovery step.

More below: why each option is right or wrong — scroll this panel

Rapid triage requires collecting volatile data and capturing logs before taking disruptive actions that alter evidence. Shutting down the port destroyed critical volatile memory.

1. ACorrect: volatile data such as ARP tables, memory and logs should be captured before disruptive containment, or the evidence is lost.
2. BIsolating the whole segment is more disruptive and still destroys volatile evidence.
3. CACL changes are containment; the lesson is to preserve evidence first.
4. DNotifying executives first delays response and does not protect evidence.

More below: why each option is right or wrong — scroll this panel

The Order of Volatility requires capturing the most ephemeral data first. The correct sequence is CPU state and running processes, followed by active network connections, then system logs, and finally persistent local disk storage.

1. AThis reverses the order; disk is the least volatile.
2. BCorrect: collect from most to least volatile, from CPU state and network connections to logs and then disk.
3. CNetwork connections are slightly less volatile than CPU state, and disk should come last.
4. DLogs are less volatile than CPU state and connections, so they should not come first.

More below: why each option is right or wrong — scroll this panel

Fileless malware resides exclusively in volatile memory (RAM) and leaves little to no trace on persistent storage. Therefore, live memory acquisition is strictly required to capture active network states, ephemeral processes, and encryption keys. Static disk imaging, logical replication, and backups will entirely miss these volatile artifacts.

1. ACorrect: fileless malware lives in RAM, so only a live memory capture preserves its artifacts.
2. BSystem state backups capture configuration on disk, not running memory.
3. COffline imaging requires powering down, which erases memory-resident malware.
4. DFile system copies capture files, and fileless malware leaves few.

More below: why each option is right or wrong — scroll this panel

Compliance frameworks typically mandate very short initial notification windows. Waiting for a final forensic report causes organizations to miss these deadlines. Initial reports should be preliminary, with follow-ups later.

1. ANotification does not change the attacker's access; containment does.
2. BNotifying regulators does not affect chain of custody.
3. CCorrect: many regulations require an initial notice within days, such as GDPR's 72 hours; the full report can follow later.
4. DNotification timing does not control law enforcement seizure.

More below: why each option is right or wrong — scroll this panel

Implementing split knowledge with dual-control escrow agents ensures that no single individual can unilaterally recover the keys. This mitigates insider threats and maintains non-repudiation. Storing complete copies offsite or simply requiring post-recovery rotation fails to prevent unauthorized initial access to the sensitive key material.

1. AOne administrator with sole recovery power is exactly the insider risk that dual control prevents.
2. BRotation after recovery is good hygiene but does not stop one person from misusing the escrow.
3. CCorrect: with split knowledge and dual control no single person can recover a key alone, limiting insider abuse and keeping actions attributable.
4. DComplete key copies offsite create another place to steal the whole key; they do not control who can use it.

More below: why each option is right or wrong — scroll this panel

Automated key rotation in production environments must preserve key versioning. This ensures the system uses new keys for encryption while retaining access to older keys for decrypting historical data. Overwriting keys destroys data, while re-encrypting causes outages.

1. ARe-encrypting everything at once is a heavy job that risks the outages rotation is meant to avoid.
2. BCorrect: with key versioning, new data uses the new key while older versions stay available to decrypt older records.
3. COverwriting the old key makes data encrypted under it unreadable.
4. DA manual approval step adds friction and does nothing for access to historical data.

More below: why each option is right or wrong — scroll this panel

Even with strong derivation functions like Argon2id, stolen hashes remain vulnerable to offline cracking. A layered strategy must include rate limiting and password blocklists to prevent attackers from using common passwords or credential stuffing. Encrypting hashes provides minimal security.

1. ANIST SP 800-63B discourages forced periodic resets; they push users toward predictable passwords.
2. BCorrect: rate limiting slows online guessing and stuffing, and blocklists reject the common or breached passwords that crack first offline.
3. CHashing the salt adds nothing; salts are not secret, and Argon2id already slows guessing.
4. DEncrypting hashes helps only while the key stays safe and does nothing about weak or reused passwords.

More below: why each option is right or wrong — scroll this panel

Public-key (asymmetric) algorithms like RSA are extremely computationally intensive and are incredibly slow compared to symmetric algorithms. Furthermore, RSA can only directly encrypt data that is smaller than its key size minus padding overhead (for RSA-4096, roughly 500 bytes). Attempting to chunk and encrypt a 50 MB file directly with RSA is both highly inefficient and improper. The correct architectural approach is hybrid encryption: using a symmetric algorithm to encrypt the bulk data, and then using RSA to encrypt the symmetric key.

1. ARSA public keys can encrypt, with the private key decrypting; verifying signatures is just another use.
2. BPadding is applied, not discarded, and it is part of what limits RSA's payload size.
3. CPublic key encryption works offline; no session with the certificate authority is needed.
4. DCorrect: RSA is slow and encrypts only a few hundred bytes per operation; large files use a symmetric key that is wrapped with RSA.

More below: why each option is right or wrong — scroll this panel

Certificate validation requires establishing trust from the leaf up to a trusted root CA. If the leaf is valid but the issuer is unrecognized, the server is likely missing the intermediate CA certificate. Browsers cannot bridge this trust gap.

1. AAdding the root to the trust store makes validation succeed, not fail.
2. BA wrong clock produces validity-period errors, but here the leaf is valid and the issuer is the problem.
3. CA name mismatch gives a hostname error, not an unknown issuer.
4. DCorrect: if the server omits the intermediate, the browser cannot chain the leaf to a trusted root and reports an unknown issuer.

More below: why each option is right or wrong — scroll this panel

IKE Phase 1 uses UDP port 500 to establish the ISAKMP control channel, which succeeds here. IKE Phase 2 establishes IPsec SAs for data traffic using ESP (IP Protocol 50). Since the firewall denies IP protocol 50, the data plane fails, resulting in established tunnels with zero throughput.

1. ACorrect: UDP 500 lets IKE build the control channel, but ESP (IP protocol 50) is blocked, so protected data never flows.
2. BNAT-T on UDP 4500 is used only when NAT is detected, and nothing here permits port 4500.
3. CAH provides integrity, not encryption, and it is IP protocol 51, which is not permitted either.
4. DNegotiation over UDP 500 is allowed, so IKE parameters are agreed; the failure comes later, on the data plane.

More below: why each option is right or wrong — scroll this panel

A /23 subnet mask locks the first 23 bits, making the last bit of the third octet a host bit. This groups two /24 networks. For 10.5.4.0, a /23 mask covers 10.5.4.0 through 10.5.5.255, accidentally including both the web servers (10.5.4.0/24) and databases (10.5.5.0/24).

1. AThis is exactly the web server range and does not reach 10.5.5.0.
2. B10.5.4.128/25 covers .128 to .255 of the web range only.
3. CCorrect: a /23 starting at 10.5.4.0 spans 10.5.4.0 to 10.5.5.255, so it includes the database subnet.
4. D10.5.4.0/25 covers 10.5.4.0 to .127, half the web range and nothing of the database.

More below: why each option is right or wrong — scroll this panel

An IPsec security association has a fixed lifetime, and 28,800 seconds (8 hours) is a common default, especially for the IKE SA. Before the lifetime ends, the peers should rekey and replace the SA without interrupting traffic. If every tunnel drops and rebuilds on that exact interval, the rekey is failing, for example because of mismatched lifetimes or rekey settings, so the SA expires and the tunnel is torn down and rebuilt from scratch. A fixed, synchronized cycle across all tunnels points to a timer, not to idle-time checks such as Dead Peer Detection, IPS session policies or certificate status.

1. AAn IPS dropping long sessions would not hit every tunnel on an exact 8-hour clock.
2. BCorrect: 8 hours (28,800 s) is a common SA lifetime; tunnels dropping at that interval are failing to rekey before expiry.
3. CRevocation is not periodic like this, and hourly revocations would not produce an 8-hour cycle.
4. DBlocked Dead Peer Detection drops tunnels after idle periods, not on a fixed timer.

More below: why each option is right or wrong — scroll this panel

Layered inspection preserves throughput on expensive deep-inspection devices by using faster edge routers to drop known bad traffic via basic Access Control Lists. This reduces the total volume the core IPS analyzes.

1. ACorrect: cheap stateless drops at the edge remove known-bad traffic before it reaches the IPS, freeing capacity for deep inspection.
2. BLarger MTUs do not cut the volume the IPS must inspect, and mismatched MTUs cause problems of their own.
3. CSkipping updates weakens detection and does nothing for capacity.
4. DSmaller TCP windows slow applications without reducing what the IPS must inspect.

More below: why each option is right or wrong — scroll this panel

In active/standby configurations, if session synchronization is disabled, the standby unit will not have the state table entries for established connections. Upon failover, it drops unrecognized traffic like existing SSH sessions. Processing power, management interfaces, and routing protocols do not directly govern the stateful preservation of existing TCP sessions.

1. ANAT rules are configuration and normally synced; what failover loses is the live session table.
2. BSSH sessions need little processing; capacity does not explain every established session dropping at once.
3. CManagement subnet layout affects administration, not transit sessions.
4. DCorrect: without session synchronization the standby has no state table, so existing connections drop after failover.

More below: why each option is right or wrong — scroll this panel

This issue stems from assuming stateless ACLs on edge devices handle stateful protocols correctly. Stateless filters evaluate packets individually without tracking connection state. Consequently, they require explicit rules to allow return traffic. Without them, legitimate return traffic is blocked, causing timeouts. Stateful inspection natively permits return traffic by connection state. Deep packet inspection and proxies operate at higher layers and handle state differently. A misplaced default-deny blocking outbound traffic would cause immediate outbound failure, not specific return traffic timeouts.

1. AA deny-all ahead of the permits would block the outbound requests themselves; the classic symptom of new stateless ACLs is missing return rules.
2. BA router running standard ACLs is not an application proxy, and fragments are not the common case.
3. CCorrect: stateless ACLs check each packet alone, so without rules for return traffic the replies are dropped and connections time out.
4. DDeep inspection is not part of standard ACLs and would not block ordinary web replies.

More below: why each option is right or wrong — scroll this panel

Analysts must identify IP headers to determine attacker actions before applying mitigation. Incoming internet traffic bearing an internal private IP as its source address indicates IP spoofing. Attackers use this technique to bypass poorly configured perimeter ACLs. This is not NAT, which translates internal IPs to public IPs for outbound traffic, not the reverse. IPv6 encapsulation, asymmetric routing anomalies, and packet fragmentation do not inherently cause inbound external traffic to legitimately originate from an internal private IP address space.

1. AFragmentation is unrelated to a private source address arriving from the internet.
2. BNAT translates outbound private addresses to public ones; legitimate inbound internet traffic never carries an internal source.
3. CCorrect: private source addresses arriving from the internet are spoofed, often to slip past rules that trust internal ranges.
4. DAsymmetric routing does not put private sources on internet traffic, and nothing in the flags points to it.

More below: why each option is right or wrong — scroll this panel

In active/active firewall deployments, traffic may leave via one node and return via the other. Without continuous state synchronization, returning packets are dropped because the receiving firewall lacks the TCP state information.

1. ARouting metrics affect path choice, not state tracking.
2. BCorrect: with active/active nodes, replies may return through the other firewall; without state sync it drops them as invalid.
3. CHealth check settings remove nodes, not packets with unknown state.
4. DRPF drops spoofed-looking packets on routers; it does not explain state-tracking failures on firewalls.

More below: why each option is right or wrong — scroll this panel

Managing an overgrown rule base requires retiring stale rules, normalizing overlaps, and keeping auditable justifications. This reduces the attack surface while supporting legitimate traffic. Relying purely on active hits might remove disaster recovery access. Grouping IP addresses violates least privilege. An implicit deny is standard but won't clean up existing overlapping rules.

1. ARules unused for 30 days may still serve rare needs such as DR or quarterly jobs; automatic deletion risks outages.
2. BOne global allow group broadens access and breaks least privilege.
3. CCorrect: retire stale rules, merge overlaps and keep a documented business justification for every remaining rule.
4. DAn implicit deny at the end is standard but does nothing about the overlapping permits above it.

More below: why each option is right or wrong — scroll this panel

An out-of-band IDS via a network tap provides detect-only capabilities without adding latency, which is critical for trading networks. Any inline IPS, even transparent or with bypass NICs, inherently introduces microsecond processing latency.

1. ABypass NICs keep traffic flowing if the IPS fails, but inline inspection still adds latency.
2. BA transparent IPS is still inline and adds processing delay.
3. CAn inline device stays in the path even when it only monitors.
4. DCorrect: a tap copies traffic to an out-of-band IDS, giving visibility with no added latency in the trading path.

More below: why each option is right or wrong — scroll this panel

When a hypervisor compromise is suspected, isolating the affected physical host and escalating to host-level containment is necessary. Because the hypervisor is compromised, guest-level actions like patching the guest OS or terminating specific malicious VMs are insufficient. The attacker controls the underlying infrastructure. Additionally, migrating running virtual machines during an active hypervisor compromise is dangerous because it risks spreading the malicious activity or failing entirely due to compromised host integrity.

1. ACorrect: the hypervisor itself is compromised, so containment must happen at host level; isolating the physical host cuts the attacker's reach.
2. BLive migration can carry the attacker's access along with the VMs, and it is slow during an active attack.
3. CThe attacker reaches memory across guests through the hypervisor; stopping one VM does not contain that.
4. DThe flaw is in the hypervisor; patching guest operating systems leaves it untouched.

More below: why each option is right or wrong — scroll this panel

Migrating to short-lived OIDC tokens minimizes risk. Long-lived credentials pose significant risks if agents are compromised. Encrypting keys at rest won't protect them in memory. A VPN doesn't stop compromised agents from misusing credentials. Quarterly rotation leaves keys vulnerable for months. Centralizing credentials doesn't address the core issue of long-lived access.

1. ANetwork restrictions do not help when the agent itself is compromised and holds valid keys.
2. BKeys must be decrypted to be used, so a compromised agent can still read them.
3. CCorrect: OIDC federation gives each job a short-lived token, so a compromised agent has nothing durable to steal.
4. DA vault protects storage, but the agent still retrieves long-lived keys that stay valid if stolen.

More below: why each option is right or wrong — scroll this panel

Allowing direct PCI pass-through grants a virtual machine direct access to physical host hardware, bypassing the hypervisor abstraction layer. This significantly increases the hypervisor attack surface, as compromised guests might exploit hardware vulnerabilities to escape the VM. While pass-through limits live migration, it does not bypass guest firewalls, prevent VM firmware updates, disable cluster micro-segmentation, or directly degrade host encryption performance.

1. ACorrect: pass-through gives the guest direct hardware and DMA access, widening what a compromised guest can attack beneath the hypervisor, including escape paths.
2. BGuest firewalls run inside the guest OS and are unaffected by how a GPU is attached.
3. CPass-through limits live migration, but guests still receive updates normally.
4. DAttaching a GPU to a guest does not touch host storage encryption.

More below: why each option is right or wrong — scroll this panel

Applications should adopt secure API patterns, including well-defined error handling, to avoid leaking sensitive state information. Verbose error handling can leak underlying infrastructure details, allowing threat actors to map the backend for targeted attacks. Returning generic errors prevents this leakage.

1. AParameterized queries stop SQL injection but not error details leaking.
2. BCorrect: generic error responses to clients, with details kept in server logs, stop the stack trace leak.
3. CMutual authentication limits who connects, but authenticated clients would still see stack traces.
4. DTesting finds the problem; it does not fix it.

More below: why each option is right or wrong — scroll this panel

Reconstructing an attack traversing from an application to cloud infrastructure requires coordinated logging and tracing across application, platform, and cloud provider telemetry. The lack of centralized cross-layer telemetry correlation prevents linking application exploits to cloud control plane API calls. Short retention periods, missing memory forensics, or unencrypted logs limit data availability but do not specifically point to missing correlation capabilities.

1. ACorrect: the attack crossed container, application and cloud control planes; without telemetry correlated across those layers the chain cannot be rebuilt.
2. BEncryption protects logs but does not explain an inability to link events across layers.
3. CBandwidth is rarely the limit for cloud audit logs; correlation is the gap.
4. DMemory forensics helps on hosts but does not cover cloud configuration changes.

More below: why each option is right or wrong — scroll this panel

When public hosting is required, applying blanket protections like disabling all public access breaks functionality. The best approach prefers narrow bucket policies for limited-purpose public access instead of broad ACLs. This balances public availability with the principle of least privilege.

1. AEncryption at rest does not change who can read objects publicly.
2. BPublic website visitors cannot be asked for MFA.
3. CBlocking all public access breaks the website.
4. DCorrect: a narrow policy allows public read only on the site's objects, keeping the site up while closing the broad access.

More below: why each option is right or wrong — scroll this panel

The definitive mitigation for SQL injection is using parameterized queries or prepared statements. This approach separates code from data, preventing the database from executing malicious input. Manual escaping often fails and can be bypassed. Network controls cannot fix vulnerable application code. Client-side checks are easily bypassed by attackers.

1. AManual escaping is error-prone and easy to get wrong in edge cases.
2. BAn IPS may catch some payloads but leaves the code flaw in place.
3. CClient-side filtering is trivially bypassed by sending requests directly.
4. DCorrect: parameterized queries keep user input as data, never as SQL code, removing the injection at its source.

More below: why each option is right or wrong — scroll this panel

Running broad antivirus full-scans or automatically deleting/quarantining suspicious files before acquiring volatile data is a major incident response misstep. This action can irreparably corrupt evidence by modifying filesystem timestamps, overwriting memory space, and destroying vital in-memory artifacts necessary for understanding the true scope of the intrusion. Volatile data must be captured first according to standard forensic order of volatility.

1. AA scan is unlikely to trigger a payload; the bigger issue is evidence loss.
2. BCorrect: scanning and auto-quarantine change timestamps and remove files before evidence is collected, destroying forensic artifacts.
3. CAntivirus scans do not encrypt network traffic or blind an IDS.
4. DTipping off an attacker is possible but secondary; the main fault is destroying evidence.

More below: why each option is right or wrong — scroll this panel

Integrating MDM with certificate provisioning enables transparent mutual authentication. The MDM silently requests and deploys client certificates from the corporate Public Key Infrastructure (PKI) to enrolled devices. This removes manual key management. Conversely, RADIUS, pre-shared keys, and hardware tokens often rely on user-managed credentials or lack non-repudiation, failing to provide the seamless machine-level mutual authentication required.

1. AHardware OTP tokens need user action, so they are not transparent, and they do not authenticate the device.
2. BShared pre-shared keys are hard to rotate and identify no single device.
3. CRADIUS validates credentials but does not by itself provide device certificates or transparent mutual authentication.
4. DCorrect: MDM silently enrols each device with a certificate from the corporate PKI, giving automatic certificate-based mutual authentication.

More below: why each option is right or wrong — scroll this panel