Refer to the Exhibit Practice Questions

The resource identifier should include the container itself.

Why it fails: A container-scoped list requires the resource identifier to end at the container, but this policy omits it, so the request never matches the granted action. Adding the container is tempting because resource ARNs do scope permissions; however, that is the fix, not the fault, and the stem asks for the cause.

The effect should be Deny.

Why it fails: Deny would block access outright, yet the error stems from the action or resource not matching the Allow statement, not from an explicit deny. Deny is tempting because it overrides allows in IAM evaluation, and would be correct when you must guarantee a principal can never perform an action.

The user lacks encryption keys.

Why it fails: Encryption keys govern decrypting stored data, not listing container objects; listing requires the appropriate blob or container read permission in the role assignment or access policy. It tempts because missing keys do cause access failures, but only for encrypted read or write operations, not enumeration.

Fail-safe

Why it fails: Fail-safe means a system defaults to a secure state on failure, not that privileged accounts are restricted. Permitting root SSH login violates least privilege, since administrators should operate through named accounts with sudo. Fail-safe applies to control failure design, such as a lock defaulting to locked.

Defense in depth

Why it fails: Defence in depth layers independent controls so one failure does not expose the system. Root SSH login is a single excessive privilege granted to an account, which least privilege prohibits. Defence in depth would instead mean combining key authentication, network restrictions and monitoring alongside disabling root access.

Separation of duties

Why it fails: Separation of duties splits a sensitive task across different people to prevent fraud, such as one person creating a vendor and another approving payment. Root SSH login concerns excessive privilege held by one account, not task division. Least privilege is the principle breached.

The condition syntax is incorrect and causes all requests to be evaluated incorrectly.

Why it fails: A syntax error would produce a policy evaluation failure or deployment rejection, not selective denial affecting only in-range addresses while out-of-range users are denied as designed. Syntax faults are tempting to blame first, but the symptom's asymmetry points to a condition operator or value mismatch.

The Deny statement overrides the Allow statement for all requests.

Why it fails: An unconditional Deny would deny out-of-range users (as observed) but also in-range users, which matches the symptom only if the Allow never applies — yet the stem's exhibit shows a conditional Allow. Deny precedence is tempting because it genuinely overrides Allow in policy evaluation.

The resource identifier includes a wildcard, causing a mismatch.

Why it fails: A wildcard in the resource identifier would affect every request regardless of source IP, yet out-of-range users are correctly denied and in-range users wrongly denied — an address-scoping fault, not a resource mismatch. Wildcards are tempting because resource scoping errors do cause blanket denials.

Man-in-the-middle attack

Why it fails: A man-in-the-middle attack requires traffic interception between two parties, which authentication logs cannot evidence; they show only login attempts, timestamps and source IPs. It is tempting because intercepted credentials enable replay, but the log pattern itself indicates brute-force or credential-stuffing attempts against accounts.

Phishing attack

Why it fails: Phishing is a social-engineering delivery method; authentication logs record credential submissions and source addresses, not email content, links or user deception. It is tempting because stolen credentials often follow phishing, but the exhibit alone evidences credential-based authentication activity rather than the delivery vector.

Privilege escalation

Why it fails: Privilege escalation follows successful authentication and appears as role or permission changes, not repeated failed logins from a single source. It is tempting because compromised accounts often precede escalation, but the exhibit shows authentication attempts only, consistent with password-guessing activity rather than elevated access.

The firewall is misconfigured and blocking legitimate traffic.

Why it fails: The OUTSIDE_IN access-group denying traffic from an external address is expected perimeter behaviour, so no misconfiguration is evidenced; a misconfigured ACL would typically block legitimate internal-to-external or established flows. It tempts because ACL errors do cause false denials, but the exhibit shows deliberate inbound filtering working correctly.

An internal host has been compromised and is exfiltrating data.

Why it fails: Exfiltration would appear as outbound traffic from an internal host leaving the network, logged by an inside-to-outside ACL, not inbound packets from 192.0.2.10 denied by OUTSIDE_IN. It tempts because compromised hosts are a real concern, but the direction and source address here contradict that scenario.

