Efficiency and process improvement in the SOC

Key: C

1. ARequiring approval for every automated containment throws away the speed automation is meant to give, even on low-impact endpoints.
2. BIsolating every suspect endpoint automatically ignores business impact and can take critical systems offline on a false positive.
3. CCorrect: Let low-impact endpoints be contained automatically for speed, and send high-impact assets through a human approval step so that a false positive can't take down a critical system.
4. DDelaying isolation on low-impact assets slows containment exactly where automation is cheapest, and does nothing to protect critical systems.

Key: B

1. AVulnerability scan results don't tell the SOAR whether a detection is a false positive, so they wouldn't have prevented the isolation.
2. BCorrect: A human approval step before destructive actions on critical assets would have let an analyst recognize the legitimate admin script before 50 production databases were isolated.
3. CAn IP reputation check helps with network indicators, but the trigger here was a local script, so reputation data wouldn't have helped.
4. DTicketing integration records the action; it does not stop an automated isolation from running.

Key: A

1. ACorrect: A dry run simulates the logic without sending the real containment calls, so it never reached the API volume of a live outbreak and couldn't reveal the rate limit.
2. BThe failure was API rate limiting under load, not a ticketing integration problem.
3. CDry-run mode skipping authentication would show up as auth errors and could not produce rate limiting, and the problem appeared only under live volume.
4. DATT&CK mapping helps with detection coverage, but has nothing to do with API call volume or rate limits.

Key: C

1. ASelf-inflicted outages from aggressive containment would appear as outages, while the data shows playbook failures beginning right after the integration update.
2. BMean time to acknowledge stayed at 5–6 minutes, which argues against alert volume overwhelming triage.
3. CCorrect: Playbook failures jumped from 2% to 18–21% and mean time to respond tripled right after the TIP API v2.1 update, which points to a changed API payload that broke parsing.
4. DAn engine misconfiguration would not line up exactly with the TIP update, which is the only change in the table.

Key: C

1. AMore workers with no rate limits just lets the failing connector consume even more resources and hit the upstream service harder.
2. BSending everything through the failing connector with unlimited retries makes the saturation worse.
3. CCorrect: A circuit breaker stops calling the failing connector after a threshold, and exponential backoff with jitter spaces out retries, so other sources keep flowing.
4. DRemoving the connector and accepting permanent data loss gives up on resilience altogether.

Key: B

1. AReleasing account-disabling and quarantine actions without testing risks mass outages from one logic error.
2. BCorrect: Test in a dry-run sandbox, then a pilot group, then roll out fully with rollback snapshots, so destructive actions are proven and reversible at each stage.
3. CRunning destructive actions with no way to roll back turns any false positive into lasting damage.
4. DA non-critical pilot is a good start, but stopping there means the playbook is never deployed or validated where it matters.

Key: D

1. AAdding playbooks without baseline metrics leaves you no way to tell whether the new automation helps or harms.
2. BRemoving all gating and auto-approving every action throws away the safety controls that produced the good metrics.
3. CNo playbook reaches 100 percent; waiting for perfect metrics blocks a clearly successful program.
4. DCorrect: 92 percent success, a 4 percent false-positive rate and stable latency justify expanding, while continuing to track the same metrics to catch regressions.

Key: C

1. ATurning off post-change dashboards hides the problem instead of fixing the drift.
2. BMore alerts with a much lower confirmation rate means more noise; sensitivity has not improved.
3. CCorrect: Roll back only the changed rule, then A/B test it on representative traffic to prove it caused the drift and tune it before redeploying.
4. DExpanding automation on top of a drifting rule automates the false positives and adds more downstream incidents.

Key: B

1. APulling every source in parallel without priority adds latency and noise rather than giving the most useful context first.
2. BCorrect: Asset criticality and patch status show whether the alert matters, exploit-maturity intel shows how urgent it is, and the owner contact makes it actionable, in that order.
3. CScheduled tasks and login patterns are host-hunting data and say nothing about the vulnerability, the asset's value or exploitability.
4. DStarting with threat intel and then dumping all logs skips asset criticality and patch status and buries the analyst in data.

Key: B

1. AConverting only IPs fixes one indicator type and leaves domain, URL and timestamp mismatches in place.
2. BCorrect: Normalize every indicator form (lowercase domains, URLs without parameters, consistent CIDR and timestamps) so the same IoC matches across tools.
3. CKeeping duplicates for every format variant multiplies the mismatch instead of fixing it.
4. DRaw URLs with tracking parameters and mixed-case domains are the inconsistent formats causing the missed matches.

Key: D

1. AScaling up the SOAR doesn't fix the external API limit, because duplicate enrichments would still exceed 1,000 per minute.
2. BSecondary authentication has nothing to do with idempotency or the enrichment load, so it mixes up unrelated concepts.
3. CAsynchronous queues smooth out bursts, but the queued duplicate lookups would still exceed the API threshold and back up critical alerts.
4. DCorrect: Throttling (deduplicating) repeat lookups for the same IP cuts calls from 4,200 to below the 1,000-per-minute threshold, freeing capacity for critical and unique enrichments.

Key: A

1. ACorrect: The IP query returns 401 Unauthorized with 'Invalid API Key', so the playbook lacks a valid credential for that endpoint, and the parse error is just a downstream effect.
2. BRate limiting returns HTTP 429 (Too Many Requests), whereas 401 means the request was not authenticated.
3. CA firewall block would cause timeouts or connection failures, while an HTTP 401 means the API answered and refused the credentials.
4. DAn outage would return 5xx errors or no response, while the provider answered and rejected the key.

Key: C

1. AAn AD query only reads data, so it changes nothing that would need undoing.
2. BA firewall block on a CTI-verified IP can be removed in moments if it proves wrong, so it is reversible.
3. CCorrect: deleting the account destroys its SID, group memberships and profile, which cannot simply be restored, and doing it automatically on an impossible-travel signal that can be a false positive makes it the step that breaks reversibility.
4. DA password reset is disruptive but easy to undo or follow with a new password, and the account and its history stay intact.

Key: A

1. ACorrect: SOAR runs repeatable steps automatically through playbooks, which cuts the time from alert to response.
2. BNo tool prevents every breach; SOAR speeds up response but doesn't make an organization immune.
3. CSOAR handles routine tasks so analysts can focus on judgment calls; it doesn't replace skilled people.
4. DSOAR usually takes alerts from a SIEM and acts on them; it complements log collection and correlation rather than replacing the SIEM.