Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 1061Question →

A Cloud Architect is establishing permission governance for a renewable energy management platform in Google Cloud. Arrange the levels of the Google Cloud resource hierarchy in order from the highest ancestor node at the top down to the individual resource level at the bottom to illustrate how inherited IAM permissions propagate downward.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct hierarchy order from top to bottom is Organization Node, followed by Folder Node, Project Node, and finally Resource Node.
Google Cloud IAM enforces policy inheritance down a strict four-level hierarchy: Organization -> Folder -> Project -> Resource. Permissions granted at higher levels automatically propagate down to all contained child nodes.

Step-by-Step Solution

1
Identify the root ancestor in Google Cloud IAM resource management.
The Organization node is identified as the root element (level 1).
In Google Cloud, the Organization node represents the company domain and sits at the top of the resource hierarchy.
2
Identify the intermediate grouping layer designed for organizational unit management.
The Folder node is identified as the level directly beneath the Organization (level 2).
Folders allow organizing projects into sub-trees for environment separation (e.g., Prod, Dev) and policy inheritance.
3
Identify the core administrative boundary where APIs and billing are enabled.
The Project node is placed below Folders (level 3).
Projects are child elements of Folders or Organizations and hold service resource instances.
4
Identify the actual GCP service instance level where data and compute reside.
The Resource node is identified as the lowest leaf node (level 4).
Individual services (e.g., GCS bucket, Compute Engine instance) are created inside projects and inherit IAM policies from all parent nodes.

Key Concept

Google Cloud Resource Hierarchy and IAM Policy Inheritance
Question 1062Question →

An SRE team at a global logistics firm is redesigning their incident response and alerting strategy for an inventory routing service running on Google Kubernetes Engine (GKE) behind an External HTTP(S) Load Balancer. During a recent database slowdown, the load balancer health checks repeatedly failed because they executed complex SQL queries, causing the load balancer to mark all healthy application pods as offline and creating a cascading outage. Furthermore, static CPU alerts generated hundreds of false-positive notifications during benign batch jobs. Which architectural modification should the team implement to prevent cascading failures while ensuring alerting reflects true user impact?

Show answer & explanation

Answer: Configure lightweight health check endpoints that verify application process responsiveness without querying downstream databases, and transition from static metric threshold alerts to multi-window SLO burn-rate alerting policies.

Answer

Configure lightweight health check endpoints that verify application process responsiveness without querying downstream databases, and transition from static metric threshold alerts to multi-window SLO burn-rate alerting policies.
The solution requires decoupling backend instance readiness from downstream database health by serving shallow health check probes. This keeps healthy compute instances active in the load balancer pool even when the database is struggling. Furthermore, adopting multi-window SLO burn-rate alerts ensures that notifications are generated only when the rate of error budget consumption poses a genuine risk to service reliability, suppressing noise from routine CPU utilization spikes.

Step-by-Step Solution

1
Analyze load balancer health check probe behavior
Identified that deep health check probes querying downstream databases cause load balancers to take healthy application instances offline when database latency rises.
Health checks must assess the health of the specific instance serving traffic, not the availability of shared downstream dependencies.
2
Redesign health check endpoint logic
Replace deep database checks with lightweight 'shallow' health check endpoints that verify local container process readiness.
Shallow checks prevent cascading outages by isolating backend container health from database performance spikes.
3
Upgrade alerting strategy to align with Site Reliability Engineering best practices
Replace static CPU metric threshold alerts with SLO multi-window burn-rate alerting policies in Cloud Monitoring.
SLO burn-rate alerts reduce false positives from routine CPU spikes and trigger incident notifications only when error budgets are being consumed at a rate threatening the SLA.

Key Concept

Shallow Load Balancer Health Checks and Multi-Window SLO Burn-Rate Alerting
Question 1063Question →

A biomedical research company hosts containerized analytics workloads on Google Kubernetes Engine (GKE) and stores container images in Artifact Registry. The security team requires a solution that automatically blocks unverified container images containing known high-severity vulnerabilities from being deployed into production GKE clusters, while continuously detecting unauthorized process executions or kernel anomalies at runtime. Which architectural strategy should you recommend?

Show answer & explanation

Answer: Configure Artifact Registry vulnerability scanning alongside Binary Authorization policies to enforce image attestations before deployment, and enable Security Command Center Container Threat Detection for runtime kernel monitoring.

Answer

Configure Artifact Registry vulnerability scanning alongside Binary Authorization policies to enforce image attestations before deployment, and enable Security Command Center Container Threat Detection for runtime kernel monitoring.
Combining Artifact Registry vulnerability scanning with Binary Authorization ensures that container images are scanned and verified via attestations before deployment to GKE. Enabling Security Command Center Container Threat Detection provides out-of-band monitoring of low-level kernel activities to identify runtime container threats without performance overhead.

