A previously unseen application keeps appearing on corporate endpoints. One team runs a blocklist of known-bad software, another runs an application allowlist. What happens to the unknown application under each model by default?
Select an answer to reveal the explanation.
Short Explanation
A blocklist is a most-wanted poster: if you're not on it, you walk right in. An allowlist is a guest list: if you're not on it, you're not getting in. That's why the unknown app sails past the blocklist and stops cold at the allowlist.
Full Explanation
The two models differ in their default action. A blocklist denies only items it explicitly names, such as known malicious hashes, publishers or application names, and permits everything else. An unknown application is not on the list, so it runs. An allowlist permits only items it explicitly names and denies everything else, so an unknown application is blocked until someone reviews and approves it. This is the core trade-off: allowlisting is stronger against novel threats but requires operational effort to maintain, while blocklisting is easy to run but always reactive. Saying both models block the application until a reputation verdict is published describes a reputation-gated control, not the default behavior of a simple blocklist. Claiming the blocklist treats unknown files as suspicious while the allowlist permits them reverses the definitions. Saying both models allow the application because it lacks a signature applies blocklist logic to the allowlist, which never depends on signatures. Exam caveat: many endpoint products combine both models with reputation and behavioral analysis, but the exam tests the default logic of each list. Operational check: introduce a harmless unsigned test application and record whether each environment allows or blocks it.