Cyber Security Quiz: Post Incident Actions

10 questions · exam conditions

0:00

Post Incident ActionsQuestion 1 of 10

Following a database breach, management initially attributes the incident to an unpatched web vulnerability. However, web application firewall logs show no matching exploit traffic, while endpoint records show a successful session using a valid administrator account. The source of those credentials has not yet been established.

What is the MOST appropriate conclusion for the lessons-learned report at this stage?

List delayed patching as the root cause because the vulnerable software was present when the breach occurred.

Record the root cause as unresolved, preserve both hypotheses, and investigate the administrator credential's provenance.

List credential theft as the root cause because use of a valid administrator session proves compromise occurred externally.

Classify patching as the root cause, then reproduce the web vulnerability to estimate the incident's potential impact.

← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Post Incident Actions

Practice Post Incident Actions in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Post Incident Actions, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

What is the MOST appropriate conclusion for the lessons-learned report at this stage?

List delayed patching as the root cause because the vulnerable software was present when the breach occurred.
Record the root cause as unresolved, preserve both hypotheses, and investigate the administrator credential's provenance. (correct answer)
List credential theft as the root cause because use of a valid administrator session proves compromise occurred externally.
Classify patching as the root cause, then reproduce the web vulnerability to estimate the incident's potential impact.

Explanation: When writing incident reports and lessons-learned documentation, a critical principle is that root cause must be evidence-based, not assumption-based. If the investigation is still open, the report must reflect that honestly — prematurely locking in a cause can misdirect remediation efforts and leave the real vulnerability untouched. Here, the evidence is contradictory: management suspects a web exploit, but the WAF logs show no matching exploit traffic. Meanwhile, endpoint logs confirm a successful session using valid admin credentials. These two data points don't support the web-exploit hypothesis — they suggest a credential-based attack. But since the source of those credentials hasn't been traced yet, you can't definitively call it credential theft either. The honest, defensible conclusion is that the root cause remains unresolved, both hypotheses should be preserved, and the credential's origin must be investigated. That's exactly what B describes. A is wrong because it commits the classic trap of conflating presence of a vulnerability with proof it was exploited. Vulnerable software being present ≠ root cause when the logs actively contradict that attack path. C is equally premature — a valid admin session could indicate credential theft, but it could also mean a malicious insider, a misconfigured account, or other causes. "Valid session exists" doesn't prove external compromise. D doubles down on A's error by treating patching as confirmed root cause and pivoting to impact modeling, which wastes resources investigating the wrong vector. The study tip here: on cyber-security exams, watch for questions that reward intellectual honesty. When evidence is incomplete or conflicting, the correct answer almost always involves preserving uncertainty and continuing investigation — not forcing a premature conclusion.

Question 2

During an incident, responders delayed isolating a compromised server because the playbook required executive approval, even when active data exfiltration was confirmed. The approval requirement had originally been added after an earlier false positive caused an unnecessary outage.

How should the organization BEST revise and validate the playbook after the incident?

Remove every approval requirement so responders can isolate any system whenever an automated alert reaches high severity.
Keep the approval requirement unchanged because preventing business disruption remains more important than response speed.
Define evidence-based emergency isolation criteria, escalation paths, and exceptions, then test them in a tabletop exercise. (correct answer)
Add the exact indicators from this incident as mandatory triggers and require executive review for all other situations.

Explanation: When revising incident response playbooks, you're balancing two competing risks: acting too slowly (allowing damage to continue) and acting too hastily (causing unnecessary outages). The original approval requirement existed for a legitimate reason — a false positive caused a real disruption — but the incident revealed it created dangerous delays. The goal is a smarter policy, not simply a looser or stricter one. Choice C is correct because it addresses both sides of the problem systematically. Defining evidence-based criteria means isolation only triggers when specific, observable conditions are met — not just any high-severity alert. Building in escalation paths and exceptions preserves accountability without requiring executive approval in every urgent scenario. Crucially, tabletop exercises validate whether the revised process actually works before the next incident, catching gaps in logic, communication, or authority. Choice A is dangerous because blanket removal of approvals trades one problem for another — responders could isolate critical production systems based on noisy automated alerts, recreating the outage problem the original policy was meant to solve. Choice B fails to acknowledge that the current playbook demonstrably harmed the organization; maintaining it unchanged ignores the lesson of the incident entirely. Choice D is a common trap called "fighting the last war" — hardcoding indicators from one specific incident makes the playbook brittle and nearly useless against novel attack patterns, while also restoring the slow executive-review bottleneck for everything else. Your study tip: on incident response questions, watch for answers that solve one extreme by creating the opposite extreme. The best playbooks are criteria-driven and tested, not simply permissive or restrictive.

