All questions
Question 1
After deploying EDR, a company receives frequent alerts when administrators use signed scripting tools to manage servers. Attackers are also known to abuse the same tools. Disabling the alerts would reduce workload but create a detection gap.
What is the most appropriate tuning approach?
- Allow all activity performed by signed scripting tools because a valid signature establishes benign intent.
- Disable behavioral monitoring on managed servers and rely on periodic malware scans for suspicious scripts.
- Add contextual exceptions for verified workflows while continuing to detect unusual users, parents, or targets. (correct answer)
- Quarantine every signed scripting tool after its first execution to eliminate future ambiguous alerts.
Explanation: When tuning an EDR, the core challenge is reducing false positives without creating detection gaps. The key insight is that context — not just the tool being used — determines whether activity is malicious. Legitimate administrator workflows are predictable: specific users, specific parent processes, specific target systems, at expected times. Attackers using the same tools will deviate from that pattern.
Answer C is correct because it preserves detection capability while reducing noise. By building exceptions tied to verified context (who is running the tool, what launched it, what it's touching), your EDR still fires when an unusual user, an unexpected parent process like a phishing email, or an atypical target system is involved. You get signal reduction without blind spots.
Answer A is the most dangerous distractor. A valid digital signature only proves the file hasn't been tampered with — it says nothing about how the tool is being used. Attackers routinely abuse legitimately signed tools like PowerShell and WMI in "living-off-the-land" attacks precisely because signatures grant implicit trust.
Answer B trades real-time behavioral detection for periodic scanning, which is a significant regression. Malware scans catch known signatures; they miss novel scripts or fileless attacks that EDR behavioral monitoring is specifically designed to detect.
Answer D is operationally absurd. Quarantining scripting tools after first execution would cripple administration workflows and still wouldn't prevent re-execution or new variants.
Study tip: On security operations questions, watch for answers that eliminate a threat by eliminating visibility — that trade always makes you less secure, not more efficient.
Question 2
EDR telemetry shows a word processor launching a script engine, which launches a system utility that contacts an unfamiliar domain. The user confirms opening an expected document received from a business partner.
Which interpretation is most defensible based on the EDR evidence?
- The activity is benign because the user expected the document and therefore authorized all resulting processes.
- The unfamiliar domain proves the business partner intentionally delivered malware to the organization.
- The system utility is the root cause because it was the final process observed before network communication.
- The process lineage is suspicious and supports investigation, but it does not by itself establish attacker identity or intent. (correct answer)
Explanation: When analyzing EDR telemetry, your job is to reason from evidence to defensible conclusions — not leap to certainty. A key principle in incident response is that process lineage (the parent-child chain of processes) can reveal suspicious behavior patterns, but it rarely tells you who is responsible or why without further investigation.
Here, the chain — word processor → script engine → system utility → external domain contact — is a classic indicator of a potentially malicious macro or embedded script. This pattern matches known malware delivery techniques, making it genuinely suspicious and absolutely worth investigating. That's exactly what D captures: the lineage raises a red flag and justifies escalation, but it doesn't alone confirm attacker identity or intent.
A is wrong because user expectation does not equal authorization for all downstream process behavior. Malware frequently piggybacks on legitimate, expected documents — that's the entire premise of spear-phishing. The user confirming they opened the file is useful context, not a clearance.
B overclaims. The unfamiliar domain is suspicious, but it could belong to a legitimate service, a compromised third-party host, or an attacker entirely unrelated to the business partner. Attributing intent to the partner from this evidence alone is a logical leap the data doesn't support.
C confuses sequence with causation. The system utility didn't cause the network communication in a forensic sense — it was an intermediate node in a chain initiated earlier. The root cause investigation must trace back to the document and how it triggered execution.
Your study tip: on security analysis questions, watch for answers that overclaim — attribution, intent, and root cause all require more evidence than a single telemetry snapshot provides.
Question 3
A threat-intelligence provider publishes a new command-and-control domain associated with an intrusion that began six weeks earlier. The organization currently sees no endpoints connecting to the domain, but it retained searchable EDR telemetry for ninety days.
What is the best use of the retained EDR data?
- Add the domain to an antivirus file-signature list and wait for a matching executable to appear.
- Conclude that the organization was unaffected because no endpoint is contacting the domain at present.
- Perform a retrospective hunt for prior contacts and examine the associated processes and endpoint actions. (correct answer)
- Delete telemetry older than the intelligence report because events recorded before publication lack detection value.
Explanation: When you see a question involving threat intelligence arriving after a potential intrusion window, think about the difference between real-time detection and retrospective investigation. The value of retained telemetry is precisely that it lets you go back and answer the question: "Were we affected before we knew to look?"
Here, the intelligence report identifies a C2 domain linked to activity that started six weeks ago. The organization has 90 days of EDR telemetry — meaning the entire relevant window is still searchable. The best action, answer C, is to perform a retrospective threat hunt: query the historical telemetry for any DNS lookups, network connections, or process activity tied to that domain. If you find hits, you can trace the associated processes, lateral movement, persistence mechanisms, and data access — turning a missed detection into a full incident reconstruction.
A is wrong because antivirus file-signature lists address future file-based threats, not past network behavior. Adding a domain to a signature list does nothing to reveal what already happened. B commits a critical logical error: the absence of current connections tells you nothing about past ones. The malware may have already completed its mission and gone quiet weeks ago. Concluding "unaffected" without checking the historical record is negligent. D is backwards — telemetry recorded during the intrusion window is the most valuable data you have. Deleting it because it predates the intelligence report would destroy your only evidence.
A useful pattern to remember: new threat intelligence + retained telemetry = mandatory retrospective hunt. On exam questions, any answer that ignores historical data when it's available is almost certainly a distractor.
Question 4
A malicious process sends data through an encrypted HTTPS connection. A network sensor can identify the destination and traffic volume but cannot inspect the encrypted content. EDR is installed and functioning on the originating endpoint.
What additional visibility can EDR most reasonably provide?
- A guaranteed reconstruction of the complete plaintext session by leveraging the endpoint's application and encryption context.
- Attribution of the connection to a specific process, along with related file, user, and execution-chain telemetry. (correct answer)
- Definitive proof that the destination is malicious, because any connection initiated by a previously unknown process is inherently suspicious.
- A full replacement for network monitoring, since endpoint telemetry captures every intermediate routing and forwarding event across the path.
Explanation: When a question pairs a network sensor with an EDR tool, you should immediately ask: what does each layer uniquely see? Network sensors observe traffic flows, volumes, and destinations — but encrypted payloads are opaque to them. EDR lives on the endpoint, giving it a fundamentally different vantage point: the operating system, process table, file system, and user context that existed before the packet was encrypted.
That's exactly why B is correct. EDR can tell you which process opened the HTTPS connection, who launched that process, what parent process spawned it, what files it touched, and what the full execution chain looked like. This telemetry doesn't require decrypting anything — it's harvested at the source, before encryption happens. That process-attribution data is precisely the "additional visibility" the network sensor cannot provide.
A is wrong because EDR does not routinely reconstruct plaintext sessions. While EDR could theoretically hook certain crypto libraries, this is not a standard, guaranteed capability — and the word "guaranteed" is a red flag. Treat absolute claims cautiously on security exams.
C contains a classic logical fallacy: an unknown process initiating a connection is suspicious, but that alone is never definitive proof of malice. Unknown ≠ malicious. EDR surfaces indicators; analysts must investigate.
D overstates EDR's scope dramatically. EDR sees activity on the endpoint; it has no visibility into intermediate routers, switches, or network hops along the path. Network monitoring remains irreplaceable for that layer.
Study tip: On tool-capability questions, match each tool to its layer of visibility — endpoint, network, or cloud — and eliminate answers that cross those boundaries or use absolute language like "guaranteed" or "complete."
Question 5
Several endpoints begin rapidly renaming files and producing high rates of write operations. The EDR platform detects the pattern as probable ransomware, but the malware's file hash has never been observed before.
Which EDR capability is most relevant to limiting damage in this situation?
- Behavior-based detection combined with automated process termination or endpoint isolation. (correct answer)
- Signature-based quarantine held until the new file hash is confirmed and distributed by multiple threat-intelligence vendors.
- Scheduled full-disk scans configured to run automatically once the suspected encryption activity has finished on each endpoint.
- Passive alert forwarding to the SIEM that preserves complete telemetry records but performs no direct endpoint response actions.
Explanation: When you see a scenario involving unknown malware causing active damage, the key question to ask yourself is: what stops the bleeding right now? EDR platforms are designed not just to detect threats, but to respond to them — and the speed and nature of that response determines how much damage occurs.
Because the malware's file hash is brand new, signature-based methods are completely blind to it. What can detect it is behavioral analysis — the EDR sees suspicious patterns like mass file renaming and abnormal write rates and flags them as ransomware-like behavior, regardless of whether the specific sample is known. Answer A is correct because it combines that behavioral detection with an immediate automated response: killing the malicious process or isolating the endpoint from the network. This containment happens in seconds, without waiting for human review, which is critical when ransomware can encrypt thousands of files per minute.
Answer B fails precisely because it depends on signature confirmation. Waiting for multiple threat-intelligence vendors to validate a new hash could take hours or days — your endpoints are fully encrypted by then. Answer C is almost comically counterproductive: scheduling scans after encryption activity finishes means you've already lost the data. That's forensics, not prevention. Answer D describes a purely passive posture — forwarding alerts to a SIEM preserves logs beautifully but does nothing to stop an active attack. Telemetry without action is observation, not defense.
The study tip here: on EDR questions involving active, ongoing threats with unknown hashes, behavior-based detection paired with automated containment is almost always the answer. Unknown = signatures useless; active = speed matters most.
Question 6
An EDR platform generates a high-confidence alert for credential theft on an employee laptop. The laptop is connected remotely through the internet, and analysts need to stop lateral movement while retaining the ability to collect evidence through the EDR console.
Which response action best meets both objectives?
- Power off the laptop immediately so that all network communication and malicious execution stop.
- Use EDR network isolation while allowing the agent's management communication, if the product supports it. (correct answer)
- Block the detected credential-theft executable while leaving all other network connections available.
- Remove the laptop's EDR agent so the suspected attacker cannot manipulate its response functions.
Explanation: When you see an incident response question with two competing objectives — stopping an attack AND preserving investigative capability — your job is to find the option that satisfies both simultaneously, not just one.
Network isolation is a core EDR containment technique that severs a compromised endpoint from the broader network, preventing lateral movement and credential reuse. The critical nuance in option B is the phrase "while allowing the agent's management communication." Most enterprise EDR platforms (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) maintain a dedicated, encrypted channel to their cloud console even during full network isolation. This means analysts can still run live queries, pull forensic artifacts, kill processes, and collect evidence — all while the attacker is cut off from the rest of the environment. Option B is correct precisely because it honors both objectives without compromise.
Option A fails the second objective entirely. Powering off the laptop destroys volatile memory (running processes, network connections, encryption keys) and severs your EDR console access, making evidence collection impossible until the device is physically recovered. Option C is far too narrow — blocking one executable leaves all network paths open, meaning the attacker can pivot laterally, exfiltrate data, or use other tools. It stops a single indicator, not the threat. Option D is counterproductive: removing the EDR agent eliminates your only remote forensic and response capability, essentially blinding yourself and handing the attacker more freedom.
A useful mental rule: in EDR containment questions, always look for the answer that restricts attacker movement while preserving analyst visibility. Those two properties together define effective, forensically-sound containment.
Question 7
A security team forwards EDR alerts into its SIEM but retains only alert summaries there. During an investigation, analysts can see an alert titled "Suspicious script execution," but they cannot determine which document launched the script or what child processes followed.
Which change would most directly close the investigative gap?
- Retain queryable EDR event telemetry containing process lineage and related endpoint activity. (correct answer)
- Increase firewall log retention so analysts can reconstruct the endpoint's complete process hierarchy.
- Replace behavioral EDR rules with file-hash rules to make each alert independently conclusive.
- Send fewer EDR alerts to the SIEM so analysts can review each summary more carefully.
Explanation: When investigating endpoint incidents, think about the difference between alert summaries and raw telemetry. A summary tells you something suspicious happened; telemetry tells you exactly what happened, in what order, and why. This question tests whether you understand what data is actually needed to reconstruct an attack chain.
The investigative gap here is precise: analysts can see that a suspicious script executed, but cannot identify the parent document that launched it or the child processes that followed. This is a process lineage problem. Option A solves it directly — queryable EDR telemetry captures the full process tree, parent-child relationships, command-line arguments, and associated endpoint activity. With that data in the SIEM, analysts can trace exactly which Word document (for example) spawned PowerShell and what network connections followed.
Option B is tempting but fundamentally wrong — firewall logs record network traffic, not endpoint process hierarchies. No amount of firewall log retention will show you what child processes ran on a host. Option C moves in the wrong direction entirely; replacing behavioral rules with file-hash rules makes detections less contextual, not more. Hash-based rules fire on known-bad files but produce no process lineage whatsoever. Option D is counterproductive — reducing alert volume doesn't add investigative detail to the alerts that remain. You'd still be staring at the same content-poor summaries.
A useful study tip: on security operations questions, always ask "what data source actually contains the information needed?" Network tools answer network questions; endpoint tools answer endpoint questions. Matching the right telemetry source to the investigative gap is a core SOC analyst skill.
Question 8
An endpoint stops sending EDR heartbeats shortly after generating alerts for privilege escalation and attempts to disable security services. The EDR console now lists the endpoint as offline, although network infrastructure shows it is still communicating externally.
How should the security team interpret the missing EDR telemetry?
- As evidence that remediation succeeded, because an offline EDR agent indicates malicious processes were terminated.
- As a possible sensor-evasion event that requires corroboration and containment through other available controls. (correct answer)
- As proof that the external traffic is benign, because active malware would normally restore the EDR heartbeat.
- As an ordinary connectivity failure that should be ignored until the endpoint reconnects to the EDR console.
Explanation: When an EDR agent goes silent immediately after generating privilege-escalation and defense-tampering alerts, you should treat the silence itself as a suspicious signal — not a neutral event. This question tests your understanding of sensor evasion and the principle that absence of telemetry is not absence of threat.
Sophisticated attackers routinely kill or blind security agents as a deliberate step in their playbook. The sequence here — escalate privileges → attempt to disable security tools → EDR goes dark — is a textbook attacker progression. Meanwhile, the endpoint is still communicating externally, which means the machine is alive and active. That combination (silent sensor + active network traffic) strongly suggests the agent was intentionally neutralized. Answer B is correct because it treats the missing telemetry as a potential evasion event and calls for corroboration through other controls (firewall logs, network flow data, SIEM alerts) and immediate containment — exactly the right incident-response posture under uncertainty.
Answer A is dangerously backwards. A dead EDR agent does not mean malware was removed; it more likely means malware succeeded in removing a defender. Answer C makes an illogical assumption — there is no rule that active malware must restore an EDR heartbeat; in fact, leaving the agent dead keeps the attacker stealthier. Answer D treats a silence-after-alerts pattern as routine connectivity noise, which ignores the critical context of the preceding alerts and the continued external traffic.
Study tip: On security exams, whenever you see a sensor go offline in conjunction with suspicious behavior, that correlation is the red flag — never interpret missing telemetry in isolation.
Question 9
A workstation's traditional antivirus scan reports no malicious files. EDR telemetry shows a spreadsheet application launching a command interpreter, which then downloads an encoded script into memory and creates a scheduled task. No executable is written to disk.
Which conclusion best reflects the conceptual value of EDR in this scenario?
- The activity is probably benign because an endpoint compromise requires antivirus to identify a malicious file.
- The activity can be confirmed as malicious solely because a command interpreter was launched by another application.
- The correlated behaviors may reveal a fileless attack even though no known malicious file was detected. (correct answer)
- The scheduled task proves persistence occurred, so collecting additional endpoint evidence is unnecessary.
Explanation: When you see a question comparing traditional antivirus to EDR capabilities, focus on what each tool actually detects — antivirus matches known malicious files, while EDR correlates behavioral telemetry across processes, memory, and system events over time.
In this scenario, the EDR captures a telling chain: a spreadsheet spawning a command interpreter, which pulls an encoded script into memory and registers a scheduled task — all without writing a file to disk. This is the textbook signature of a fileless attack, a technique specifically designed to evade file-based detection. Because no malicious file ever touches disk, antivirus has nothing to scan. EDR's power is recognizing that this sequence of behaviors, even without a known-bad file, is highly suspicious and warrants investigation. That makes C the correct answer — correlated behavioral patterns can surface fileless threats that bypass traditional detection entirely.
A is wrong because it assumes endpoint compromise requires a detectable malicious file. Fileless attacks exist precisely to disprove this assumption — no file is needed to cause damage. B is wrong because a command interpreter launching from another application isn't inherently malicious; legitimate administrative scripts do this regularly. A single behavior in isolation cannot confirm malicious intent without broader context. D is wrong because detecting a scheduled task confirms a potential persistence mechanism, but it doesn't eliminate the need for further investigation — you still need to understand what the task executes, its origin, and the full attack chain.
Your study tip: on security exams, whenever a scenario mentions "no file written to disk" paired with behavioral anomalies, think fileless attack and EDR's behavioral correlation — that pairing is a reliable pattern.
Question 10
An EDR rule detects process injection, terminates the target process, and quarantines the originating file. Ten minutes later, analysts discover that the same account authenticated successfully to a server from another endpoint.
Which statement most accurately characterizes the EDR outcome?
- The EDR prevented the incident because terminating the detected process guarantees that no earlier actions succeeded.
- The EDR only detected the incident because response requires an analyst to perform every containment action manually.
- The EDR failed to respond because successful response requires automatically isolating every endpoint using the account.
- The EDR detected and responded locally, but those actions do not prove the broader incident was contained. (correct answer)
Explanation: When you see a question about EDR (Endpoint Detection and Response) outcomes, ask yourself: what did the tool actually accomplish, and what remains unknown? EDR operates at the endpoint level — it can detect, terminate, and quarantine locally, but those actions have a defined scope.
In this scenario, the EDR did real work: it identified process injection, killed the malicious process, and quarantined the source file. That's both detection and response. However, ten minutes later the same account authenticates from a different endpoint — meaning the threat actor may have already moved laterally, harvested credentials, or established persistence before the EDR acted. The local response was real, but it doesn't prove the overall incident was contained. That's exactly what D captures.
A is wrong because it assumes terminating a process retroactively prevents anything that happened before termination. Earlier actions — credential theft, data exfiltration, backdoor installation — could have already succeeded. Termination is not a time machine.
B is incorrect because the scenario explicitly describes automated EDR actions (termination, quarantine). B falsely claims no response occurred and that all containment requires manual analyst work, which contradicts what EDR tools are designed to do.
C sets an unreasonably absolute standard — claiming the EDR "failed" because it didn't automatically isolate every endpoint using that account. That would describe a SOAR-level or identity-based response, not a failure of EDR. The EDR did respond; it just responded locally.
Study tip: On security operations questions, always distinguish scope of action from success of outcome — a tool can respond correctly within its boundaries while the broader incident remains unresolved.