A security engineer needs to establish centralized detection and alerting across an enterprise Google Cloud organization for unauthorized API invocation attempts and policy violations blocked at the perimeter. The solution must fulfill the following operational requirements: Capture and distinguish between administrative configuration modifications and perimeter or policy denial events. Enable automated near-real-time alerting in Cloud Monitoring when unauthorized or denied API invocation attempts spike across projects. Ingest and centralize the required audit telemetry without incurring unexpected ingestion drop-offs due to default project settings. Which configuration strategy should the engineer implement?

Aggregate organization-level Cloud Audit Logs for Admin Activity and Policy Denied logs (`cloudaudit.googleapis.com%2Factivity` and `cloudaudit.googleapis.com%2Fpolicy`) into a central project, create a logs-based metric filtered on policy denials and method calls, and attach a Cloud Monitoring alerting policy with notification channels.: ### What this solution is This architecture centralizes organization-wide **Cloud Audit Logs** into a dedicated security logging project, establishes custom **logs-based metrics** targeting specific policy violation streams, and triggers automated alerts via **Cloud Monitoring**. ### How it meets the requirements - **Capturing administrative changes and perimeter denials:** Cloud Audit Logs automatically records administrative actions in Admin Activity logs (`cloudaudit.googleapis.com%2Factivity`) and logs access blocks enforced by perimeter controls (such as VPC Service Controls and IAM) in Policy Denied logs (`cloudaudit.googleapis.com%2Fpolicy`). - **Automated near-real-time alerting:** Creating a user-defined logs-based counter metric on the aggregated Policy Denied log stream extracts counts of denied invocations. Cloud Monitoring evaluates these counts against defined threshold conditions and notifies on-call teams. - **Centralized ingestion:** An aggregated log sink defined at the organization root routes logs from all child folders and projects into a centralized log bucket, preventing disparate or dropped project-level auditing. ### Key advantages - **Immutability and default coverage:** Admin Activity and Policy Denied audit logs are enabled by default and cannot be disabled by project owners, ensuring comprehensive tamper-resistant coverage. - **Granular filter criteria:** Logs include caller IP (`RequestMetadata.caller_ip`), method names (`protoPayload.methodName`), and resource identities, facilitating precise metric filtering. - **Fast threat detection:** Logs-based metrics populate time-series data immediately as log entries are ingested into Cloud Logging.

Audit Monitor Api Policy Denials Alerts | Professional Cloud Security Engineer

Audit Monitor Api Policy Denials Alerts

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.

A security engineer needs to establish centralized detection and alerting across an enterprise Google Cloud organization for unauthorized API invocation attempts and policy violations blocked at the perimeter.

The solution must fulfill the following operational requirements:

Capture and distinguish between administrative configuration modifications and perimeter or policy denial events.
Enable automated near-real-time alerting in Cloud Monitoring when unauthorized or denied API invocation attempts spike across projects.
Ingest and centralize the required audit telemetry without incurring unexpected ingestion drop-offs due to default project settings.

Which configuration strategy should the engineer implement?

Deploy the Google Cloud Ops Agent on all Compute Engine instances, configure a Prometheus endpoint to emit workload.googleapis.com metrics, and set up ActiveMQ integration alerting policies in Cloud Monitoring.

Configure an Istio AuthorizationPolicy with the AUDIT action inside Cloud Service Mesh on ingress gateways, and route the resulting envoy access logs directly to Cloud Monitoring using MQL alerting rules.

Aggregate organization-level Cloud Audit Logs for Admin Activity and Policy Denied logs (cloudaudit.googleapis.com%2Factivity and cloudaudit.googleapis.com%2Fpolicy) into a central project, create a logs-based metric filtered on policy denials and method calls, and attach a Cloud Monitoring alerting policy with notification channels.

Enable Data Access audit logs globally at the organization root, rely on the default _Default sink for storage in each individual project, and create project-level PromQL queries in Metrics Explorer to track cloudaudit.googleapis.com%2Fsystem_event.

Professional Cloud Security Engineer

Audit Monitor Api Policy Denials Alerts

Related questions