Professional Cloud Security Engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
A security operations team is investigating an incident triggered by an Event Threat Detection finding: Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity.
While analyzing the raw Google Cloud Admin Activity audit log entry associated with the incident in Cloud Logging, the analyst observes the following authenticationInfo and requestMetadata structure:
{
"protoPayload": {
"serviceName": "storage.googleapis.com",
"methodName": "storage.buckets.setIamPolicy",
"authenticationInfo": {
"principalEmail": "prod-backup-manager@company-prod.iam.gserviceaccount.com",
"serviceAccountDelegationInfo": [
{
"principalEmail": "cicd-deployer@company-prod.iam.gserviceaccount.com"
},
{
"principalEmail": "external-contractor@partner.com"
}
]
},
"requestMetadata": {
"callerIp": "198.51.100.24"
}
}
}
How should the security analyst interpret the identity hierarchy and audit fields to reconstruct this security event?
The API call was executed under the authority of prod-backup-manager, the original caller who initiated the chain was external-contractor, and cicd-deployer served as an intermediate delegated service account.
The API call was initiated by cicd-deployer because it appears first in serviceAccountDelegationInfo, and external-contractor is an authorized spectator or secondary approver.
The API call was executed directly by prod-backup-manager without delegation, and the serviceAccountDelegationInfo list displays the identities whose IAM permissions were removed by the policy update.
The API call was executed under the authority of external-contractor, who directly impersonated cicd-deployer, while prod-backup-manager represents the target resource being modified.
The API call was executed under the authority of prod-backup-manager, the original caller who initiated the chain was external-contractor, and cicd-deployer served as an intermediate delegated service account.
In Google Cloud Audit Logs, when API calls are executed using service account impersonation or delegation chains, the protoPayload.authenticationInfo object records both the direct identity whose privileges were evaluated and the sequence of identities that delegated those privileges.
principalEmail): The top-level principalEmail field (prod-backup-manager@company-prod.iam.gserviceaccount.com) records the final service account whose IAM permissions authorized the storage.buckets.setIamPolicy method.serviceAccountDelegationInfo bottom): In multi-step delegation chains, the entries in serviceAccountDelegationInfo describe the delegation sequence in reverse order; the principal at the bottom (the last element of the list, external-contractor@partner.com) is the originating actor who initiated the impersonation sequence.cicd-deployer@company-prod.iam.gserviceaccount.com) represent intermediate service accounts whose credentials or tokens were generated along the transitive delegation chain.external-contractor@partner.com is the initial identity requiring credential revocation and compromise assessment.iam.serviceAccounts.getAccessToken or roles/iam.serviceAccountTokenCreator) spanning from external-contractor through cicd-deployer to prod-backup-manager.198.51.100.24 back to the external entity that originated the request.Understanding the ordering within serviceAccountDelegationInfo ensures investigators do not misattribute malicious changes solely to the service account executing the API call, enabling full remediation of the compromised originating identity and intermediate privilege escalation vectors.
The API call was initiated by cicd-deployer because it appears first in serviceAccountDelegationInfo, and external-contractor is an authorized spectator or secondary approver.
The API call was executed directly by prod-backup-manager without delegation, and the serviceAccountDelegationInfo list displays the identities whose IAM permissions were removed by the policy update.
The API call was executed under the authority of external-contractor, who directly impersonated cicd-deployer, while prod-backup-manager represents the target resource being modified.