Step-by-Step Solution

1
Identify pre-deployment container security requirements
Combine Artifact Registry vulnerability scanning (to detect image CVEs) with Binary Authorization attestations to ensure unverified images cannot be deployed to GKE.
Binary Authorization acts as an admission controller on GKE clusters to block non-attested images.
2
Identify runtime container threat detection requirements
Enable Security Command Center Premium Container Threat Detection.
Container Threat Detection continuously monitors container runtime behavior and eBPF kernel traces to identify unauthorized process executions and security violations.

Key Concept

Multi-layered container security using Binary Authorization for deployment control and Security Command Center Container Threat Detection for runtime protection.
Question 1064Question →

A financial services organization processes transactions using microservices on Google Cloud. To control operational expenses, the lead architect must reduce Cloud Logging storage ingestion costs. However, compliance mandates require retaining all security audit records and application error logs for seven years in BigQuery. Which architectural approach should you implement to satisfy both cost optimization and compliance log retention requirements?

Show answer & explanation

Answer: Create a Log Router sink that exports audit logs and logs with severity ERROR or higher to BigQuery, while setting an exclusion filter on the default log bucket for logs with severity below ERROR.

Answer

Create a Log Router sink that exports audit logs and logs with severity ERROR or higher to BigQuery, while setting an exclusion filter on the default log bucket for logs with severity below ERROR.
The correct approach uses Cloud Logging Log Router sinks to selectively export required audit and error logs to BigQuery for long-term compliance storage, while configuring exclusion filters on the default bucket to prevent low-severity routine logs from accumulating ingestion costs.

Step-by-Step Solution

1
Analyze compliance and retention requirements
Identified that audit logs and high-severity error logs must be preserved long-term in BigQuery.
Regulatory compliance mandates seven-year data retention for critical operational and audit events.
2
Analyze cost optimization requirements
Identified that lower-severity logs (such as DEBUG and INFO) generate high volume and should be excluded from storage ingestion.
Excluding routine low-severity logs prevents unnecessary Cloud Logging storage charges.
3
Configure Cloud Logging Log Router and exclusion filters
Established a targeted sink for BigQuery export and added selective exclusion filters on the log bucket.
Log Router sinks allow precise routing of filtered logs to external destinations like BigQuery, while bucket exclusion filters stop unwanted logs from incurring ingestion fees.

Key Concept

Monitoring, Logging, and Observability Integration
Question 1065Question →

What is the correct sequential order of steps in Google Cloud for managing an automated alerting lifecycle and incident response, starting from metric detection to post-incident review?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with Cloud Monitoring detecting a metric threshold breach and opening an incident, followed by sending notification payloads via Pub/Sub, running automated diagnostic triage scripts, notifying on-call personnel for remediation, and concluding with incident closure and post-incident threshold refinement.
The standard incident management workflow begins with automated metric breach detection in Cloud Monitoring. Next, the alert engine dispatches messages via Pub/Sub notification channels. Automated handlers (such as Cloud Run) extract diagnostic logs to triage the event. On-call engineers use this context to resolve the issue, and finally, the incident is closed and followed by a blameless post-mortem review.

Step-by-Step Solution

1
Identify the detection phase.
Cloud Monitoring evaluates metrics and opens an incident upon threshold violation.
Alerting systems require a condition breach to initiate an incident payload.
2
Identify the notification dispatch phase.
Cloud Monitoring publishes the incident details to a Pub/Sub notification channel.
Notification channels route alerts from Monitoring to downstream integrations.
3
Identify the automated remediation/triage phase.
Cloud Run consumes the Pub/Sub alert event to query Cloud Logging for diagnostics.
Automated event handlers enhance incident context before human intervention.
4
Identify the human incident response phase.
On-call engineers receive alerts, acknowledge the issue, and execute mitigation.
Engineers resolve complex root causes once automated enrichment provides context.
5
Identify the post-incident learning phase.
The team closes the incident and conducts a post-mortem to update alert policies.
Continuous operational improvement relies on post-incident threshold review.

Key Concept

Incident Management Lifecycle and Automated Alerting
Question 1066Question →

A healthcare software provider is deploying a patient record processing application on Compute Engine. The security compliance team mandates that raw 256-bit encryption keys must be generated and maintained entirely within the company's controlled on-premises environment and supplied in each API request, ensuring Google Cloud never persists or manages the key material in Cloud KMS. Additionally, security governance requires adhering to least privilege without granting excessive administrative permissions across cloud resources. Which encryption strategy and access management approach aligns with these requirements?

Show answer & explanation

Answer: Use Customer-Supplied Encryption Keys (CSEK) by providing the raw AES-256 key in API requests for disk encryption, and grant fine-grained predefined IAM roles to compute service accounts.

Answer

