Cyber Security Quiz: Anti Malware And Allowlisting
10 questions · exam conditions
0:00
Anti Malware And AllowlistingQuestion 1 of 10

Anti-malware scanning causes latency on a server that processes large archival files. An administrator excludes the entire data volume from real-time and scheduled scanning. An attacker subsequently stores malware in that volume and launches it through a scheduled task.

Which change best addresses the underlying control weakness while considering the performance requirement?

Retain the volume-wide exclusion but require users to rename executable files before placing them on the volume.
Replace anti-malware with allowlisting, because allowlisting prevents exploitation of any approved application on the server.
Disable real-time scanning server-wide and perform a single full scan only after each archival processing cycle completes.
Narrow the exclusion to validated files or processes, and add compensating execution restrictions and behavior monitoring.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Anti Malware And Allowlisting

Practice Anti Malware And Allowlisting 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 Anti Malware And Allowlisting, 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

Anti-malware scanning causes latency on a server that processes large archival files. An administrator excludes the entire data volume from real-time and scheduled scanning. An attacker subsequently stores malware in that volume and launches it through a scheduled task.

Which change best addresses the underlying control weakness while considering the performance requirement?

  1. Retain the volume-wide exclusion but require users to rename executable files before placing them on the volume.
  2. Replace anti-malware with allowlisting, because allowlisting prevents exploitation of any approved application on the server.
  3. Disable real-time scanning server-wide and perform a single full scan only after each archival processing cycle completes.
  4. Narrow the exclusion to validated files or processes, and add compensating execution restrictions and behavior monitoring. (correct answer)
Explanation: When you see a question about security controls and performance trade-offs, ask yourself: does this solution actually eliminate the vulnerability, or does it just shift or ignore it? The underlying weakness here isn't the anti-malware software itself — it's an overly broad exclusion that removed protection from an entire volume, creating a blind spot attackers could exploit. Option D is correct because it applies the principle of least privilege to scanning exclusions: instead of excluding everything, you exclude only what's validated (specific archival files or trusted processes), then layer in compensating controls — execution restrictions (preventing unauthorized binaries from running) and behavior monitoring (detecting suspicious activity even without signature scanning). This directly closes the gap without sacrificing the performance gains the administrator originally needed. Option A fails immediately because renaming executables is trivially bypassed. Attackers can rename files back, and many malware payloads don't rely on file extensions to execute. This is security theater, not a real control. Option B misrepresents allowlisting: while allowlisting is a strong control, it does not prevent approved applications from being exploited or misused — a scheduled task running an allowlisted interpreter (like PowerShell) could still execute malicious payloads. The claim that it "prevents exploitation of any approved application" is factually wrong. Option C actually worsens the posture: disabling real-time scanning server-wide expands the attack surface dramatically, and a single post-cycle scan still leaves a wide window of exposure during processing. Study tip: On security exam questions, watch for answers that sound convenient but trade comprehensive protection for simplicity — the best answer almost always narrows the scope of a control rather than eliminating it entirely.

Question 2

A security dashboard shows a remote endpoint as compliant based on its last report from 18 hours ago. Since that report, the endpoint has left the corporate network, and an attacker with local administrative access has attempted to disable the anti-malware agent.

Which interpretation of the dashboard status is most accurate?

  1. The endpoint remains protected because a compliant status cannot be reported unless tamper protection is currently active.
  2. The endpoint is compromised because any reporting delay confirms the anti-malware service has been successfully disabled.
  3. The endpoint remains compliant until the console receives direct confirmation that malware has executed on the system.
  4. The status reflects only the last check-in; current assurance requires verifying report freshness and agent health. (correct answer)