An external host is launching a denial-of-service (DoS) attack.

Why it fails: Denied inbound TCP to internal hosts indicates the OUTSIDE_IN ACL is functioning as designed, not a DoS: a DoS floods accepted or half-open connections rather than triggering repeated ACL denies. It tempts because volumetric attacks do generate many packets, but those would be permitted or rate-limited, not denied by an inbound access-group.

Availability

Why it fails: Availability concerns ensuring systems and data remain accessible to authorised users, typically via redundancy, failover and backups. Event logging does not maintain uptime or restore service. Availability would be the supported principle if the exhibit showed load balancing, replication or disaster recovery measures keeping resources reachable.

Authentication

Why it fails: Authentication verifies a subject's claimed identity through credentials such as passwords, tokens or certificates. Logging occurs after identity is established, recording activity rather than proving who someone is. Authentication would be the correct principle if the exhibit showed a sign-in mechanism or credential validation process.

Non-repudiation

Why it fails: Logging records who performed an action, supporting accountability and audit trails, but non-repudiation requires cryptographic proof binding a party to an action, such as digital signatures. Logs alone can be altered or deleted. Non-repudiation is the right answer when signatures or tamper-evident evidence prevent someone denying an action.

Separation of duties

Why it fails: Separation of duties splits a sensitive task across different people so no single actor completes it alone; the exhibit's policy assigns permissions or conditions to one role rather than dividing a transaction between parties. It is tempting because it is a fundamental control, but it requires multiple actors, which the policy does not establish.

Defense in depth

Why it fails: Defence in depth means layering independent controls so one failure does not expose the asset; the exhibit's policy governs a single decision point rather than stacked, independent safeguards. Layering is tempting because it is a core security principle, but it applies where multiple distinct controls are combined, not to one access rule.

Non-repudiation

Why it fails: Non-repudiation uses cryptographic proof or signed audit records binding an action to its originator; the exhibit's policy merely permits or denies access and creates no verifiable evidence of who performed what. It is tempting because logging and accountability are related concepts, but non-repudiation demands cryptographic assurance the policy does not supply.

The server is being used for remote desktop access

Why it fails: Remote desktop access uses TCP 3389 and is inbound to the server, not repeated outbound attempts to many external IPs on a non-standard port. It is tempting because RDP traffic can be tunnelled over arbitrary ports, but that still terminates on a listening service, not fan-out connections to numerous external hosts.

The server is performing a port scan

Why it fails: A port scan originates from the scanning host and targets many destination ports on one or more hosts; here the internal server repeatedly initiates outbound connections to external addresses on a single non-standard port, which is beaconing behaviour. Port scanning suits an interpretation where one source probes sequential ports across targets.

The server is a legitimate mail server

Why it fails: Mail servers use well-known ports such as 25, 465 and 587; repeated connections to external addresses on a non-standard port do not match SMTP behaviour. Legitimate mail traffic would be the interpretation when the exhibit shows standard mail ports and expected relay destinations.

Phishing

Why it fails: Phishing relies on a deceptive message persuading a user to surrender credentials or execute a payload, so the evidence would be mail headers, URLs or attachment hashes. The log snippet contains no email artefacts or user interaction, making this classification unsupported; it would be correct where a lure is traced to a click.

Man-in-the-middle

Why it fails: Man-in-the-middle involves an adversary intercepting and relaying traffic between two parties, typically via ARP poisoning, rogue proxies or forged certificates. The exhibit shows no interception or session hijacking between endpoints, so the evidence does not support this classification; it would fit logs showing duplicated MAC addresses or unexpected certificate chains.

Insider threat

Why it fails: Insider threat describes misuse by an authorised account, but the log shows external infrastructure and protocol manipulation rather than a trusted user abusing legitimate access. It would be the right classification when logs evidence an employee accessing or exfiltrating data beyond their job role, not when the traffic pattern itself is anomalous.

The server is experiencing a buffer overflow attack