Use Customer-Supplied Encryption Keys (CSEK) by providing the raw AES-256 key in API requests for disk encryption, and grant fine-grained predefined IAM roles to compute service accounts.
Customer-Supplied Encryption Keys (CSEK) are designed specifically for scenarios where raw AES-256 keys must be generated and managed outside of Google Cloud and supplied with each API request. Google does not store key material on disk or in Cloud KMS with CSEK. Additionally, pairing CSEK with fine-grained predefined IAM roles enforces least privilege and avoids granting excessive administrative authority.

Step-by-Step Solution

1
Analyze key custody and operational requirements
Identified requirement for raw 256-bit keys supplied in each API call without storing keys in Cloud KMS.
This operational requirement maps specifically to Customer-Supplied Encryption Keys (CSEK), distinct from Customer-Managed Encryption Keys (CMEK).
2
Evaluate IAM access control governance
Determined that predefined or custom fine-grained roles must be used instead of primitive roles.
Primitive roles (Owner, Editor, Viewer) grant excessively broad permissions, violating mandatory security governance policies.
3
Select the compliant solution
Combined CSEK implementation with fine-grained predefined IAM roles.
This combination satisfies both key custody constraints and access management policies.

Key Concept

Customer-Supplied Encryption Keys (CSEK) vs CMEK key custody model
Estimated Time:1m 30s
Question 1067Question →

A enterprise team is configuring an automated CI/CD pipeline on Google Cloud using Cloud Build and Cloud Deploy to automatically build container images and deliver service updates to Cloud Run. To satisfy corporate compliance mandates, the Cloud Build execution service account must be configured according to the principle of least privilege so that it can create releases in Cloud Deploy and act on behalf of the deployment service account without gaining unnecessary administrative rights. Which IAM permission configuration meets these security and pipeline requirements?

Show answer & explanation

Answer: Grant the Cloud Build service account the Cloud Deploy Releaser role (roles/clouddeploy.releaser) at the project level, and grant it the Service Account User role (roles/iam.serviceAccountUser) specifically on the dedicated Cloud Deploy execution service account.

Answer

Grant the Cloud Build service account the Cloud Deploy Releaser role (roles/clouddeploy.releaser) at the project level, and grant it the Service Account User role (roles/iam.serviceAccountUser) specifically on the dedicated Cloud Deploy execution service account.
The correct solution enforces the principle of least privilege. Granting the predefined Cloud Deploy Releaser role allows Cloud Build to create pipeline releases. Scoping the Service Account User role specifically to the target execution service account ensures that Cloud Build can pass that identity to Cloud Deploy without gaining access to other service accounts or administrative control.

Step-by-Step Solution

1
Identify the minimum predefined role required for Cloud Build to create releases in Cloud Deploy.
The Cloud Deploy Releaser role (roles/clouddeploy.releaser) provides necessary permissions to create and manage releases without full administrative privileges.
Following least privilege requires selecting predefined functional roles rather than primitive or administrative roles.
2
Determine the required IAM permission for Cloud Build to trigger execution under the deployment service account identity.
The Service Account User role (roles/iam.serviceAccountUser) must be granted to the Cloud Build service account on the specific Cloud Deploy execution service account.
This allows Cloud Build to impersonate or delegate execution to the designated service account without granting Service Account Admin or project-wide permissions.

Key Concept

Least Privilege IAM Role Binding in Cloud Build and Cloud Deploy Pipelines
Question 1068Question →

Your organization operates a real-time transaction processing API on Google Cloud. To maintain strict reliability standards, you are implementing an automated incident management and escalation workflow using Google Cloud Observability tools. Order the operational steps sequentially from initial anomaly detection to full incident resolution and notification.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with Cloud Monitoring detecting an SLO error budget burn rate breach, followed by publishing an alert event to a Pub/Sub topic notification channel, triggering an automated Cloud Run remediation service to restore performance capacity, and concluding with Cloud Monitoring verifying metric recovery and resolving the incident.
In GCP Site Reliability Engineering practices, incident management starts with metric-driven anomaly detection (SLO burn rate evaluation). Upon detecting a breach, Cloud Monitoring uses Pub/Sub notification channels to asynchronously trigger automated remediation code (such as Cloud Run or Cloud Functions). Once the automated action restores service metrics, Cloud Monitoring validates recovery and marks the incident resolved.

Step-by-Step Solution

1
Detect metric anomaly using SLO burn rate alerting policy
An alert incident is created in Cloud Monitoring when latency SLIs breach the error budget threshold.
Incident response workflows begin with automated threshold detection based on SLIs/SLOs.
2
Dispatch incident payload to automated notification channel
A structured incident message is delivered to a GCP Pub/Sub topic.
Pub/Sub serves as an asynchronous event bus decoupler for downstream automated remediation.
3
Trigger event-driven remediation service
Cloud Run consumes the Pub/Sub message and executes mitigation steps to scale up compute infrastructure.
Automated response minimizes Mean Time to Resolution (MTTR) before human escalation.
4
Verify metric stabilization and auto-close incident
Cloud Monitoring registers normal SLI levels, closes the open incident, and logs final resolution.
Alert policies automatically mark incidents resolved once conditions return below threshold levels for the re-evaluation duration.

