Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 881Question →

A digital gaming studio is analyzing its continuous delivery pipeline on Google Cloud. The automated pipeline uses Cloud Build to execute Terraform manifests that provision compute clusters and database resources for new game instances. During an operational review, the team observes two major issues: concurrent pipeline runs occasionally overwrite each other's infrastructure changes causing state corruption, and the pipeline runs under an over-privileged security context. Which combination of architectural changes should the team implement to secure the pipeline and ensure infrastructure state integrity?

Show answer & explanation

Answer: Configure a dedicated custom service account for Cloud Build with least-privilege IAM roles, and configure Terraform to use a Cloud Storage remote backend with object versioning and state locking enabled.

Answer

The correct architecture requires configuring a custom service account for Cloud Build assigned minimal granular IAM roles needed for resource provisioning, alongside configuring Terraform to store state in a remote Cloud Storage backend with object versioning and state locking enabled.
Configuring a dedicated custom service account for Cloud Build bound to fine-grained predefined roles ensures least-privilege security control. Using a Cloud Storage remote backend with versioning and object locking prevents simultaneous pipeline executions from corrupting the Terraform state file.

Step-by-Step Solution

1
Analyze pipeline security requirements.
Identified that using primitive or over-privileged roles creates a security risk; replacing them with a dedicated custom service account adhering to least privilege isolates pipeline access.
Cloud Build should only possess the specific permissions necessary to create and manage targeted resources.
2
Analyze IaC state management requirements.
Identified that local build storage or unversioned state files cause state corruption during concurrent runs.
Cloud Storage remote backends support object locking (via backend state locking) to prevent race conditions and versioning to allow recovery.
3
Combine security and state management solutions.
Selected the option that pairs custom least-privilege service accounts with locked, versioned Cloud Storage backends.
This comprehensively addresses both identity security and infrastructure deployment reliability.

Key Concept

CI/CD Pipeline Security and Infrastructure as Code State Management Best Practices
Question 882Question →

An enterprise plan involves migrating a legacy batch-processing platform requiring 500 high-capacity Compute Engine Virtual Machines to a single target GCP region within a strict maintenance window. Prior to executing the migration script, which proactive capacity planning step must the cloud architect take to prevent deployment failure due to resource limits?

Show answer & explanation

Answer: Audit existing project quotas and submit a regional quota increase request for Compute Engine CPU cores and instances prior to deployment.

Answer

Audit existing project quotas and submit a regional quota increase request for Compute Engine CPU cores and instances prior to deployment.
The correct answer emphasizes requesting regional quota increases in advance. Google Cloud enforces project resource quotas to prevent unexpected consumption and protect infrastructure. When deploying large workloads (such as 500 Compute Engine instances), architects must verify quota availability and request increases early to prevent API provisioning failures.

Step-by-Step Solution

1
Calculate required compute resources
Determine the exact CPU, memory, and instance count needed in the target region (500 VMs).
Accurate resource totals are required to evaluate current quota headroom.
2
Review current regional quotas in Google Cloud Console
Identify any gap between default quota limits and required capacity.
GCP projects come with default quotas that restrict compute deployment size until explicitly raised.
3
Submit a quota increase request before deployment
Obtain approval and allocated quota capacity prior to launching automated migration scripts.
Quota increases require evaluation and processing time by GCP, preventing quota enforcement errors during execution.

Key Concept

Regional Quota Management and Infrastructure Provisioning Limits
Question 883Question →

A financial enterprise is designing a perimeter security architecture on Google Cloud for a payment processing platform deployed across multiple projects. The architectural requirements specify that workload instances must privately access Google APIs (such as Cloud Storage and BigQuery) without internet egress, while strictly preventing data exfiltration to external GCP organizations. Additionally, network administrators require centralized, non-bypassable firewall rules across all projects, and the design must adhere to GCP constraints prohibiting transitive routing across peered VPCs. Which TWO design choices should the Cloud Architect implement to satisfy these security and network requirements?

Select all that apply

Show answer & explanation

Answer: Configure a VPC Service Controls perimeter encompassing the payment processing projects and route access to Google APIs via Private Service Connect (PSC) endpoints.; Apply Hierarchical Firewall Policies at the Organization node and utilize Secure Tags to enforce consistent security rules across project VPCs.

Answer

The architect must configure a VPC Service Controls perimeter combined with Private Service Connect endpoints for API security and exfiltration prevention, and deploy Hierarchical Firewall Policies with Secure Tags to enforce centralized organization-wide network firewall rules.
Implementing VPC Service Controls with Private Service Connect ensures that Google API requests remain within a strictly defined security boundary, effectively mitigating data exfiltration risks. In addition, Hierarchical Firewall Policies paired with Secure Tags enable organization-wide network governance and mandate uniform security policy enforcement that cannot be altered at the project level.

Step-by-Step Solution

