Three failed logins. Is the service down?
The error is the same. The affected scope is not yet clear.
The question
Bellmere is a fictional healthcare group with clinics, offices and a supply warehouse. Its scheduling application is needed for the next shift. These are authored observations, not an employer’s actual interview question.
- Office leadThree people on the east-floor wired network see 'Cannot reach sign-in'. Please restart the scheduling service.
- Previous support noteOne user already restarted their laptop. The error remained. No shared service change has been approved.
| Successful | Failed | |
|---|---|---|
| East-floor wired network | 0 | 3 |
| Approved corporate Wi-Fi, same application | 3 | 0 |
All six checks use current accounts. The three wired failures reproduce before the login form loads. Wi-Fi is an approved alternate corporate network, not an access-control bypass.
- Name lookup
- The supplied diagnostic report shows the east-floor configured resolver returning NXDOMAIN for the application host. The Wi-Fi resolver returns the expected host record. NXDOMAIN means that resolver reports the name does not exist; it does not prove a global application outage.
- Change boundary
- The service desk can collect diagnostics and offer the approved alternate network. The network team owns resolver changes; the application team owns service restarts.
“State what you know, choose the next owner, and give the office lead a useful update.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Limit the claim
What would you do here? Open the move you’d make.
Open a scheduling-service outage from the three reports
Tempting, but it misses something. The same application works through the comparison network. A shared-service outage is not established.
Report a wired-network-specific failure
The strong move. This describes the observed boundary and keeps the underlying cause open.
See how a strong candidate says it
“We have three failures on one wired network and three successful checks on approved corporate Wi-Fi. This supports a network-specific problem; it does not establish a scheduling-service outage.”
Why it works: The successful comparison narrows the failure without proving its underlying cause.
Step 2: Use the discriminating evidence
What would you do here? Open the move you’d make.
Reset one user's password to test authentication
Tempting, but it misses something. These failures occur before the login form. The supplied resolver difference is more relevant than changing an account.
Retain both resolver results and failure timestamps
The strong move. This gives the network owner comparable evidence without a disruptive change.
See how a strong candidate says it
“The name-lookup results differ by configured resolver before authentication begins. I would retain those results and the times, rather than reset passwords or repeat the laptop restart.”
Why it works: A test is useful when it distinguishes the remaining explanations.
Step 3: Stay within the change boundary
What would you do here? Open the move you’d make.
Escalate the evidence to the network owner
The strong move. The owner can investigate the resolver path and approve the relevant change.
Switch the three devices to a public resolver temporarily
Tempting, but it misses something. That is outside the supplied authority and may bypass managed controls or break internal resolution.
See how a strong candidate says it
“I would send the network team the affected floor, configured resolver, host name, timestamps and comparison results. I would not change DNS settings or restart a shared service without its owner's approval.”
Why it works: A plausible diagnosis does not create permission to change infrastructure.
Step 4: Verify the workaround and own the update
What would you do here? Open the move you’d make.
Get a user task check and set the next update
The strong move. This distinguishes a useful workaround from a repaired wired service and preserves ownership.
Close the issue because Wi-Fi worked in the comparison
Tempting, but it misses something. The affected users still need to verify their task, and the wired fault remains unresolved.
See how a strong candidate says it
“Please use the approved corporate Wi-Fi if it is available, then confirm that the scheduling task works. I have sent the wired-network evidence to the network team and will update you at 09:30, even if its cause is still under investigation.”
Why it works: A verified workaround restores some work while the original fault remains open.
The answer, in short
- Decision
- Escalate the wired resolver evidence and verify the approved workaround.
- Because
- All three wired checks fail while all three approved Wi-Fi checks succeed; the name-lookup reports differ before authentication.
- What would change it
- Failures on the comparison network, or new application-side evidence, would widen the investigation. Only an owner-confirmed repair and user checks would support closing the wired fault.
Common traps
- Treating several reports as proof of a global outage.
- Changing managed resolver settings without authority.
- Calling a workaround a permanent repair.
Check your answer
- Did you separate three wired failures from three Wi-Fi successes?
- Did you use the pre-login lookup evidence instead of repeating a password or laptop reset?
- Did you name the network owner and preserve the change boundary?
- Did you ask the user to verify the task and set an update time?
Last reviewed Nov 10, 2026