All practice questions

1598 questions

All types1,598 Multiple choice815 Multiple select537 Numeric8 Matching64 Ordering174

A fintech enterprise based in the United Kingdom is migrating its payment settlement and audit engine to Google Cloud to meet stringent UK Financial Conduct Authority (FCA) regulations and national data sovereignty requirements. The solution architecture must enforce four strict compliance mandates:
1. All storage and compute infrastructure must be physically restricted to the europe-west2 (London) region.
2. Exfiltration of sensitive customer transaction data to external, uncontrolled cloud environments by compromised authenticated identities must be prevented.
3. Google support personnel and system administrators must be explicitly prevented from accessing underlying customer data without real-time, explicit customer authorization.
4. All customer data at rest must be encrypted using keys managed within the customer's controlled key ring located in europe-west2.

Which architectural design fully satisfies all four compliance and sovereignty requirements?

Enforce the Resource Locations organization policy constraint (constraints/gcp.resourceLocations) limited to europe-west2, establish a VPC Service Controls security perimeter around the project resources, enable Access Approval with Access Transparency, and configure Customer-Managed Encryption Keys (CMEK) residing in europe-west2.

Grant granular IAM roles to security administrators, restrict Cloud KMS key rings to europe-west2, enable Access Approval, and rely exclusively on Cloud IAM deny policies without VPC Service Controls to block unauthorized external resource access.

Mandate Customer-Supplied Encryption Keys (CSEK) for all Cloud Storage and BigQuery datasets, enforce the Resource Locations organization policy constraint restricted to europe-west2, and configure Access Transparency without enabling Access Approval.

Assign the Owner primitive IAM role to the dedicated compliance service account, enforce VPC Service Controls perimeters, enable Access Approval, and configure Customer-Managed Encryption Keys (CMEK) hosted in a multi-region location for high availability.

Show answer & explanation

Answer: Enforce the Resource Locations organization policy constraint (constraints/gcp.resourceLocations) limited to europe-west2, establish a VPC Service Controls security perimeter around the project resources, enable Access Approval with Access Transparency, and configure Customer-Managed Encryption Keys (CMEK) residing in europe-west2.

Answer

The correct answer combines all four essential security and compliance primitives required by strict data sovereignty standards: Resource Locations Organization Policy for spatial residency, VPC Service Controls to prevent exfiltration, Access Approval to control Google personnel access, and regional CMEK for cryptographic governance.

Step-by-Step Solution

Address regional data residency mandates

Enforce `constraints/gcp.resourceLocations` set strictly to `europe-west2` across the resource hierarchy to prevent resource creation in unauthorized locations.

Organization policies provide declarative guardrails to guarantee compliance with national data sovereignty laws.

Mitigate data exfiltration risks

Configure a VPC Service Controls perimeter encompassing storage, database, and compute resources.

VPC Service Controls restrict communication between Google Cloud services and prevent authorized identities from copying data outside the defined perimeter.

Restrict cloud service provider administrator access

Enable Access Approval alongside Access Transparency.

Access Transparency provides logs of Google administrator actions, while Access Approval requires administrative access requests to be explicitly approved by customer security teams prior to data access.

Implement key management for cryptographic governance

Use Customer-Managed Encryption Keys (CMEK) stored in Cloud KMS located in `europe-west2`.

CMEK allows the customer to control key lifecycle and location while leveraging native Google Cloud integration without the burden of storing raw key material on-premises (CSEK).

Key Concept

Data Sovereignty and Regulatory Governance Controls

Question 782Question →

An enterprise architecture team needs to provision a mission-critical Cloud Bigtable instance to store real-time IoT telemetry data. The regulatory compliance framework requires that persistent data be encrypted using Customer-Managed Encryption Keys (CMEK) and that all database traffic remain isolated within the private network via Private Services Access (PSA). What is the correct sequence of steps to provision this storage infrastructure securely?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the Cloud KMS key and granting the Encrypter/Decrypter role to the Cloud Bigtable Service Agent. Next, allocate an internal IP range and establish the Private Services Access VPC peering connection. Then, create the Cloud Bigtable instance referencing the CMEK key URI. Finally, configure and provision the cluster within the instance attached to the private network topology.

Provisioning database resources with custom encryption and private networking requires strict ordering of security and infrastructure dependencies. First, key access must be granted to the service agent so encryption verification succeeds during storage creation. Second, Private Services Access must be established so private IP addresses can be assigned to the instance nodes. Third, the instance is created referencing the CMEK key. Finally, the cluster is provisioned within the created instance and connected to the private network topology.

Step-by-Step Solution

Configure CMEK and IAM permissions

Cloud Bigtable Service Agent possesses necessary permissions to access the KMS CryptoKey.

GCP service APIs reject storage resource provisioning if the service account cannot access the specified CMEK key.

Establish Private Services Access (PSA)

IP allocation and Service Networking VPC peering connection created between VPC and Google producer network.

Private connectivity requires pre-allocated CIDR blocks to avoid address collisions when provisioning cluster endpoints.

Provision the Cloud Bigtable instance using CMEK

Bigtable instance created with persistent disks bound to the KMS key.

Instance creation references the pre-configured CMEK key URI established in Step 1.

Deploy and finalize cluster parameters

Cluster initialized with target node count and storage type inside the private VPC network.

Cluster topology deployment relies on both the active instance shell and established Private Services Access network.

Key Concept

Dependency ordering for GCP database provisioning with CMEK encryption and Private Services Access

Question 783Question →

A financial clearing platform on Google Cloud has accumulated significant technical debt following consecutive rapid feature releases. An architectural audit identifies two primary vulnerabilities: operational risk from manual Cloud Console modifications that cause severe configuration drift against infrastructure code, and security risk from application service accounts assigned primitive roles/editor permissions. You are tasked with establishing a technical debt remediation framework that enforces strict infrastructure governance and least-privilege security without disrupting service uptime. Which combination of architectural actions should you recommend?

Automate Terraform deployments through a CI/CD pipeline, mandate drift detection to review and import out-of-band changes, restrict manual write access to the Cloud Console, and refactor service accounts to use minimal predefined roles.