1
Evaluate data exfiltration prevention and API access requirements.
Identified that VPC Service Controls combined with Private Service Connect endpoints fulfills private access while blocking boundary cross-organization exfiltration.
IAM roles enforce access control but do not prevent authorized entities from transferring data outside perimeter boundaries.
2
Evaluate centralized rule enforcement and network governance.
Selected Hierarchical Firewall Policies attached at the organization level with Secure Tags.
Hierarchical policies cannot be overridden by project-level firewall rules and provide consistent security posture.
3
Analyze network topology constraints.
Rejected transitive hub-and-spoke VPC Peering design.
VPC Network Peering does not support transitive routing in Google Cloud.

Key Concept

Designing multi-project GCP perimeter security using VPC Service Controls, Private Service Connect, and Hierarchical Firewall Policies.
Question 884Question →

An enterprise digital publishing platform hosts its core services in us-central1 and maintains a secondary disaster recovery environment in us-east4 on Google Cloud. The infrastructure utilizes Compute Engine Managed Instance Groups (MIGs), Cloud SQL cross-region read replicas, and Cloud Storage. During an upcoming business continuity validation drill, the architecture team must test regional failover procedures while ensuring continuous replication remains undisturbed and preventing resource allocation failures. Which TWO validation procedures should the team include in their disaster recovery test plan? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Automate pre-drill verification to ensure compute, network, and storage quotas in us-east4 are sufficient to support the full production load prior to executing failover procedures.; Promote an isolated clone of the secondary Cloud SQL database replica to run validation queries and synthetic transaction tests without breaking the active cross-region replication stream.

Answer

The correct validation procedures are to verify regional resource quotas in the disaster recovery region prior to drill execution, and to test failover readiness using isolated database clones to preserve active replication streams.
Effective DR validation procedures must verify both infrastructure quota availability and data integrity without jeopardizing production operations. Pre-verifying regional resource quotas ensures that the DR target region can accommodate full production traffic during a failover event. Using a cloned database replica provides a isolated environment to execute validation tests without interrupting continuous cross-region replication or mutating production state.

Step-by-Step Solution

1
Audit pre-drill resource headroom and regional quotas in the secondary region.
Confirms that Compute Engine MIGs and network resources can scale to full operational load during failover.
GCP quota increases require advance request and approval; failure to check quotas before a drill leads to provisioning failures.
2
Create isolated database snapshot clones for synthetic drill testing.
Enables end-to-end failover validation while keeping the primary-to-secondary database replication stream intact.
Directly modifying or promoting active replicas disrupts ongoing replication and risks production data integrity.

Key Concept

Developing Procedures for Business Continuity and Disaster Recovery Validation
Question 885Question →

An enterprise cloud security architect is documenting how Google Cloud IAM calculates effective access permissions when a service account attempts to read an object stored in a Cloud Storage bucket. Arrange the steps of the IAM policy evaluation process in the correct chronological order from initial API request submission to the final access determination.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence evaluates IAM permissions top-down along the resource hierarchy: Request initiation -> Organization root evaluation -> Folder hierarchy evaluation -> Project level evaluation -> Resource policy evaluation and final union calculation.
Google Cloud IAM evaluates permissions top-down starting from the API request receipt, proceeding from the Organization root down through Folders, Project, and finally Resource-level policies. Effective access is determined by combining all permissions granted along the hierarchy path.

Step-by-Step Solution

1
Submit API Request
The API call containing identity context and desired permission is received by Google Cloud services.
Evaluation begins only after an authenticated call specifies a target operation.
2
Evaluate Organization Root Policies
Permissions granted at the top-level Organization node are gathered.
GCP IAM permission inheritance starts at the top ancestor of the resource tree.
3
Evaluate Folder Nodes
Permissions granted across parent folders and sub-folders are gathered.
Permissions inherit down through intermediate folder nodes in the resource hierarchy.
4
Evaluate Project Node
Permissions granted at the Project level are gathered.
Project-level policy bindings apply to all resources residing within that project.
5
Evaluate Resource Policies & Determine Access
Effective permissions across all levels are combined to make an allow or deny authorization decision.
IAM permissions are additive down the hierarchy, with explicit deny policies taking precedence.

Key Concept

GCP IAM Resource Hierarchy Evaluation and Permission Inheritance
Question 886Question →

A retail enterprise is provisioning a regional relational database infrastructure on Google Cloud using Terraform. Multiple cloud engineers will execute concurrent deployments, and compliance guidelines require protecting the infrastructure configuration state against state corruption, concurrent executions, and accidental state destruction. Which strategy should be implemented to securely provision and manage the infrastructure state?

Show answer & explanation

Answer: Configure a remote Terraform backend utilizing a Google Cloud Storage bucket with Object Versioning enabled and native backend locking.

Answer

Configure a remote Terraform backend utilizing a Google Cloud Storage bucket with Object Versioning enabled and native backend locking.
Configuring a remote Cloud Storage backend with Object Versioning enabled ensures centralized state management, automated lock acquisition to prevent concurrent state overwrites, and state recovery capabilities.

