Troubleshooting Scenario Questions

The WAP's DHCP server is malfunctioning.

Why it fails: A functioning WAP DHCP server is precisely why clients hold 192.168.1.0/24 addresses, so it is working as configured. The fault is the second DHCP scope creating a separate subnet that cannot route to the printer at 192.168.0.50. A WAP's DHCP server is legitimately used where guest isolation from the office LAN is intended.

The switch port for the printer is faulty.

Why it fails: A faulty switch port would break connectivity for all clients, not only those holding 192.168.1.0/24 addresses; the working computers prove the printer's link is fine. The failure pattern follows the WAP's DHCP scope. Replacing a switch port is the right step when a single cabled device loses link entirely.

The printer is not powered on.

Why it fails: A powered-off printer would prevent every computer from printing, yet the stem states some office computers still reach the shared printer successfully. The split correlates exactly with the 192.168.1.0/24 addresses, indicating a subnet mismatch. Powering the printer on is the fix when no client can reach it at all.

Ring

Why it fails: In a ring, each node depends on its neighbours, so one cable or node failure can disrupt the entire loop unless dual rings are used. It tempts because ring topologies offer predictable performance, and would be correct where deterministic throughput matters more than isolating a single cable fault.

Bus

Why it fails: A bus topology shares one backbone, so a single cable break can isolate multiple devices or the whole segment, failing the resilience requirement. It tempts because it is cheap and simple for small offices, and would suit a scenario prioritising low cabling cost over fault isolation.

Mesh

Why it fails: A mesh topology requires each device to maintain multiple direct links to others, creating excessive cabling and configuration overhead for a 20-device network. This fails the stem’s need for easy troubleshooting, as tracing faults across numerous interconnections is cumbersome. The option is tempting because mesh offers high resilience to cable failures, and in a critical data-centre environment where maximum redundancy is essential, it would be the correct choice.

Disable the Windows Firewall on the server to allow traffic

Why it fails: Disabling the server firewall does not address the client's inability to ping 192.168.1.1, because the client's default gateway points to 192.168.1.10, so its packets never reach the modem. It is tempting because firewalls block traffic, and this would be correct if the server were dropping forwarded packets while routing correctly.

Replace the cable modem as it is not routing traffic correctly

Why it fails: The modem is reachable from the server, proving it routes correctly, so replacing it cannot resolve the client's failed ping to 192.168.1.1. It is tempting because modem faults commonly cause internet outages, and replacement would be correct if the modem were genuinely failing to forward traffic.

Configure the DNS server to forward queries to 8.8.8.8

Why it fails: DNS forwarding to 8.8.8.8 cannot fix the failure, since the client cannot even ping the modem at 192.168.1.1, a layer-3 reachability problem independent of name resolution. It is tempting because DNS misconfiguration commonly breaks internet access, and forwarding would be correct if pings to the gateway succeeded but names failed.

The network connection

Why it fails: A network connection is irrelevant when the machine shows no power, since link negotiation requires an energised NIC and running firmware. Checking it is tempting because network faults commonly cause boot-time errors, yet here the failure precedes POST, so physical power delivery must be verified first.

The operating system version

Why it fails: An operating system version cannot be queried on a machine that receives no power, so it cannot be the first check. It is tempting because OS version matters for compatibility and update troubleshooting once a system boots, but power-on faults must be traced through PSU, cabling and POST first.

The amount of free disk space

Why it fails: Free disk space cannot prevent power-on; a machine with a full disk still POSTs. It is tempting because disk capacity causes boot failures, but only after power-on, so checking power supply, cabling, and POST beep codes comes first.

Update the graphics driver

Why it fails: Graphics drivers govern display rendering and have no bearing on network interface configuration, IP addressing or link state, so the fault remains. It tempts when a recent driver update coincides with the symptom, but driver rollback is the correct step only for display artefacts, not connectivity loss.

Replace the router

Why it fails: Swapping the router replaces functioning hardware before any diagnostic evidence identifies it as faulty, and the real cause, such as a disabled NIC or wrong gateway, persists. It tempts when the whole network appears down, but router replacement is justified only after confirming the device itself fails its own tests.

