Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
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.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
An enterprise web service running on a fleet of Compute Engine Linux VMs generates over 40,000 HTTP access log entries per second per instance during peak traffic. The operations team identifies two major issues:
StudyCerts
StudyCertsgoogle-fluentd) is reaching its single-core CPU limit and dropping log entries due to buffer overflow.You must design an observability architecture that achieves the following requirements:
Which solution should you implement?
Modify the logrotate configuration on each VM to use copytruncate with postrotate agent restarts; deploy log-based metrics on the _Default log bucket; route 100% of logs to BigQuery for analysis.
Upgrade instances to the Google Cloud Ops Agent; define log-based metrics on the incoming log stream to track overall request counts; configure an exclusion filter on the _Default log sink with sample(insertId, 0.90) for logs with HTTP status codes below 500.
Configure the legacy Logging agent with a record_transformer filter to trim payload sizes below 256 KiB; create a Cloud Monitoring uptime check for traffic metrics; route all logs to a Cloud Storage cold archive bucket.
Keep the legacy Logging agent and assign multiple worker processes on port 24231; apply an exclusion filter of sample(insertId, 0.10) for HTTP 5xx error logs; rely on Logs Analytics SQL queries for request metrics.
Modify the logrotate configuration on each VM to use copytruncate with postrotate agent restarts; deploy log-based metrics on the _Default log bucket; route 100% of logs to BigQuery for analysis.
Upgrade instances to the Google Cloud Ops Agent; define log-based metrics on the incoming log stream to track overall request counts; configure an exclusion filter on the _Default log sink with sample(insertId, 0.90) for logs with HTTP status codes below 500.
This architecture combines the high-throughput Google Cloud Ops Agent with Log-based Metrics and Log Exclusion Filters using deterministic sampling in Cloud Logging.
google-fluentd agent is CPU-bounded and capped at roughly 5,500 entries per second on a single core. Upgrading to the Google Cloud Ops Agent increases throughput capacity to approximately 160,000 log entries per second on Linux, easily handling 40,000 entries per second without buffer overflows.sample(insertId, 0.90) on logs where httpRequest.status < 500 discards 90% of non-error logs before ingestion into the _Default bucket, retaining an exact 10% uniform sample.500 or higher bypass the exclusion filter entirely and are stored in full for debugging and auditing.sample() function hashes fields such as insertId to produce statistically accurate uniform sampling across distributed instances.This design leverages native Cloud Logging pipeline behavior—extracting metric data before exclusion routing—so no monitoring visibility is lost while drastically reducing storage spend and agent compute bottlenecks.
Configure the legacy Logging agent with a record_transformer filter to trim payload sizes below 256 KiB; create a Cloud Monitoring uptime check for traffic metrics; route all logs to a Cloud Storage cold archive bucket.
Keep the legacy Logging agent and assign multiple worker processes on port 24231; apply an exclusion filter of sample(insertId, 0.10) for HTTP 5xx error logs; rely on Logs Analytics SQL queries for request metrics.