Question 3

The same misconfiguration contributes to two incidents six months apart. The first post-incident action had been marked complete when an engineering ticket was opened, although no configuration change was deployed. The ticket was later closed during backlog cleanup.

Which process change would MOST likely prevent this failure from recurring?

Require the incident manager to open duplicate tickets in both the security and engineering tracking systems.
Require accountable owners, due dates, implementation evidence, and verification before corrective actions are closed. (correct answer)
Keep lessons-learned reports open until the organization has experienced six months without a similar incident.
Escalate all security-related engineering tickets directly to executives when they are initially entered into the backlog.

Explanation: When you see a question about repeated security incidents caused by the same root cause, you're being tested on corrective action management — specifically, whether a remediation process has enough rigor to ensure fixes are actually implemented, not just documented. The core failure in this scenario isn't that a ticket was opened — it's that opening a ticket was treated as completing the action. The corrective action was never verified, and the ticket was quietly closed during backlog cleanup. Option B directly addresses this by requiring four gates before closure: an accountable owner (someone responsible), a due date (urgency enforced), implementation evidence (proof the fix was deployed), and verification (confirmation it worked). This transforms corrective actions from administrative gestures into auditable, enforceable commitments — precisely what failed here. Option A adds redundant ticket creation across two systems, but duplication doesn't prevent tickets from being abandoned or closed without verification. You'd just have two unresolved tickets instead of one. Option C ties closure to a six-month incident-free period, which is an outcome-based measure that can't distinguish whether the fix worked or the threat simply didn't materialize — and it delays legitimate closure indefinitely. Option D escalates tickets to executives at entry, which might create urgency initially but doesn't establish accountability or verification mechanisms; executives can't monitor every backlog item, and the same cleanup problem would recur. The study tip here: when a question involves a recurring failure, the correct answer almost always attacks the verification gap — the missing proof that a fix was actually implemented — rather than adding communication steps or monitoring layers.

Question 4

After a business email compromise incident, the response team reset the affected employee's password and re-registered multifactor authentication. Investigators later determined that the attacker continued accessing mail through a previously authorized malicious OAuth application. The post-incident review found no procedure for reviewing application grants.

Which control improvement would MOST directly address the persistence mechanism identified during the review?

Require more frequent password changes and increase phishing-awareness training for employees with access to corporate email.
Strengthen inbound email filtering and quarantine messages containing links to newly registered external domains.
Revoke existing malicious grants, restrict user consent, and alert on newly authorized high-risk applications. (correct answer)
Require hardware-based multifactor authentication and disable legacy password authentication for all mailbox users.

Explanation: When you see a post-incident review question like this, focus on the specific persistence mechanism described — not the initial attack vector. Here, the attacker maintained access through a malicious OAuth application grant, which is entirely independent of credentials or MFA. OAuth tokens authorize third-party apps to access resources on a user's behalf, and those grants survive password resets and MFA re-enrollment. That's the core trap this question is built around. C is correct because it directly targets the OAuth persistence mechanism at every stage: revoking existing malicious grants eliminates the attacker's current foothold, restricting user consent prevents future unauthorized grants, and alerting on high-risk new authorizations closes the detection gap the review identified. This maps precisely to the attack path described. A is wrong because password changes and phishing training don't affect OAuth tokens already in place. The passage explicitly states the attacker continued accessing mail after the password was reset — proving credentials weren't the lever anymore. A is solving the wrong problem. B is wrong because inbound email filtering addresses the delivery phase of the attack, not persistence. Even perfect filtering wouldn't revoke a token the attacker already holds. This is a common distractor that sounds relevant to email security without addressing the actual mechanism. D is wrong because hardware MFA and disabling legacy authentication are strong credential controls, but OAuth application grants operate above the authentication layer. An attacker using an authorized app token bypasses authentication entirely — stronger MFA doesn't cancel an already-approved token. Your study tip: when a question describes a persistence mechanism, always ask what specifically keeps the attacker in — and match controls to that mechanism, not to how they got in initially.