Reinstall the operating system

Why it fails: Reinstalling the operating system destroys the user's configuration and data while leaving the actual connectivity fault, such as a failed DHCP lease or bad cable, undiagnosed. It tempts when the OS appears corrupted, but that is warranted only after hardware, link and IP-layer checks have been exhausted.

The security update changed the service startup type to Disabled. Set it back to Automatic.

Why it fails: Error 1069 means the service account's logon credentials failed, not that the startup type changed; the stem already confirms it is set to Automatic. Checking startup type is tempting because updates can alter service configuration, but that produces a different error, not a logon failure.

The security update deleted the database file. Reinstall the application.

Why it fails: A deleted database file would not stop the SQL Server service from starting; the service would run and the application would report a missing or suspect database instead. Reinstallation is tempting when files are suspected missing, but error 1069 points to the service account's logon credentials failing.

The security update corrupted the database files. Restore the database from backup.

Why it fails: Corrupted database files would not prevent the SQL Server service itself from starting, and error 1069 explicitly indicates a logon failure for the service account. Restoring from backup is tempting after suspected corruption, but the service never reaches the point of opening database files.

Primary key

Why it fails: A primary key enforces uniqueness and non-null on its column, but the scenario concerns a non-key required field, which a NOT NULL constraint governs. It tempts because primary keys do reject nulls, yet they apply only to the designated key column, not to arbitrary required fields.

Index

Why it fails: An index speeds up data retrieval and can enforce uniqueness, but it does not require a column to hold a value. It tempts because unique indexes reject duplicates and nulls in some systems, yet the scenario needs a NOT NULL constraint on a non-key required field.

Foreign key

Why it fails: A foreign key enforces referential integrity between tables, requiring the value to match an existing parent key; it does not mandate that a column contain a value. It tempts because foreign keys do restrict inserts, but only when a referenced row is absent, not when a field is simply empty.

Install new software

Why it fails: Installing software is not a standard troubleshooting step.

Escalate to vendor immediately

Why it fails: Escalation is a later step after initial troubleshooting fails.

IPv4 address

Why it fails: An incorrect IPv4 address would prevent all connectivity, including access by IP address, so it cannot explain name-only failure. The option tempts because IP misconfiguration commonly causes browsing problems, but the symptom of working IP access points specifically to DNS resolution, not addressing.

Subnet mask

Why it fails: A wrong subnet mask breaks local subnet routing, yet the host still reaches the default gateway and resolves names via DNS, so domain browsing would work. Mask errors typically cause partial connectivity failures, not name-only failure. The symptom points to DNS resolution, making the DNS server address the incorrect setting.

DHCP enabled

Why it fails: DHCP being enabled or disabled affects how the host obtains an address, not whether domain names resolve; a valid lease still permits IP-based access. The option tempts because DHCP supplies DNS server addresses, but the stem shows IP connectivity already works, isolating the fault to DNS configuration.

8.8.8.8

Why it fails: 8.8.8.8 sits in the public routable space as Google Public DNS, outside the RFC 1918 ranges 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. It is tempting because it is a well-known address technicians use for connectivity testing, but reachability does not make an address private.

203.0.113.5

Why it fails: 203.0.113.5 falls in 203.0.113.0/24, reserved by RFC 5737 for documentation examples, not RFC 1918 private addressing. It is tempting because reserved documentation ranges are non-routable on the public internet, but non-routability differs from private addressing, so it is not a private IPv4 address.

169.254.1.1

Why it fails: 169.254.1.1 lies in 169.254.0.0/16, the link-local range assigned by APIPA when DHCP fails, not an RFC 1918 private address. It is tempting because link-local addresses are non-routable and appear during troubleshooting, but the stem asks specifically for private IPv4 addressing.

The path rule for C:\Program Files is too broad.

Why it fails: A broad C:\Program Files path rule governs executables in that directory only; it cannot deny execution from D:\Apps. It is tempting because overly permissive path rules are a genuine AppLocker misconfiguration, but the fault here lies with the rule covering the custom application's own location.