Key Concept

Event-driven automated incident management and escalation pipelines using Cloud Monitoring, Pub/Sub, and Cloud Run.
Question 1069Question →

A multinational financial services enterprise runs a multi-project architecture on Google Cloud with strict regulatory audit requirements. The operations team needs to centralize high-severity application errors and Cloud Audit Logs into a dedicated security operations project while optimizing ingestion costs for high-volume debug logs. However, recent incident reviews revealed that essential audit events were omitted because of misconfigured log ingestion rules, and overly permissive access was granted during deployment. Which TWO architecture and log routing strategies should a Cloud Architect implement to guarantee audit log retention, optimize costs, and enforce least-privilege administrative security?

Select all that apply

Show answer & explanation

Answer: Configure an organization-level aggregated Log Router sink with an explicit inclusion filter for audit logs and high-severity errors, directing stream outputs to BigQuery and Cloud Storage while excluding debug logs using fine-grained exclusion filters that explicitly bypass `_Required` audit logs.; Assign the least-privilege `roles/logging.configWriter` role at the organization level for sink management, and grant the sink service account `roles/bigquery.dataEditor` on the destination datasets.

Answer

The correct architecture requires creating an organization-level aggregated Log Router sink with precise inclusion filters that protect audit logs from exclusion, while granting least-privilege IAM roles (`roles/logging.configWriter` and destination-specific writer permissions) to administer logging infrastructure.
The correct strategy combines an organization-level aggregated Log Router sink with targeted filters to retain critical security audit logs while dropping non-essential debug logs, along with fine-grained IAM role assignment (`roles/logging.configWriter` and `roles/bigquery.dataEditor`) to enforce least-privilege security principles.

Step-by-Step Solution

1
Evaluate central log routing requirements across multi-project environments.
Identified that an organization-level aggregated sink is required to capture security and application logs systematically.
Organization-level sinks automatically collect logs from all current and future projects in the hierarchy.
2
Design log inclusion and exclusion filter parameters.
Configured exclusion filters to drop low-severity debug logs while explicitly safeguarding `_Required` audit and high-severity logs.
Overbroad exclusion filters can accidentally drop critical audit logs needed for compliance and security investigations.
3
Enforce least-privilege IAM configurations for sink administration and ingestion.
Assigned `roles/logging.configWriter` for sink creation and specific data writer roles for the destination sink service account.
Primitive roles like Owner introduce severe security risks and exceed functional requirements.

Key Concept

Monitoring, Logging, and Observability Integration
Question 1070Question →

A financial technology company structures its Google Cloud resources using separate environment folders (`Production` and `Staging`) under an Organization node. A third-party security auditing team requires read-only permissions to inspect security configurations, IAM policies, and asset inventories for all current and future resources inside the `Production` folder. The auditors must not be allowed to modify resource configurations, access application data payloads, or manage service account keys. Which IAM role binding strategy adheres to Google-recommended best practices for least privilege and resource hierarchy management?

Show answer & explanation

Answer: Assign the predefined Security Reviewer role (`roles/iam.securityReviewer`) at the `Production` folder level.

Answer

Assign the predefined Security Reviewer role (`roles/iam.securityReviewer`) at the `Production` folder level.
Assigning the predefined Security Reviewer role (`roles/iam.securityReviewer`) at the folder level grants read-only access to security policies and resource configurations for all current and future projects in that folder through inheritance. This enforces least privilege without operational overhead or granting access to underlying application data.

Step-by-Step Solution

1
Identify the required permissions and resource scope
The requirement specifies read-only access to inspect security configurations across all resources within the `Production` environment folder.
Security auditors need centralized inspection capabilities without access to underlying application data or administrative modification rights.
2
Leverage GCP resource hierarchy inheritance
Binding the IAM role at the `Production` folder level automatically propagates permissions downstream to all child projects and resources.
Inheritance reduces operational overhead by eliminating the need to manage individual IAM bindings on a per-project basis.
3
Select the appropriate predefined IAM role following least privilege
`roles/iam.securityReviewer` grants read-only access to security configurations and IAM policies without exposing underlying data payloads or granting primitive broad access.
Predefined roles offer fine-grained access matching job functions, whereas primitive roles grant excessive read permissions across all services.

Key Concept

Resource Hierarchy IAM Role Inheritance and Least Privilege
Question 1071Question →