Step-by-Step Solution

1
Identify the state management requirements for Infrastructure as Code provisioning.
Requirements include support for team collaboration, prevention of concurrent state operations, and resilience against state corruption.
Enterprise IaC deployments require remote centralized state backends to prevent race conditions.
2
Evaluate Google Cloud Storage capabilities for Terraform backends.
Cloud Storage supports native lock acquisition and Object Versioning.
Object Versioning enables rollback to historical state versions if accidental state corruption occurs, while native locking prevents concurrent modifications.

Key Concept

Terraform Remote Backend & State Provisioning Security
Question 887Question →

An enterprise security architecture team needs to establish automated rotation for a database password stored in Google Cloud Secret Manager. The workflow must use Cloud Pub/Sub and a Cloud Function to automatically generate, test, and store new password versions every 90 days according to least privilege principles. In what order should the administrative steps be performed to configure this automated rotation pipeline?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The sequence of administrative steps must be: First, grant the Secret Manager Service Agent the Pub/Sub Publisher role on the notification topic. Second, deploy the rotator Cloud Function with a dedicated user-managed service account. Third, grant the rotator service account Secret Manager Secret Version Adder and Secret Accessor roles on the secret. Fourth, configure the rotation schedule and Pub/Sub topic on the target Secret Manager secret.
Configuring automated rotation in Secret Manager requires enabling infrastructure permissions prior to activating schedules. First, the Google-managed Secret Manager service agent requires `roles/pubsub.publisher` on the target Pub/Sub topic so rotation events can be emitted. Second, the rotation worker code (Cloud Function) and its dedicated service account must be deployed. Third, that dedicated service account must be granted least privilege permissions (`roles/secretmanager.secretVersionAdder` and `roles/secretmanager.secretAccessor`) on the secret resource. Finally, attaching the rotation schedule and Pub/Sub topic to the secret starts the timer and completes the pipeline.

Step-by-Step Solution

1
Authorize Secret Manager Service Agent for Pub/Sub notification publishing
Secret Manager has permission to emit rotation topics.
Secret Manager uses a Google-managed service agent to send event notifications when rotation periods elapse.
2
Deploy the rotation Cloud Function with a custom service account identity
Rotator endpoint and identity are provisioned.
The function logic handles generating new database credentials and executing rotation tests.
3
Assign least privilege IAM roles to the rotator service account
Rotator function identity can add new secret versions without administrative privileges.
Applying specific Secret Manager roles ensures the function can fetch existing secrets and write newly rotated payload versions.
4
Attach rotation period and Pub/Sub topic parameters to Secret Manager secret metadata
Automated 90-day rotation trigger is active.
Configuring the secret schedule is the final step once target topics and execution workers are fully authorized.

Key Concept

Secret Manager Automated Rotation Architecture and IAM Authorization Lifecycle
Question 888Question →

A financial services organization is storing sensitive transactional data in Cloud Spanner. Compliance regulations mandate that data at rest must be encrypted using encryption keys managed in Google Cloud KMS by a centralized security team, completely separated from database administrators. Additionally, automated key rotation must be configured without requiring application code changes or manually re-encrypting existing data. Which key management strategy should the cloud architect recommend?

Show answer & explanation

Answer: Configure Customer-Managed Encryption Keys (CMEK) using Cloud KMS, and grant the Cloud Spanner Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter role on the KMS key.

Answer

Configure Customer-Managed Encryption Keys (CMEK) using Cloud KMS, granting the Cloud Spanner Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter role.
The correct strategy uses Customer-Managed Encryption Keys (CMEK) managed via Cloud KMS. Security teams can configure automated key rotation schedules in Cloud KMS, while granting the Cloud Spanner Service Agent the specific fine-grained Cloud KMS CryptoKey Encrypter/Decrypter role (`roles/cloudkms.cryptoKeyEncrypterDecrypter`). This maintains strict separation of duties and satisfies regulatory mandates.

Step-by-Step Solution

1
Analyze key management requirements
The requirement demands centralized key lifecycle management in Cloud KMS with automated key rotation and separation of duties.
CMEK integrates Cloud KMS with GCP services, allowing security administrators to enforce key rotation and policies independently of database administrators.
2
Determine service identity permissions
Grant `roles/cloudkms.cryptoKeyEncrypterDecrypter` to the Cloud Spanner Service Agent.
GCP services require specific service agent service account roles on Cloud KMS keys to encrypt and decrypt data on behalf of the customer.

Key Concept

Customer-Managed Encryption Keys (CMEK) and Key Management Service (KMS) Access Control
Question 889Question →