Configure a scheduled background job to execute automated terraform apply runs that overwrite uncommitted Cloud Console changes without state reconciliation, and assign roles/iam.serviceAccountAdmin to developer identities.

Retain primitive roles/editor permissions on existing application service accounts to avoid application access failures, while deploying VPC Service Controls security perimeters to block Console administrative operations.

Store Terraform state files inside local Git repositories across developer build environments to track history, and grant roles/owner to application service accounts to streamline deployment authorization across newly added GCP services.

Show answer & explanation

Answer: Automate Terraform deployments through a CI/CD pipeline, mandate drift detection to review and import out-of-band changes, restrict manual write access to the Cloud Console, and refactor service accounts to use minimal predefined roles.

Answer

The optimal strategy to resolve IaC technical debt and IAM privilege creep is to centralize IaC execution within automated pipelines, restrict direct manual Console write permissions, reconcile state drift systematically, and downgrade primitive roles to fine-grained predefined roles.

Step-by-Step Solution

Analyze identified technical debt anti-patterns.

Identified manual infrastructure mutation (IaC drift) and over-privileged service accounts (primitive roles) as core risks.

Technical debt remediation requires addressing both operational governance and security posture.

Establish declarative infrastructure state governance.

Enforce central remote state backends (Cloud Storage with versioning), mandate CI/CD execution for Terraform apply operations, and audit/import drift using terraform plan/import.

Preventing uncommitted Console edits ensures environment reproducibility and prevents state file corruption.

Refactor identity permissions to least privilege.

Audit permissions using IAM Recommender and replace primitive roles (Editor/Owner) with specific predefined or custom IAM roles tailored to service functions.

Primitive roles grant excessive broad permissions across all resources, violating GCP security standards.

Key Concept

Assessing and Mitigating Technical Debt in Cloud Architectures

Question 784Question →

A biotechnology company manages its Google Cloud workloads within a resource hierarchy containing a dedicated folder named Genomics-Research. An automated CI/CD deployment pipeline running in a separate management project needs to attach and execute jobs as a specific worker service account inside a project under Genomics-Research. The security team mandates adhering strictly to the principle of least privilege while maintaining operational isolation. Which configuration recommended by Google Cloud best practices meets these requirements?

Grant the Service Account User role (roles/iam.serviceAccountUser) on the specific worker service account resource to the deployment pipeline service account.

Grant the Service Account Admin role (roles/iam.serviceAccountAdmin) on the target project to the deployment pipeline service account.

Grant the Editor primitive role (roles/editor) at the Genomics-Research folder level to the deployment pipeline service account.

Enforce a VPC Service Controls perimeter around the Genomics-Research folder without assigning IAM service account impersonation roles.

Show answer & explanation

Answer: Grant the Service Account User role (roles/iam.serviceAccountUser) on the specific worker service account resource to the deployment pipeline service account.

Answer

Grant the Service Account User role (roles/iam.serviceAccountUser) on the specific worker service account resource to the deployment pipeline service account.

The optimal Google Cloud security design mandates granting roles at the narrowest resource level possible. Granting the Service Account User role (roles/iam.serviceAccountUser) directly on the specific worker service account gives the deployment pipeline principal exact authorization to impersonate and launch workloads with that identity without granting broader project or folder permissions.

Step-by-Step Solution

Identify the minimum necessary permission required for identity impersonation.

The deployment pipeline requires permission to attach/use the target service account to run workloads.

The specific permission required for service account attachment and execution is iam.serviceAccounts.actAs.

Determine the resource boundary to apply least privilege.

Apply the role directly to the individual service account resource rather than at the project or folder level.

Resource-level bindings restrict access specifically to the target principal without granting collateral access to other identities in the project or folder hierarchy.

Select the appropriate IAM predefined role.

Assign roles/iam.serviceAccountUser to the pipeline identity on the target service account.

This role grants the actAs permission strictly on the designated service account object.

Key Concept

Fine-Grained IAM Service Account Impersonation and Resource Hierarchy Scoping

Question 785Question →

An enterprise is designing a real-time telemetry processing pipeline on Google Cloud using Cloud Pub/Sub. Internal compliance standards require that message data stored at rest within Cloud Pub/Sub topics must be encrypted using Customer-Managed Encryption Keys (CMEK) managed via Cloud KMS. The security team strictly mandates separation of duties and least privilege access. Which TWO configuration steps must you perform to encrypt the Cloud Pub/Sub topic with CMEK? (Select TWO.)

Select all that apply

Create a Cloud KMS Symmetric Encryption key in the location matching the Pub/Sub topic, and specify the key resource ID during topic creation.

Grant the Cloud KMS CryptoKey Encrypter/Decrypter role on the specific KMS key to the Google-managed Cloud Pub/Sub Service Agent service account.

Generate a raw 256-bit AES key on-premises and pass it in HTTP request headers as a Customer-Supplied Encryption Key (CSEK) when publishing messages.

Assign the primitive Editor role on the Cloud KMS KeyRing to the default Compute Engine service account to allow automated key rotation.

Show answer & explanation

Answer: Create a Cloud KMS Symmetric Encryption key in the location matching the Pub/Sub topic, and specify the key resource ID during topic creation.; Grant the Cloud KMS CryptoKey Encrypter/Decrypter role on the specific KMS key to the Google-managed Cloud Pub/Sub Service Agent service account.

Answer

The required setup involves creating a symmetric Cloud KMS key in the same geographic location as the topic and referencing its resource ID, while assigning the Cloud KMS CryptoKey Encrypter/Decrypter role to the Google-managed Cloud Pub/Sub Service Agent service account.

To configure CMEK on a Cloud Pub/Sub topic, you must create a Cloud KMS key in a matching location and attach its key resource ID to the topic. In addition, Google Cloud Pub/Sub accesses keys using its Google-managed Service Agent, which must be granted the Cloud KMS CryptoKey Encrypter/Decrypter role.

Step-by-Step Solution

Determine the required encryption key model.

The requirement specifies CMEK (Cloud KMS managed key lifecycle) rather than CSEK (customer-supplied raw key headers).

CMEK allows central lifecycle management, auditability, and integration with GCP native services.

