Scenario practice questions

Man-in-the-middle (MITM)

Why it fails: A MITM attack involves an attacker secretly intercepting and possibly altering communications between two parties. While a phishing page could theoretically be part of a MITM chain, the scenario describes direct credential theft via a deceptive email, not interception of an existing session. Thus, MITM is not the best classification here.

SQL injection

Why it fails: SQL injection is a code injection technique that exploits vulnerabilities in an application's database layer to execute malicious SQL statements. This scenario involves no database interaction or web application vulnerability; it is purely a social engineering attempt to trick a user into surrendering credentials. Therefore, SQL injection is not applicable.

Denial-of-service (DoS)

Why it fails: A DoS attack aims to make a system or network resource unavailable by overwhelming it with traffic or requests. In this scenario, the attacker is not trying to disrupt availability; instead, they are attempting to steal credentials through deception. Therefore, DoS does not describe the attack, even though the fake page might eventually become unavailable.

DHCP Server Scope

Why it fails: A DHCP server scope is configured on a Layer 3 interface only when the firewall itself serves addresses to clients; a routed interface needs a static IP and subnet mask instead. It is tempting because DHCP server configuration does live on Layer 3 interfaces, but only for interfaces acting as a DHCP server for a segment.

MAC Address Override

Why it fails: MAC address override is an optional setting for interfaces using DHCP or PPPoE, not a required parameter for a routed interface; the mandatory values are the zone and IP address. It is tempting because override appears in interface configuration, but it only matters when the interface obtains its address dynamically.

Virtual Wire Pair Identifier

Why it fails: A virtual wire pair identifier belongs to virtual wire interfaces, which forward traffic transparently at Layer 2 without IP addressing; a Layer 3 interface requires a zone and IP address. It is tempting because virtual wire pairs are configured on the same firewall, but they serve tap or inline Layer 2 deployments.

The firewall's management plane CPU is exceeding 90% utilization.

Why it fails: Management-plane CPU load affects session stability and convergence, not the deterministic best-path algorithm, which compares attributes regardless of load. It is tempting because high CPU does cause route churn and flapping, and it would be the answer if sessions were dropping or updates were being delayed.

The BGP peer is configured in a different autonomous system.

Why it fails: eBGP versus iBGP peer type does not itself prevent selection; routes from any valid peer still compete on attributes, and eBGP normally wins. It is tempting because AS relationships shape path preference, and peer AS configuration would be the answer if the session were failing to establish or routes were rejected inbound.

The Virtual Router does not have OSPF enabled.

Why it fails: OSPF's presence is irrelevant to BGP best-path selection; the decision process compares attributes such as weight, local preference, AS path length and MED. It is tempting because OSPF and BGP often run together, and OSPF would matter if the question asked about route redistribution or administrative distance between protocols.

Post-Incident Activity

Why it fails: Post-Incident Activity involves reviewing lessons learned and improving processes after the incident is resolved. It does not include determining whether an event is an incident. The analyst is at the beginning of the response, not after resolution, so this phase is incorrect for the given situation.

Preparation

Why it fails: Preparation involves establishing policies, tools, and training before an incident occurs. While important, it does not include the actual validation or scoping of a live alert. The analyst here is already responding to an alert, so Preparation is not the phase where the determination of incident status happens.

Containment, Eradication, and Recovery

Why it fails: Containment, Eradication, and Recovery focuses on limiting damage, removing the threat, and restoring systems. It happens after an incident has been confirmed. In this scenario, the analyst has not yet determined if the alert is a real incident, so this phase is premature and does not match the described activity.

Domain Generation Algorithm (DGA) communication

Why it fails: DGA is used by malware to generate a large number of domain names to contact command-and-control servers, but the queries typically resolve to malicious domains and may not carry data in the subdomain itself. In this scenario, the long, random subdomains suggest data encoding, which is more characteristic of DNS tunneling. DGA focuses on domain flux, not data exfiltration.

Fast flux DNS

Why it fails: Fast flux DNS involves rapidly changing DNS records to hide malicious servers behind a constantly changing set of IP addresses. It does not typically involve long, random subdomains carrying data. The scenario describes data being encoded in the subdomains, which is not a characteristic of fast flux. Fast flux is more about resilient hosting than exfiltration.

DNS cache poisoning

Why it fails: DNS cache poisoning corrupts DNS resolver caches to redirect users to malicious sites. It does not generate high volumes of queries with long, random subdomains from a single workstation. The observed pattern is indicative of an active covert channel, not an attack on DNS infrastructure. Cache poisoning would affect many users and not show this query pattern.

The workstation is retransmitting a lost segment to the server.

Why it fails: Retransmissions are identified by repeated sequence numbers and payload data, not by the RST flag. RST is a control flag used to reset or refuse a connection, not to recover lost data. Interpreting a reset as a retransmission would lead an analyst to the wrong conclusion about why the session ended.

The workstation is requesting a graceful, orderly shutdown of the session.

