These questions cover data architecture and security — two domains that appear consistently in the GCP Professional Cloud Architect exam and test your ability to compose Google Cloud services into complete solutions.
Question 1
A company needs to build a data lake on GCP that stores raw data from multiple sources, enables batch processing with Apache Spark, and supports BI queries directly against the processed data. Which GCP architecture achieves this?
- A) Cloud Storage (raw data) → Dataproc (Spark processing) → BigQuery (BI queries)
- B) Cloud SQL (all data) → Dataflow (processing) → BigQuery
- C) Cloud Bigtable (all data) → Dataflow → Vertex AI
- D) Cloud Spanner (raw data) → Cloud Functions → BigQuery
Answer: A — Cloud Storage → Dataproc → BigQuery
This is the standard GCP data lake pattern:
- Cloud Storage: Object storage for raw data in any format (CSV, JSON, Parquet, Avro). Cost-effective at any scale and natively integrated with every GCP data service.
- Dataproc: Managed Hadoop/Spark service for batch processing. Reads from Cloud Storage, transforms data, writes output back to Storage or directly to BigQuery.
- BigQuery: Serverless analytical warehouse optimised for BI queries. Supports petabyte-scale queries with no infrastructure management.
Why the alternatives don't fit:
- Cloud SQL: Relational database, not designed for data lake volumes or schema-on-read
- Cloud Bigtable: Wide-column NoSQL for high-throughput time-series and operational workloads, not batch Spark
- Cloud Spanner: Globally distributed relational database — wrong tier for raw data lake storage
BigQuery also supports external tables pointing to Cloud Storage, allowing queries directly on raw data without loading — worth knowing for the exam.
</details>Question 2
A security team needs to detect unusual IAM activity, such as unexpected service account key creation and API calls from unfamiliar locations, across the entire GCP organisation. Which service provides this with minimal configuration?
- A) Cloud Monitoring with custom metrics for IAM API call rates
- B) Cloud Audit Logs exported to BigQuery for ad-hoc analysis
- C) Security Command Center with Event Threat Detection enabled
- D) Cloud Armor with adaptive protection enabled
Answer: C — Security Command Center with Event Threat Detection
Security Command Center (SCC) is GCP's centralised security management platform. Event Threat Detection (ETD) uses Google's threat intelligence and ML models to analyse Cloud Audit Logs in real time and surface findings for known attack patterns — including:
- Unusual service account key creation
- Logins from anomalous locations or Tor exit nodes
- Data exfiltration patterns
- Cryptomining activity
ETD works across the entire organisation with no custom query writing. Findings appear in SCC and can be routed to Pub/Sub for automated response via Cloud Functions.
Comparing the options:
| Option | Effort | Threat detection capability |
|---|---|---|
| Cloud Monitoring custom metrics | High — write each metric/alert manually | Only metrics you define |
| BigQuery audit log analysis | Very high — write all queries manually | Ad-hoc, not real-time |
| SCC Event Threat Detection | Low — enable and configure notifications | Built-in threat models, real-time |
| Cloud Armor | Medium | Layer 7 WAF for external traffic only |
Question 3
A development team uses Cloud Build for CI/CD. Merges to main should deploy automatically to staging, but production deployments require a manual approval step. Which Cloud Build configuration achieves this?
- A) Use two separate GCP projects and promote artifacts manually between them
- B) Configure a Cloud Build trigger for
mainwith a manual approval step before the production deploy step - C) Write a single
cloudbuild.yamlwith an environment variable that skips production in CI - D) Use Cloud Scheduler to delay production deployments by 24 hours automatically
Answer: B — Cloud Build trigger with a manual approval step
Cloud Build triggers support approval gates natively. You can configure a trigger so that when a build reaches a designated step, it pauses and requires a human approver to continue. The approver receives a notification and approves or rejects in the Cloud Build console or via the API.
The typical pipeline flow:
Push to main
→ Cloud Build trigger fires
→ Run tests (automated)
→ Deploy to staging (automated)
→ [APPROVAL GATE] — pause, notify approvers
→ Deploy to production (manual approval required)
Approvers can review the staging environment before approving. If rejected, the build fails without touching production.
Using separate GCP projects is valid for isolation but doesn't prevent deploying without approval — someone still has to manually run the production deployment. An environment variable workaround is fragile and can be accidentally bypassed.
</details>Key Takeaways
- GCP data lake pattern: Cloud Storage (raw) → Dataproc (Spark) → BigQuery (BI) — each layer is purpose-built
- Security Command Center with Event Threat Detection provides organisation-wide threat detection against Cloud Audit Logs with no custom queries
- Cloud Build approval gates pause pipelines at a specific step pending human review — production deployments need no workarounds