CS0-003 Security Operations Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Review the cloud application's audit logs for file access or sharing events

  Why this is correct

  Cloud application audit logs (e.g., Microsoft 365's Unified Audit Log or Google Workspace's Admin Log) provide a tamper-evident record of every file access, download, share, and permission change linked to a user or session. By correlating the CASB alert's timestamp, source IP, and geolocation with these logs, the analyst can determine definitively whether sensitive files were opened, downloaded, or shared externally. This evidence-first approach confirms or refutes exfiltration and helps scope the incident without causing business disruption.

• ✗

  Disable the user's account immediately

  Why it's wrong here

  Immediately disabling the user's account is a containment action that presumes the alert represents a confirmed compromise, but CASB alerts are often triggered by benign anomalies such as a legitimate user traveling, a VPN egress, or an IP geolocation mismatch. Taking this irreversible step without first reviewing the user's authentication and audit logs can lock out a productive employee or contractor and generate unnecessary helpdesk escalations. Moreover, if the alert is a false positive, the account disablement itself becomes a mini-incident that distracts from real threats; investigation must precede containment.

• ✗

  Reset the user's password without further analysis

  Why it's wrong here

  Resetting a password without first analyzing the alert assumes the credential itself was stolen, but the CASB alert may stem from an unauthorized third-party application using OAuth tokens, a compromised device registered with the account, or a policy violation unrelated to password theft. A password reset does not invalidate existing OAuth grants, session cookies, or API tokens, so it often fails to remediate the actual access path the alert detected. Additionally, if data was already exfiltrated, a password change does nothing to recover or assess the exposure—confirming compromise through log analysis should always come first.

• ✓

  Check the user's recent authentication logs for successful logins

  Why this is correct

  Authentication logs from the cloud identity provider (e.g., Azure AD Sign-ins Logs or Okta System Log) capture successful and failed login attempts along with the source IP, device fingerprint, and multi-factor authentication (MFA) result. Matching the CASB alert's source location against recent successful logins for that user allows the analyst to determine whether the user themselves legitimately accessed the app from that region or whether an attacker used stolen credentials. This is a pivotal triage step because it validates the alert as a true positive (e.g., impossible travel confirmed) or a false positive (e.g., user accessed via a corporate VPN), before any further containment is applied.

• ✗

  Block all access to the cloud application from that location

  Why it's wrong here

  Blocking all access from the alert's geographic location is an aggressive and overly broad response that can affect many legitimate users who share that region or egress IP, such as remote employees connecting through the same ISP or a branch office. Attackers routinely route traffic through proxies, cloud IP ranges, or botnets in other regions, so a location-based block may not prevent further malicious access and can be easily bypassed. The CASB alert is only a trigger to investigate the specific user and session, not to impose network-level quarantine, which should be reserved for confirmed, ongoing malicious activity after evidence has been gathered.

Go deeper

Related to this question