QuestionCONSTRUCTED
Interview prep: a successful sign-in from a country the user has never visited
A mid-level cloud question that tests whether you separate authentication from session, and whether you can decide quickly without deciding wrongly.
mid levelclouda spoken answer of about 3 minutes
The question
“An account shows a successful sign-in from a country the user has never been to. How do you decide whether it is malicious, and what do you do in the meantime?”
Goodcorrect, and where most candidates stop
I would ask the user whether they were travelling or using a VPN, check the IP address's reputation, and look at the user's other recent sign-ins. If it was not them, I would reset the password and enable MFA if it was not already on.
Betteradds the limits and the second source
The country is the least useful field on the record. I would look at the address's provider, because a hosting provider or an anonymising VPN is rare for a real user; at the device and browser, compared with what they normally use; at the app they signed in to; and at how authentication was satisfied.
I would ask the user by phone rather than email, because if the account is compromised the attacker can read the reply. If it was not them, I would revoke all sessions before resetting the password, check for newly registered MFA methods, and look for inbox rules, forwarding and app consents created since the sign-in.
Bestwhat somebody who has done it says
I would separate two questions that the alert runs together: was this authentication the user, and is this session the user's.
A successful sign-in with MFA from abroad is, these days, frequently the user's own authentication being relayed. A phishing kit sits between them and the real login page, they complete MFA, and the attacker keeps the session cookie. So a satisfied MFA challenge does not clear it, and the thing to look for is the same session appearing from two addresses within minutes, and non-interactive token refreshes from infrastructure the user has never used.
On deciding: containment here is cheap and reversible. Revoking sessions costs the user a sign-in; waiting costs whatever the session reaches. So if the record does not fit after a few minutes, I would revoke and then investigate, rather than investigate and then revoke. I would check MFA methods and devices registered since, mailbox rules and forwarding, app consents, and file access, and search for the same address against other accounts.
Before accepting "it was me, on a VPN", I would check that the provider really is their VPN's, and that the device matches one of theirs. And I would note retention: Entra keeps sign-in logs for seven days on the free tier, so if this tenant is on it, the export happens now or not at all.
Why the gap between them matters
Good follows a checklist. Better reads the record. Best understands the attack that produces this record most often now, and so knows which part of the good answer is dangerous: a password reset without revoking sessions leaves a relayed session running. The first-15-minutes checklist is the same reasoning as steps.
What they are listening for
Whether you look at the sign-in record's detail rather than the country, know that MFA succeeding does not clear it, and are willing to contain before you are certain when containment is cheap.
Where it goes next
- MFA was satisfied on the suspicious sign-in. Does that make it more or less likely to be the user?
- The user says it was them, on a VPN. What do you check before you accept that?
- Where would you look for the attacker using a session they already have?
Confident and wrong
- Blocking the country and closing the ticket.
- Treating a satisfied MFA challenge as proof that it was the user.
- Emailing the user to ask, from or to the account in question.