Why it fails: An orderly shutdown uses FIN flags, typically FIN, ACK exchanges in both directions, allowing buffered data to flush. RST is the opposite of graceful: it immediately destroys the connection without ensuring data delivery. Confusing RST with FIN misrepresents the abrupt nature of a reset, which is a critical distinction when analyzing captures.

The workstation is negotiating encryption parameters for the session.

Why it fails: Negotiating encryption parameters happens inside the TLS handshake carried over the established TCP connection, using TLS records rather than TCP control flags. A RST is a transport-layer signal that terminates the connection, so it cannot represent a negotiation step. This option confuses application-layer TLS negotiation with TCP control signaling.

ICMP

Why it fails: ICMP is used for error reporting and diagnostics, such as the ping utility, but it does not by itself determine whether a path supports a larger frame size. While ICMP can carry error messages like 'fragmentation needed,' it is not the protocol that actively tests or negotiates the maximum transmission unit (MTU) along the path. Relying on ICMP alone would not confirm path MTU support; a dedicated mechanism is required.

Dynamic Host Configuration Protocol (DHCP)

Why it fails: DHCP is used to automatically assign IP addresses and other network configuration parameters to hosts. It does not participate in MTU discovery or frame size negotiation. Although DHCP can provide an interface MTU option, it does not dynamically test the path between two endpoints. Thus, DHCP is not the protocol to examine for confirming path MTU support.

Address Resolution Protocol (ARP)

Why it fails: ARP resolves IP addresses to MAC addresses on a local network segment. It does not test or negotiate frame sizes or MTU along a path. While ARP is essential for local delivery, it operates at Layer 2 and has no role in determining whether a larger frame can traverse multiple hops. Therefore, it would not help confirm path MTU support in this scenario.

The firewall is not configured with a decryption policy, so it cannot inspect HTTPS traffic for URL categories.

Why it fails: While decryption is necessary to inspect HTTPS URLs, the scenario does not specify that the sites are HTTPS. Many blocked categories could be HTTP. Moreover, URL filtering can still categorize HTTPS sites based on SNI and certificate information without decryption, though full URL path inspection requires decryption. The primary issue is the profile action, not decryption.

The Security policy rule action is set to Allow, but no URL Filtering profile is attached to the rule, so the firewall does not inspect URLs.

Why it fails: The scenario states that a URL Filtering profile is attached to the rule. Therefore, this is not the cause. Even if the profile were attached, the action Allow would still permit traffic that matches the rule, but URL filtering would block categorized sites if the profile is configured to block. The problem is that the profile is not effectively blocking, not that it is missing.

The URL Filtering profile is not applied because the Security policy rule is missing an Application filter set to 'web-browsing'.

Why it fails: An Application filter is not required for a URL Filtering profile to function. The firewall performs URL categorization based on the HTTP request regardless of whether an Application filter is specified. If the rule allows all applications, URL filtering still applies to web traffic. The issue is not the absence of an Application filter; it is that the profile is not correctly attached or the action is not set to deny.

Missing User-ID mapping for the internal client IP addresses.

Why it fails: User-ID mapping governs policy enforcement and logging, not NAT translation or routing, so missing mappings do not block the connection itself. It is tempting because User-ID failures do cause silent policy denies, which is the correct diagnosis when rules are identity-based rather than address-based.

Incorrect configuration of the GlobalProtect Portal external gateway address.

Why it fails: The GlobalProtect portal external gateway address affects only VPN client connectivity, not NAT translation of internal-to-public traffic. It tempts because portal misconfiguration genuinely breaks remote access, so it is the right suspect when VPN users, rather than internal clients, cannot connect.

Attaching an incorrect WildFire analysis profile to the security rule.

Why it fails: A WildFire profile determines file submission and verdict actions, not whether a TCP session to a NAT address is permitted or translated. It tempts because profile misconfiguration can drop traffic, making it the right answer when the failure involves file transfers rather than initial connection establishment.

Check that local DHCP leases are renewed every 30 seconds.

Why it fails: DHCP lease renewal frequency does not affect established outbound TLS sessions to the Cortex XDR cloud; agents need DNS resolution and port 443 reachability. Frequent lease renewal would matter when endpoints must promptly pick up changed IP configuration or scope options.

Confirm that inbound SSH port 22 is open on all endpoint host firewalls.

Why it fails: Inbound SSH on port 22 governs administrative access to endpoints, not outbound agent telemetry; Cortex XDR requires outbound 443 to the cloud. Opening inbound SSH would be relevant when administrators need remote shell access to managed hosts.

Verify that SNMP v3 trap listeners are active on port 162.

Why it fails: SNMP traps carry device telemetry to a monitoring station, not agent incident reports; Cortex XDR agents push data to the cloud over TLS on port 443. SNMP v3 would be the item to verify when network devices must forward alerts to an SNMP manager.

Global Wi-Fi WPA3 enterprise RADIUS shared secrets.

