Professional Cloud Architect · 15% of the exam

Manage and provision a solution infrastructure: free practice questions

5 sample questions from our 38-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real Google Cloud exam.

1. An organization uses Cloud Monitoring to observe a multi-tier application. The team wants to create an alerting policy that fires only when BOTH of the following conditions are true simultaneously for more than 5 minutes: CPU utilization on the API tier exceeds 85%, AND the error rate on the database tier exceeds 50 errors per second. Which alerting policy configuration achieves this?

  • A. Create two separate alerting policies — one for CPU and one for error rate — and configure PagerDuty to deduplicate alerts when both fire at the same time.
  • B. Create a single alerting policy with multiple conditions and set the condition combiner to `AND`, with each condition specifying its own metric threshold and a 5-minute duration window.✓ Correct
  • C. Create a single alerting policy with multiple conditions and set the condition combiner to `OR` so that either condition alone can trigger the alert.
  • D. Use a log-based alert that queries Cloud Logging for log entries matching both high CPU and high error rate patterns within a 5-minute window.
Explanation

Option B is correct because Cloud Monitoring alerting policies support multiple conditions with an `AND` combiner (also known as `ALL_CONDITIONS_MET`). With this setting, the incident is only created when all specified conditions are simultaneously in a breach state, and the 5-minute duration window is configurable per condition. This precisely matches the requirement. Option A is wrong because relying on an external tool like PagerDuty for deduplication is not a reliable way to enforce simultaneous condition logic — the two policies fire independently and there is no guaranteed correlation. Option C is wrong because an `OR` combiner fires when either condition alone breaches the threshold, which does not match the requirement of both being true simultaneously. Option D is wrong because CPU utilization is a metric, not a log — log-based alerts cannot directly query metric values, and this approach would be fragile and incomplete.

2. An operations team needs to receive an alert when the 99th percentile latency of a Cloud Run service exceeds 2 seconds for more than 5 consecutive minutes. They want the alert sent to a Slack channel. What is the correct sequence of steps to implement this in Cloud Monitoring?

  • A. Create a log-based metric on Cloud Run request logs, create an alerting policy on that metric with a threshold of 2000 ms over a 5-minute alignment period, create a notification channel of type 'Webhook' pointed at the Slack incoming webhook URL, and attach it to the policy.✓ Correct
  • B. Create a custom metric by writing a Cloud Function that queries Cloud Run metrics every minute and publishes latency data to Cloud Monitoring, then create an alerting policy with an email notification channel.
  • C. Enable Cloud Trace on the Cloud Run service, create a Service Level Objective (SLO) for latency, and configure a burn-rate alert that pages the on-call engineer.
  • D. Create an uptime check targeting the Cloud Run service URL, set the alert threshold to 2000 ms, and configure a PagerDuty notification channel.
Explanation

Option A is correct. Cloud Run request latency is available as a built-in metric (`run.googleapis.com/request_latencies`), but 99th-percentile aggregation requires careful alignment. Using a log-based metric on Cloud Run request logs allows percentile distribution tracking. The alerting policy is configured with the appropriate threshold and duration window (5 minutes). A Webhook notification channel pointing to a Slack incoming webhook URL is the supported method for Slack integration in Cloud Monitoring. All steps are accurate and achievable within Cloud Monitoring. Option B is wrong because it introduces unnecessary complexity—Cloud Run latency metrics already exist natively; polling with a Cloud Function is redundant and adds latency to alerting. Using email also does not satisfy the Slack channel requirement. Option C is wrong because while SLOs and burn-rate alerts are valid for SRE workflows, they measure error budget consumption over longer windows and are not a direct 'latency > 2s for 5 minutes' threshold alert; also, the alert destination is pager/on-call rather than Slack. Option D is wrong because uptime checks measure endpoint availability (HTTP status codes and response time for the check probe), not the real-user 99th-percentile latency distribution; the 'threshold' in an uptime check is for the check's own response time, which is different.