The publisher rule is incorrect.

Why it fails: Publisher rules match signed binaries by certificate attributes; an incorrect publisher rule would affect only signed applications matching that certificate, not an unsigned custom app in D:\Apps. It is tempting because publisher rules are the recommended AppLocker approach for signed software, but they are irrelevant to this path-based failure.

The enforcement mode is set to Enforce, blocking all unlisted apps.

Why it fails: Enforce mode applies the configured rules rather than blocking everything unlisted; a rule permitting D:\Apps may simply be absent, which is why the app fails. It is tempting because AppLocker's enforcement modes govern whether rules are audited or applied, and Enforce is the correct setting once rules are validated.

The switch's uplink port is faulty

Why it fails: A faulty uplink port would disrupt all traffic traversing the switch, not repeatedly bounce a single member link while the other remains up. It is tempting because uplink faults do cause intermittent connectivity, and this would be the answer if the whole switch or its upstream path were dropping, rather than one LAG member.

The switch is experiencing broadcast storms

Why it fails: Broadcast storms flood all switch ports but do not selectively bounce one aggregated link while the other stays up. It is tempting because storms cause intermittent connectivity, yet the correct cause is a mismatched LACP configuration or flapping member link, which the logs would show as interface state changes.

The server's network adapter is overheating

Why it fails: Overheating would affect the adapter's traffic, not selectively drop one aggregated link while the other stays up and server logs stay clean. Thermal faults typically degrade both links or cause total failure. It is tempting because heat genuinely causes intermittent faults, and an overheating NIC would be the right diagnosis if both links flapped together under sustained load.

Web browser

Why it fails: The browser renders HTML, runs client-side JavaScript and issues HTTP requests; server-side logic executes on the remote web or application server. The browser would be the answer if the question asked which component processes client-side scripting or displays the interface.

Local firewall

Why it fails: A local firewall filters inbound and outbound network traffic on the host; it never executes application code. It would be the correct component if the question concerned blocked ports or denied connections causing the application to be unreachable.

Operating system

Why it fails: The operating system manages hardware, processes and files; it hosts the runtime but does not itself execute the application's server-side business logic. It would be the answer if the question asked which component allocates CPU and memory to the web server process.

Incorrect default gateway

Why it fails: The gateway 192.168.2.1 is on the workstation's own subnet, so it is correctly configured; the fault is that 192.168.1.100 sits on a different subnet (192.168.1.0/24) unreachable without routing. An incorrect gateway applies when the configured address falls outside the host's subnet.

Incorrect subnet mask

Why it fails: The mask 255.255.255.0 is correct for a /24 network, so it does not cause the fault. The workstation sits in 192.168.2.0/24 while the server is in 192.168.1.0/24, and the gateway 192.168.2.1 cannot route there. An incorrect mask would be the cause only if the address and mask disagreed.

Duplicate IP address on the network

Why it fails: A duplicate IP would cause intermittent or complete loss of connectivity and ARP conflicts, but the configuration shows a valid unique address on 192.168.2.0/24. Duplicate addressing fits when the host intermittently drops connections or reports address-conflict errors, not a consistent cross-subnet failure.

Operating system kernel

Why it fails: The kernel is the core of the operating system, loaded by the bootloader after firmware initialisation completes, so it cannot initialise the hardware that must already be running to load it. It is tempting because it manages hardware once running, making it correct when asked what controls devices after boot.

Boot loader

Why it fails: A boot loader runs after firmware has already initialised the hardware, so it only locates and starts the kernel rather than performing that initialisation itself. It is tempting because it does load the operating system, making it the correct answer when the question asks what hands control from firmware to the OS.

Device driver

Why it fails: A device driver is software loaded by the running kernel to control a specific peripheral, so it cannot execute before any OS exists. It is tempting because drivers do initialise hardware, but only after boot, whereas firmware such as UEFI or BIOS performs power-on self-test and hands control to the bootloader.