Why it fails: No indication of buffer overflow in the alert.

The server's certificate has expired and the client is falling back to SSLv3

Why it fails: Certificate expiration typically causes browser warnings, not a protocol downgrade to SSLv3.

The server has been misconfigured to use SSLv3 instead of TLS

Why it fails: While possible, the alert specifically mentions 'SSL Stripping' as a signature, indicating an attack.

Separation of duties

Why it fails: Separation of duties splits critical tasks across multiple people to prevent fraud, which the default policy does not do since it assigns permissions uniformly. It applies when no single administrator should complete an entire sensitive transaction alone.

Defense in depth

Why it fails: Defense in depth layers multiple independent controls so one failure does not expose the system, while the default policy is a single baseline permission set. It applies when architecting overlapping controls across network, host and application tiers.

Need to know

Why it fails: Need to know limits access to information required for a task, whereas the default policy grants broad baseline permissions to all users rather than restricting by job role. It applies when designing least-privilege access for sensitive data.

Account lockout

Why it fails: Account lockout requires the log to record the account being locked after repeated failed attempts, which the exhibit does not show. It tempts because lockouts are a common security event, and it would be correct if the entry named the locked account and the lockout source.

Successful remote login

Why it fails: A successful remote login requires the log to show a network logon type with successful authentication, but the exhibit records a different event category. It tempts because remote access events are frequently examined during investigations, and it would be correct if the entry showed logon type 3 or 10 with success.

Failed local login

Why it fails: A failed local login requires an authentication attempt against the local machine's credential store, whereas the exhibit shows a network-based authentication event. It tempts because failed logons are a common audited event, and it would be correct if the log recorded an interactive logon failure on the host itself.

Ignore the alert as it is a false positive

Why it fails: Dismissing the alert assumes the traffic is benign without any triage, leaving a potentially SpyEye-infected host beaconing to its controller. False-positive closure is legitimate only after verifying the signature against known-good traffic; here the exhibit shows a botnet check-in pattern that warrants investigation, not suppression.

Block the destination IP at the firewall

Why it fails: Blocking the destination IP stops this single check-in but leaves the infected internal host communicating with the botnet's other command-and-control servers. Firewall blocks are tempting for containing known malicious infrastructure, yet the immediate priority is isolating the compromised endpoint, since SpyEye will simply fail over to alternate addresses.

Run a full antivirus scan on the internal host

Why it fails: A full antivirus scan is slow and signature-based, leaving the host communicating with the botnet command-and-control server throughout, so containment is delayed. It tempts because scanning is a familiar remediation step, and would be correct after the host is isolated, once active exfiltration has been stopped.

Add world read permission.

Why it fails: Adding world read lets every user on the system read the file, directly contradicting the policy that restricts reading to user1 and the developers group. It is tempting when a service account outside the group must access the file, where world read is the deliberate fix.

Change group permissions to rw-r--.

Why it fails: Setting group permissions to rw-r-- grants group write access, exceeding the read-only requirement and violating least privilege. It is tempting because removing the group execute bit looks like tightening, and rw-r-- would be correct if developers genuinely needed to modify the file.

Change the owner to user2.

Why it fails: Changing ownership to user2 removes user1's access while granting user2 full owner rights, so the owner/group read requirement is broken rather than tightened. Ownership transfer suits handing a file to a different account, not restricting permissions; the mode bits (group read already set, other read absent) are what need adjusting here.

Compliant with both RTO and RPO

Why it fails: The exhibit's measured recovery times exceed the stated RTO or RPO, so claiming compliance with both contradicts the figures shown. It tempts because a design can meet both objectives when actual recovery and data-loss windows fall inside their targets, which is precisely what the exhibit must demonstrate.

Compliant with neither

Why it fails: The exhibit's measured values satisfy at least one objective, so neither failing cannot hold. It is tempting when both figures appear marginal against their targets, but the calculation must compare each measured value against its own threshold independently before declaring non-compliance.

Compliant with RPO but not RTO

Why it fails: RPO is not met; RTO may be met.