Why it fails: Wi-Fi WPA3 RADIUS shared secrets are configured in the wireless infrastructure or authentication server, not Cortex XDR endpoint policy. Granular per-department endpoint settings use endpoint policy groups, profiles and exceptions. The confusion arises because Cortex XDR integrates with network security, and RADIUS secrets would be correct when configuring 802.1X authentication for wireless clients.

BGP Autonomous System Number (ASN) path configuration tables.

Why it fails: BGP ASN path tables belong to network routing configuration on routers, not Cortex XDR endpoint management. Granular per-department endpoint settings use endpoint policy groups, profiles and exceptions. The mix-up is understandable because Cortex XDR consumes network telemetry, and BGP configuration would be correct when tuning internet routing paths between autonomous systems.

The Network Access layer

Why it fails: The Network Access layer (also called Link layer) handles physical transmission and framing of data on the local link, including MAC addressing and Ethernet. It does not perform logical addressing or routing decisions between separate networks. The analyst's task targets logical addressing and inter-network routing, which occurs above the physical and link functions.

The Application layer

Why it fails: The Application layer contains protocols like HTTP, DNS, and SMTP that interface with user software and network services. It relies on lower layers for addressing and routing and performs neither function itself. Choosing this layer confuses user-facing protocols with the network-layer duties of logical addressing and path selection between separate networks.

The Transport layer

Why it fails: The Transport layer provides end-to-end communication services such as segmentation, flow control, and reliability using TCP or UDP. It does not assign logical addresses or route packets between networks. While port numbers are logical, they identify applications, not network hosts, so this layer does not satisfy the logical addressing and routing requirement.

Vishing

Why it fails: Vishing is voice phishing conducted over the phone. This scenario involves an email with a malicious link, not a phone call. Thus, vishing does not apply. The attack vector is email, making phishing the appropriate term.

Whaling

Why it fails: Whaling is a type of phishing specifically targeting high-profile executives like CEOs or CFOs. The scenario describes an email to an employee, not necessarily an executive. Therefore, whaling is not the correct classification for this attack.

Spear phishing

Why it fails: Spear phishing is a targeted form of phishing aimed at specific individuals or groups, often using personalized information. While this email could be targeted, the scenario does not provide enough detail to confirm it is spear phishing rather than broad phishing. The general term phishing is more accurate here.

Provide the code but only after asking the caller to state their employee ID and department name.

Why it fails: This fails because employee IDs and department names are often discoverable on internal directories, badges, or social media, so they do not prove identity. The one-time passcode remains the actual authentication secret, and sharing it after a superficial challenge still hands the attacker account access. Verification must happen out-of-band, not through questions the attacker can answer.

Transfer the caller to the security operations center while keeping the line open so the SOC can trace the call.

Why it fails: This fails because the analyst should not stay engaged in an unverified conversation or attempt tracing that requires telecom coordination the analyst does not control. Keeping the line open risks further social engineering and delays reporting. The immediate priority is to stop the interaction, avoid disclosing the code, and confirm the request through a known-good channel before reporting.

Read the six-digit code to the caller because the request came from an internal extension that appears trustworthy.

Why it fails: This fails because caller ID and internal extensions can be spoofed through VoIP systems, and the six-digit code is exactly the second factor that protects the account. Disclosing it lets the attacker complete a login or enroll a rogue authenticator. Trusting the displayed extension replaces verification with assumption, which is the weakness the attacker is exploiting in this scenario.

Initiate a live terminal session

Why it fails: A live terminal session provides interactive access to the endpoint, allowing the analyst to run commands manually. While this can be used to collect data, it is interactive and may disrupt the user if not careful. It is not a one-click forensic collection action and requires expertise to gather comprehensive data efficiently.

Isolate the endpoint

Why it fails: Isolating the endpoint would cut off network communication, preventing data exfiltration but also disrupting the user's work and potentially hindering forensic collection. This action is typically used when an active threat needs to be contained immediately. It is not suitable for non-disruptive forensic data collection.

Run a script

Why it fails: Running a script allows execution of custom code on the endpoint, which could collect forensic data, but it requires writing and deploying a script. It is not a built-in response action specifically designed for forensic data collection. While powerful, it is not the most direct or standard method for this scenario.

Disable the user's account in Active Directory to prevent further access.

Why it fails: Disabling the account is a containment step that should be taken only after confirming a compromise. Doing so immediately could disrupt business operations if the alert is a false positive, such as a user traveling. The analyst should first validate the alert by gathering more information.

Escalate the alert to Tier-2 immediately for further investigation.

Why it fails: Escalation should occur after initial triage confirms the alert's severity. The analyst has tools to quickly assess the situation; escalating without preliminary analysis wastes Tier-2 resources and delays response. The first step is to gather context to determine if escalation is necessary.

Contact the user to ask if they recently traveled to that location.

Why it fails: Contacting the user is a valid step but can be time-consuming and may alert a potential attacker if the account is compromised. The analyst should first use available data to assess the alert. If logs indicate a high risk, then user contact can be part of verification, but it is not the first action.