3. A team maintains two Terraform root modules—one for networking and one for application infrastructure—stored in separate directories. The application module needs to reference the VPC network name created by the networking module without duplicating code. What is the recommended Terraform approach to share this value between the two root modules?

  • A. Hardcode the VPC network name as a local variable in the application module, updating it manually whenever the networking module changes.
  • B. Use a `terraform_remote_state` data source in the application module to read outputs from the networking module's state file stored in a Cloud Storage backend.✓ Correct
  • C. Merge both modules into a single root module so all resources share the same state file and can reference each other's outputs directly.
  • D. Use a Cloud Build pipeline to copy the output value from the networking module into an environment variable, then inject it into the application module at plan time.
Explanation

Option B is correct. The `terraform_remote_state` data source is the canonical Terraform mechanism for sharing outputs between independent root modules. The networking module publishes its VPC name as an output, and the application module reads it from the networking module's remote state (e.g., stored in a Cloud Storage bucket configured as a GCS backend). This keeps modules decoupled while enabling safe, automated cross-module data sharing. Option A is wrong because hardcoding the value creates maintenance toil and introduces human error; if the network is renamed or recreated, the application module becomes stale and a manual synchronization step is required. Option C is wrong because merging modules into a single root module eliminates separation of concerns, makes state files large and risky (a mistake in one area can affect the other), and removes the ability to independently manage networking and application infrastructure lifecycles. Option D is wrong because injecting values through CI/CD environment variables is fragile, ties the infrastructure to a specific pipeline tool, and makes local development (running `terraform plan` without the pipeline) difficult or broken.

4. A cloud engineer needs to organize Google Cloud resources for a large enterprise with three business units, each containing multiple teams and environments (dev, staging, prod). The security team requires that IAM policies applied at the business-unit level automatically cascade to all teams within that unit, while still allowing team-level customization. Which resource hierarchy structure best satisfies these requirements?

  • A. Create one project per business unit and use resource labels to distinguish teams and environments.
  • B. Create one folder per business unit, with sub-folders per team, and projects for each environment under each team folder.✓ Correct
  • C. Create one folder per environment (dev, staging, prod) at the organization level, with projects for each team inside each environment folder.
  • D. Place all resources in a single project and use IAM conditions to restrict access per business unit.
Explanation

Option B is correct because GCP folders support nested hierarchies, and IAM policies are inherited downward — policies set at the business-unit folder cascade to all team sub-folders and their projects, while additional project-level or sub-folder-level bindings allow team-level customization. Option A is wrong because projects are the boundary for billing and access, not a structural hierarchy — labels do not enforce IAM inheritance. Option C groups by environment, not business unit, breaking the requirement that business-unit-level policies cascade to all teams in that unit. Option D places everything in a single project, making fine-grained isolation impossible and conflating all teams' resources.

5. An infrastructure team uses Cloud Build to run Terraform for all environment provisioning. After a recent reorganization, a new `staging` environment must be provisioned from a separate Cloud Build trigger that reads Terraform variable files from a Cloud Storage bucket in a different project. The trigger fires successfully but Terraform fails with a '403 Forbidden' error when reading the variable file. What is the most likely cause and fix?

  • A. The Cloud Build service account in the build project does not have the Storage Object Viewer role on the bucket in the other project. Grant that role to the Cloud Build service account.✓ Correct
  • B. Cloud Build triggers cannot read files from Cloud Storage buckets; the variable file must be committed to the source repository and referenced directly in the build configuration.
  • C. The Terraform backend configuration is pointing to the wrong state bucket, causing the 403 error when trying to read variables. Update the backend block to the correct bucket name.
  • D. The Cloud Storage bucket has Uniform Bucket-Level Access disabled, so object ACLs are blocking the build. Enable Uniform Bucket-Level Access on the bucket.
Explanation

Option A is correct. Cloud Build runs under a service account (by default the Cloud Build service account, `<project-number>@cloudbuild.gserviceaccount.com`). When it attempts to read an object from a bucket in a different project, that service account must be granted the Storage Object Viewer (or equivalent) role on that cross-project bucket. A 403 error is the direct symptom of missing IAM permissions. Option B is wrong because Cloud Build steps can absolutely read from Cloud Storage using `gsutil` or the GCS provider; this is a common and supported pattern. Option C is wrong because the error is a 403 (permission denied), not a configuration mismatch; additionally, the backend and variable file are separate concerns. Option D is wrong because Uniform Bucket-Level Access being enabled or disabled does not by itself cause a 403; the root issue is that the service account identity has no IAM binding on the bucket, regardless of ACL mode.

33 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free