You need to configure your local development environment to authenticate programmatic interactions with Google Cloud APIs using Application Default Credentials (ADC) via service account impersonation, avoiding the use of long-lived downloaded service account keys. In what sequence should you execute these configuration steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by authenticating your user identity (`gcloud auth login`), granting your identity the Service Account Token Creator role on the service account, and finally generating Application Default Credentials configured with service account impersonation (`gcloud auth application-default login --impersonate-service-account`).
To establish secure local programmatic access using Application Default Credentials without downloading long-lived keys, you must first authenticate your user identity, ensure your identity holds the Service Account Token Creator role on the target service account, and then generate ADC with the impersonation flag active.

Step-by-Step Solution

1
Authenticate user identity.
Establishes active user credentials in the local Google Cloud CLI context.
Impersonation requires an existing authenticated primary principal to initiate token requests.
2
Assign the Service Account Token Creator IAM role.
Grants permission for the user identity to generate short-lived tokens for the service account.
Without `roles/iam.serviceAccountTokenCreator`, API calls requesting impersonated credentials will fail authorization checks.
3
Generate Application Default Credentials (ADC) with impersonation.
Writes a local ADC credentials file configured to mint temporary service account access tokens automatically.
This allows client SDKs using ADC to authenticate securely as the service account without exposing static JSON key files.

Key Concept

Programmatic GCP SDK Authentication using Application Default Credentials (ADC) and Service Account Impersonation
Question 890Question →

A Switzerland-based aerospace defense contractor is migrating its telemetry and aircraft design repository to Google Cloud. Compliance mandates dictate that all data at rest must remain strictly confined to the europe-west6 (Zurich) region and protected against unauthorized cloud provider personnel access during administrative support. Furthermore, you must prevent authorized internal users from exfiltrating sensitive datasets to external Google Cloud storage locations outside the enterprise network boundary. Which TWO architectural controls should you implement to satisfy these regulatory compliance and data sovereignty requirements?

Select all that apply

Show answer & explanation

Answer: Configure an Organization Policy using the constraints/gcp.resourceLocations constraint enforcing resource creation strictly in europe-west6, and enable Access Approval at the organization level.; Establish a VPC Service Controls security perimeter around the Cloud Storage buckets and telemetry processing services containing sensitive data.

Answer

Enforcing regional resource creation via Organization Policies alongside Access Approval for cloud provider access governance, combined with VPC Service Controls security perimeters to prevent data exfiltration.
To satisfy regional data sovereignty and prevent unauthorized cloud provider access, applying an Organization Policy with constraints/gcp.resourceLocations restricts data and resource deployment to europe-west6, and Access Approval ensures Google engineers cannot access data without customer permission. To prevent data exfiltration, VPC Service Controls creates a cryptographic and network security boundary around GCP services, preventing data transfers to external GCP projects.

Step-by-Step Solution

1
Enforce strict data residency and access transparency controls
Configuring constraints/gcp.resourceLocations restricts resource creation strictly to europe-west6, while Access Approval ensures explicit authorization is required for any Google support personnel access.
Meets regulatory data sovereignty and administrative access requirements.
2
Implement data exfiltration controls
Defining a VPC Service Controls security perimeter around Cloud Storage and data processing services prevents authorized entities from copying sensitive datasets outside the designated enterprise boundary.
IAM alone controls who has access, but VPC Service Controls restricts where data can be moved.

Key Concept

Regulatory Compliance, Data Sovereignty, and Data Governance
Question 891Question →

An enterprise hybrid application written in Python needs to programmatically manage infrastructure resources across multiple Google Cloud projects via Google Cloud Client Libraries. The application runs simultaneously on on-premises virtual machines and Google Kubernetes Engine (GKE) clusters. Company security compliance strictly prohibits the creation and storage of downloadable, long-lived service account JSON key files anywhere in the deployment pipeline. Furthermore, the application must interact with APIs across target projects without delegating broad administrative permissions to the workload identity directly. How should you design the programmatic authentication and authorization architecture to satisfy these requirements?

Show answer & explanation

Answer: Configure Workload Identity Federation for the on-premises workloads and Workload Identity for the GKE workloads to mint short-lived Application Default Credentials (ADC), and use IAM Service Account Impersonation with fine-grained custom roles for target project access.

Answer

Configure Workload Identity Federation for on-premises workloads and Workload Identity for GKE workloads to obtain short-lived credentials dynamically, combined with IAM Service Account Impersonation for granular cross-project API access.
The correct strategy combines Workload Identity Federation for on-premises systems and GKE Workload Identity for containerized workloads. Both mechanisms exchange native identity tokens (OIDC/SAML/Kubernetes tokens) for short-lived Google Cloud OAuth2 tokens via Application Default Credentials (ADC), completely avoiding static JSON keys. Cross-project authorization is cleanly achieved using IAM Service Account Impersonation, granting short-lived, fine-grained access tokens to targeted target service accounts.

Step-by-Step Solution

1
Establish short-lived identity mapping without static keys
On-premises workloads authenticate via Workload Identity Federation (using external OIDC/SAML tokens), while GKE workloads leverage GKE Workload Identity to map Kubernetes service accounts directly to GCP service accounts.
This satisfies the governance requirement preventing the creation and maintenance of downloadable, long-lived JSON service account keys.
2
Implement Service Account Impersonation for multi-project authorization
The application requests short-lived access tokens for specific destination service accounts in target projects by leveraging the Service Account Token Creator role.
Impersonation ensures the workload operates under short-lived tokens scoped specifically to required target actions across project boundaries.
3
Apply fine-grained IAM roles to target service accounts
Target service accounts in downstream projects are assigned specific predefined or custom roles (e.g., Compute Instance Admin) rather than primitive roles.
Enforces least privilege access control while performing programmatic SDK operations.

Key Concept

Keyless Programmatic Authentication and Multi-Project Service Account Impersonation
Estimated Time:3m 0s
Question 892Question →

An insurance enterprise processes policyholder claims on Google Cloud using two primary components: a synchronous Claim Submission API that impacts immediate customer satisfaction, and an asynchronous Document Archival worker pipeline that processes claims for long-term auditing within a 24-hour window. Executive leadership wants to align operational reliability alerting with business impact while avoiding alert fatigue. Which TWO actions should the Cloud Architect recommend to achieve this alignment?

Select all that apply

Show answer & explanation

Answer: Define a tight availability SLO for the Claim Submission API measured by successful HTTP request ratio (SLI), and configure multi-window error budget burn-rate alerts for on-call engineers.; Set a throughput and latency SLO for the Document Archival pipeline over a 24-hour window, deferring operational intervention until sustained error budget depletion threatens the daily audit deadline.

Answer

The Cloud Architect should establish a high-availability SLO with multi-window burn-rate alerting for the customer-facing Claim Submission API, while defining a 24-hour window SLO for the asynchronous Document Archival pipeline that only escalates when sustained error budget depletion threatens operational deadlines.
Effective SRE and business process optimization requires aligning reliability targets with user impact. The synchronous Claim Submission API directly affects policyholders, making a real-time HTTP success SLI with multi-window burn-rate alerts essential to mitigate outage risks. Conversely, the asynchronous Document Archival service can tolerate short-term delays, making a wider 24-hour evaluation window appropriate to avoid paging engineers for transient backlogs that do not breach business compliance targets.

Step-by-Step Solution

1
Analyze service criticality and business impact for each system component
Identified Claim Submission API as synchronous/user-facing (high business impact for downtime) and Document Archival as asynchronous batch processing (tolerant of transient delays up to 24 hours).
SLOs must reflect customer experience and business consequence rather than uniform technical targets.
2
Formulate appropriate Service Level Indicators (SLIs) and Service Level Objectives (SLOs) matching component requirements
Configured real-time HTTP success ratio SLI for the submission API and a 24-hour completion latency/throughput SLI for the archival pipeline.
Differentiating metric windows prevents alert fatigue while maintaining appropriate safeguards for critical workflows.
3
Establish error budget burn-rate alerting strategies instead of static infrastructure threshold alerts
Alerts trigger when consumption of error budgets accelerates beyond safe thresholds, ignoring routine CPU utilization spikes on asynchronous workers.
Burn-rate alerts tie operational escalation directly to potential SLO breaches rather than raw resource metrics.

Key Concept

Aligning SLO targets and error budget alerting strategies with business criticality and user experience rather than enforcing uniform metrics or raw infrastructure thresholds.
Estimated Time:1m 30s
Question 893Question →

An online retail enterprise is preparing for an upcoming annual mega-sale expected to drive a projected 10×10\times surge in peak user traffic over a 48-hour window. Their primary application architecture consists of a stateless HTTP API tier deployed on Compute Engine Managed Instance Groups (MIGs) and a Cloud SQL PostgreSQL backend database. During previous smaller sales, sudden traffic spikes caused temporary latency spikes because MIG reactive autoscaling took several minutes to spin up new virtual machine instances, and the Cloud SQL backend suffered from connection exhaustion. Furthermore, the architecture team needs to ensure infrastructure scaling will not fail due to cloud platform limitations during the event. Which capacity planning and workload scaling optimization strategy should the Cloud Architect recommend?

Show answer & explanation

Answer: Audit existing project quotas and request regional Compute Engine CPU and IP quota increases well in advance, enable predictive autoscaling or schedule scheduled autoscaling scaling for the MIGs, and introduce connection pooling alongside database read replicas for Cloud SQL.

Answer

The Cloud Architect should recommend proactive capacity planning: requesting regional resource quota increases well in advance, implementing predictive or scheduled autoscaling on Compute Engine MIGs to eliminate startup latency, and optimizing database scaling with connection pooling and read replicas.
Proactive capacity management requires requesting regional compute and network quota increases in advance to ensure the cloud project can accommodate the 10×10\times traffic surge. Combining predictive or scheduled autoscaling on MIGs ensures VM instances are fully provisioned before the traffic arrives, eliminating boot-up latency spikes. Additionally, adding connection pooling and Cloud SQL read replicas addresses the database connection exhaustion bottleneck without requiring expensive re-architecture.

