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.

• ✓

  View Admin Activity audit logs in Logs Explorer, which are enabled by default.

  Why this is correct

  Admin Activity audit logs are enabled by default for every Google Cloud project and record all IAM policy changes, including modifications to roles, bindings, and service account keys. To see who changed permissions, you can go directly to the Logs Explorer and query protoPayload.methodName=SetIamPolicy without creating any sinks or enabling additional features. This is the only option that directly answers the question with zero configuration effort.

• ✗

  Use Organization Policy to deny IAM policy changes and monitor violations.

  Why it's wrong here

  Organization Policy is a governance mechanism for enforcing constraints (e.g., restricting resource locations or disabling service account key creation), not a logging or monitoring tool for tracking past IAM changes. It cannot produce a record of who changed what, and policy violations are not written to audit logs; they are simply denied at request time. Using it would help prevent future changes but would not reveal historical IAM modifications as requested.

• ✗

  Enable Data Access audit logs for all services in the organization.

  Why it's wrong here

  Data Access audit logs capture read, write, and metadata operations on user data and are disabled by default because they can be high-volume and costly. They do not record IAM policy changes; IAM permission modifications are exclusively a type of Admin Activity audit log event. Enabling Data Access for all services would generate a massive amount of irrelevant logging and still fail to show the IAM changes you want to view.

• ✗

  Enable audit logging on each project individually using gcloud logging sinks.

  Why it's wrong here

  Admin Activity audit logs need no explicit enabling, so running gcloud logging sinks to enable audit logging on each project is unnecessary and misses the point: sinks are used to route existing logs to external destinations like BigQuery or Pub/Sub, not to turn on logging. Individual project changes are redundant because Admin Activity is already on globally, and adding sinks would add cost and complexity for no value in this scenario.

Go deeper

Related to this question