The treasurer's Microsoft Entra ID account shows a sign-in from an unfamiliar country. Which cloud sourcetype should the analyst pull first?
Select an answer to reveal the explanation.
Short Explanation
Account takeover is an identity story, so start with the IdP's sign-in log—Entra, not the city's leftover AWS flow logs. VPC flow will not tell who typed the treasurer's password. Wrong sourcetype, wrong investigation.
Full Explanation
When the treasurer's Microsoft Entra ID account shows a sign-in from an unfamiliar country, the analyst should pull Azure AD or Microsoft Entra sign-in or audit logs first—the identity sourcetype for that cloud account. Those logs hold location, IP address, client application, conditional access results, and MFA outcomes needed for account-takeover triage on civic SaaS and mailbox access. No AWS network or storage log substitutes for identity-provider evidence when the question is about an Entra sign-in.
VPC Flow Logs from an AWS account that does not host treasurer identity cannot explain Entra sign-ins or token issuance for Microsoft 365. CloudTrail data events for an S3 bucket unrelated to the treasurer's login are object-level storage audit, not identity-provider authentication. GuardDuty findings for a test VPC with no Entra trust are the wrong cloud detection plane for this Microsoft identity question and will not list the unfamiliar country claim.
Exam caveat: Entra or Azure AD account anomalies require Entra sign-in or audit sourcetypes first; do not substitute AWS network, storage, or GuardDuty logs for IdP telemetry.
Operational check: query Entra sign-in logs for the treasurer UPN in the unfamiliar-country window, note risk flags and MFA results, check for new mailbox rules, revoke active sessions, and contain per municipal incident-response playbooks.