Google ACE Configuring Access and Security Practice Question

A company has an organization with multiple folders and projects. They want to audit all IAM policy changes across the entire organization. Which approach meets the requirement with minimal effort?

⚠ Common exam trap

ACE often tests the misconception that you must enable audit logs to see IAM changes, when in fact Admin Activity logs are on by default and already capture them; candidates may incorrectly choose Data Access logs or per-project sinks.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

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

Admin Activity audit logs are enabled by default for all Google Cloud projects and organizations, and they automatically capture IAM policy changes (e.g., SetIamPolicy calls) at the organization, folder, and project levels. Because they are always on and aggregated at the organization level, you can view them in Logs Explorer without enabling anything or configuring per-project sinks. This meets the audit requirement with minimal effort.

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

Google ACE Configuring Access and Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question