Google Cloud Professional DevOps Engineer Advanced Practice Exam: Hard Questions 2025

You are onboarding 40 newly acquired business units into a single Google Cloud organization. Each unit must be able to create projects only from an approved set, inherit baseline security controls (logs retained, restricted public IPs, CMEK defaults), and be prevented from disabling required APIs. Some units need different network perimeters but must still share a centralized security project for logs and SIEM export. You need a design that is enforceable at scale and minimizes manual drift. What should you do?

Your organization uses a centralized Terraform pipeline to provision projects and baseline security resources. Multiple teams contribute modules. A recent change accidentally granted overly broad IAM roles in several production projects before being detected. You need a preventive control that blocks noncompliant IAM bindings at provisioning time across all projects (including those created in the future) while still allowing teams to use Terraform. What is the best approach?

A Cloud Build pipeline builds a container and deploys to Cloud Run. You introduce Binary Authorization with attestations so only images built by Cloud Build can be deployed. After enabling it, deployments intermittently fail with permission errors when Cloud Run tries to verify the attestation. Builds and attestation creation succeed. The deployment service account is separate from the build service account. What is the most likely fix?

You run a microservices platform on GKE with GitOps. A new release caused elevated 500s. You need an automated canary process that (1) gradually shifts traffic, (2) automatically rolls back based on SLO-based metrics from Cloud Monitoring, and (3) records release metadata for postmortems. Your teams want minimal bespoke scripting and prefer managed/standard tooling. What should you implement?

Your org uses private pools for Cloud Build with no public egress. Builds pull dependencies from Artifact Registry and also need to download a small file from a third-party HTTPS endpoint. The security team refuses to open general internet egress. Builds are failing. You must keep builds isolated while enabling this specific external dependency fetch with strong controls and auditability. What should you do?

A product team reports that their 99.9% availability SLO is frequently violated due to brief spikes in latency and error rate during deployments. They currently page on any SLO violation, causing alert fatigue. You want to redesign alerting to align with SRE best practices using error budgets while still catching fast-burning incidents quickly. What should you implement?

You operate a multi-region service behind a global external HTTP(S) Load Balancer. During a regional outage, some users still experienced elevated latency and intermittent 502s for 10 minutes even though the service has healthy capacity in other regions. Post-incident analysis shows that failover was delayed by slow health check convergence and stale backends. You need to reduce time-to-failover without significantly increasing false positives during partial brownouts. What is the best change?

Your GKE cluster emits high-cardinality metrics due to labels that include request IDs and user IDs. Cloud Monitoring costs and query performance are degrading, and SLO dashboards time out. You still need per-user debugging capability, but not as time-series metrics. What should you do?

A latency SLO for a Cloud Run service is implemented using a log-based metric derived from request logs. After a traffic surge, the SLO shows excellent performance, but users report timeouts. Investigation finds that many requests never produced application logs due to early termination at the load balancer or platform before reaching the container. You need an accurate SLI for latency and availability that captures platform-level failures. What should you do?

A critical API on GKE shows periodic p99 latency spikes. CPU utilization is moderate, but node-level metrics show frequent disk I/O bursts and container restarts correlate with readiness probe failures. The service uses a local disk cache inside each pod and writes temporary files heavily. You need to reduce tail latency and improve stability without overprovisioning CPU. What is the best approach?