Free Google Cloud Professional Cloud Architect Practice Questions: Cloud Architecture Design
Practice 10 free Google Cloud Professional Cloud Architect questions on Cloud Architecture Design, with answers, explanations, and the IT Mastery next step.
Try the IT Mastery web app for a richer interactive practice experience with mixed sets, timed mocks, topic drills, explanations, and progress tracking.
Topic snapshot
| Field | Detail |
|---|---|
| Practice target | Google Cloud Professional Cloud Architect |
| Topic area | Designing and Planning a Cloud Solution Architecture |
| Blueprint weight | 25% |
| Page purpose | Focused sample questions before returning to mixed practice |
How to use this topic drill
Use this page to isolate Designing and Planning a Cloud Solution Architecture for Google Cloud Professional Cloud Architect. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 25% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
Sample questions
These are original IT Mastery practice questions aligned to this topic area. They are not official Google Cloud questions, copied live-exam content, or exam dumps. Use them to preview question style and explanation depth before continuing with topic drills, mixed sets, and timed mocks in IT Mastery.
Question 1
Topic: Designing and Planning a Cloud Solution Architecture
A retailer is comparing designs for a customer recommendation platform.
| Input | Detail |
|---|---|
| Product strategy | EU launch in 6 months; EU PII must stay in the EU; recommendations refresh within 5 minutes; support future AI experiments |
| Team preferences | Web team prefers GKE for all services; analytics team prefers one US data lake |
| Operating constraint | Four-person platform team |
Which recommendation best balances these constraints?
Options:
A. Ship a simple batch recommendation job now and defer governance and near-real-time updates.
B. Centralize all raw customer data in a US data lake to reduce analytics cost.
C. Use regional managed data and streaming services with EU PII boundaries, balancing compliance, launch speed, operations, and future AI extensibility.
D. Standardize on GKE for all services to maximize web team familiarity and control.
Best answer: C
Explanation: Product strategy requirements define the outcomes and guardrails the architecture must satisfy: market launch timing, EU data residency, freshness, and future AI evolution. Implementation preferences are negotiable ways to implement the solution, such as using GKE everywhere or centralizing data in one lake. A balanced recommendation should meet the nonnegotiable requirements first, then choose implementation patterns that reduce delivery and operational risk. Regional managed data and streaming services can keep EU PII in the EU, meet freshness needs, reduce the burden on a small platform team, and avoid locking the company out of later AI workflows. Team preferences can influence the design only where they do not conflict with those goals.
- GKE standardization follows a team preference, but it increases operational effort and does not justify ignoring managed-service fit.
- US centralization may simplify analytics cost and access, but it violates the EU PII residency requirement.
- Deferred governance may speed an initial build, but it misses required privacy controls and near-real-time freshness.
Question 2
Topic: Designing and Planning a Cloud Solution Architecture
A global logistics company is modernizing its data platform. It has these requirements:
- Order and settlement services need strongly consistent SQL transactions across several entities and active-active multi-region writes.
- Vehicle telemetry uses sparse, high-volume time-series data and needs low-latency lookups and range scans by vehicle and time.
- Analysts need ad hoc SQL and BI over years of history without affecting serving workloads.
- Session state can be rebuilt and needs sub-millisecond in-memory access.
Which Google Cloud data-service mapping best fits these requirements?
Options:
A. Spanner for orders; Bigtable for telemetry; BigQuery for analytics; Memorystore for sessions.
B. AlloyDB for orders; BigQuery for telemetry; Bigtable for analytics; Memorystore for sessions.
C. Firestore for orders; Bigtable for telemetry; BigQuery for analytics; AlloyDB for sessions.
D. Cloud SQL for orders; Firestore for telemetry; BigQuery for analytics; Memorystore for sessions.
Best answer: A
Explanation: The deciding concept is matching each access pattern to the right data service. Spanner fits the order and settlement workload because it provides relational SQL with strong consistency and horizontal, multi-region transactional scale. Bigtable fits sparse, high-throughput time-series or key/range lookup workloads such as telemetry by vehicle and time. BigQuery is the analytics engine for ad hoc SQL and BI over large historical datasets, separated from operational serving paths. Memorystore fits rebuildable session state that needs very low-latency in-memory access. Cloud SQL and AlloyDB are strong regional relational choices, but they are not the best fit for active-active global transactional writes at Spanner scale.
- Regional relational store misses the active-active global transaction requirement, and Firestore is not optimized for sparse high-volume telemetry scans.
- Swapped analytics stores fails because BigQuery is not a low-latency serving database and Bigtable is not an ad hoc BI SQL warehouse.
- Document orders fails because Firestore does not match the stated relational SQL transaction requirement, and AlloyDB is not an in-memory session cache.
Question 3
Topic: Designing and Planning a Cloud Solution Architecture
A financial services startup is designing a customer onboarding API on Google Cloud. Before choosing products, the architect must translate the requirements into architecture constraints. Which design implication is best supported by the exhibit?
Exhibit: Requirements excerpt
| Requirement | Visible fact |
|---|---|
| Availability | Monthly downtime must be under 22 minutes |
| Recovery | RTO 15 minutes; RPO 1 minute |
| Performance | p95 API latency under 250 ms for US and EU users |
| Security | EU PII must be stored and processed only in EU regions |
| Operations/cost | Small SRE team; avoid idle duplicate stacks where possible |
Options:
A. Centralize all PII in the lowest-cost US region.
B. Use managed multi-region serving with EU data locality and automated recovery.
C. Keep a fully idle cold standby stack in Europe.
D. Use one US region with nightly backups and manual recovery.
Best answer: B
Explanation: The exhibit turns business goals into architecture constraints: the API cannot be a single-region, manually restored system because the downtime, RTO, RPO, and latency targets require resilient serving locations close to US and EU users with automated recovery. The PII rule constrains data placement and processing for EU users to EU regions, so a global design must preserve data residency instead of centralizing all data. The small SRE team and cost note favor managed, autoscaling components and active use of deployed capacity where possible. The key takeaway is to derive constraints first, then choose services that satisfy them together.
- Single US region misses latency, recovery, and residency constraints; nightly backups cannot satisfy a 1-minute RPO.
- US PII centralization may simplify operations, but it conflicts with the explicit EU data residency requirement.
- Cold standby reduces active capacity, but manual failover and idle stacks conflict with the RTO and operations/cost notes.
Question 4
Topic: Designing and Planning a Cloud Solution Architecture
A retailer is replacing an on-premises pricing API. The architecture team must choose the first Google Cloud runtime without blocking likely future changes.
Exhibit: Requirements summary
| Area | Requirement |
|---|---|
| Packaging | OCI container; stateless HTTP API |
| Traffic/cost | Bursty; must scale to zero when idle |
| Operations | Minimal platform management; no Kubernetes expertise |
| Current needs | No sidecars, daemonsets, or node-level control |
| Evolution | Add event-driven workers and scheduled jobs later |
Which platform choice best fits the exhibit?
Options:
A. Deploy on Cloud Run first
B. Rebuild for App Engine standard
C. Use Compute Engine managed instance groups
D. Start with GKE Standard
Best answer: A
Explanation: The exhibit points to Cloud Run: a stateless HTTP container, bursty idle traffic, scale-to-zero cost behavior, and minimal platform management. Preserving future evolution does not mean choosing the most complex platform first. It means avoiding unnecessary lock-in while meeting today’s requirements. Cloud Run keeps the OCI container artifact, supports managed revisions and traffic splitting, and can extend to event-driven services or Cloud Run jobs for later asynchronous and scheduled workloads. If future requirements introduce Kubernetes APIs, service mesh, or node-level control, the containerized design gives a clearer migration path to GKE than a VM-specific or runtime-specific rebuild would.
- GKE first overweights hypothetical future control needs and adds operational complexity not justified by the exhibit.
- Managed instance groups provide VM portability but do not naturally satisfy scale-to-zero and minimal operations goals.
- App Engine standard is managed, but rebuilding for a runtime-specific platform reduces container portability without a visible need.
Question 5
Topic: Designing and Planning a Cloud Solution Architecture
An online pharmacy runs on Google Cloud in one primary region. It needs a DR plan before expansion. Budget does not allow active-active for every workload, and the team can maintain only a few tested failover runbooks.
| Workload | Recovery requirement |
|---|---|
| Orders DB on Cloud SQL for PostgreSQL | Transactionally consistent recovery, RPO <= 5 minutes, RTO <= 1 hour for regional outage |
| Prescription PDFs in Cloud Storage | Recover deleted or overwritten objects for 14 days, RTO <= 24 hours |
| BigQuery analytics | Rebuildable from source logs within 48 hours |
Which recommendation best balances recovery objectives, consistency, cost, and operational effort?
Options:
A. Daily exports and snapshots for all workloads in a backup project
B. Restore orders from BigQuery analytics and keep PDFs in one bucket
C. Tiered DR: Cloud SQL PITR plus cross-region replica; versioned PDFs; rebuild analytics
D. Active-active multi-region for the database, PDF store, and analytics
Best answer: C
Explanation: A tiered recovery design should match each workload to its business impact and recovery objective. The orders database is the system of record and has strict RPO/RTO targets, so it needs Cloud SQL automated backups with point-in-time recovery, a cross-region replica or equivalent regional DR pattern, replication-lag monitoring, and a tested promotion runbook. PDFs need protection from delete or overwrite events, so Cloud Storage Object Versioning with an appropriate retention/lifecycle policy fits the 14-day recovery need without the operational cost of active-active application DR. BigQuery analytics are derived and can be rebuilt, so protecting the source logs and rebuild process is usually enough. The key trade-off is spending availability and operations effort where data loss would be most damaging.
- Active-active everywhere overprotects PDFs and rebuildable analytics, adding cost and runbook complexity the team cannot support.
- Daily exports only miss the 5-minute database RPO and may require a manual restore longer than the 1-hour RTO.
- Analytics as recovery source fails because derived BigQuery tables are not the transactionally consistent system of record for orders.
Question 6
Topic: Designing and Planning a Cloud Solution Architecture
A company is choosing between two Google Cloud designs for a new partner ordering product. The architecture review must identify which gaps are business-critical before funding a proof of concept.
Exhibit: Stakeholder and design notes
| Item | Visible fact |
|---|---|
| Product strategy | Launch in 10 weeks; keep the current partner REST API contract. |
| Compliance | EU customer records must stay in EU locations. |
| Design A | Uses Cloud Run and managed services; meets launch/API/EU needs; does not reuse Helm charts. |
| Design B | Uses GKE and existing Helm charts; needs API contract changes; EU data plan unresolved. |
Which interpretation should guide the review?
Options:
A. Favor Design B because Helm reuse lowers delivery risk.
B. Favor Design A; Helm reuse is an implementation preference.
C. Treat both designs as equal until infrastructure cost is estimated.
D. Require both designs to use GKE before comparing them.
Best answer: B
Explanation: Architecture evaluation should separate product strategy requirements from implementation preferences. The launch timeline, partner API compatibility, and EU data-location constraint are explicit business or compliance requirements. A design that misses those requirements creates product and regulatory risk, even if it aligns with an engineering preference. Reusing Helm charts may reduce migration effort, but the exhibit does not make GKE or Helm a mandatory business outcome. The review should score each design against the visible requirements first, then consider implementation preferences as secondary trade-offs.
- Helm reuse may help delivery, but it does not override unresolved API and EU data-location gaps.
- Cost estimate first is tempting, but no cost requirement is provided and cost cannot make unmet requirements acceptable.
- Mandating GKE turns a preference into a constraint without a stated product or compliance reason.
Question 7
Topic: Designing and Planning a Cloud Solution Architecture
An architect is reviewing the first executive dashboard for a migrated order-entry platform on Google Cloud. Leadership approved the migration to increase completed orders, keep checkout responsive during peak events, control unit economics, and confirm sales-team adoption.
Exhibit: Current dashboard
| Business goal | Current metric shown |
|---|---|
| Increase completed orders | Cloud Run CPU utilization |
| Keep checkout responsive | Monthly uptime percentage |
| Control unit economics | Total Google Cloud invoice |
| Confirm sales-team adoption | Number of VMs decommissioned |
Which next action best aligns the dashboard with the business goals?
Options:
A. Treat utilization and VM retirement as sufficient success evidence.
B. Tune CPU alerts before defining business-facing metrics.
C. Report only monthly uptime and total invoice trends.
D. Add order-completion KPIs, checkout SLOs, unit-cost, and adoption metrics.
Best answer: D
Explanation: A business-aligned cloud dashboard should combine outcome KPIs, service-level measures, cost indicators, and adoption metrics. In this scenario, CPU utilization and VM decommissioning are useful operational or migration signals, but they do not prove that customers are completing more orders or that sales teams are using the new system. Better measures include completed-order rate or conversion, checkout latency and error-rate SLIs with explicit SLO targets, cost per completed order, and active usage by sales teams. Total invoice alone can rise with business growth, so unit cost is more meaningful. The key takeaway is to measure whether the architecture is delivering the intended business value, not only whether infrastructure is running.
- Infrastructure-only evidence fails because utilization and VM retirement do not show customer outcomes or user adoption.
- Invoice and uptime only misses unit economics and user experience quality during critical checkout flows.
- CPU alert tuning may improve operations, but it should follow metrics tied to business and service goals.
Question 8
Topic: Designing and Planning a Cloud Solution Architecture
A media company is migrating 500 TB of image and video assets used by a web catalog and batch AI tagging jobs. Assets are uploaded in bursts, read frequently for about 60 days, then rarely accessed but must be retained for 7 years. Applications access assets by object ID over HTTPS and do not need POSIX file locking. The team wants high durability, low operational effort, and lower long-term storage cost. Which storage recommendation best balances these constraints?
Options:
A. Use Filestore Enterprise with SSD capacity
B. Store the media binaries in BigQuery tables
C. Use Cloud Storage with retention and lifecycle rules
D. Use Persistent Disk behind managed NFS servers
Best answer: C
Explanation: The decisive pattern is large unstructured binary assets with object-ID access and aging value. Cloud Storage object storage is designed for durable objects, direct HTTPS access, bursty ingest, and integration with batch or AI pipelines without operating file servers. Lifecycle rules can keep recent objects in a higher-access class, then transition older objects to lower-cost classes as access drops; a retention policy can support the 7-year retention requirement. This balances latency for current assets, cost for cold assets, durability, and operational effort. File, block, or analytics storage may be useful around the workflow, but they are not the primary repository for this access pattern.
- Filestore is tempting when applications need shared POSIX semantics, but the stem says object-ID HTTPS access and no file locking.
- Persistent Disk with NFS optimizes control over block-backed file serving, but it adds server operations and weak lifecycle fit.
- BigQuery is useful for analytics metadata, but storing raw media binaries there optimizes queryability over object delivery and lifecycle cost.
Question 9
Topic: Designing and Planning a Cloud Solution Architecture
A company runs a customer payment API on Google Cloud. The architecture currently meets a contractual latency SLO, a 99.95% availability commitment, and PCI-related audit log retention. Monthly spend has increased, and leadership asks for a recommendation that lowers cost without changing these commitments. Which recommendation is the best balanced approach?
Options:
A. Use SLO data to right-size resources and commit steady baseline capacity
B. Move most serving capacity to Spot VMs immediately
C. Disable regional database HA and rely on nightly exports
D. Reduce audit log retention until storage spend meets target
Best answer: A
Explanation: Cost optimization is not the same as simple cost reduction. Optimization lowers spend while maintaining required business outcomes, such as latency SLOs, availability commitments, and compliance obligations. In this scenario, the right approach is to use observability and utilization data to identify waste, right-size overprovisioned resources, improve autoscaling, and use commitment-based discounts for predictable baseline capacity. These actions target inefficient spend without weakening the architecture’s contractual or regulatory requirements.
Pure cost-cutting changes, such as reducing redundancy or shortening required retention, may lower the bill but transfer risk to availability, recovery, or compliance. The key distinction is that optimization preserves the commitments that define solution success.
- Spot-first capacity may reduce compute cost, but it can undermine serving reliability if used for most latency-sensitive production capacity.
- Removing HA lowers database cost, but it directly conflicts with the availability commitment.
- Shorter retention reduces storage spend, but it violates the stated PCI-related audit log requirement.
Question 10
Topic: Designing and Planning a Cloud Solution Architecture
A company is reviewing private connectivity for an internal payment API hosted in a producer project behind an internal load balancer. Application teams in separate projects must consume the API without using public IP addresses. Based on the architecture note, what is the best next design action?
Exhibit: Architecture note
| Requirement | Detail |
|---|---|
| Consumer networks | Separate VPCs; some CIDR ranges overlap |
| Reachability | Only the payment API, not the producer VPC |
| Control | Producer approves which consumers connect |
| Operations | No plan to move teams into common subnets |
Options:
A. Enable Private Google Access in each subnet.
B. Publish the API through Private Service Connect.
C. Peer each consumer VPC with the producer VPC.
D. Attach the projects to a Shared VPC host.
Best answer: B
Explanation: Private Service Connect is the right pattern when consumers in separate VPCs or projects need private access to a specific producer service while preserving network isolation. In the exhibit, consumers are not being asked to deploy into centrally owned subnets, so Shared VPC does not match the operating model. VPC Network Peering would connect networks, requires compatible address space, and grants broader reachability than the requirement allows. Private Service Connect lets the producer publish the API as a service attachment and lets approved consumers create private endpoints in their own VPCs. The key design implication is service-level private access, not shared network administration.
- Shared VPC mismatch fails because the teams are not moving workloads into centrally managed host subnets.
- Peering overexposes fails because VPC peering requires compatible address space and provides network-to-network reachability.
- Private Google Access confusion fails because it is for accessing Google APIs and services from subnets, not publishing a custom producer API.
Continue in the web app
Use IT Mastery for interactive Google Cloud Professional Cloud Architect practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.
Try Google Cloud Professional Cloud Architect on Web