GCP Incident Triage Lab: Leaked Key to Containment

It covers a leaked service account key found by Security Command Center, reading Cloud Audit Logs, the gap when Data Access logs are off, persistence through a new key and an outside IAM grant, a compromised GKE workload identity, Workload Identity Federation conditions, a BigQuery data extraction, a changed VPC Service Controls perimeter, central log evidence and prevention with organization policy constraints.

No. Google documents that Admin Activity and System Event audit logs are always written and cannot be disabled, while Data Access audit logs are off by default for all services except BigQuery. The lab uses that gap: without them you cannot prove whether Cloud Storage objects were read, so you scope by what the credential could access.

Stop the credential working and keep the evidence. Google's guidance is to delete an exposed key quickly and warns that removing it from a repository is not enough. In the lab we disable the key first, record its ID, and delete it after the evidence is captured; that ordering is PlayCISO practice rather than a Google statement.

No. It is a fictional composite built from finding names and behaviours that Google documents, such as Event Threat Detection's Initial Access, Persistence and Exfiltration categories. The organisation, projects, accounts and address are invented.

Each decision scores 0 to 10 and the final result is the share of the maximum. A short band explains what your score means and the debrief shows the source behind each rationale.