Your organization is establishing an automated incident management workflow in Google Cloud to rapidly mitigate unexpected latency spikes in a critical microservice. Place the following operational and technical steps in the correct chronological order from initial detection setup to post-incident validation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Configure a Cloud Monitoring alerting policy based on microservice latency threshold conditions, 2) Attach a Google Cloud Pub/Sub topic notification channel to the configured alerting policy, 3) Execute automated remediation via an event-driven Cloud Run function triggered by incoming Pub/Sub alert messages, and 4) Verify incident resolution and post-remediation service health using Cloud Monitoring dashboards.
The workflow follows a standard event-driven incident lifecycle in GCP: first establishing detection thresholds in Cloud Monitoring, next integrating an asynchronous Pub/Sub notification channel, then triggering automated serverless remediation upon incident creation, and finally confirming metric normalization on operational dashboards.

Step-by-Step Solution

1
Define threshold detection rules
Cloud Monitoring policy actively monitors latency telemetry for condition breaches.
Automated incident management requires explicit SLI/SLO threshold boundaries to trigger alerts.
2
Bind Pub/Sub notification channel to the policy
Alert state transitions publish structured incident payloads to the designated Pub/Sub topic.
Pub/Sub provides an asynchronous, decoupled broker for event-driven automation in GCP.
3
Trigger programmatic remediation
Cloud Run function ingests the alert event and scales backend resources or adjusts traffic routing.
Automated mitigation logic must execute in response to alert notifications to reduce mean time to resolution (MTTR).
4
Validate service recovery
Cloud Monitoring metrics confirm latency has subsided and error budgets are preserved.
Post-incident verification confirms the automated action successfully resolved the incident without manual intervention.

Key Concept

Automated Incident Escalation and Event-Driven Remediation
Question 1072Question →

An enterprise organization is updating its observability architecture for workloads running on Compute Engine instances. The team requires centralized collection of application and system telemetry for real-time operational monitoring, as well as long-term retention of critical security and error logs in BigQuery for security analytics. Operational costs must be optimized without accidentally discarding high-severity audit and application error logs. Which TWO actions should the Cloud Architect recommend to satisfy these requirements? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Install and configure the Google Cloud Ops Agent on all Compute Engine virtual machines to collect unified system logs and metrics for Cloud Logging and Cloud Monitoring.; Configure an aggregated Log Router sink with an inclusion filter targeting severity levels of ERROR or higher to stream critical log entries to BigQuery.

Answer

The Cloud Architect should install the Google Cloud Ops Agent on all Compute Engine VMs to collect telemetry and create an aggregated Log Router sink with an inclusion filter targeting severity levels of ERROR or higher to stream critical log entries to BigQuery.
Deploying the Google Cloud Ops Agent ensures comprehensive collection of system logs and performance metrics from Compute Engine instances into Cloud Logging and Monitoring. Creating a Log Router sink with explicit inclusion filters targeting ERROR or higher severity levels ensures that high-value logs are securely exported to BigQuery for security analytics without incurring storage costs for routine low-severity logs.

Step-by-Step Solution

1
Identify telemetry collection requirements for Compute Engine VMs.
Determine that Google Cloud Ops Agent is the standard GCP solution for capturing both system metrics and application logs.
Ops Agent combines logging and monitoring into a single agent optimized for Compute Engine workloads.
2
Determine the proper log routing strategy for security analytics in BigQuery.
Configure a Log Router sink with explicit inclusion filters (`severity >= ERROR`) targeting BigQuery.
Inclusion filters route essential logs while avoiding ingestion cost overheads associated with low-severity logs.

Key Concept

Monitoring, Logging, and Observability Integration
Question 1073Question →

A telecommunications enterprise is migrating its core IoT telemetry platform to Google Cloud. The executive steering committee demands zero unplanned downtime, while the engineering team voices strong concern regarding their lack of operational familiarity with Google Cloud services. To successfully manage this organizational change and meet technical requirements, which implementation strategy should the lead Cloud Architect recommend?

Show answer & explanation

Answer: Implement a phased migration plan using canary deployments alongside tailored training modules, and request regional resource quota adjustments in advance of migration milestones.

Answer

Implement a phased migration plan using canary deployments alongside tailored training modules, and request regional resource quota adjustments in advance of migration milestones.
Combining phased canary deployments with structured team training directly addresses stakeholder risk anxiety and team operational readiness, while proactive quota management ensures smooth infrastructure growth on Google Cloud.

Step-by-Step Solution

1
Assess stakeholder requirements and team readiness
Identified operational risk concerns and skill gaps among engineering personnel
Organizational change management requires addressing human factors alongside technical design
2
Formulate deployment and enablement strategy
Designed a phased rollout with canary deployments and team training programs
Gradual releases mitigate deployment risk while structured training builds operational competency
3
Align resource provisioning prerequisites
Proactively requested regional quota increases prior to cutover
Ensures technical infrastructure scaling is not blocked by cloud provider default quotas

