Google ACE Configuring Access and Security 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.

• ✗

  System Event audit logs

  Why it's wrong here

  These logs record administrative actions that impact the configuration of Google Cloud resources, but they specifically track system-generated events like lifecycle changes of resources (e.g., VM instance creation/deletion, disk resizing) and operations performed by Google's systems, not user-driven IAM policy modifications. IAM policy changes are classified as Admin Activity (Cloud Audit Logs category) because they're administrative operations by principals, and System Event logs explicitly exclude changes made by users to resource policies. Therefore, they won't show an IAM policy change.

• ✗

  Data Access audit logs

  Why it's wrong here

  Data Access logs capture API calls that read or modify user data, such as reading from a Cloud Storage bucket or querying a database, and they are disabled by default for that reason. IAM policy changes are administrative actions, not data access operations, and they fall under Admin Activity. Also, Data Access logs do not include writes to metadata or policy changes; they track data plane operations like object reads/writes, not control plane changes like IAM bindings.

• ✗

  VPC Flow Logs

  Why it's wrong here

  VPC Flow Logs record metadata about network traffic flowing through VPC subnets, such as source/destination IPs, ports, and protocols, to help with network monitoring and security analysis. They do not log control plane operations or API calls, so any IAM policy change (a control plane action) would never appear. IAM changes are triggered via Cloud Resource Manager APIs and are captured by Admin Activity audit logs, not network packet metadata.

• ✓

  Admin Activity audit logs

  Why this is correct

  Admin Activity audit logs are enabled by default and capture all API calls that modify the configuration or metadata of resources, including IAM policy updates. For an organization with multiple folders, these logs at the org level record IAM binding changes on any resource in the hierarchy, such as 'setIamPolicy' from projects or folders. They provide an audit trail of who changed what, when, from where, and for which resource, making them the correct log type for investigating IAM policy modifications.

Go deeper

Related to this question