Explanation: When you see questions about endpoint compliance dashboards, think about the difference between recorded state and current state — security tools can only report what they've observed, and a stale report tells you nothing about what happened afterward. That's exactly what makes D the right interpretation here. The dashboard shows "compliant" based on a check-in from 18 hours ago. Since then, the endpoint left the network and an attacker with local admin rights attempted to tamper with the anti-malware agent. The dashboard hasn't updated because the agent can no longer report back. The status is a snapshot frozen in time, not a live health signal. True assurance requires asking two questions: how fresh is this report, and is the agent itself still healthy and communicable? A is dangerously wrong because it assumes tamper protection is foolproof. An attacker with local administrative privileges may be able to bypass or forcibly stop tamper protection — that's precisely why this scenario is a threat. Compliant status does not retroactively guarantee the agent survived the attack. B overcorrects in the other direction. A reporting delay alone doesn't confirm the agent was successfully disabled — it might reflect a network connectivity issue, a VPN disconnection, or normal check-in timing. Jumping to "compromised" from silence alone is an assumption, not a conclusion. C confuses detection with protection. Waiting for confirmed malware execution before questioning compliance is a reactive, dangerous standard — by then, real damage may already be done. Your takeaway: on security exams, always treat a stale compliance report as an unknown, not a green light. Report freshness is a core assurance control, not a formality.

Question 3

A company creates an allowlisting rule that permits any executable signed by a major software vendor. Attackers later obtain the vendor's signing certificate and use it to sign a malicious utility. The certificate has not yet been revoked, and endpoints can validate its signature.

What limitation of the allowlisting design is most directly demonstrated?

  1. Publisher rules prove that code is vulnerability-free but do not verify whether its installation path is protected.
  2. Publisher rules can trust malicious signed code when signer scope is broad and revocation has not propagated. (correct answer)
  3. Publisher rules calculate fixed file hashes, so every signed update must receive a separate approval entry.
  4. Publisher rules block all newly signed software until behavioral analysis has classified the executable as benign.
Explanation: When you see questions about application allowlisting, focus on what the rule actually validates and what it assumes — this question tests whether you understand the trust boundary a publisher-based rule creates and where that boundary breaks down. Publisher rules work by trusting any executable carrying a valid signature from an approved certificate. This design implicitly assumes that the signing certificate itself remains uncompromised. When an attacker steals that certificate and signs malware, the endpoint sees a valid signature from a trusted publisher — and allows execution. Critically, because the certificate hasn't been revoked, the normal safety net (certificate revocation) hasn't kicked in. Two compounding weaknesses appear simultaneously: the rule's scope is too broad (anything the vendor signs is trusted) and revocation hasn't propagated to stop the bleeding. That's exactly what B describes, making it correct. A is wrong because it introduces a red herring about installation paths. Path-based rules are a separate allowlisting mechanism; the passage never mentions path restrictions, and the core failure here is about blind trust in a stolen certificate, not an unprotected directory. C is wrong because it mischaracterizes how publisher rules work. Hash-based rules require per-file approval entries, but publisher rules deliberately avoid that — they trust by signer identity, not file hash. C confuses two different rule types. D is wrong because it describes behavior analysis or sandboxing, not publisher rules at all. Publisher rules make a static trust decision at signature verification; they don't queue executables for behavioral classification. Study tip: Always ask "what does this rule actually verify?" Publisher rules verify who signed it, not what it does — that gap is the recurring exam trap.

Question 4

Anti-malware detects and quarantines an information-stealing program several minutes after it executes. The console reports that the malicious file can no longer run from its original location.

What should the incident handler infer from the quarantine result?

  1. Quarantine contains the detected file but does not prove that stolen credentials or persistence have been remediated. (correct answer)
  2. Quarantine reverses changes made by the program but cannot restore the file to its original directory.
  3. Quarantine proves execution was prevented because detected files are isolated before any instructions can run.
  4. Quarantine removes all related components because anti-malware associates each payload with its complete attack chain.
Explanation: When you see an incident-response question involving anti-malware actions, shift your thinking from "was the threat stopped?" to "what exactly did this tool accomplish — and what gaps remain?" Quarantine is a containment action, not a full remediation. Quarantine isolates the detected executable so it can no longer run from its original path. That is meaningful — but notice the timeline in the passage: the program executed first, then was detected minutes later. That window is critical. During that time, the malware could have harvested credentials, written registry keys for persistence, dropped additional payloads, or exfiltrated data. Quarantining the original file does none of the following: remove credentials it already copied, undo persistence mechanisms it installed, or recall data it sent outbound. Answer A is correct because it accurately frames quarantine as a containment step that still leaves remediation work unfinished. Answer B is wrong because quarantine does not reverse system changes — that is the role of remediation or rollback tools. It also mischaracterizes quarantine as something that can't restore a file; the restore function is typically available in most anti-malware consoles. Answer C describes prevention, not detection. The passage explicitly states the file executed, then was detected afterward — so execution was never prevented. This is a classic trap that conflates "blocked" with "quarantined after the fact." Answer D overstates anti-malware capability. Most tools detect and isolate the specific identified file; they do not automatically map and eliminate every component of a multi-stage attack chain. Study tip: On security exams, always distinguish between the phases of incident response — containment, eradication, and recovery are separate steps, and no single tool completes all three automatically.

Question 5

During an allowlisting pilot, a business-critical application occasionally launches temporary helper binaries with changing hashes. Security proposes allowing the entire temporary directory by path, while operations proposes disabling enforcement across all pilot endpoints.

Which approach best balances availability with the security purpose of allowlisting?

  1. Use audit data to identify the helpers, then create the narrowest sustainable rules and monitor exceptions. (correct answer)
  2. Permit the temporary directory by path because rapidly changing binaries cannot be controlled by any other attribute.
  3. Disable enforcement for the pilot because false positives demonstrate that default-deny controls are unsuitable.
  4. Approve every observed temporary binary automatically because execution during the pilot establishes business necessity.
Explanation: When evaluating allowlisting decisions, always ask yourself: does this solution preserve the principle of default-deny while solving the operational problem, or does it simply abandon that principle for convenience? Allowlisting exists to ensure only known, approved software executes — so any "fix" that guts that guarantee isn't really a fix. The strongest approach is A. By using audit data to identify exactly which helper binaries are causing blocks, you can craft narrow, targeted rules — perhaps based on file path patterns, parent process, or signing certificates — rather than broad exceptions. This keeps enforcement active, minimizes the attack surface, and gives you visibility through monitored exceptions. It's the only option that actually solves the problem without sacrificing the security goal. B is tempting because changing hashes do make hash-based controls impractical, but concluding that path-based allowlisting of an entire temporary directory is the best solution is a logical leap. Temporary directories are a favorite staging ground for malware precisely because they're writable and often less scrutinized. This option also falsely assumes path is the only alternative attribute — parent process, digital signature, or behavior-based rules may all apply. C commits a classic logical error: concluding that false positives prove the control is wrong, rather than that the configuration needs refinement. Default-deny is not unsuitable just because it blocks unexpected things — that's literally what it's supposed to do. D essentially automates approval based on the fact that something ran, which is circular reasoning. Execution during a pilot doesn't establish legitimacy; it just means enforcement wasn't working yet. The key study takeaway: on security design questions, always favor the answer that refines controls rather than removes them.

Question 6

To accelerate an allowlisting deployment, an administrator enables learning mode on a reference workstation for one week. Unknown programs observed during that period are converted into allow rules. The workstation had not been reimaged or independently verified before learning began.

What is the most significant risk in this deployment method?

  1. Learning mode will reject legitimate programs because observed files cannot be converted into allowlisting policies.
  2. Learning mode may legitimize preexisting malware, so the baseline should be established from a trusted state. (correct answer)
  3. Learning mode will invalidate digital signatures because approved files receive organization-specific cryptographic hashes.
  4. Learning mode may remove operating-system files that do not execute during the observation period.
Explanation: When you see a question about application allowlisting or baseline security, always ask yourself: what is the trust level of the starting point? The entire value of an allowlist depends on whether the programs being approved are actually safe — which means the reference system must be in a known-good state before observation begins. Here, the administrator skipped reimaging or independently verifying the workstation before enabling learning mode. If malware was already present and quietly running during that week, learning mode would observe it executing and automatically promote it into an allow rule. The organization has now officially blessed the malware to run — defeating the entire purpose of allowlisting. This is why B is correct: learning mode can legitimize preexisting threats, and the baseline must originate from a verified, trusted state. A describes a behavior that simply doesn't happen — learning mode is specifically designed to convert observed files into allow rules, not reject them. This answer reverses the actual function of the feature. C is a fabrication. Learning mode doesn't interfere with digital signatures or generate "organization-specific cryptographic hashes" that overwrite existing ones. Allowlisting tools typically use existing hash values and certificates as criteria; they don't invalidate them. D inverts the logic entirely. Learning mode adds permissions for what it observes; it does not delete or quarantine files that don't execute. Nothing in the allowlisting process removes OS files passively sitting on disk. For the exam, remember this principle: a security baseline is only as trustworthy as the system it was taken from. Any time a question involves baselining or learning mode, immediately check whether the source system's integrity was verified first.

Question 7

A malicious document launches an approved command interpreter, which retrieves an encoded command and executes it directly in memory. No new executable is written to disk. A later signature-based scan reports no infected files.

Which conclusion and defensive improvement are most appropriate?

  1. The endpoint is clean because persistence requires a malicious executable; increase the frequency of file scans.
  2. The document was harmless because the interpreter was approved; suppress alerts involving trusted operating-system tools.
  3. File scanning can miss memory-resident activity; add script inspection and behavior-based process monitoring. (correct answer)
  4. The command must have altered executable hashes; rebuild the allowlist from the current endpoint contents.
Explanation: When you see a scenario where malware operates without dropping files to disk, you're being tested on fileless malware and the limits of traditional defenses. The core concept is that signature-based scanners look for known malicious patterns in stored files — but if nothing is written to disk, there's nothing for them to find. In this scenario, a malicious document hijacks a legitimate interpreter (think PowerShell or cmd.exe), downloads an encoded payload, and runs it entirely in memory. The scan comes back clean — not because the system is safe, but because the attack was designed to evade exactly that type of detection. This is why C is correct: file scanning has a fundamental blind spot for memory-resident activity. The right defensive response is layering in script content inspection (which analyzes what scripts actually do, not just whether they're signed) and behavior-based process monitoring (which flags suspicious process chains, like Word spawning PowerShell). A is wrong because it rests on a false premise — persistence does not require a malicious executable. Fileless attacks can achieve persistence through registry modifications, scheduled tasks, or WMI subscriptions. Scanning more often doesn't help if the method is inherently undetectable that way. B is dangerously wrong and represents a classic attacker strategy called "living off the land." Using trusted, approved tools is precisely how attackers avoid detection — suppressing those alerts would blind you to the most sophisticated threats. D is a distractor that misunderstands the attack. The interpreter wasn't tampered with; it was used legitimately. Rebuilding an allowlist addresses nothing here. Study tip: On security exams, fileless/living-off-the-land attacks almost always signal that signature or file-based controls are insufficient — look for answers that add behavioral or in-memory detection.

Question 8

An organization enforces application allowlisting with rules based on cryptographic hashes. A trusted accounting application is approved and runs normally. After the vendor installs a legitimate security update in the same directory, the application is blocked even though its digital signature remains valid.

Which explanation and corrective action best preserve the intent of the control?

  1. The update changed the file hashes; validate and approve the new hashes or adopt narrowly scoped publisher rules. (correct answer)
  2. The update changed the installation path; restore the original path and retain the existing hash rules.
  3. The update invalidated all vendor signatures; disable signature verification until the vendor issues another certificate.
  4. The update triggered heuristic detection; add the entire application directory to the anti-malware exclusion list.
Explanation: When you see a question about application allowlisting, focus on what the control actually examines — in hash-based rules, the system generates a cryptographic fingerprint of each approved file and blocks anything whose fingerprint doesn't match, regardless of other attributes like signatures or location. Here's what happened in the scenario: a legitimate update modified the application's binary files. Even though the update is trustworthy, any change to a file's contents — even a single byte — produces a completely different hash. That's why the app is blocked: the stored approved hash no longer matches the updated file's hash. The fix is to validate that the update is genuine, then either approve the new hashes or switch to publisher/certificate-based rules scoped narrowly to that vendor. This is exactly what A describes, and it preserves the intent of the control by maintaining strict verification rather than weakening it. B is wrong because the scenario never mentions a path change — the update occurred in the same directory. Restoring a path wouldn't fix a hash mismatch and misdiagnoses the problem entirely. C is wrong and dangerous. Digital signatures remained valid according to the passage, so the premise is false. Disabling signature verification "temporarily" is a classic security erosion trap — it solves nothing here and introduces real risk. D confuses allowlisting with anti-malware heuristics. These are separate controls. Exempting a directory from malware scanning doesn't resolve an allowlist hash mismatch and creates a blind spot in your defenses. Study tip: On security exams, always ask which layer of control is actually being described — allowlisting, signatures, and heuristics each operate independently. Mixing them up is the most common trap in these questions.

Question 9

A laptop's anti-malware product combines local signatures with cloud reputation analysis. The laptop remains disconnected from all networks for several days. Its local engine is enabled, but its signatures and reputation cache have not been updated.

Which statement best describes the protection available during the disconnection?

  1. The laptop remains fully protected because cloud classifications are automatically embedded in every local engine update.
  2. The laptop loses all anti-malware protection because local signature scanning requires continuous internet connectivity.
  3. Local controls remain available, but stale signatures and unavailable cloud analysis reduce detection of newer threats. (correct answer)
  4. The laptop can detect only signed malware because cloud reputation analysis applies exclusively to unsigned executables.
Explanation: When a security product combines local signature scanning with cloud reputation analysis, you're looking at a layered defense model. Questions like this test whether you understand what each layer does independently — and what happens when one layer goes offline. Local signature scanning works entirely on the device: the engine compares files against a database of known threat patterns stored locally. It functions without internet access. Cloud reputation analysis, however, queries remote servers to evaluate unknown or suspicious files in real time — so it fails completely when the device is disconnected. The catch with local signatures is that they go stale: any malware released after the last update won't be recognized. C captures both realities accurately — local controls keep running, but detection capability degrades because signatures are outdated and the cloud layer is simply unavailable. A is wrong because cloud classifications are not pre-embedded in local engine updates. The cloud layer is a live, separate query — not something baked into the signature package during an update cycle. B is the opposite extreme and equally false: local signature scanning is specifically designed to work offline. Losing cloud access does not eliminate local scanning. D invents a distinction the technology doesn't actually make. Cloud reputation analysis evaluates any suspicious file — not exclusively unsigned executables. Signed malware is a real category, and the cloud layer absolutely covers it. As a study tip, watch for answers that treat layered security as all-or-nothing. On security exams, the realistic answer almost always acknowledges partial protection loss rather than complete failure or complete immunity.

Question 10

An application-control policy blocks unapproved executables but allows a digitally signed administrative scripting engine required by support staff. An attacker uses that engine to execute commands from an untrusted script stored in a user-writable directory.

Which policy improvement most directly addresses this bypass without assuming the scripting engine itself is malicious?

  1. Replace publisher rules with path rules that permit every program installed under the operating-system directory.
  2. Add script-specific controls covering content inspection, constrained-mode execution, and origin or signing requirements. (correct answer)
  3. Exclude the scripting engine from anti-malware scanning so its approved commands are not flagged or interrupted.
  4. Approve the untrusted script's current hash, since the trusted engine has already processed and validated its operations.
Explanation: When you see a question about application-control bypasses, your focus should be on the granularity of trust. Allowing a trusted engine is not the same as trusting everything that engine is told to run — and that gap is exactly what this scenario exploits. The attacker isn't subverting the engine itself; they're feeding it malicious instructions from an untrusted source. B is correct because it directly closes that gap. Script-specific controls — such as PowerShell's Constrained Language Mode, content inspection, and requirements that scripts be signed or originate from trusted locations — restrict what the approved engine is allowed to do with untrusted content. The engine stays approved; only its attack surface shrinks. A is wrong because path-based rules tied to the OS directory are both overly broad and unrelated to the problem. Attackers can stage payloads in approved paths, so expanding path trust actually weakens your posture rather than hardening it. C is dangerously backwards. Excluding a scripting engine from anti-malware scanning removes a detection layer without addressing the underlying control gap. It would make the attacker's job easier, not harder. D treats the symptom as a solution. Approving the current hash of a malicious script means you've now whitelisted the threat. Hashes are static; attackers simply modify the file to generate a new one, bypassing the rule immediately on the next iteration. The strategic takeaway: on application-control questions, always ask what is trusted versus what that trusted thing is allowed to execute. Layered controls — engine approval plus script-level restrictions — are almost always the correct hardening direction.