Key Concept

Analyzing Business Stakeholder Requirements and Managing Organizational Change
Question 1074Question →

A multinational financial enterprise operates hundreds of microservices hosted across multiple Google Cloud projects. The compliance team mandates that all audit and operational logs must be archived for seven years in an immutable state to comply with regulatory standards. Simultaneously, the Security Operations (SecOps) team requires real-time log ingestion into an external Security Information and Event Management (SIEM) platform located in a central security project. During a recent production incident, on-call engineers discovered that crucial application error logs were missing, preventing root cause analysis. Investigation revealed that previous cost-cutting measures introduced aggressive log exclusion configurations. Which TWO architectural and configuration actions should the Cloud Architect recommend to satisfy security compliance, enable real-time SIEM integration, and resolve the missing incident log issue?

Select all that apply

Show answer & explanation

Answer: Configure an organization-level aggregated Log Router sink with an inclusion filter targeting a Pub/Sub topic in the central SecOps project for SIEM streaming, alongside a secondary sink targeting a Cloud Storage bucket configured with a locked Retention Policy for compliance storage.; Audit existing Cloud Logging exclusion filters across all projects to ensure high-severity ERROR and CRITICAL logs are explicitly exempted from exclusion rules, allowing essential diagnostic telemetry to be ingested.

Answer

The recommended solution is to configure an organization-level aggregated Log Router sink targeting Pub/Sub for real-time SIEM integration and Cloud Storage with a locked Retention Policy for compliance, while auditing existing log exclusion filters to explicitly preserve ERROR and CRITICAL severity logs.
Combining an organization-level aggregated Log Router sink (targeting Pub/Sub for real-time SIEM streaming and Cloud Storage with Bucket Lock for compliance) with an audit of log exclusion filters satisfies all architectural requirements. Pub/Sub enables decoupled real-time ingestion into SIEM tools, Bucket Lock ensures WORM compliance for seven years, and exempting high-severity logs from exclusion rules ensures critical telemetry is preserved during incidents.

Step-by-Step Solution

1
Analyze Centralized Log Aggregation Requirements
Identify that an organization-level aggregated sink is required to collect logs across all sub-projects without individual project setup.
Organization sinks capture logs comprehensively across the entire GCP resource hierarchy.
2
Determine Ingestion Destinations for Real-Time SIEM and Long-Term Archival
Select Pub/Sub for streaming to external SIEM systems and Cloud Storage with Bucket Lock for 7-year immutable compliance storage.
Pub/Sub provides high-throughput event streaming, whereas Cloud Storage Bucket Lock enforces compliant WORM storage.
3
Address Missing Application Error Logs
Audit and modify existing exclusion filters to ensure ERROR and CRITICAL logs are not discarded during ingestion.
Exclusion filters drop logs prior to ingestion; removing or exempting high-severity logs restores visibility during active incidents.

Key Concept

Monitoring, Logging, and Observability Integration
Question 1075Question →

A global logistics enterprise runs a real-time inventory tracking platform on Google Cloud. Telemetry data from IoT sensors is ingested via Cloud Pub/Sub and processed by memory-intensive worker applications running on Compute Engine Managed Instance Groups (MIGs). During simulation testing for an upcoming peak event, Pub/Sub message queues backed up rapidly because the MIG autoscaler failed to add instances quickly enough under heavy memory pressure when configured with default CPU utilization metrics. Furthermore, instance creation attempts stalled mid-scaling due to reaching regional vCPU limits. Which TWO actions should you take to optimize workload scaling and capacity planning for this platform? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the Managed Instance Group autoscaling policy using custom Cloud Monitoring metrics tracking Pub/Sub unacknowledged message age and worker memory utilization.; Audit existing resource quotas in the target region and submit requests for vCPU quota increases well in advance of the anticipated peak load.

Answer

The platform requires configuring custom Cloud Monitoring metrics (such as Pub/Sub unacknowledged message age and memory utilization) for MIG autoscaling, along with proactively requesting regional vCPU quota increases prior to peak workload events.
To optimize workload scaling for memory-intensive streaming workers processing Pub/Sub queues, autoscaling must be driven by custom metrics reflecting queue backlog (unacknowledged message age) and worker memory consumption. Additionally, capacity planning demands auditing regional GCP quotas and requesting vCPU quota increases ahead of time to avoid provisioning failures during peak demand spikes.

Step-by-Step Solution

1
Analyze the autoscaling bottleneck for the memory-intensive and queue-bound workload.
Default CPU utilization metrics fail to trigger autoscaling when workers are bound by memory saturation or growing Pub/Sub message queues.
Autoscaling policies must align with the actual resource bottleneck (queue depth and memory) using custom metrics.
2
Identify capacity limit constraints during burst scaling events.
Provisioning attempts failed due to reaching regional Compute Engine quotas during peak traffic spikes.
Capacity planning requires reviewing regional quotas and requesting quota increases in advance of anticipated scale-out events.

Key Concept

Workload Autoscaling Optimization and Regional Capacity Planning
Question 1076Question →

Your team is setting up automated alerting in Google Cloud Monitoring for a critical application. You want to ensure that incident notifications fire reliably when an operational issue consumes your error budget too quickly, while avoiding alert fatigue caused by brief, transient metric spikes. Which alerting policy approach should you implement?

Show answer & explanation

Answer: Configure an SLO-based alerting policy using multi-window error budget burn rate conditions.

Answer

Configure an SLO-based alerting policy using multi-window error budget burn rate conditions.
Configuring an SLO-based alerting policy using multi-window burn rate conditions measures the speed at which the error budget is being depleted. This ensures that incident alerts fire quickly when a true outage occurs while suppressing alerts during brief, insignificant metric fluctuations.

Step-by-Step Solution

1
Identify the primary alerting requirement.
The requirement is to alert reliably on service-impacting incidents while filtering out noise from brief, self-resolving spikes.
Traditional static metric thresholds trigger frequent false alarms during transient spikes.
2
Evaluate Google Cloud SRE alerting best practices.
Monitoring the error budget burn rate over multiple time windows (short lookback and long lookback) aligns alerts directly with actual customer impact.
Burn-rate alerting calculates how rapidly the application is consuming its allowable error budget.
3
Select the appropriate Cloud Monitoring alerting condition.
Configure an SLO burn rate alert policy in Cloud Monitoring.
This strategy ensures high precision and recall for automated incident response.

Key Concept

Error budget burn rate alerting in Google Cloud Monitoring
Estimated Time:1m 0s
Question 1077Question →

A biotechnology enterprise processes genomic sequencing data on Google Cloud across multiple research projects under a central Cloud Billing account. Raw sequencing files are ingested into Cloud Storage, and transformed analytical datasets are loaded into BigQuery for ad-hoc querying by data science teams. Recent audits show unpredictable BigQuery billing spikes caused by unconstrained, variable query workloads across teams. The organization requires a FinOps cost governance solution that establishes predictable budget boundaries without committing to rigid, unused baseline compute capacity. Which approach should the Cloud Architect recommend?

Show answer & explanation

Answer: Configure BigQuery Reservations using flexible autoscaling slot caps with Enterprise edition and assign reservations to project folders to control maximum expenditure while accommodating workload variance.

Answer

Configure BigQuery Reservations using flexible autoscaling slot caps with Enterprise edition and assign reservations to project folders to control maximum expenditure while accommodating workload variance.
Configuring BigQuery Reservations with autoscaling slots and setting slot caps at the project folder level allows teams to handle fluctuating analytical query demands while enforcing hard budget guardrails to eliminate unexpected billing spikes.

Step-by-Step Solution

1
Analyze workload characteristics and governance objectives.
Identified ad-hoc, variable analytical query patterns requiring cost caps without long-term rigid commitments.
Variable workloads require dynamic scaling with upper spending limits to prevent budget overruns.
2
Evaluate BigQuery capacity management features.
Determined that BigQuery Reservations with autoscaling slot caps enforce organizational budget limits while dynamically accommodating spikes.
Slot caps establish a maximum expenditure ceiling per project folder without requiring static, over-provisioned commitments.

Key Concept

BigQuery Capacity Governance and Slot Reservations
Estimated Time:1m 30s
Question 1078Question →

A global retail organization runs an online checkout service hosted on Google Cloud. During peak promotional events, downstream service dependencies occasionally experience transient latency spikes that consume the service level objective (SLO) error budget. The SRE team needs to implement an incident management and automated alerting strategy that minimizes alert fatigue by notifying on-call engineers only when the error budget is burning at a rate that risks an SLO breach, while simultaneously initiating automated remediation to reroute non-critical traffic via a Cloud Run service. Which approach should the cloud architect recommend?

Show answer & explanation

Answer: Configure Cloud Monitoring alerting policies using multi-window, multi-burn-rate conditions on the latency Service Level Indicator (SLI), sending notifications to an incident channel and publishing alert state changes to a Pub/Sub topic that triggers the Cloud Run remediation service.

Answer

Configure Cloud Monitoring alerting policies using multi-window, multi-burn-rate conditions on the latency Service Level Indicator (SLI), sending notifications to an incident channel and publishing alert state changes to a Pub/Sub topic that triggers the Cloud Run remediation service.
The solution using multi-window multi-burn-rate alert policies aligns with Google Cloud SRE best practices. It measures how rapidly the SLO error budget is being consumed over both short (e.g., 5 minutes) and long (e.g., 1 hour) lookback windows. This prevents alert fatigue from brief non-critical latency bursts while ensuring timely notification for true incidents. Routing notifications through Pub/Sub provides a reliable event-driven mechanism to trigger Cloud Run for automated incident mitigation.

Step-by-Step Solution

1
Analyze alerting criteria requirements
Identify that avoiding alert fatigue while guarding SLO budgets requires burn-rate alerting rather than static threshold monitoring.
Burn-rate alerting measures consumption rate of the error budget over multiple time windows (short and long), filtering out brief transient spikes while catching sustained degradations.
2
Design automated notification and remediation pipeline
Select Pub/Sub as the messaging notification channel from Cloud Monitoring alerting policy to decouple alert triggers from execution.
Cloud Monitoring alerting policies can natively publish incidents to Cloud Pub/Sub, which asynchronously invokes Cloud Run microservices for automated traffic rerouting.
3
Evaluate downstream health check design
Ensure health checks test local instance health rather than deep downstream dependencies.
Testing deep dependencies in health checks causes backend pools to drain unnecessarily during downstream dependency issues, worsening outages.

Key Concept

Multi-Window Multi-Burn-Rate Alerting & Automated Incident Response Integration
Question 1079Question →

An enterprise fleet telemetry application ingests real-time device metrics into Google Cloud. To minimize storage costs, the team implemented Cloud Logging exclusion filters across the project. During a recent service disruption, automated alerts failed to fire because essential application exception logs were inadvertently dropped before Cloud Monitoring could evaluate log-based alert metrics. Which configuration adjustment to the logging and alerting architecture resolves this incident management gap while maintaining cost optimization?

Show answer & explanation

Answer: Adjust the Cloud Logging exclusion filters to explicitly preserve logs with severity level ERROR and above while filtering out lower-severity informational and debug entries.

Answer

Adjust the Cloud Logging exclusion filters to explicitly preserve logs with severity level ERROR and above while filtering out lower-severity informational and debug entries.
Refining exclusion filters to explicitly exempt logs with severity level ERROR or higher guarantees that critical failure telemetry reaches Cloud Logging and Cloud Monitoring for automated alerting, while still achieving cost optimization by excluding noise from informational logs.

Step-by-Step Solution

1
Analyze the root cause of the alerting failure
Aggressive exclusion filters dropped log entries prior to evaluation by Cloud Monitoring log-based metrics.
Log-based alerting policies depend on Cloud Logging capturing matching log entries.
2
Formulate a cost-effective log management policy
Filter out high-volume debug and info logs while safeguarding severity levels ERROR, CRITICAL, and EMERGENCY.
This guarantees reliable automated alert triggering during operational incidents without ballooning log ingestion costs.

Key Concept

Log Ingestion Exclusion Filters and Log-Based Alerting
Estimated Time:1m 30s
Question 1080Question →

A multinational e-commerce company is migrating its telemetry processing pipeline to Google Cloud. The architecture requires storing raw telemetry data in Cloud Storage and querying processed datasets in BigQuery. The security compliance team requires that all data at rest be encrypted using keys stored within Google Cloud where key usage is fully audited, while strictly adhering to the principle of least privilege for automated service access. Which configuration strategy should the Cloud Architect recommend?

Show answer & explanation

Answer: Configure Customer-Managed Encryption Keys (CMEK) in Cloud KMS, and grant the Cloud Storage and BigQuery service agents the Cloud KMS CryptoKey Encrypter/Decrypter role on the specific encryption key.

Answer

Configure Customer-Managed Encryption Keys (CMEK) in Cloud KMS, and grant the Cloud Storage and BigQuery service agents the Cloud KMS CryptoKey Encrypter/Decrypter role on the specific encryption key.
Configuring Customer-Managed Encryption Keys (CMEK) through Cloud KMS provides centralized key management, key rotation capabilities, and full logging of cryptographic operations in Cloud Audit Logs. Granting the predefined role `roles/cloudkms.cryptoKeyEncrypterDecrypter` to the Cloud Storage and BigQuery service agents grants only the specific permissions needed to perform encryption and decryption tasks, strictly observing the principle of least privilege.

Step-by-Step Solution

1
Identify the key management requirement
Cloud KMS with Customer-Managed Encryption Keys (CMEK) provides cloud-hosted key management with integrated Cloud Audit Logs.
CMEK allows the organization to control key lifecycle and rotation while leveraging Google Cloud services to manage key storage.
2
Determine least privilege IAM roles for Google Cloud service agents
The Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) should be granted specifically to the Cloud Storage and BigQuery service agents.
Service agents require permission to perform cryptographic operations (encrypt/decrypt) on data objects without gaining administrative control over the key hardware or policies.

Key Concept

Customer-Managed Encryption Keys (CMEK) and Least Privilege IAM for Cloud KMS Service Agents
PreviousPage 54 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin