Troubleshooting Scenario Questions

The user account is locked out

Why it fails: A locked-out account produces event 4740 and a bad-password or account-locked logon failure, which the exhibit does not show. It is tempting because lockout genuinely blocks RDP, and would be correct if the log recorded the account lockout event or repeated failed logons from the user.

The server is not a member of the domain

Why it fails: Domain membership is not required for RDP; a standalone server accepts local or workgroup credentials, so the log would show a logon failure rather than a trust or domain-controller error. It is tempting because domain trust failures do block Kerberos authentication, which is the correct diagnosis when the log names a broken secure channel.

The user's Kerberos ticket has expired

Why it fails: An expired Kerberos ticket triggers silent renewal or a fresh TGT request, so the log would show a Kerberos or NTLM error, not the account state recorded in the exhibit. It is tempting because ticket expiry genuinely causes authentication failures, and would be correct if the log cited a Kerberos pre-authentication or ticket error.

Firewall blocking UDP port 500

Why it fails: A blocked UDP 500 would prevent IKE negotiation starting, producing timeout or no response rather than 'no proposal chosen'. Firewall rules on port 500 are the right check when the tunnel cannot initiate at all, not when proposals fail to match.

Incorrect peer IP address

Why it fails: An incorrect peer IP address stops IKE packets reaching the responder, giving timeouts or no response, not a proposal mismatch. Verifying peer addresses is correct when the tunnel never initiates, whereas 'no proposal chosen' means IKEv2 parameters were exchanged but disagreed.

Expired certificates

Why it fails: 'No proposal chosen' indicates IKE phase 1 could not agree encryption, hash, DH group or lifetime, so the tunnel never reaches certificate authentication. Certificates matter when a certificate-based peer identity is used, but here the pre-shared key is already confirmed correct.

The server's private key is missing.

Why it fails: A missing private key causes handshake or decryption failures, not a chain-building error; s_client still receives the certificate and reports the untrusted issuer. It is tempting because key and certificate problems are often grouped together, and a missing key would be the answer if the server failed to complete the TLS handshake.

The server certificate is self-signed.

Why it fails: A self-signed certificate produces exactly this error because no local issuer exists in the trust store to verify it. However, the stem asks for the most likely cause given the exhibit, and the option is incorrect here because the exhibited chain shows an intermediate issuer, not a self-signed leaf.

The server certificate has expired.

Why it fails: Expiry produces a distinct 'certificate has expired' verification failure with explicit date messages, not 'unable to get local issuer certificate'. It is tempting because expired certificates are a common cause of TLS trust errors, and would be correct if the output cited validity dates rather than issuer lookup.

Return through the first door

Why it fails: Remaining inside the mantrap's interlock is the designed behaviour; the first door stays locked until the second closes, so returning through it is impossible and traps the employee. Mantraps exist to prevent tailgating, and the correct action is using the intercom to summon security.

Force the second door open

Why it fails: Forcing the door defeats the mantrap's interlock and can damage the barrier or injure the occupant, and it bypasses the access-control decision that denied entry. It is tempting under urgency, but the correct action is to exit via the first door or use the intercom; physical force is never the sanctioned response.

Wait for someone to open from the other side

Why it fails: Waiting for another person defeats the mantrap's purpose: it is a single-person interlock preventing tailgating, so an occupant must never be admitted by someone else. That is tempting as a courtesy when a door jams, but the correct response is to use the intercom or exit path rather than breach the controlled barrier.

The user's group memberships are conflicting with the required role.

Why it fails: Conflicting group memberships would typically deny access through explicit deny or role exclusion, yet the stem shows the required role is simply not held. It is tempting because RBAC conflicts cause access failures, but it would be correct where overlapping roles produce contradictory permissions rather than a missing assignment.

There is a firewall rule blocking traffic from the user's IP range.

Why it fails: A firewall rule blocking the user's IP range would prevent any connection to the application server, contradicting the verified reachability and the user's ability to authenticate. It would be the correct cause if traffic were dropped before reaching the host.

The application's session timeout is set too low.

Why it fails: Session timeout terminates idle authenticated sessions; it cannot block a user who is already authenticated and authorised from reaching an application. It would be the correct cause if the user were repeatedly logged out mid-session.

Configure firewall rules to block UDP port 53

Why it fails: Blocking UDP port 53 halts all legitimate DNS resolution, including the queries clients need, without preventing cache poisoning from upstream resolvers. Firewall filtering suits restricting specific untrusted hosts, but DNS poisoning requires validating responses via DNSSEC rather than severing the protocol entirely.

Disable DNS recursion on authoritative servers

Why it fails: Disabling recursion on authoritative servers is already standard hardening; those servers never resolve external queries anyway, so it does nothing against poisoning of a recursive resolver's cache. This setting suits authoritative-only deployments, but the attack targets recursive resolvers, which must retain recursion to serve clients.

Enable DHCP snooping on switches

Why it fails: DHCP snooping filters rogue DHCP servers on layer-2 segments, protecting against address assignment spoofing, not forged DNS responses. It would be correct where unauthorised DHCP servers hand out false gateways, but DNS poisoning arrives via resolver cache corruption, which snooping never inspects.

The network firewall rules governing outbound syslog traffic from all monitored hosts

Why it fails: Firewall rules are a shared transport path, so a blocking change would simultaneously affect many source types rather than only domain controllers. Because the remaining sources still deliver events, the transport layer is demonstrably working, making a general firewall rule review a low-value first step compared with the source-specific collection components.

The SIEM correlation rules that map domain controller event IDs to alert severity levels

Why it fails: Correlation rules determine which ingested events become alerts and at what severity; they do not control whether events arrive at the platform. If events stopped at 02:00, the data never reached the correlation engine, so tuning rule logic or severity mappings would not restore ingestion and would waste the analyst's time during triage.

The retention and rollover settings on the SIEM storage volumes

Why it fails: Storage retention and index rollover affect how long already-collected data remains searchable, not whether new events are accepted. Since every other log source continues to report normally, the storage tier is clearly functioning and accepting writes, which makes retention configuration an implausible explanation for a single source going silent.