Step-by-Step Solution

1
Evaluate resource quota constraints ahead of high-traffic events.
Identified that GCP quotas (e.g., regional CPU limits, in-use IP addresses) are hard bounds that require advance approval from Google Cloud support.
Failing to request quota increases in advance can cause compute instance creation to fail during rapid scale-out events.
2
Select the optimal compute autoscaling strategy for predictable traffic surges.
Chose predictive autoscaling or scheduled scaling for Compute Engine MIGs over purely reactive autoscaling.
Predictive autoscaling analyzes historical load patterns and provisions capacity ahead of expected spikes, preventing initialization latency and request drops.
3
Address database tier bottlenecks and connection scaling.
Implemented connection pooling (such as PgBouncer) and Cloud SQL read replicas.
Connection pooling multiplexes frontend requests to minimize backend connection overhead, while read replicas offload read query capacity from the primary instance.

Key Concept

Capacity Planning and Workload Scaling Optimization
Question 894Question →

A cloud engineering team is configuring an automated CI/CD deployment pipeline using Cloud Build to deploy containerized microservices to a Google Kubernetes Engine (GKE) cluster. To comply with organizational security governance and the principle of least privilege, the team needs to assign permissions to the Cloud Build service account. Which configuration represents the optimal approach for granting Cloud Build access to deploy workloads to the cluster?

Show answer & explanation

Answer: Grant the Cloud Build service account the Kubernetes Engine Developer role (roles/container.developer) on the target cluster.

Answer

Grant the Cloud Build service account the Kubernetes Engine Developer role (roles/container.developer) on the target cluster.
Granting the predefined Kubernetes Engine Developer role (`roles/container.developer`) provides the Cloud Build service account with the exact set of permissions required to deploy, update, and manage containerized workloads in the GKE cluster while preventing unauthorized changes to cluster infrastructure.

Step-by-Step Solution

1
Determine the functional requirement of the CI/CD service account during deployment.
The pipeline requires permissions to apply Kubernetes manifests and manage application pods/services in the GKE cluster.
Identifying the specific runtime requirement helps narrow down the minimal required IAM scope.
2
Evaluate Google Cloud predefined IAM roles for Google Kubernetes Engine.
The predefined role `roles/container.developer` supplies complete workload management capabilities (such as deploy, update, and inspect) on GKE clusters without granting cluster creation, deletion, or node pool administration privileges.
Using predefined fine-grained roles ensures compliance with security governance and the principle of least privilege.

Key Concept

Configuring least privilege IAM service account permissions for Cloud Build CI/CD deployments to GKE
Estimated Time:1m 0s
Question 895Question →

A SaaS logistics company operating on Google Cloud provides two core features: a real-time fleet GPS tracking API and an end-of-month regulatory compliance report generator. The business incurs financial penalties if the real-time tracking API availability drops below 99.9%99.9\%, whereas compliance report generation allows a 24-hour delivery window without penalty. Currently, the engineering team applies a single composite availability goal of 99.99%99.99\% across the entire platform, causing frequent false-alarm pages and unnecessary over-engineering costs. Which approach should the Cloud Architect recommend to properly align technical SLOs and SLIs with business impact?

Show answer & explanation

Answer: Decouple the platform into distinct services, defining a target availability SLO of 99.9%99.9\% based on successful HTTP request ratio SLIs for real-time tracking, and a completion-time SLO based on a 24-hour latency SLI for batch report generation.

Answer

Decouple the platform into distinct services, defining a target availability SLO of 99.9% based on successful HTTP request ratio SLIs for real-time tracking, and a completion-time SLO based on a 24-hour latency SLI for batch report generation.
The correct strategy decouples heterogeneous workloads (real-time streaming vs. asynchronous batch processing) so their technical SLOs reflect their respective business requirements. Real-time GPS tracking requires high availability to avoid financial penalties, whereas compliance reporting requires a throughput or latency-based metric within a 24-hour window.

Step-by-Step Solution

1
Analyze business impact and requirements for each workload
Real-time tracking requires high availability (99.9%99.9\%) due to financial SLA penalties. Compliance reporting is batch-oriented with a 24-hour tolerance window.
SLOs must directly reflect user expectations and contractual business consequences rather than arbitrary technical defaults.
2
Define appropriate Service Level Indicators (SLIs) for each service
Real-time tracking SLI = (Successful tracking requests) / (Total tracking requests). Compliance report SLI = (Reports completed within 24 hours) / (Total generated reports).
SLIs quantify actual performance in terms that map directly to functional requirements (availability vs batch completion latency).
3
Set Service Level Objectives (SLOs) and manage error budgets independently
Real-time tracking SLO is set to 99.9%99.9\% monthly availability. Reporting SLO is set to 99%99\% of jobs completed within 24 hours.
Separating SLOs prevents non-critical batch jobs from depleting the error budget of critical real-time features.

