Professional-Cloud-Architect Practice Test Questions

Explanation
The goal is to allow third-party tools to access an API on behalf of dealerships. This is a classic scenario for delegated authorization, where a user (the dealership) grants a third-party application limited access to their data without sharing their credentials.

Let's evaluate each option:
Why A is Correct:
OAuth 2.0 is the industry-standard protocol for delegated authorization. It is specifically designed for this use case.
How it works:
A dealership (the resource owner) authenticates with a trusted identity provider (e.g., Google, or TerramEarth's own). The third-party tool (the client) then receives a limited-access token (an access token) that it can use to call the vehicle data API on the dealership's behalf.
Benefits:
It is secure, scalable, and widely adopted. Third-party developers are already familiar with integrating OAuth 2.0. It allows TerramEarth to control what data each third-party tool can access and for which dealership, without ever handling the dealership's login credentials.

Why B is Incorrect:
SAML 2.0 is a protocol for authentication (Single Sign-On), not for delegated API authorization. It is designed to allow a user to log in once and access multiple related web applications (like Google Apps or Salesforce). It is not suited for granting third-party applications programmatic access to a specific API. Using SAML for this would be complex, non-standard, and less secure than OAuth.

Why C is Incorrect:
Restricting access by source IP address is a weak and inflexible form of security.
It does not provide user or application-level authentication. Anyone within the partner's IP range would have access.
It is not scalable, as it requires managing IP whitelists for every third-party developer.
Crucially, it provides no delegation. It cannot distinguish between different dealerships using the same third-party tool. All dealership data accessible to that third party's IP would be exposed, violating data isolation.

Why D is Incorrect:
Creating secondary credentials (shared secrets or usernames/passwords) is a significant security anti-pattern.
Password Proliferation:
Dealers would have to manage multiple sets of credentials.
Lack of Revocation:
If a dealer wants to stop a third party's access, they must change their password, which would break all other integrated tools.
Security Risk:
The third-party tool must store these credentials, creating a massive security risk if they are compromised. It also gives the third party full access to the dealer's account, with no way to limit the scope of access (e.g., "read-only").
No Auditing:
It becomes difficult to audit which application performed a specific action.

Reference:
OAuth 2.0 Framework (RFC 6749):
The official specification defines OAuth 2.0 as "a protocol that allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity."
Google Cloud - API Security:
Google's own API management platforms (like Apigee and Cloud Endpoints) heavily leverage and recommend OAuth 2.0 for securing API access and enabling third-party ecosystems, which is exactly what TerramEarth needs to build.

Explanation:
TerramEarth’s goal is to improve reliability and minimize data transfer time over cellular connections, replacing an unreliable FTP process that restarts transfers from the beginning on failure. The best solution must:
Avoid FTP (due to its lack of resumable uploads and poor fault tolerance).
Use resumable, efficient, and reliable transfer protocols.
Minimize latency and cost by storing data close to the source.

✅ Why D is Correct
Regional buckets store data in a specific region, reducing latency and avoiding cross-region egress costs.
Google Cloud Storage supports resumable uploads over HTTP(S), which is ideal for unreliable networks like cellular — uploads can resume from the last byte on failure.
Direct API uploads remove the need for intermediate FTP servers or clusters.
ETL can run regionally or centrally, depending on architecture, but the data is reliably and efficiently collected.

Reference
📘 Resumable Uploads – Cloud Storage
📘 Storage Locations – Regional vs Multi-Regional

❌ Why Other Options Are Incorrect
A. One GKE cluster of FTP servers + Multi-Regional bucket
❌ FTP is unreliable and inefficient over cellular. Multi-regional storage is more expensive and unnecessary for this use case.

B. Multiple GKE clusters with FTP servers + Multi-Regional buckets
❌ Still relies on FTP, which is error-prone. Also, Multi-Regional buckets are costlier and not needed if data is region-specific.

C. Direct transfer to Multi-Regional buckets via HTTP(S)
❌ While HTTP(S) is good, Multi-Regional storage is more expensive and unnecessary. Regional buckets are more cost-effective and performant for localized data ingestion.

Summary:
To improve reliability and reduce transfer time:
Use HTTP(S) with resumable uploads to handle flaky cellular connections.
Store data in regional buckets close to the vehicle’s location.
Avoid FTP and Multi-Regional storage unless global availability is required.

Explanation:
The key requirements are:
Data Source: Unconnected trucks (no real-time cellular link).
Primary Goal: Store data in the cloud while reducing costs.
Future Use: The data will be used next year to train machine learning models.
This defines a "cold storage" or "batch upload" scenario where latency is irrelevant, but cost is the primary driver.

Let's evaluate each option:
Why D is Correct:
This is the most cost-effective solution that fits the operational constraints.
Hourly Snapshots:
For unconnected vehicles, real-time streaming is impossible. Batching data into hourly snapshots is the correct approach. Compressing it on the vehicle before any transfer saves on egress costs from the vehicle and storage costs in the cloud.
GCS Coldline Bucket:
Google Cloud Storage Coldline is specifically designed for data that is accessed once per year or less. It has the lowest storage cost among the GCS classes, with a slightly higher cost to access the data. Since the data will be used "next year" for a batch training job, this is the perfect use case for Coldline, minimizing the storage cost for the entire year.

Why A is Incorrect:
The process (hourly snapshots) is correct, but the storage class is wrong. GCS Nearline is for data accessed once per month or less. It is more expensive than Coldline. Using Nearline for data that will sit untouched for a year would incur unnecessary and higher storage costs, violating the primary goal of cost reduction.

Why B is Incorrect:
This option is fundamentally flawed for unconnected vehicles.
Real-time Push:
This is impossible without a continuous network connection.
BigQuery for Raw Storage:
BigQuery is an analytics data warehouse, not a cost-effective raw data lake. Storing raw, compressed telemetry data in BigQuery is significantly more expensive than storing it in Coldline and is not its intended use. You would load the data into BigQuery from GCS when you are ready to analyze it.

Why C is Incorrect:
This option also fails due to the connectivity constraint and cost.
Real-time Push:
Again, not possible for unconnected trucks.
Cloud Bigtable:
Bigtable is a low-latency, high-throughput NoSQL database. It is optimized for real-time access and serving, not for cheap long-term storage of historical data. Its storage costs are much higher than GCS Coldline, making it the most expensive and least suitable option for this batch-oriented, cost-saving requirement.

Reference
Google Cloud Storage Classes:
The official documentation clearly defines the use cases and cost structure for the different storage classes. Coldline is recommended for "data you plan to read or modify on average once per year or less. Ideal for... data archiving."
Data Lifecycle on Google Cloud:
Best practices dictate moving data to the most cost-effective storage tier based on its access patterns. For data that will not be used for 12 months, Coldline is the explicit recommendation.

Explanation:
TerramEarth’s shift to Google Cloud Platform (GCP) will significantly impact several legacy enterprise processes — especially those tied to infrastructure ownership, cost modeling, and scalability. The most affected areas are:

✅ Why B Is Correct
Capacity Planning: In the cloud, capacity is elastic and on-demand. Traditional long-term forecasting and hardware provisioning are replaced by autoscaling and usage-based planning.
TCO Calculations:
Total Cost of Ownership shifts from hardware, facilities, and maintenance to cloud service consumption. GCP introduces new cost models (e.g., sustained use discounts, per-second billing) that require updated financial analysis.
Opex/Capex Allocation:
Cloud adoption moves spending from capital expenditures (CapEx — buying servers) to operational expenditures (OpEx — paying for usage). This changes budgeting, procurement, and accounting processes.

Reference:
📘 Google Cloud Enterprise Best Practices
📘 Cloud Financial Management

❌ Why Other Options Are Incorrect
A. LAN changes LAN
architecture may evolve, but it’s not a primary enterprise process impacted by cloud migration. Most changes occur at the WAN or interconnect level.

C. Utilization measurement
While cloud platforms offer granular usage metrics, this is a tooling shift — not a fundamental enterprise process change.

D. Data center expansion
GCP adoption reduces the need for physical data center growth, but the process itself is not transformed — it’s simply deprecated.

Summary
TerramEarth’s move to GCP transforms how they plan, budget, and evaluate infrastructure:
Capacity planning becomes dynamic.
TCO modeling shifts to cloud economics.
OpEx/CapEx accounting realigns with service-based consumption.

Explanation:
The scenario describes a massive increase in data volume: 20 million records per second, totaling 40 TB per hour. This is a classic high-throughput, real-time data ingestion problem. The solution must be highly scalable, durable, and capable of decoupling the data producers (vehicles) from the consumers (data processing services).

Let's evaluate each option:
Why B is Correct:
Cloud Pub/Sub is the purpose-built service for this exact scenario.
Scalability:
Pub/Sub is designed to handle ingestion rates of millions of messages per second globally. It can automatically scale to accept the 20 million records/sec without any pre-provisioning.
Durability and Reliability:
It provides persistent, reliable message storage. If the downstream processing system fails or is slow, Pub/Sub will hold the messages until the system recovers, preventing data loss.
Decoupling:
It acts as a "shock absorber" for the data pipeline. Vehicles can publish data as fast as they generate it, independent of how fast the backend systems (like Dataflow or BigQuery) can process it. This isolation is critical for system stability.
Integration:
It seamlessly integrates with Google Cloud's data processing services like Dataflow, which can then subscribe to the topic, process the data, and load it into destinations like BigQuery, Cloud Storage, or Bigtable.

Why A is Incorrect:
Having millions of vehicles write directly to Google Cloud Storage (GCS) is not feasible or efficient.
Inefficient for Small Writes:
GCS is optimized for large objects, not for millions of tiny, individual 600-byte writes per second. The overhead of establishing a connection and creating an object for each record would be enormous and would quickly hit request rate limits.
Lack of Real-Time Processing:
Writing to GCS creates discrete files. This introduces latency, as a file must be closed before it can be processed. It does not support a real-time streaming pipeline.

Why C is Incorrect:
Streaming data directly to BigQuery is strongly discouraged and would fail at this scale.
Cost and Quotas:
BigQuery streaming inserts have quotas and costs associated with them. Ingesting 20 million records per second would massively exceed these quotas and be prohibitively expensive.
Improper Use Case:
BigQuery is an analytical warehouse, not a data ingestion bus. The correct pattern is to stream data into Pub/Sub, process it (e.g., with Dataflow), and then batch load the results into BigQuery for efficiency and cost-effectiveness.

Why D is Incorrect:
Continuing to use the existing FTP system is a recipe for catastrophic failure.
Lack of Scalability:
FTP servers are not designed to handle connections from 20 million concurrent clients or an ingestion rate of 40 TB/hour. The system would collapse under the load.
Management Overhead:
Managing a global fleet of FTP servers to handle this scale would be an operational nightmare, requiring constant scaling, patching, and monitoring, defeating the purpose of using managed cloud services.

Reference
Google Cloud - Pub/Sub Documentation:
Explicitly states that Pub/Sub is designed for "streaming analytics and data integration pipelines to ingest and distribute data." It is the foundational service for building event-driven systems and handling high-volume data streams.
Google Cloud Architecture Center - IoT Data Processing:
The standard reference architecture for IoT and telemetry data always uses Pub/Sub as the ingestion point, followed by Dataflow for processing, and then storage in BigQuery, Bigtable, or GCS.

Explanation:
Fully autonomous vehicles require zero-trust security, hardware-level integrity, and tamper-proof operations to ensure safety, reliability, and protection against cyber threats. In such architectures, every component — both hardware and software — must be verified and isolated to prevent compromise or unauthorized access.

Option A: Treat every microservice call between modules on the vehicle as untrusted. ✅
Why it’s correct:
This aligns with Zero Trust Architecture (ZTA) principles, where no communication is implicitly trusted, even between internal components.
In an autonomous vehicle, multiple microservices handle critical operations such as navigation, object detection, telemetry, and braking systems.
Treating inter-service calls as untrusted ensures that every request is authenticated, authorized, and encrypted — minimizing risks of lateral movement if one module is compromised.
Common methods include mutual TLS (mTLS) for secure communication, service identity verification, and API-level authorization.

Benefits:
Prevents internal spoofing or privilege escalation.
Ensures secure inter-module communication on the vehicle’s internal network.
Reduces the risk of compromised modules affecting critical systems.
Reference:
Google Cloud – BeyondCorp and Zero Trust Security Model
NIST SP 800-207 – Zero Trust Architecture
Option C: Use a Trusted Platform Module (TPM) and verify firmware and binaries on boot. ✅

Why it’s correct:
TPM (Trusted Platform Module) provides hardware-based security for verifying system integrity before the operating system starts.
During boot, Secure Boot uses TPM to verify digital signatures of firmware and binaries. If any unauthorized change is detected, the system halts or switches to a recovery state.
This prevents rootkits, firmware tampering, or unauthorized code execution, which is critical for safety-critical systems like autonomous vehicles.
TPM also helps store encryption keys securely and enable attestation — proving to a central control system that the vehicle’s software stack is authentic.

Benefits:
Ensures system integrity from the hardware up.
Protects against firmware attacks or malicious updates.
Supports cryptographic attestation for remote security checks.

Reference:
Trusted Computing Group – TPM Overview
Google Cloud IoT Security Best Practices

Why the other options are not correct:
B. Require IPv6 for connectivity to ensure a secure address space. ❌
IPv6 provides a larger address space, but it does not inherently enhance security.
Security depends on authentication, encryption, and access controls, not on the IP version.
Autonomous vehicles often use private network protocols or message buses (CAN, DDS, MQTT), which don’t benefit from IPv6 in terms of security.

D. Use a functional programming language to isolate code execution cycles. ❌
While functional programming promotes deterministic and side-effect-free code, it is not a core architectural security mechanism.
Language choice influences reliability and maintainability but does not ensure runtime or hardware-level security needed for autonomous operation.

E. Use multiple connectivity subsystems for redundancy. ❌
Redundant connectivity (e.g., LTE, 5G, satellite) improves availability, not security.
It may even expand the attack surface if additional interfaces are exposed.
The question explicitly focuses on strong security, not reliability or fault tolerance.

F. Enclose the vehicle's drive electronics in a Faraday cage to isolate chips. ❌
A Faraday cage protects against electromagnetic interference (EMI), not cybersecurity threats.
It offers physical protection, but does not secure firmware, APIs, or communication channels between modules.

References:
NIST SP 800-207 – Zero Trust Architecture
Google BeyondCorp: Zero Trust Security Model
Trusted Computing Group – TPM Specification Overview
Google Cloud IoT Security Best Practices

Explanation:
TerramEarth wants to build an API that meets business requirements while allowing the development team to focus on business logic, not infrastructure or custom frameworks. The goal is to deliver value quickly and securely — especially for dealers and partners, not the general public.

✅ Why A Is Correct
Google App Engine is a fully managed platform-as-a-service (PaaS) that abstracts away infrastructure concerns like scaling, patching, and load balancing.
Google Cloud Endpoints provides a lightweight, managed API gateway that supports authentication, monitoring, and quota enforcement — ideal for partner-facing APIs.
This combination allows developers to focus on business logic, not boilerplate or framework setup.
It’s optimized for internal/external partner APIs with secure access control via API keys or OAuth.

Reference
📘 Google Cloud Endpoints Overview
📘 App Engine Standard Environment

❌ Why Other Options Are Incorrect
B. JAX-RS Jersey on App Engine
❌ Adds unnecessary complexity. Requires manual framework setup and doesn’t leverage Cloud Endpoints for API management.

C. Swagger on App Engine
❌ Swagger (OpenAPI) is a spec, not a runtime framework. It helps define APIs but doesn’t replace the need for an API gateway or runtime management.

D. Django on Google Kubernetes Engine (GKE)
❌ GKE requires container orchestration and infrastructure management. Overkill for a simple API, and distracts from business logic.

E. Tomcat with Swagger on GKE
❌ Similar to D — adds operational overhead and complexity. Not ideal when the goal is rapid delivery and minimal infrastructure burden.

Summary
To build a secure, scalable API for dealers and partners with minimal overhead:
Use App Engine for managed hosting.
Use Cloud Endpoints for API management and security.

Explanation:
JencoMart’s application now serves traffic in Asia. To evaluate success against their business and technical goals, you need to track metrics that reflect:
User engagement (business goal)
System reliability and performance (technical goals)

✅ Why B Is Correct
Total visits measure user adoption and traffic volume — a key business indicator.
Error rates directly reflect system reliability and help identify issues like failed requests or service outages
. Latency affects user experience and is critical for performance benchmarking in the target region (Asia).
Together, these metrics provide a comprehensive view of how well the application is performing and being received in Asia.

Reference
📘 Google Cloud Monitoring Best Practices
📘 SRE Metrics – Google’s Four Golden Signals

❌ Why Other Options Are Incorrect
A. Latency difference between US and Asia
❌ Only compares performance across regions — doesn’t measure adoption or reliability in Asia.

C. Total visits and average latency for users in Asia
❌ Omits error rates, which are essential for tracking system health and diagnosing failures.

D. Number of character sets in the database
❌ Irrelevant to performance or business success. This is a low-level data detail, not a strategic metric.

Summary
To measure success for JencoMart’s Asia deployment:
Track total visits for engagement.
Monitor error rates for reliability.
Measure latency for performance.

Explanation:
JencoMart’s slow migration to Google Cloud Platform (GCP) suggests infrastructure-level bottlenecks that are limiting throughput. Based on the hybrid architecture shown (on-premises connected via Cloud VPN to GCP), the most likely culprits are:

✅ A. A single VPN tunnel, which limits throughput
Cloud VPN has bandwidth limitations (typically up to 3 Gbps per tunnel).
A single tunnel can become a bottleneck during large-scale data transfers.
Scaling requires multiple tunnels or Dedicated Interconnect.
Reference
📘 Cloud VPN Throughput Limits

✅ B. A tier of Google Cloud Storage that is not suited for this task
Using Coldline or Archive tiers for active migration workloads can slow access and increase latency.
Migration tasks require Standard or Nearline tiers optimized for frequent access and faster performance.
Reference
📘 GCS Storage Classes Comparison

✅ C. A copy command that is not suited to operate over long distances
Tools like cp or rsync over long-haul networks can be inefficient due to latency and lack of parallelism.
GCP recommends using gsutil -m or Transfer Appliance for large-scale transfers.
Reference
📘 gsutil Performance Tips

❌ Why Other Options Are Incorrect
D. Fewer VMs in GCP than on-premises machines
❌ VM count alone doesn’t determine throughput. GCP VMs can scale vertically or horizontally, and performance depends more on configuration than raw count.

E. A separate storage layer outside the VMs, which is not suited for this task
❌ GCP storage is designed to be decoupled from compute. Using Cloud Storage or Persistent Disks is standard practice and not inherently a bottleneck.

F. Complicated internet connectivity between on-premises and GCP
❌ The diagram shows a Cloud VPN, which bypasses public internet routing. Unless misconfigured, this isn’t a primary bottleneck.

Summary
To maximize migration throughput, JencoMart should:
Add multiple VPN tunnels or upgrade to Dedicated Interconnect.
Use Standard-tier Cloud Storage for active workloads.
Replace inefficient copy tools with gsutil -m or Transfer Appliance.

Explanation:
The scenario involves a hybrid environment during migration:
On-premises infrastructure needs temporary access to Cloud Datastore to upload data.
GCE VMs in Google Cloud will need permanent access to Cloud Datastore.
The key-management strategy must balance security and practicality for these two different environments.

Let's evaluate each option:
Why C is Correct:
This strategy uses the most secure option for each environment.
For On-premises:
Services running outside of Google Cloud cannot leverage the automatic, managed identity of a service account. The only way for them to authenticate as a service account is by using a provisioned service account key (a JSON key file). While these keys are long-lived credentials and pose a security risk, they are the necessary solution for this temporary, migration-specific need. The keys should be securely stored and deleted immediately after the migration is complete.
For GCE VMs:
This is the best practice. GCE VMs can be assigned a service account at creation. The platform automatically manages the authentication using short-lived credentials, and no key files are ever downloaded or stored on the VM. This is far more secure than using static keys and is the recommended approach for all workloads running within Google Cloud.

Why A is Incorrect:
This strategy is insecure because it uses service account keys for the GCE VMs. Since the VMs are inside Google Cloud, they should use the built-in, managed identity. Manually provisioning and managing keys on VMs is an anti-pattern that introduces an unnecessary and persistent security risk.

Why B is Incorrect:
This strategy is inconsistent and insecure.
Using a user account for the on-premises infrastructure is poor practice. User accounts are for human users, not for machine identities. They are tied to an individual, which breaks accountability, and their access can be revoked if the person leaves the company.
It also repeats the error of using service account keys for GCE VMs, which is insecure.

Why D is Incorrect:
This is an overly complex and unnecessary solution.
Deploying a custom authentication service adds significant development and operational overhead for a temporary migration task.
The on-premises systems would then authenticate to this custom service, which would in turn need credentials to access Datastore, creating an indirect and more fragile chain of trust. The straightforward and standard method is to use a service account key for the limited duration of the migration.

Reference:
Google Cloud - Service Account Best Practices:
The documentation explicitly advises: "Avoid using service account keys whenever possible." For workloads on GCE, GKE, etc., you should use the managed service account. It also states, "If you must use a service account key, ... rotate and delete the keys frequently."
Google Cloud - Authenticating from outside Google Cloud:
The documentation for scenarios like this specifies that for "workloads running on-premises or on another cloud provider," you must download a private key to use for authentication. This validates the need for a temporary key for the on-premises portion.