Google ACE Practice Question: A team discovers their Cloud Logging costs are…

A team discovers their Cloud Logging costs are unexpectedly high. The majority of costs come from verbose DEBUG-level logs from a development service in production. They want to stop storing DEBUG logs without modifying the application. What is the solution?

⚠ Common exam trap

Many exam-takers think modifying the application's log level is the only way to reduce log volume, but Cloud Logging exclusion filters provide a non-invasive, infrastructure-level solution that avoids code changes.

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

✓

Create a Cloud Logging exclusion filter to discard DEBUG-level log entries from the service

Cloud Logging exclusion filters allow you to discard log entries based on criteria such as severity level, log name, or resource labels before they are ingested and stored. By creating an exclusion filter that matches DEBUG-level log entries from the specific development service, you can stop storing those logs without modifying the application code. This approach directly reduces storage costs because excluded logs are not indexed or retained.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Set the application's log level to INFO — this is the only way to reduce log volume
Why it's wrong here
Raising the application's log level to INFO requires modifying, rebuilding, and redeploying the service, whereas a Log Router exclusion filter achieves the same drop of DEBUG entries outside the application. The claim that this is the 'only' way is false — the correct answer is a filter — and changing log level also still lets INFO-and-above logs flow, which is exactly what the exclusion filter would do. It is a valid tactic but a heavier engineering change; it is not uniquely necessary to reduce log volume.
✓
Create a Cloud Logging exclusion filter to discard DEBUG-level log entries from the service
Why this is correct
A Cloud Logging exclusion filter in the Log Router can match DEBUG entries from the service's resource type (e.g., `resource.type="cloud_run_revision"` and `severity=DEBUG`) and discard them before they are written to any sink or storage. Because exclusion filters are evaluated during ingestion, the matched entries are never billed, so this reduces logging costs immediately without code changes or redeployment. The application can keep emitting DEBUG logs; Log Router simply drops them, making this the operational solution that directly addresses the cost driver.
✗
Move the development service to a separate GCP project with a lower logging tier
Why it's wrong here
GCP does not offer per-project 'logging tiers' or a cheaper logging edition; every project pays the same pay-as-you-go rate based on log volume measured in bytes. Moving the development service to a separate project merely splits the bill across two IDs — the total ingest bytes, and therefore the total cost, stays identical unless you also add exclusion filters in that new project. A separate project can help with IAM isolation but not with reducing the volume of logs Cloud Logging receives.
✗
Delete old DEBUG log entries manually — Cloud Logging charges for stored volume
Why it's wrong here
Cloud Logging charges primarily for ingested volume — every entry counted and billed as it arrives — so deleting old DEBUG logs after they have already been stored does nothing to undo the ingestion cost. The stored-log portion is comparatively small and governed by retention settings, not by manual deletion. A post-hoc cleanup is also manual, error-prone, and doesn't scale; only filtering at ingestion time prevents the bytes from being billed in the first place.

Go deeper

Google ACE Practice Question: A team discovers their Cloud Logging costs are…

Why each option matters

Option-by-option breakdown

Related to this question