Key Concept

Aligning SLAs, SLOs, and SLIs with Business Impact
Question 896Question →

A financial technology enterprise processes high-throughput transaction streams using Google Kubernetes Engine (GKE) and Cloud Spanner. During quarterly settlement windows, incoming event volume surges suddenly by 20×20\times baseline load within a 3-minute window. During recent events, the platform experienced packet drops and elevated latency because the GKE Horizontal Pod Autoscaler (HPA) reacted too slowly to CPU load, and worker node scaling was constrained by regional Compute Engine quota limits. Which TWO capacity planning and workload scaling optimization strategies should you implement to resolve these performance bottlenecks? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Deploy low-priority pause pods to maintain a pre-allocated buffer of node capacity, and reconfigure HPA to autoscale based on unconsumed Pub/Sub message queue depth.; Request regional Compute Engine CPU and API quota adjustments in advance of scheduled traffic spikes, and implement client-side connection pooling to handle Cloud Spanner session growth.

Answer

The correct strategies are to deploy low-priority pause pods with custom Pub/Sub queue-depth HPA metrics, and to request regional Compute Engine quota increases in advance while implementing database connection pooling.
To absorb sudden 20×20\times traffic spikes, capacity planning requires both compute readiness and proactive quota management. Implementing low-priority pause pods creates a pre-provisioned pool of VM resources that high-priority application pods can immediately reclaim without waiting for new VM startup times. Reconfiguring HPA to scale on queue depth (such as Pub/Sub unconsumed message count) ensures pod scaling initiates as soon as work accumulates. Concurrently, submitting regional quota requests before peak events guarantees that underlying GCP compute limits do not block scale-out, while database connection pooling protects Cloud Spanner from session exhaustion.

Step-by-Step Solution

1
Analyze pod autoscaling bottlenecks during rapid ingestion bursts.
Identified that CPU utilization is a lagging indicator for sudden queue-based traffic spikes.
Scaling microservices based on unconsumed Pub/Sub message queue depth triggers HPA before CPU load accumulates.
2
Address GKE node provisioning latency for rapid scale-out.
Implemented overprovisioning via low-priority pause pods.
Pause pods reserve compute capacity on VM nodes; when actual work pods need resources, pause pods are evicted instantly, bypassing GKE VM creation delays.
3
Evaluate infrastructure quota boundaries.
Identified that Compute Engine regional quotas act as hard ceilings during automated scaling.
Quota increases must be requested proactively from Google Cloud prior to predictable peak demand events.
4
Optimize database connectivity scaling.
Added connection pooling and session management for Cloud Spanner clients.
Prevents downstream database connection saturation as worker pod count expands rapidly.

Key Concept

Capacity Planning, Preemptive Overprovisioning, and Custom Metric Autoscaling in GCP
Question 897Question →

An enterprise development team is deploying an automated Python application inside a Google Kubernetes Engine (GKE) Pod. The application needs to programmatically upload archived files to a Cloud Storage bucket using the official Google Cloud Python Client Library. Which TWO actions should the team take to securely authenticate and execute these API calls? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Configure Workload Identity on the GKE cluster and map the Kubernetes Service Account to a Google IAM Service Account configured with least-privilege storage permissions.; Initialize the Cloud Storage client in the application code without passing explicit key paths, relying on Application Default Credentials (ADC) to detect runtime credentials.

Answer

The correct practices are to bind the Kubernetes Service Account to a Google IAM Service Account using Workload Identity, and to instantiate the client library relying on Application Default Credentials (ADC).
Enabling Workload Identity maps the Kubernetes Service Account to a Google Cloud IAM Service Account, providing secure short-lived identity tokens to the Pod. Relying on Application Default Credentials (ADC) inside the Python client library allows the SDK to automatically discover these tokens without hardcoded credentials or manual token handling.

Step-by-Step Solution

1
Identify the authentication mechanism for GKE Pods accessing GCP APIs.
Workload Identity provides short-lived tokens directly to Pods, eliminating service account key management.
This is the recommended security pattern for GKE applications invoking GCP APIs.
2
Determine how the client library should discover credentials.
Instantiating the client without explicit credential arguments enables Application Default Credentials (ADC) to resolve the environment identity automatically.
ADC ensures portable, secure programmatic authorization across Google Cloud environments.

Key Concept

Workload Identity and Application Default Credentials (ADC) for secure SDK interaction
Question 898Question →

A cloud platform team needs to deploy a Cloud SQL for PostgreSQL database instance with Private Services Access (PSA) and Customer-Managed Encryption Keys (CMEK). Arrange the operational steps in the correct order to provision this infrastructure successfully.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with establishing Private Services Access, followed by granting IAM permissions for Cloud KMS to the Cloud SQL service agent, provisioning the CMEK-encrypted database instance over private IP, and concluding with database connectivity verification.
Provisioning database infrastructure with Private Services Access (PSA) and Customer-Managed Encryption Keys (CMEK) follows strict prerequisite ordering: network connectivity and IAM key permissions must exist before creating the dependent database instance, with post-provisioning connectivity checks executed last.

Step-by-Step Solution

1
Allocate IP address ranges and configure Private Services Access VPC peering.
The VPC network is connected to Google service networking infrastructure.
Cloud SQL requires Private Services Access peering to assign private IP addresses within the VPC.
2
Assign roles/cloudkms.cryptoKeyEncrypterDecrypter to the Cloud SQL service account.
Cloud SQL service identity gains access rights to encrypt and decrypt using the specified Cloud KMS key.
Attempting to create a CMEK-enabled instance will fail at creation time if the service agent lacks KMS permissions.
3
Create the Cloud SQL instance specifying the private network connection and CMEK key URI.
The database instance is provisioned with customer-managed encryption and private IP networking.
This step relies on the pre-existing private network peering and encryption identity rights.
4
Verify database endpoint accessibility from authorized client instances in the VPC.
Operational readiness and network security controls are validated.
Testing private connectivity is the final validation phase of database provisioning.

Key Concept

Cloud SQL Provisioning Dependency Ordering with PSA and CMEK
Question 899Question →

A developer is building a Node.js microservice deployed to Cloud Run that needs to programmatically publish telemetry messages to a Google Cloud Pub/Sub topic. Which authentication approach should the developer use to allow the Google Cloud Client Library to interact with Pub/Sub securely?

Show answer & explanation

Answer: Rely on Application Default Credentials (ADC) by letting the client library automatically retrieve identity tokens from the Cloud Run metadata server.

Answer

Rely on Application Default Credentials (ADC) by letting the client library automatically retrieve identity tokens from the Cloud Run metadata server.
The correct option uses Application Default Credentials (ADC), which allows Google Cloud Client Libraries to automatically fetch short-lived access tokens directly from the runtime container's metadata server without embedding static keys.

Step-by-Step Solution

1
Identify the authentication requirement for GCP client libraries running on managed compute environments like Cloud Run.
GCP client libraries naturally look for credentials using the Application Default Credentials (ADC) strategy.
ADC abstracts credential lookup across different execution environments.
2
Evaluate the security mechanism on Cloud Run.
Cloud Run attaches a designated identity (service account) to the container instance via the internal metadata server.
This allows applications to obtain short-lived OAuth 2.0 access tokens programmatically without managing service account keys.

Key Concept

Application Default Credentials (ADC) and Metadata Server Authentication
Question 900Question →

A healthcare organization is migrating an operational telemetry application to Google Cloud. The architecture uses Compute Engine persistent disks for temporary cache storage and Cloud Storage for long-term log archiving. Security compliance mandates that all data at rest be encrypted using keys generated and protected inside FIPS 140-2 Level 3 validated Hardware Security Modules (HSMs) in Google Cloud, while supporting automated key rotation. Furthermore, key access control must strictly adhere to the principle of least privilege without relying on broad administrative roles. Which TWO configuration steps should the security architect implement to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Provision Customer-Managed Encryption Keys (CMEK) in Cloud KMS configured with the HSM protection level, and define an automated key rotation schedule on the CryptoKey.; Grant the Cloud KMS CryptoKey Encrypter/Decrypter role specifically to the Cloud Storage Service Agent and Compute Engine Service Agent identity accounts.

Answer

The architect should configure Customer-Managed Encryption Keys (CMEK) backed by Cloud HSM with automated rotation schedules, and grant the Cloud KMS CryptoKey Encrypter/Decrypter role directly to the Cloud Storage and Compute Engine Service Agents.
Provisioning CMEK backed by Cloud HSM meets the FIPS 140-2 Level 3 hardware security constraint and enables automated key rotation directly through Cloud KMS. Granting the Cloud KMS CryptoKey Encrypter/Decrypter role specifically to the Cloud Storage Service Agent and Compute Engine Service Agent grants the precise permissions needed by GCP services to perform cryptographic operations on behalf of the user, adhering strictly to the principle of least privilege.

Step-by-Step Solution

1
Identify key storage and compliance requirements
Requirements specify FIPS 140-2 Level 3 HSM key protection and automated key rotation within Google Cloud.
Cloud KMS with the HSM protection level (Cloud HSM) satisfies hardware security requirements while allowing automated rotation.
2
Determine appropriate service access permissions for encryption
GCP service agents require granular permissions to encrypt and decrypt resources using the specified CMEK key.
Granting `roles/cloudkms.cryptoKeyEncrypterDecrypter` to specific service agents follows least-privilege practices without using primitive roles.

Key Concept

CMEK with Cloud HSM and IAM Service Agent Least Privilege
PreviousPage 45 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin