Cloud Digital Leader Trust and security with Google Cloud 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.

• ✗

  Manually reviewing and removing the employee's IAM bindings across all Google Cloud projects one by one

  Why it's wrong here

  Manual IAM binding review across potentially dozens of projects is slow, error-prone, and incomplete — the employee may have IAM bindings in projects the IT team doesn't know about. During the review period, access remains active.

• ✓

  Disabling the employee's Google Workspace account (which immediately invalidates all active sessions and prevents new authentication), then auditing for and revoking any service account keys they created

  Why this is correct

  This is the comprehensive approach. Disabling the Workspace identity immediately invalidates all active OAuth tokens and prevents new sign-ins — all GCP access based on that identity stops instantly. Auditing for service account keys they created closes the remaining gap (keys are separate credentials not tied to the user account).

• ✗

  Changing the employee's password immediately — they can no longer log in with the old password

  Why it's wrong here

  Changing the employee's password only blocks future password-based sign-ins; it does not invalidate already-issued OAuth tokens or existing sessions, so the terminated employee can continue making authenticated API calls, accessing Cloud Storage, and using GCP services until those tokens expire. Moreover, if the employee uses federated login with SSO (e.g., SAML) or service account impersonation, a local password change may have little to no effect on their ability to authenticate. Proper termination requires disabling the user account, which revokes all active sessions and tokens immediately, not merely changing a credential that leaves the underlying session infrastructure intact.

• ✗

  Waiting until the end of the business day to revoke access to avoid disrupting active workflows

  Why it's wrong here

  Delaying revocation until the end of the business day keeps the terminated employee's active Google Cloud sessions and OAuth tokens valid, allowing continued access to sensitive data and project resources throughout that entire period. An employee who is being terminated poses an insider threat, and any delay—even for workflow convenience—creates a window for data exfiltration or malicious changes. Immediate access revocation is a non-negotiable security control; if workflow disruption is a concern, use break-glass accounts or pre-staged handoff procedures rather than leaving a former employee's access live.

Go deeper

Related to this question