Identify the principal conducting key operations.

Cloud Pub/Sub utilizes a Google-managed Service Agent ([email protected]).

Granting roles/cloudkms.cryptoKeyEncrypterDecrypter to the Service Agent enforces separation of duties so end users and compute workloads do not need direct key decryption permissions.

Ensure resource location alignment.

The Cloud KMS KeyRing and CryptoKey must exist in the same region or multi-region as the Cloud Pub/Sub topic.

GCP mandates location matching for CMEK resources to prevent cross-region latency and regulatory non-compliance.

Key Concept

Configuring CMEK for Google Cloud services requires granting the Cloud KMS CryptoKey Encrypter/Decrypter role to the service's Google-managed Service Agent while matching resource and key locations.

Estimated Time:2m 0s

Question 786Question →

A global logistics provider operates a real-time event-driven platform on Google Cloud that processes both high-priority shipment rerouting events and low-priority operational telemetry. The business contract specifies a steep financial penalty if shipment rerouting requests take longer than $5$ seconds to complete, whereas operational telemetry can tolerate processing delays of up to $10$ minutes without incurring any business or financial impact. The engineering leadership team wants to establish a service level monitoring strategy that tightly couples operational alerting with actual business financial risk while avoiding unnecessary infrastructure over-provisioning and alert fatigue. Which strategy correctly aligns technical SLI measurement and SLO alerting with these business goals?

Define the SLI specifically as the ratio of shipment rerouting events completed within 5 seconds to total shipment rerouting events measured at the ingress gateway. Set a monthly SLO of 99.9% for this specific pipeline, and configure multi-window, multi-burn-rate alerts based on error budget consumption speed.

Define the SLO as the actual measured latency percentage of all combined system traffic (rerouting and telemetry events) meeting the 5-second target, and configure alerts to trigger whenever the rolling 5-minute average processing time exceeds 5 seconds.

Define the SLI as worker pool CPU and memory utilization across all event-processing clusters, and configure high-priority paging alerts whenever any worker node exceeds 85% CPU utilization for more than 1 minute.

Establish a uniform 99.999% SLA across both shipment rerouting and operational telemetry pipelines by deploying active-active multi-region infrastructure for all event ingestion layers.

Show answer & explanation

Answer: Define the SLI specifically as the ratio of shipment rerouting events completed within 5 seconds to total shipment rerouting events measured at the ingress gateway. Set a monthly SLO of 99.9% for this specific pipeline, and configure multi-window, multi-burn-rate alerts based on error budget consumption speed.

Answer

The correct strategy is to define the SLI specifically as the ratio of high-priority shipment rerouting events completed within 5 seconds to total rerouting events at the ingress gateway, establish a 99.9% monthly SLO for that target, and deploy multi-window multi-burn-rate alerts based on error budget depletion rates.

The solution correctly separates business-critical transactions (rerouting) from low-impact background data (telemetry). Defining the SLI as a ratio of good requests to total requests at the entry point captures the actual user/business experience. Utilizing multi-window, multi-burn-rate alerting on the error budget provides timely notifications when financial penalties are threatened, while preventing false alarms caused by transient spikes.

Step-by-Step Solution

Isolate high-impact business operations from non-critical background processes.

Identified that shipment rerouting events carry financial penalties when delayed past 5 seconds, while operational telemetry does not.

SLIs and SLOs must reflect actual business risk to prevent over-spending and false operational alarms.

Construct a valid Service Level Indicator (SLI).

Formulated the SLI as

\frac{\text{Successful events processed } \le 5\text{s}}{\text{Total valid events}}

for critical rerouting events.

An SLI is a quantifiable ratio of good events over total events measured at a valid boundary (ingress gateway).

Establish an Error Budget Burn-Rate Alerting strategy.

Applied multi-window multi-burn-rate alerting to track consumption of the 99.9% SLO error budget.

Burn-rate alerting ensures operations teams are paged only when error budget consumption rates threaten a business SLO breach.

Key Concept

Aligning SLIs/SLOs with Business Impact and Error Budget Alerting

Question 787Question →

Match each enterprise security and governance requirement to its corresponding Google Cloud data encryption and key management model.

Click a left item, then click its matching right item

Show answer & explanation

Answer

Matching pairings: FIPS 140-2 Level 3 automated key rotation maps to CMEK via Cloud HSM; Per-request raw key injection without persistence maps to CSEK; External key management via on-premises HSM endpoints maps to Cloud EKM; Zero-configuration automated encryption maps to Google-default Encryption.

Each encryption model aligns with specific key control boundaries: Google-default is zero-configuration baseline encryption; CMEK via Cloud HSM offers managed hardware protection (FIPS 140-2 Level 3) with Cloud KMS automated rotation; CSEK requires raw AES-256 keys passed per request without storage; Cloud EKM delegates key operations to external on-premises HSM endpoints.

Step-by-Step Solution

Analyze the requirement for automated rotation within a cloud-managed hardware security module.

CMEK backed by Cloud HSM fulfills FIPS 140-2 Level 3 requirements while allowing automated rotation via Cloud KMS.

Cloud HSM hosts key material natively within Google's cloud security boundary under hardware protection.

Evaluate the requirement for per-request raw key injection without persistence by Google.

CSEK requires raw 256-bit AES key material passed in API headers for transient in-memory operations.

CSEK ensures Google Cloud stores neither the root key nor key wrapping structures across API calls.

Identify the external key sovereignty pattern connecting GCP services to on-premises HSM APIs.

Cloud EKM establishes API connectivity between Google Cloud services and third-party external key managers.

Cloud EKM guarantees root keys reside physically outside Google Cloud infrastructure at all times.

Identify the baseline zero-overhead encryption model.

Google-default encryption transparently handles symmetric key generation and data encryption out of the box.

All Google Cloud storage and database services automatically encrypt data at rest by default.

Key Concept

Classification of GCP Data Encryption Models (Google-default, CMEK/Cloud HSM, CSEK, Cloud EKM)

Question 788Question →

A financial technology company operates a real-time payment authorization API. The business team identifies that authorization latencies exceeding $200\text{ ms}$ lead to increased checkout abandonment and direct revenue loss. The company has a contractual SLA with merchants guaranteeing $99.5\%$ monthly service availability. To align operational engineering metrics with these business goals while enabling safe release velocity, how should the Cloud Architect define the SLI and SLO strategy?

Define the SLI as the proportion of valid requests served in less than

200\text{ ms}

, set an internal SLO target of

99.9\%

for this SLI, and use the error budget to manage deployment risk.

Define the SLO as the actual measured ratio of fast requests, set the SLI target percentage to

99.9\%

, and configure deployment gates to block releases whenever the SLI drops below the external

99.5\%

SLA limit.

Define the SLI strictly as the ratio of HTTP 200 responses to total requests, set the SLO to

99.5\%

to match the merchant SLA, and issue immediate page alerts whenever average latency spikes over

200\text{ ms}

for 5 minutes.

Define the SLI by using backend database transaction query times from Cloud Load Balancer health checks, and set a target SLO of

99.99\%

to guarantee zero transaction latency issues.

Show answer & explanation

Answer: Define the SLI as the proportion of valid requests served in less than $200\text{ ms}$ , set an internal SLO target of $99.9\%$ for this SLI, and use the error budget to manage deployment risk.

Answer

The correct strategy is to define the SLI as the proportion of valid requests served under

200\text{ ms}

, establish an internal SLO target of

99.9\%

, and utilize the remaining error budget to govern deployment velocity.

The correct option correctly aligns the technical metric (SLI measuring requests under

200\text{ ms}

) with the specific business risk (cart abandonment). It sets an internal SLO (

99.9\%

) that is stricter than the external contractual SLA (

99.5\%

), giving the team a buffer to detect and resolve incidents before breaching SLA commitments. Furthermore, it uses the error budget to balance operational stability with feature deployments.

Step-by-Step Solution

Identify the critical user-centric metric tied to business impact.

Latency exceeding

200\text{ ms}

impacts revenue; therefore, the Service Level Indicator (SLI) must measure the proportion of requests completing within

200\text{ ms}

SLIs must reflect actual user experience directly linked to business outcomes.

Establish the Service Level Objective (SLO) target above the Service Level Agreement (SLA).

An internal SLO of

99.9\%

provides a

0.4\%

buffer above the external

99.5\%

SLA.

Setting internal SLOs tighter than external SLAs ensures teams receive early warnings and can remediate issues before violating commercial contracts.

Implement error budget governance for feature releases.

The difference between

100\%

and the

99.9\%

SLO target establishes an error budget (

0.1\%

) that dictates when releases can occur.

Error budgets align product development and operations by allowing rapid innovation when budget is available and prioritizing stability when budget is exhausted.

Key Concept

Aligning user-centric SLIs/SLOs with business revenue impact and establishing error budget buffers above SLAs.

Question 789Question →

A global smart grid utility provider hosts its real-time telemetry processing platform on Google Cloud. The primary production environment runs in us-central1, with us-east4 designated as the disaster recovery (DR) region. The enterprise requires a non-disruptive, periodic DR validation exercise to verify that Recovery Point Objective (RPO < 15 minutes) and Recovery Time Objective (RTO < 1 hour) are met. In what correct sequential order should the Cloud Architect execute the DR validation procedure?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct procedural order is: (1) Verify regional resource quotas in us-east4, (2) Provision Compute Engine capacity reservations in us-east4, (3) Create an isolated testing VPC and promote read-only database replicas, (4) Execute synthetic workload smoke tests to validate RPO and RTO metrics, and (5) Tear down test infrastructure and document validation metrics.

A structured disaster recovery validation procedure must follow a strict dependency order. First, cloud quota prerequisites must be verified and adjusted because quota increases require administrative processing time. Second, capacity reservations must be created in the target region to guarantee that hardware is available. Third, an isolated environment (VPC and database snapshots/replicas) must be established so that testing does not impact live operations. Fourth, synthetic tests are run within the sandbox to measure RPO/RTO against target objectives. Finally, test infrastructure is dismantled to prevent unnecessary spend, and audit logs are archived.

Step-by-Step Solution

Audit and request regional quota increases in the target DR region.

Ensures the project has sufficient quota headroom for compute, networking, and storage resources.

Quota adjustments may take time to process; attempting to provision resources without sufficient quota will fail.

Acquire Compute Engine capacity reservations in the DR region.

Guarantees compute capacity is reserved in target zones regardless of regional demand.

Without reservations, resource availability cannot be guaranteed during regional outages or large-scale DR drills.

Set up an isolated sandbox network and populate it with test data replicas/snapshots.

Creates a safe environment mirroring production state up to the target RPO.

Isolation prevents test traffic or data writes from corrupting primary production systems.

Run validation tests and measure RTO/RPO metrics.

Empirically verifies that failover automation meets recovery requirements.

Provides actual metrics on startup duration, database sync integrity, and service availability.

Decommission test resources and log exercise evidence.

Optimizes costs by removing temporary infrastructure and satisfies enterprise compliance requirements.

Temporary test resources should be cleaned up immediately following test completion.

Key Concept

Disaster Recovery Validation Sequence and Non-Disruptive Testing Procedures

Question 790Question →

An enterprise organization tracks the performance of its order fulfillment API hosted on Google Cloud. The engineering team has established a target goal of achieving $99.9\%$ successful API responses over a rolling 30-day window to align with customer experience goals. Which component specifically represents the quantifiable metric of actual, real-time successful responses divided by total requests?

Service Level Indicator (SLI)

Service Level Objective (SLO)

Service Level Agreement (SLA)

Error Budget Burn Rate

Show answer & explanation

Answer: Service Level Indicator (SLI)

Answer

Service Level Indicator (SLI)

A Service Level Indicator (SLI) is the specific metric that quantifies performance, such as the ratio of successful API requests to total API requests measured over time.

Step-by-Step Solution

Identify the role of the metric being requested

The scenario asks for the metric that calculates actual performance (successful requests divided by total requests).

Differentiating between measurement metrics and target threshold values is fundamental to Site Reliability Engineering (SRE).

Map the SRE terminology to the scenario elements

The target goal (

99.9\%

) is the SLO, while the calculated ratio of valid requests is the SLI.

An SLI measures compliance against the defined SLO.

Key Concept

Service Level Indicator (SLI) vs Service Level Objective (SLO) alignment

Question 791Question →

A university research institute needs to establish hybrid network connectivity between its primary on-premises facility and a Google Cloud Virtual Private Cloud (VPC) network. The institute is not located in a Google Cloud Interconnect colocation facility and requires a private network connection providing 4 Gbps of bandwidth that does not traverse the public internet. Additionally, the hybrid connectivity architecture must strictly satisfy Google Cloud's 99.99% availability SLA. Which network deployment strategy should the Cloud Architect implement to meet these requirements?

Provision a Partner Interconnect connection with redundant VLAN attachments deployed across two distinct service provider edge availability domains, using Cloud Router to establish dynamic BGP routing.

Provision a single 10 Gbps Dedicated Interconnect circuit connected directly to a Cloud Router within the target GCP region.

Provision an HA Cloud VPN gateway with two active IPsec tunnels configured with Cloud Router for dynamic routing over public internet links.

Configure VPC Network Peering directly between the on-premises edge router and the Google Cloud VPC network.

Show answer & explanation

Answer: Provision a Partner Interconnect connection with redundant VLAN attachments deployed across two distinct service provider edge availability domains, using Cloud Router to establish dynamic BGP routing.

Answer

Provisioning a Partner Interconnect connection with redundant VLAN attachments across two distinct edge availability domains, routed dynamically using Cloud Router, fulfills all requirements for private non-internet bandwidth, missing colocation presence, and 99.99% SLA availability.

The correct choice utilizes Partner Interconnect, which is explicitly designed for enterprise hybrid connections when the on-premises facility is not co-located at a Google Cloud Interconnect location. By ordering capacities from a supported service provider, selecting a total bandwidth of 4 Gbps, and deploying redundant VLAN attachments in two separate Edge Availability Domains with Cloud Router, the organization achieves private network isolation and satisfies Google Cloud's 99.99% SLA guidelines.

Step-by-Step Solution

Analyze facility constraints and connectivity medium requirements.

Since the institute is not co-located at a Google Cloud peering facility and cannot use the public internet, Dedicated Interconnect and HA Cloud VPN are ruled out.

Dedicated Interconnect requires a co-location presence in a Google facility, whereas HA Cloud VPN operates over public internet circuits.

Evaluate throughput and SLA topology requirements.

A 4 Gbps requirement exceeds standard VPN limits and demands Partner Interconnect. To achieve a 99.99% SLA, redundant VLAN attachments must be provisioned across two edge availability domains (EADs) with Cloud Router dynamic BGP routing.

Google Cloud's 99.99% SLA for Partner Interconnect specifically requires dual VLAN attachments across two distinct EADs connected to dual Cloud Routers.

Key Concept

Selecting and configuring Google Cloud Partner Interconnect for 99.99% HA topology without direct facility co-location.

Question 792Question →

An organization is provisioning infrastructure for a standard regional e-commerce application operating in a single Google Cloud region. The solution requires a relational database system optimized for cost and single-region transactional performance without global distribution overhead. Additionally, the DevOps team must provision a shared remote backend for Infrastructure as Code (Terraform) state management that prevents concurrent state modifications, protects against accidental deletion/corruption through state recovery, and adheres to key management governance using Cloud KMS. Which architectural provisioning strategy meets these requirements?

Provision a Cloud SQL instance for the database workload, and store the Terraform state in a Cloud Storage bucket configured with object versioning and Customer-Managed Encryption Keys (CMEK) via Cloud KMS.

Provision a multi-region Cloud Spanner instance for the database workload, and store the Terraform state in a regional Cloud Storage bucket without object versioning.

Provision a Cloud SQL instance for the database workload, and maintain the Terraform state file on a local persistent disk attached to a centralized deployment virtual machine.

Provision a Cloud SQL instance for the database workload, and configure a Cloud Storage bucket using Customer-Supplied Encryption Keys (CSEK) provided via raw key strings for the remote state backend.

Show answer & explanation

Answer: Provision a Cloud SQL instance for the database workload, and store the Terraform state in a Cloud Storage bucket configured with object versioning and Customer-Managed Encryption Keys (CMEK) via Cloud KMS.

Answer

The correct strategy provisions Cloud SQL, which accurately fits the single-region relational requirement without incurring unnecessary Cloud Spanner overhead. Storing the Terraform remote state in Cloud Storage with object versioning enabled ensures state backup recovery, native backend state locking, and encryption governed by Cloud KMS (CMEK).

Step-by-Step Solution

Select the appropriate database service based on regional scale requirements.

Cloud SQL is selected over Cloud Spanner because the application is confined to a single region and requires standard relational database capabilities without multi-region global replication overhead.

Cloud Spanner is designed for globally distributed, multi-region SQL workloads and adds unnecessary cost for single-region applications.

Design the Infrastructure as Code (Terraform) remote state storage strategy.

A Cloud Storage (GCS) bucket with object versioning enabled is chosen to store the remote Terraform state file.

GCS provides native state locking through Terraform backend integration and object versioning allows restoring past states in case of corruption.

Apply key governance controls to the storage backend.

Enforce CMEK using Cloud KMS keys on the GCS bucket.

CMEK integration satisfies internal key management governance while leveraging Cloud KMS for lifecycle and rotation management.

Key Concept

Provisioning Cloud SQL and configuring secure Cloud Storage remote state backends with CMEK and versioning for Terraform.

Question 793Question →

An enterprise analytics team is configuring a BigQuery data warehouse to store sensitive customer interaction logs. Corporate security policy dictates that data at rest must be encrypted using Customer-Managed Encryption Keys (CMEK) managed in Cloud KMS, with automated key rotation configured every 90 days. To ensure BigQuery can encrypt new table writes and perform background re-encryption following key rotations without violating the principle of least privilege, which configuration action must the security architect perform?

Grant the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) directly to the BigQuery Service Agent service account on the designated encryption key.

Grant the primitive Owner role (roles/owner) to the BigQuery Service Agent on the Cloud KMS KeyRing containing the encryption key.

Generate a raw 256-bit AES Customer-Supplied Encryption Key (CSEK) and pass key headers in every API call so Cloud KMS can perform automatic key rotation.

Define a VPC Service Controls perimeter around Cloud KMS and BigQuery, relying on perimeter ingress rules to grant service access without assigning IAM key permissions.

Show answer & explanation

Answer: Grant the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) directly to the BigQuery Service Agent service account on the designated encryption key.

Answer

Grant the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) to the BigQuery Service Agent service account on the Cloud KMS key.

Google Cloud services utilizing Customer-Managed Encryption Keys (CMEK) authenticate key access via service agents. Granting the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) to the BigQuery Service Agent enables BigQuery to encrypt new data and re-encrypt existing tables upon key rotation while adhering strictly to the principle of least privilege.

Step-by-Step Solution

Identify the service account required for Google Cloud service integrations using CMEK.

BigQuery uses its dedicated service agent account ([email protected]) to access KMS keys.

Service agents handle backend service interactions like table encryption and background key re-encryption.

Determine the minimal IAM role required for key usage.

The Cloud KMS CryptoKey Encrypter/Decrypter role provides encryption and decryption permissions needed for data protection without administrative rights.

Applying fine-grained predefined roles satisfies least privilege security policy requirements.

Key Concept

CMEK Service Agent Authorization and Cloud KMS IAM Roles

Question 794Question →

An organization is configuring a Virtual Private Cloud (VPC) network topology for internal compute resources. Compute Engine instances reside in a private subnet with no external IP addresses assigned. These instances require outbound access to download software updates from external internet repositories and must also interact with Google Cloud Storage APIs, while preventing any inbound internet traffic. Which configuration properly enables these requirements with minimal operational complexity?

Enable Private Google Access on the private subnet for Google Cloud API traffic, and configure Cloud Router with Cloud NAT for outbound internet egress.

Establish VPC Network Peering to a central transit VPC containing a Cloud NAT gateway, allowing instances in the private subnet to route internet traffic transitively through the peered network.

Provision a 10 Gbps Dedicated Interconnect connection to route all outbound internet traffic and Cloud Storage API calls through on-premises network firewalls.

Assign granular Identity and Access Management (IAM) roles to the service account without modifying subnet settings, allowing API and internet traffic through Google default routing.

Show answer & explanation

Answer: Enable Private Google Access on the private subnet for Google Cloud API traffic, and configure Cloud Router with Cloud NAT for outbound internet egress.

Answer

Enabling Private Google Access on the subnet alongside Cloud Router with Cloud NAT provides direct access to Google Cloud APIs and outbound internet connectivity for private instances without exposing them to inbound connections.

Enabling Private Google Access on a VPC subnet allows virtual machines without public IP addresses to securely reach Google Cloud APIs such as Cloud Storage via internal IP routing. Deploying Cloud NAT using Cloud Router enables controlled outbound internet access for software updates while preventing inbound internet connections from reaching the instances.

Step-by-Step Solution

Identify network connectivity requirements for virtual machines without external IP addresses.

Instances require access to both Google Cloud APIs (Cloud Storage) and public internet destinations (repository updates).

Without external IP addresses or NAT mechanisms, instances cannot initiate outbound TCP/UDP traffic to public destinations.

Select the appropriate native GCP VPC networking features.

Private Google Access routes traffic to Google APIs over internal Google networking routes. Cloud NAT provides managed Network Address Translation for public internet egress.

This combination keeps instances isolated from inbound internet access while satisfying both outbound connectivity needs efficiently.

Key Concept

Subnet Private Google Access and Cloud NAT configuration for private VPC egress.

Question 795Question →

A high-throughput electronic health record (EHR) analytics platform on Google Cloud operates primarily out of us-central1 with an automated failover target in us-east4. The application requires a Recovery Point Objective (RPO) of under 1 minute and a Recovery Time Objective (RTO) of under 15 minutes. During a scheduled disaster recovery (DR) simulation drill, database replication verified clean state synchronization, but application compute instances in us-east4 failed to scale up to accept incoming traffic due to regional vCPU quota exhaustion, leading to an RTO breach. Which procedure should the Cloud Architect mandate to resolve this issue and validate future DR readiness?

Provision Compute Engine capacity reservations in the target DR region for baseline workload requirements and include automated regional quota pre-checks in the DR validation runbook prior to initiating traffic failover.

Rely on standard Compute Engine Managed Instance Group autoscaling in us-east4 and configure Cloud Monitoring alerts to automatically submit urgent GCP quota increase requests at the moment failover is triggered.

Change the disaster recovery architecture from warm standby to a cold standby backup-and-restore model using nightly disk snapshots to eliminate compute quota usage until a disaster occurs.

Replace cross-region Cloud Load Balancing with HA VPN tunnels between the two regions to bypass GCP regional Compute Engine quota constraints during traffic failover.

Show answer & explanation

Answer: Provision Compute Engine capacity reservations in the target DR region for baseline workload requirements and include automated regional quota pre-checks in the DR validation runbook prior to initiating traffic failover.

Answer

Reserving capacity in the destination DR region guarantees compute availability when failover occurs. Combining this with automated pre-check validation steps ensures that quotas and capacity are verified before traffic failover is initiated, maintaining strict adherence to RPO and RTO bounds.

Step-by-Step Solution

Analyze the root cause of the DR failure

The failure was caused by Compute Engine regional vCPU quota exhaustion during autoscaling in the secondary region (us-east4).

Managed Instance Groups cannot launch instances beyond the project's regional vCPU quota limit regardless of autoscaling rules.

Identify the mechanism to guarantee compute availability in target region

Compute Engine Capacity Reservations guarantee instance availability in a specific zone/region.

Reservations ensure that capacity is allocated and ready during a DR event without risking stockouts or quota surprises.

Establish validation procedures for DR execution

Incorporate automated API-based quota checking in the DR runbook prior to traffic redirection.

Validating quotas as a pre-flight step in the DR procedure prevents partial failovers and guarantees compliance with the 15-minute RTO target.

Key Concept

Disaster Recovery Capacity Planning and Quota Validation Procedures

Question 796Question →

An enterprise global supply chain platform hosts its primary database on Cloud SQL for PostgreSQL in `us-east4` with a cross-region read replica in `us-central1` to support disaster recovery (DR). The business mandates a recovery point objective (RPO) of under 5 minutes and a recovery time objective (RTO) of under 1 hour. Your team is designing an annual non-disruptive DR validation procedure to verify failover readiness and application functionality in `us-central1`. Which procedure should you incorporate into the validation plan to meet these requirements without risking production data integrity?

Verify compute and storage resource quotas in `us-central1` ahead of the test, promote a isolated clone of the cross-region replica for validation testing, and test DNS traffic steering to the staging endpoint.

Initiate an unannounced live promotion of the primary cross-region database replica to master status in `us-central1` and immediately update production Cloud DNS A records to route active customer traffic.

Execute the DR validation script using standard regional default quotas in `us-central1` and promote the standby replica directly during the test window.

Migrate the database to a multi-region HA Cloud VPN setup prior to testing to ensure continuous cross-region transactional consistency without needing replica promotion.

Show answer & explanation

Answer: Verify compute and storage resource quotas in `us-central1` ahead of the test, promote a isolated clone of the cross-region replica for validation testing, and test DNS traffic steering to the staging endpoint.

Answer

Verify compute and storage resource quotas in the target disaster recovery region prior to testing, create and promote a isolated clone of the read replica to test application functionality, and update DNS pointing to non-production staging endpoints.

Safe DR validation procedures require pre-verifying regional resource quotas to guarantee capacity in the secondary region. Using a database clone of the cross-region read replica for validation allows full write testing and application verification without disrupting live replication or introducing production risk.

Step-by-Step Solution

Audit target region quotas

Ensure Compute Engine and storage resource quotas in `us-central1` are sufficient to host failover workloads before initiating validation.

Quota limits can silently fail spin-up tasks during a failover drill.

Clone cross-region read replica

Create a point-in-time database clone from the `us-central1` cross-region read replica.

Promoting a clone preserves the active replication stream between `us-east4` and `us-central1` so production remains unaffected during validation.

Validate application logic and networking

Connect test application instances in `us-central1` to the cloned database and verify end-to-end operational readiness.

Ensures RTO and RPO validation criteria are met without impacting active production data.

Key Concept

Disaster Recovery Validation and Failover Testing Procedures

Question 797Question →

An enterprise organization is running a production database on Compute Engine virtual machines with predictable, 24/7 continuous utilization expected for at least three years. The FinOps team needs to significantly reduce compute expenses without modifying the underlying infrastructure or compromising performance. Which cloud cost management strategy should the cloud architect recommend?

Purchase 3-year Committed Use Discounts (CUDs) for the required compute resource capacity.

Migrate the database to Spot VMs to maximize cost savings on instance hourly rates.

Migrate the database workload to Google Kubernetes Engine (GKE) Autopilot to optimize compute billing.

Re-architect the database to run on Cloud Spanner to leverage automatic serverless pricing.

Show answer & explanation

Answer: Purchase 3-year Committed Use Discounts (CUDs) for the required compute resource capacity.

Answer

Purchase 3-year Committed Use Discounts (CUDs) for the required compute resource capacity.

Purchasing Committed Use Discounts (CUDs) provides deep cost savings for predictable 24/7 compute workloads over a 3-year term without requiring any workload re-architecture or operational changes.

Step-by-Step Solution

Analyze the workload characteristics and operational requirements.

The workload is a stateful production database running continuously 24/7 with predictable utilization over a 3-year timeline.

Cost optimization strategies must match the availability and predictability requirements of the workload.

Evaluate Google Cloud cost reduction mechanisms suited for baseline capacity.

Committed Use Discounts (CUDs) provide deeply discounted rates for predictable baseline resources in exchange for a 1-year or 3-year commitment.

CUDs require no infrastructure migration or code changes while offering optimal financial savings for steady-state workloads.

Key Concept

Committed Use Discounts (CUDs) for steady-state workload cost optimization

Estimated Time:45s

Question 798Question →

A global telecommunications provider is analyzing its automated SDLC and CI/CD release workflow for provisioning multi-region Google Cloud infrastructure using Terraform and Cloud Build. The current pipeline executes builds using the default Cloud Build service account, which has been assigned the primitive `roles/editor` role at the project level. Additionally, concurrent pipeline runs occasionally overwrite each other's infrastructure state because state files are saved locally within the Cloud Build ephemeral build container. The architecture team needs to refactor the pipeline to enforce least-privilege security access and ensure state file integrity and concurrency control during automated deployments. Which strategy should the team implement?

Configure Cloud Build triggers to run as a dedicated user-managed service account assigned only the granular IAM roles required for target GCP resources, and configure Terraform to store state in a Cloud Storage backend with object versioning and state locking.

Assign the primitive `roles/owner` role to the default Cloud Build service account to prevent deployment authorization failures, and write state files to an attached persistent disk on the build worker.

Maintain Cloud Build execution under the default service account, but write Terraform state files directly to a standard Cloud Storage bucket without object versioning or backend state locking enabled.

Grant pipeline developers the `roles/iam.serviceAccountAdmin` role across the GCP organization resource hierarchy so Cloud Build can impersonate any service account, while caching state files in local build container memory.

Show answer & explanation

Answer: Configure Cloud Build triggers to run as a dedicated user-managed service account assigned only the granular IAM roles required for target GCP resources, and configure Terraform to store state in a Cloud Storage backend with object versioning and state locking.

Answer

The optimal solution requires replacing default project-level service accounts with a dedicated user-managed service account configured for Cloud Build triggers. This service account is assigned only the specific predefined or custom IAM roles necessary to provision the target infrastructure. Simultaneously, migrating Terraform state storage from ephemeral container storage to a Google Cloud Storage backend enables native distributed state locking and object versioning, preventing concurrent build runs from corrupting state data.

Step-by-Step Solution

Analyze CI/CD service account security requirement

Identified that using primitive roles (Editor/Owner) or default service accounts introduces security risks.

Default service accounts carry excessive broad permissions; custom service accounts allow granular, least-privilege IAM scoping.

Analyze Infrastructure as Code (IaC) state management requirement

Identified that local state storage causes concurrency conflicts and state loss in ephemeral build containers.

Terraform remote state stored in a Cloud Storage backend supports automatic state locking via Cloud Storage strongly consistent operations and preserves history via bucket versioning.

Synthesize the comprehensive architectural solution

Combined dedicated service account execution with GCS Terraform remote backend configuration.

Meets both least-privilege security policies and operational stability for automated SDLC deployment pipelines.

Key Concept

Least-privilege CI/CD service account configuration and remote IaC state management in Google Cloud

Question 799Question →

A global smart agriculture company is designing a telemetry processing platform on Google Cloud. The system consists of two workload components:

1. Component 1: A stateless HTTP REST microservice that processes telemetry reports from field sensors. Traffic is unpredictable, with long idle periods and sharp spikes. The component must scale down to zero when idle to minimize costs and require minimal operational overhead.
2. Component 2: A long-running, stateful backend application requiring custom host OS Linux kernel parameters (sysctl tuning) and direct raw TCP socket configuration for legacy device protocol handling.

Which TWO platform architectural decisions should you recommend to satisfy these requirements while adhering to Google Cloud best practices?

Select all that apply

Deploy Component 1 to Cloud Run services to leverage fully managed autoscaling down to zero instances during idle periods with minimal operational overhead.

Deploy Component 2 to Google Kubernetes Engine (GKE) standard node pools where host Linux kernel settings and node configurations can be customized.

Deploy Component 1 to a dedicated Google Kubernetes Engine (GKE) cluster with a fixed node pool to process the incoming HTTP REST telemetry.

Deploy Component 2 to Cloud Run Services with custom OS kernel parameter flags declared in the service deployment manifest.

Deploy Component 1 onto a fixed-size Compute Engine Managed Instance Group covered by 3-year Committed Use Discounts.

Show answer & explanation

Answer: Deploy Component 1 to Cloud Run services to leverage fully managed autoscaling down to zero instances during idle periods with minimal operational overhead.; Deploy Component 2 to Google Kubernetes Engine (GKE) standard node pools where host Linux kernel settings and node configurations can be customized.

Answer

Deploy Component 1 to Cloud Run services, and deploy Component 2 to Google Kubernetes Engine (GKE) standard node pools.

Cloud Run is the optimal platform for Component 1 because it natively supports stateless HTTP workloads, scales down to zero during idle periods to eliminate unnecessary costs, and minimizes operational management. For Component 2, GKE standard node pools provide the necessary access to configure host Linux kernel parameters and handle stateful networking requirements.

Step-by-Step Solution

Analyze Component 1 requirements

Component 1 is a stateless HTTP microservice with unpredictable traffic, long idle times, and a requirement to minimize management overhead and cost.

Cloud Run provides serverless container execution for stateless HTTP workloads, scaling down to zero when idle so no cost is incurred.

Analyze Component 2 requirements

Component 2 requires stateful capabilities, low-level OS/kernel parameter tuning (sysctl), and specialized raw TCP socket protocol access.

Cloud Run containers do not allow host OS kernel modifications. GKE standard nodes allow node-level OS tuning via DaemonSets or startup scripts while providing stateful workload orchestration.

Select the optimal GCP compute combination

Combine Cloud Run for Component 1 and GKE standard cluster for Component 2.

This combination avoids unnecessary cluster overhead for stateless microservices while fulfilling specialized host configuration needs for stateful workloads.

Key Concept

Selecting GCP Compute Platforms based on workload statefulness, operational overhead, autoscaling needs, and OS customization requirements

Question 800Question →

A global SaaS enterprise processes real-time financial reconciliations on Google Cloud. Business stakeholders have determined that transaction processing latencies exceeding 5 seconds lead to immediate contractual SLA financial penalties and customer churn. Conversely, brief total availability outages under 30 seconds are mitigated by client-side retries and carry minimal business impact. The Site Reliability Engineering (SRE) team must configure observability and reliability metrics that accurately reflect these business priorities.

Which TWO architectural and operational strategy decisions should the SRE team implement to align technical metrics with business impact? (Select 2 answers.)

Select all that apply

Define the Service Level Indicator (SLI) as the proportion of valid transaction requests completed within 5 seconds, establishing an SLO target that limits error budget consumption based on acceptable financial penalty exposure.

Configure operational alerting based on multi-window, multi-burn-rate error budget consumption rather than single-window static latency threshold breaches.

Define the primary Service Level Indicator (SLI) as the proportion of HTTP 200 OK response codes to total requests, establishing a 99.99% availability SLO target.

Configure static threshold alerts to trigger immediate PagerDuty incident escalation whenever latency exceeds 5 seconds during any single 1-minute monitoring window.

Show answer & explanation

Answer: Define the Service Level Indicator (SLI) as the proportion of valid transaction requests completed within 5 seconds, establishing an SLO target that limits error budget consumption based on acceptable financial penalty exposure.; Configure operational alerting based on multi-window, multi-burn-rate error budget consumption rather than single-window static latency threshold breaches.

Answer

The SRE team should define the SLI based on the proportion of requests completed within the 5-second business threshold and configure alerting based on multi-window error budget burn rates.

Aligning technical objectives with business outcomes requires measuring the exact condition that causes business loss (latencies exceeding 5 seconds) as the SLI and protecting the error budget using multi-window burn rate alerts to prevent unnecessary engineer paging on brief non-impacting events.

Step-by-Step Solution

Analyze business impact vs. technical metrics

Identified that latency > 5s drives financial penalties, whereas short downtime is acceptable due to client retries.

SLIs and SLOs must measure the user experience and business risk rather than default infrastructure availability metrics.

Select the appropriate SLI/SLO measurement

Define SLI as good requests (latency <= 5s) / total requests.

Directly tracks the latency threshold where business penalties occur.

Establish an effective alerting strategy

Implement multi-window burn-rate alerting.

Ensures engineers are paged only when error budget depletion risks breaching the SLO and causing financial impact.

Key Concept

Aligning SLIs, SLOs, and Error Budget Alerting with Business Penalties and User Impact

PreviousPage 40 / 80Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept