GCP-CLOUD-ARCHITECT Practice Questions

The core requirements are storing a private key in a dedicated hardware security module (HSM) and achieving FIPS 140-2 Level 3 compliance. Google Cloud HSM is the service designed specifically for these needs. It provides a fully managed, single-tenant HSM service that allows you to host encryption keys and perform cryptographic operations within a FIPS 140-2 Level 3 certified hardware appliance. This ensures that the key material never leaves the physical HSM, protecting it from threats like disk theft and meeting stringent compliance standards.

B. Cloud Identity and Access Management (IAM): IAM is a service for managing authorization and access control to Google Cloud resources. It does not provide cryptographic key storage or management capabilities.

C. Cloud Storage with CMEK: Customer-Managed Encryption Keys (CMEK) use Cloud KMS to protect data at rest in services like Cloud Storage. This option is incorrect because the primary need is to protect the database's private key, not data in Cloud Storage.

D. Cloud KMS (Software-backed key): While Cloud KMS is a key management service, its software-backed keys are validated at FIPS 140-2 Level 1. This does not meet the explicit requirement for Level 3 compliance or storage in a dedicated hardware module.

1. Google Cloud Documentation, "Cloud HSM overview": "Cloud HSM is a cloud-hosted hardware security module (HSM) service that allows you to host encryption keys and perform cryptographic operations in a cluster of FIPS 140-2 Level 3 certified HSMs." (Source: Google Cloud, Cloud HSM Documentation, Overview section, Paragraph 1).

2. Google Cloud Documentation, "Cloud Key Management Service documentation - Protection levels": This document details the different protection levels available in Cloud KMS. It specifies that HSM protection level keys are stored in a hardware security module and that "Cloud HSM provides FIPS 140-2 Level 3 validation." In contrast, it states that SOFTWARE protection level keys are "validated at FIPS 140-2 Level 1." (Source: Google Cloud, Cloud KMS Documentation, Concepts, Protection levels section).

3. Google Cloud Documentation, "Compliance offerings": This resource lists Google Cloud's compliance with various standards. Under FIPS 140-2, it explicitly lists Cloud HSM as "Validated at Level 3". (Source: Google Cloud, Security, Compliance Offerings, FIPS 140-2 section).

Cloud Dataflow is the most suitable service for this scenario. It is a fully managed service for executing Apache Beam pipelines, which are designed for both batch and stream processing. Dataflow excels at complex, stateful transformations such as windowing and aggregations on unbounded data streams. It provides a unified programming model and is optimized for low-latency, real-time processing, directly meeting the requirements for millisecond latency and complex operations on clickstream data from Pub/Sub. Its native integration with Pub/Sub as a source and various sinks makes it ideal for powering real-time operational dashboards.

A. BigQuery: BigQuery is an analytical data warehouse optimized for large-scale SQL queries, not a stream processing engine for complex, stateful transformations like windowing with millisecond latency.

B. Cloud Functions: Cloud Functions are designed for simple, stateless, event-driven computations. They are not suitable for complex stateful operations like windowing that require maintaining context across multiple events.

D. Dataproc Serverless for Spark: While Spark supports streaming, its core model is often micro-batching, which typically introduces higher latency than Dataflow's per-event processing model, making Dataflow a better fit for millisecond-latency requirements.

1. Google Cloud Documentation - Choosing a stream analytics option: This official guide compares streaming services. It positions Dataflow for "Complex event time-based processing (windowing, sessions, etc.)" and notes it offers the "Lowest latency" among the options, making it ideal for real-time use cases.

Source: Google Cloud Documentation, "Stream analytics options," section: "Comparison of stream analytics options."

2. Google Cloud Documentation - Dataflow Overview: "Dataflow is a managed service for executing a wide variety of data processing patterns... Use cases include: Streaming analytics. Use Dataflow for low-latency processing of real-time events..."

Source: Google Cloud Documentation, "Dataflow overview."

3. Apache Beam Programming Guide - Windowing: As Dataflow executes Beam pipelines, the Beam documentation is authoritative. The guide details the rich windowing semantics (tumbling, sliding, session windows) that are fundamental to the question's requirements.

Source: Apache Beam Documentation, "Programming Guide," section: "Windowing."

4. Google Cloud Solutions - Architecture for streaming IoT data: This reference architecture commonly shows the pattern of Pub/Sub for ingestion, Dataflow for real-time processing (transformation, windowing, aggregation), and then loading results into a serving layer for dashboards.

Source: Google Cloud Solutions, "Architecture for streaming IoT data on Google Cloud."

The gcloud app deploy command is used to deploy application source code to App Engine. To meet the requirement of testing a new version before it serves live traffic, two specific flags are necessary. The --version flag allows you to assign a unique identifier to the new deployment (e.g., v2). The --no-promote flag is crucial; it instructs App Engine to deploy the new version but not to automatically route any traffic to it. This allows you to access and test the new version directly via its version-specific URL (e.g., v2-dot-YOURPROJECTID.appspot.com) before manually migrating traffic.

A. gcloud app services update is used to modify existing services, primarily for migrating traffic between versions, not for deploying new application code.

B. gcloud app create is used only once per project to initialize the App Engine application and set its region; it does not deploy code versions.

C. gcloud compute is the command group for managing Compute Engine resources like virtual machines, not for deploying App Engine applications.

1. Google Cloud SDK Documentation, gcloud app deploy: The official documentation for the command explicitly defines the --no-promote flag: "Do not promote the deployed version to receive traffic. The default is to promote the version and stop the previous version." This directly supports the chosen answer.

Source: Google Cloud, gcloud app deploy reference, Flags section. https://cloud.google.com/sdk/gcloud/reference/app/deploy

2. Google Cloud App Engine Documentation, Splitting Traffic: This guide explains the deployment workflow and the use of the --no-promote flag for testing purposes. It states, "When you deploy a new version, you can choose to prevent traffic from being automatically routed to that new version by using the --no-promote flag."

Source: Google Cloud, App Engine Standard Environment, "Splitting Traffic", Deploying new versions section. https://cloud.google.com/appengine/docs/standard/python3/splitting-traffic

3. Google Cloud App Engine Documentation, Managing Versions: This document outlines how versions are managed and clarifies that deploying a new version without promoting it is a standard practice for testing before a full rollout.

Source: Google Cloud, App Engine, "How Versions are Managed". https://cloud.google.com/appengine/docs/standard/python3/versions

Vertex AI Extensions are specifically designed to connect large language models (LLMs) with external systems through APIs. They act as a secure bridge, enabling a generative AI model to retrieve real-time information from private data sources, such as a Salesforce SaaS application, or to trigger actions in other systems. This allows the model's responses to be grounded in the most current and relevant proprietary data, directly addressing the requirement to interact with an external API securely. The framework manages authentication, discovery, and execution of these external tools for the model.

A. Vertex AI Feature Store is a managed service for storing, serving, and managing machine learning features for model training and inference, not for real-time API integration.

B. Vertex AI Model Garden is a curated repository of pre-trained models. It provides access to models but does not provide the mechanism for connecting them to external APIs.

C. Cloud Data Loss Prevention is a service for discovering, classifying, and redacting sensitive data. It does not enable API calls from a model, although it could be used to protect data in transit.

1. Google Cloud Documentation, "Vertex AI Extensions overview": "Vertex AI Extensions let you connect large language models (LLMs) to external systems. By using extensions, you can enable your LLMs to retrieve real-time information and act on behalf of users... An extension is a connection to an external tool or API that an LLM can use." This document explicitly states the purpose of Extensions is to connect models to external APIs.

2. Google Cloud Documentation, "How Vertex AI Extensions work": "Vertex AI Extensions provide a framework for you to define tools that a model can use. These tools can be Google Cloud tools, such as BigQuery or Cloud Functions, or they can be external tools that are defined by using an OpenAPI specification." This confirms its role in integrating with external tools like a SaaS application.

3. Google Cloud Documentation, "Vertex AI Feature Store overview": "Vertex AI Feature Store is a managed service that lets you store, serve, manage, and share machine learning (ML) features at scale." This reference clarifies that the Feature Store's purpose is managing ML features, not API connectivity for generative models.

4. Google Cloud Documentation, "Explore pre-trained models in Vertex AI Model Garden": "Vertex AI Model Garden is a platform that helps you discover, test, customize, and deploy Google-proprietary and select open source models." This source defines the Model Garden as a repository, distinct from an integration tool.

This architecture provides a comprehensive solution for a highly available, multi-region application. The Global External HTTP(S) Load Balancer uses a single global IP address to route users to the closest healthy Regional Managed Instance Group, minimizing latency and providing seamless failover if one region becomes unavailable. The use of Regional Managed Instance Groups ensures the stateless front-end is resilient to zonal failures within each region. For the database, Cloud Spanner is the ideal choice as it is a globally distributed, strongly consistent database designed for multi-region fault tolerance and high availability (99.999% SLA). Its PostgreSQL interface facilitates the migration from the existing PostgreSQL backend while meeting the stringent availability requirements.

A. Cloud Storage is an object store, not a relational database system. It cannot replace the functionality of a PostgreSQL backend for a transactional e-commerce application.

B. This option describes a single-region architecture. A regional GKE cluster, Regional Persistent Disk, and Cloud SQL are all confined to one region and do not provide regional fault tolerance.

D. Cloud SQL for PostgreSQL is a regional service. While it supports cross-region read replicas, failover is a manual process and does not provide the seamless, active multi-region capability required. Cloud Spanner is purpose-built for this scenario.

1. Global Load Balancing and MIGs: Google Cloud Documentation, "External HTTP(S) Load Balancing overview," describes how the global load balancer can direct traffic to backends (like Managed Instance Groups) in the region closest to the user. It also details the automatic failover capabilities. (See section: "How External HTTP(S) Load Balancing works").

2. Cloud Spanner for Multi-Region Databases: Google Cloud Documentation, "Spanner instances," explains that multi-region instances "replicate data in multiple regions... and can tolerate the loss of an entire region." The documentation on the "PostgreSQL interface" confirms its suitability for migrating from PostgreSQL.

3. Cloud SQL Regional Nature: Google Cloud Documentation, "Cloud SQL high availability configuration," states, "The HA configuration provides high availability for a Cloud SQL instance within a single region." This highlights its limitation for multi-region fault tolerance compared to Cloud Spanner.

4. Architectural Best Practices: Google Cloud Architecture Framework, "Reliability pillar," emphasizes designing for resilience across zones and regions. The document states, "For global applications with the highest availability requirements (for example, 99.999%), we recommend a multi-region architecture... For relational database workloads, we recommend that you use Cloud Spanner." (See section: "Disaster recovery patterns").

The core requirement is to establish consistent policy management and security across a multi-cloud and on-premises Kubernetes environment (GKE, EKS, on-premises). Anthos is Google Cloud's platform designed specifically for this purpose. It provides a unified control plane to manage Kubernetes clusters regardless of their location. Using Anthos, Cymbal can apply consistent configurations, policies (with Anthos Config Management), and security controls (with Anthos Service Mesh and Policy Controller) across their entire fleet of GKE, on-premises, and EKS clusters. Migrating workloads (A) is a drastic alternative to management, while options C and D address entirely different technical problems (AI inference and data replication, respectively) and do not solve the central challenge of unified cluster management.

1. Google Cloud Documentation, "Anthos technical overview": In the "What is Anthos?" section, it states, "Anthos is a managed application platform that extends Google Cloud services and engineering practices to your environments so you can modernize apps faster and establish operational consistency across them... You can run Anthos on Google Cloud, on-premises, at the edge, and on other public clouds such as AWS and Azure." This confirms its capability to manage multi-cloud environments.

2. Google Cloud Documentation, "Attach Amazon EKS clusters to Anthos": The introductory paragraph states, "Attaching your Amazon Elastic Kubernetes Service (EKS) clusters to Google Cloud enables you to manage and operate your EKS clusters together with your GKE and other Anthos clusters from the Google Cloud console." This directly addresses the scenario of managing EKS clusters.

3. Google Cloud Documentation, "Anthos Config Management overview": This document explains, "Anthos Config Management lets you deploy and monitor programmatic policies for your clusters on-premises, on Google Cloud, and in multi-cloud environments." This directly supports the requirement for "consistent policy management."

4. Google Cloud Documentation, "Anthos Service Mesh overview": This page describes how Anthos Service Mesh "lets you manage, observe, and secure services running on your clusters... without changing your application code." This supports the requirement for consistent security across environments.

This solution correctly implements the principle of least privilege and separation of duties within a Shared VPC architecture. Granting developers the Compute Network User (roles/compute.networkUser) role on the Host project is the standard practice. This role provides the necessary permissions to use the shared network resources (e.g., create VM instances that connect to shared subnets) without granting any administrative privileges to modify the VPC network or its firewall rules. Concurrently, granting the Project Owner role within their own service projects gives them the required autonomy to manage their applications and resources.

A. Organization Policies are used to enforce constraints on resource configurations (e.g., disabling public IPs), not to grant or deny permissions to specific IAM principals like a user group.

B. VPC Peering is a different networking architecture. It would decentralize network control, which contradicts the goal of having a centrally managed network in a Host project.

C. Granting the Project Editor role on the Host project is overly permissive. It includes permissions to modify networks and firewalls, directly violating the core security requirement.

1. Google Cloud Documentation, "Shared VPC", Section: "Administrators and users of Shared VPC": This document explicitly outlines the IAM roles for Shared VPC. It states, "Service Project Admins... need the compute.networkUser role... This role allows them to use the Shared VPC network but does not grant them any permission to make administrative changes to the Shared VPC network." This directly supports the use of the Compute Network User role for developers on the Host project as described in option D.

2. Google Cloud Documentation, "IAM basic and predefined roles reference", Section: "Compute Engine roles": The description for the roles/compute.networkUser role confirms it grants permissions to use networks and subnets but not to create or modify them. Conversely, the documentation for the roles/editor primitive role shows it contains broad permissions, including compute.networks.update, which validates why option C is incorrect.

3. Google Cloud Documentation, "Introduction to the Organization Policy Service", Section: "Overview": This page clarifies the distinction between IAM and Organization Policies. It states, "IAM focuses on who, and lets the administrator authorize who can take action on specific resources based on user permissions. Organization Policy focuses on what, and lets the administrator set restrictions on specific resources to determine how they can be configured." This confirms that an Organization Policy (Option A) is the incorrect tool for this scenario.

Cloud Spanner with a multi-region configuration is the only solution that meets all the requirements. It is a globally distributed, relational database service designed for active-active architectures that require horizontal scalability and strong transactional consistency across regions. Its ability to handle synchronous replication with external consistency ensures that data written to any region is immediately available and consistent in all other configured regions. This directly addresses the need for concurrent writes with low latency and high consistency for a global, mission-critical application.

A. Cloud Firestore with eventual consistency: This option is incorrect because its multi-region replication model is eventually consistent, which violates the strict requirement for high consistency for concurrent writes.

C. Cloud SQL Read Replica with asynchronous replication: This creates an active-passive architecture for writes. Only the primary instance can handle write operations, failing the active-active requirement. Asynchronous replication also introduces data lag.

D. BigQuery: BigQuery is an enterprise data warehouse designed for large-scale analytics (OLAP), not a transactional database (OLTP) suitable for low-latency application reads and writes.

1. Google Cloud Documentation - Cloud Spanner, "Multi-region configurations": "Multi-region configurations enable you to replicate your database's data in multiple regions... This enables you to have low-latency reads and writes from multiple locations across the globe... Spanner maintains synchronous replication and strong consistency in multi-region configurations."

Source: Google Cloud Documentation, Cloud Spanner, "Instances", Section: "Multi-region configurations".

2. Google Cloud Documentation - Cloud Spanner, "Transactions": "Cloud Spanner offers external consistency, which is a stronger guarantee than 'strong consistency'... External consistency guarantees that Spanner executes transactions in a way that is indistinguishable from a system in which the transactions are executed serially."

Source: Google Cloud Documentation, Cloud Spanner, "Transactions", Section: "Consistency".

3. Google Cloud Documentation - Cloud Firestore, "Choose a database: Cloud Firestore or Cloud SQL": "Cloud Firestore has an eventually consistent storage layer... This means that a read operation might not see the result of a very recent write operation."

Source: Google Cloud Documentation, Cloud Firestore, "Documentation", Section: "Choose a database".

4. Google Cloud Documentation - Cloud SQL, "Replication options": "The primary instance handles all write operations. The read replica handles only read requests." This confirms the active-passive model for writes.

Source: Google Cloud Documentation, Cloud SQL for MySQL, "Replication", Section: "Replication options".

5. Corbett, J. C., et al. (2012). "Spanner: Google's Globally-Distributed Database." In Proceedings of the 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI '12). This foundational, peer-reviewed paper describes Spanner's architecture, stating, "Spanner is designed to support global, externally consistent transactions." (Section 1: Introduction).

DOI: Available through ACM Digital Library or USENIX archives. A public version is often hosted on Google Research publications.

This architecture represents a canonical Google Cloud pattern for high-throughput IoT or telemetry data. Pub/Sub provides a scalable, durable ingestion point for high-velocity streams. Dataflow is used for stream processing, such as data cleansing, transformation, or enrichment.

Cloud Bigtable is the optimal choice for storage due to its extremely low-latency writes and its design for handling massive time-series datasets. The specified row key schema (VehicleID + reversedtimestamp) is a critical best practice. It prevents hotspotting by distributing writes across the cluster, and it co-locates all data for a single vehicle, making queries for recent maintenance data highly efficient.

A. BigQuery is an analytical data warehouse optimized for large-scale queries, not the low-latency writes and point-reads required for real-time monitoring of individual vehicles.

C. This option is incorrect. BigQuery Omni is for multi-cloud analytics, not data ingestion. GKE and EKS are compute platforms, not the primary storage solution for this use case.

D. Using a leading, monotonically increasing timestamp in a Bigtable row key is a severe anti-pattern. It would cause all writes to target a single node, creating a massive hotspot and failing to scale.

1. Google Cloud Documentation, "Schema design for time series data": This document explicitly recommends the pattern used in the correct answer. It states, "To make it easy to retrieve the most recent records, use a reversed timestamp... A good row key for this use case might be [vehicleid]#[reversedtimestamp]." It also warns against the anti-pattern in option D: "Using an unmodified timestamp as the row key is not recommended."

2. Google Cloud Architecture Center, "Architecture for connecting IoT devices to Google Cloud": This reference architecture shows a common pattern for real-time data paths: IoT Device -> Pub/Sub -> Dataflow -> Cloud Bigtable. This validates the selection of services for the ingestion, processing, and low-latency storage of telemetry data.

3. Google Cloud Documentation, "About Cloud Bigtable": Under the section "What Cloud Bigtable is good for," it lists "Time series data" and "IoT data" as primary use cases. It highlights its strength in handling "high write throughput" and "low-latency serving," which directly contrasts with the capabilities of an analytical warehouse like BigQuery (Option A) for this specific workload.

The core requirement is to provide outbound internet access to a Compute Engine VM that has no external IP address. Cloud NAT is a managed Google Cloud service designed specifically for this purpose. It allows instances in a private subnet to initiate outbound connections to the internet for tasks like downloading updates or patches, while preventing unsolicited inbound connections. It is the most direct, secure, and minimal cloud-native component to fulfill this requirement without exposing the VM to the internet.

A. A Cloud VPN connection to an on-premises NAT gateway.

This is a complex solution that creates an unnecessary dependency on on-premises infrastructure. While technically feasible, it is not the minimum or most efficient cloud-native component for this task.

B. A VPC Service Control perimeter.

VPC Service Controls are a security feature used to prevent data exfiltration from Google-managed services (like BigQuery or Cloud Storage), not to provide general internet egress for Compute Engine VMs.

C. Private Google Access enabled on the subnet.

Private Google Access allows private VMs to access the external IPs of Google APIs and services only (e.g., Cloud Storage, Container Registry). It does not grant access to the general internet for third-party patch repositories.

1. Google Cloud Documentation - Cloud NAT overview: "Cloud NAT (network address translation) lets certain resources without external IP addresses create outbound connections to the internet. Cloud NAT provides outbound connectivity for the following resources: Compute Engine virtual machine (VM) instances without external IP addresses..." This document explicitly states the purpose of Cloud NAT, which directly matches the question's scenario.

2. Google Cloud Documentation - Configure Private Google Access: "Private Google Access lets VM instances that only have internal IP addresses reach the external IP addresses of Google APIs and services." This reference clarifies that Private Google Access is limited to Google services and is not a solution for general internet access.

3. Google Cloud Documentation - VPC Service Controls overview: "VPC Service Controls helps you mitigate the risk of data exfiltration from your Google Cloud services such as Cloud Storage and BigQuery." This confirms that VPC Service Controls is a data security feature, irrelevant to providing network connectivity.

4. Google Cloud Documentation - Cloud VPN overview: "Cloud VPN securely connects your peer network to your Virtual Private Cloud (VPC) network through an IPsec VPN connection." This shows that Cloud VPN's primary purpose is to connect networks, making it an indirect and overly complex solution for the stated problem.