Question 5

A service provider accidentally exposed an API token used to access the organization's customer records. The token had broad privileges, no source restrictions, and a one-year lifetime. The contract required general security controls but did not specify an incident-notification deadline.

Which post-incident action set MOST comprehensively addresses the lessons learned?

Reduce token scope and lifetime, restrict permitted sources, and add contractual notification and review requirements. (correct answer)
Rotate the exposed token, require the provider to retrain staff, and retain the existing access configuration.
Add a contractual notification deadline, request an annual audit report, and preserve the current token privileges.
Terminate the provider immediately, migrate the service internally, and prohibit future external API integrations.

Explanation: When a third-party security incident exposes sensitive data through a misconfigured API token, your post-incident response should address every failure layer simultaneously: technical controls, operational practices, and contractual governance. Questions like this test whether you recognize that a comprehensive remediation plan closes all the gaps that enabled the breach, not just the most visible one. Answer A is correct because it targets all three root causes identified in the passage. The token had excessive scope, no source restrictions, and a dangerously long lifetime — A directly fixes each of these with reduced privileges, IP/source allowlisting, and shorter expiration windows. It also patches the contractual gap by adding notification deadlines and periodic review requirements. This is defense-in-depth applied to vendor management. Answer B is a common trap. Rotating the token stops the immediate bleeding, but retaining the existing access configuration leaves the same vulnerabilities intact — you'd be one future exposure away from the identical incident. Retraining staff alone doesn't fix systemic control gaps. Answer C adds a notification deadline, which addresses one contractual weakness, but it ignores all the technical failures entirely. Preserving current token privileges means nothing was actually learned from the incident. Answer D is an overreaction that creates new risk. Terminating providers and banning all external API integrations is disproportionate, operationally disruptive, and doesn't teach any transferable security practice for future vendor relationships. The key strategy here: when a question asks what "most comprehensively" addresses lessons learned, the correct answer must fix all identified gaps — technical, operational, and contractual — not just one category.

Question 6

After an MFA-push fatigue incident, the organization enables number matching and limits repeated push requests. Management wants evidence that the changes reduce the relevant risk, rather than evidence that deployment was completed.

Which measure would BEST validate the effectiveness of these control improvements?

The percentage of enrolled users whose authenticator software received the new configuration before the project deadline.
The total number of help-desk tickets mentioning multifactor authentication during the month after implementation.
The rate of unauthorized approvals during controlled tests and actual alerts, normalized by the number of push attempts. (correct answer)
The number of departments that acknowledged the revised authentication standard and distributed it to their employees.

Explanation: When evaluating security controls, you must distinguish between deployment metrics (did we roll it out?) and effectiveness metrics (did it actually reduce risk?). This question tests exactly that distinction. Management explicitly wants evidence of risk reduction, so any measure tracking completion, awareness, or volume without linking to attack outcomes will miss the mark. C is the correct answer because it directly measures what the controls are designed to prevent: unauthorized approvals. By tracking the rate of unauthorized approvals during both red-team tests and real alerts — normalized against push attempt volume — you get a true signal of whether number matching and push-limit policies are stopping attackers. Normalization is critical; raw counts would be misleading if push volume changed significantly after deployment. A tracks the percentage of users who received the updated configuration before a deadline. That's a rollout completion metric, not a risk-reduction metric. Full deployment is a prerequisite, not proof the control works. B counts help-desk tickets mentioning MFA. This is a noisy, ambiguous measure — tickets could spike because users are confused by the new interface, or drop because attackers paused activity, neither of which tells you whether unauthorized approvals decreased. D measures how many departments acknowledged and distributed the revised standard. That's a policy-awareness metric, which tracks communication, not control efficacy. A department can acknowledge a policy without the controls actually functioning. The key study tip: on security exam questions about validating controls, always ask yourself — "does this metric measure the bad outcome we're trying to prevent?" If it measures effort, coverage, or awareness instead, it's almost certainly a distractor.

Question 7

A security analyst closed an alert that later proved to be the first indication of a compromise. During the review, the team learns that the alert generated hundreds of false positives each week, had no documented escalation criteria, and was not assigned to a specific response queue.

Which post-incident action would BEST apply a blameless, control-focused lessons-learned approach?

Issue a formal warning to the analyst and require the entire security team to repeat annual alert-handling training.
Increase the alert's severity so future occurrences cannot be closed without approval from the security manager.
Require analysts to investigate every occurrence fully until the monitoring platform can be replaced with a newer product.
Tune the alert, document escalation criteria, assign ownership, and measure whether the revised process detects recurrences. (correct answer)

Explanation: When you see post-incident review questions on a security exam, ask yourself: does this response fix the system or punish the person? Blameless, control-focused lessons-learned frameworks — common in both DevOps and security operations — assume that individuals make mistakes because processes, tools, or environment set them up to fail. The goal is systemic improvement, not accountability theater. Option D is the correct answer because it directly addresses every structural failure identified in the passage. The alert generated excessive false positives (needs tuning), had no escalation criteria (needs documentation), and had no ownership (needs assignment). Measuring whether the revised process detects recurrences closes the feedback loop, turning a reactive fix into a verifiable control — exactly what a mature SOC improvement cycle looks like. Option A is a trap because it blames the analyst and mandates generic training. Neither action addresses the root causes: a noisy, undocumented, unassigned alert. Punishing individuals for systemic failures is precisely what blameless retrospectives reject. Option B simply raises the bureaucratic bar without fixing the underlying noise problem. If the alert still floods analysts with false positives, requiring manager approval only adds friction and bottlenecks response — it doesn't improve detection quality. Option C is operationally unrealistic and ignores the immediate problem. Waiting for a platform replacement while demanding full investigation of every false positive will burn out analysts and likely produce more missed alerts, not fewer. Your study tip: when exam questions describe multiple compounding failures (bad tuning and missing documentation and no ownership), the correct answer almost always addresses all of them systematically rather than applying a single punitive or superficial fix.

Question 8

A post-incident review confirms that attackers exploited an internet-facing legacy application and then reached a sensitive database. Replacing the application will take nine months. A web application firewall signature can be evaded, but testing shows that restricting external access and segmenting the application from the database would substantially reduce the attack path.

Which corrective-action plan BEST reflects risk-based prioritization?

Wait for application replacement because temporary controls may create complexity and will eventually become unnecessary.
Restrict exposure and segment the application promptly, while tracking replacement as the long-term corrective action. (correct answer)
Deploy only the firewall signature because it can be implemented quickly without changing application connectivity.
Accept the risk for nine months because management has already approved funding for the replacement project.

Explanation: When you see a question about post-incident corrective actions, think in terms of risk-based prioritization: the goal is to reduce exposure now while pursuing permanent fixes in parallel. Waiting for a perfect solution while a known vulnerability remains exploitable is not acceptable risk management — it's risk avoidance dressed up as planning. Option B is correct because it directly applies this principle. Restricting external access and segmenting the application from the database addresses the two specific attack vectors confirmed in the incident review. These controls are testable, effective, and deployable immediately — the nine-month replacement timeline doesn't justify leaving the environment exposed. Tracking replacement as the long-term corrective action ensures the temporary controls don't become permanent through neglect. Option A is a classic trap: it frames interim controls as unnecessary complexity rather than recognizing them as layered defense during a known window of vulnerability. The fact that something will eventually be replaced doesn't mean you ignore the risk in the meantime. Option C fails because the question already tells you the WAF signature can be evaded. Deploying a control you know is bypassable — while leaving the access path and network segmentation unchanged — doesn't meaningfully reduce risk. Speed of deployment is irrelevant if the control is ineffective. Option D misreads what management approval means. Funding a replacement project authorizes a solution; it does not constitute a formal risk acceptance decision for the interim period, nor does it eliminate the obligation to apply available mitigations. Your takeaway: on risk management questions, watch for answers that conflate "we have a plan" with "we have a control." A future fix is not a present safeguard.

Question 9

Investigators estimate that an attacker remained in the environment for approximately 45 days. Authentication logs were retained for only 14 days, preventing confirmation of the initial access method. The organization must define a corrective action without retaining all telemetry indefinitely.

Which recommendation BEST addresses the lesson learned while remaining risk-based?

Extend centralized, integrity-protected authentication log retention beyond the expected investigative window and review it periodically. (correct answer)
Retain every raw security event permanently so future investigators can reconstruct any possible attack sequence.
Keep the current retention period but require responders to begin collecting evidence within 24 hours of each alert.
Export monthly authentication summaries because aggregated counts require less storage than searchable event-level records.

Explanation: When a question asks you to balance investigative capability against operational cost, you're being tested on risk-based log retention — a core principle in incident response and security operations. The goal isn't to collect everything forever, nor to collect so little that investigations fail. It's to retain the right data, long enough, reliably enough to support realistic forensic needs. Answer A is correct because it directly addresses the root cause of the investigative failure: logs aged out before investigators could examine them. Extending retention beyond the expected dwell time (here, 45 days is the benchmark) means future investigations won't hit the same dead end. Integrity protection prevents tampering, and periodic review ensures the policy stays calibrated — all without demanding unlimited storage. B sounds thorough but represents the opposite trap: retaining every raw event permanently is neither practical nor risk-based. Storage costs scale indefinitely, and the question explicitly rules out retaining all telemetry indefinitely. Good security strategy prioritizes high-value data, not everything. C is tempting because faster response sounds helpful, but it misunderstands the problem. A 24-hour collection window doesn't help if the relevant logs are already gone. The issue is retention duration, not investigator reaction time. D confuses compression with usefulness. Monthly summary counts tell you how many logins occurred, not who, from where, or when — exactly the detail investigators need to reconstruct an attacker's initial access. Aggregation destroys forensic value. Study tip: On incident response questions, always separate the symptom (investigation failed) from the root cause (logs expired). Answers that address symptoms without fixing the root cause are almost always distractors.

Question 10

A ransomware incident did not destroy backup data, but restoration took four times longer than the approved recovery time objective. The review found that the recovery runbook omitted identity and name-resolution dependencies, which had to be rebuilt before application restoration could begin.

Which post-incident improvement would BEST address both the documented weakness and the recovery objective?

Increase backup capacity and retain additional copies so more historical versions are available during the next recovery.
Revise the recovery time objective to match the observed restoration time and report the change to senior management.
Purchase faster backup media and continue using the existing recovery sequence to preserve procedural consistency.
Map recovery dependencies, revise the runbook sequence, and validate it through a timed restoration exercise. (correct answer)

Explanation: When a recovery process fails to meet its recovery time objective (RTO), your first instinct should be to diagnose why, not just accept the failure or adjust the target. This question tests whether you understand that effective disaster recovery improvement requires both fixing the root cause and validating the fix — not just patching around the symptom. The scenario is explicit: the runbook omitted identity and name-resolution dependencies, forcing responders to rebuild critical infrastructure before applications could even start. This is a sequencing and documentation failure. The best fix, reflected in D, attacks that root cause directly — map the missing dependencies, correct the runbook's restoration order, and then prove the fix works by running a timed exercise. That timed exercise is crucial because it validates both accuracy (correct sequence) and speed (RTO compliance). Choice A is a red herring. More backup copies or capacity does nothing to fix a sequencing problem — the bottleneck wasn't missing data, it was missing procedural knowledge about what to restore first. Choice B is perhaps the most dangerous distractor: revising the RTO upward to match poor performance is rationalizing failure rather than fixing it. RTOs are business requirements; you don't lower the bar because you stumbled. Choice C mistakes procedural consistency for procedural correctness. If the existing sequence is broken, preserving it — even with faster media — guarantees the same failure, just slightly quicker. For the exam, remember: when a question combines a root-cause failure with a missed performance target, the correct answer will always address both the cause and include validation. Anything that skips either step is incomplete.