Google Cloud Professional Cloud Architect: Network, Compute, and Storage Choices

Google’s current PCA blueprint explicitly asks candidates to design network, storage, and compute resources and then manage those resources in production. The point is not to memorize every SKU. It is to select a platform that fits traffic patterns, control requirements, data behavior, latency, resilience, and the team’s operating model. That is why the Google Cloud Professional Cloud Architect should be studied alongside architectural decision making rather than as a list of products.

These choices are coupled. A serverless compute decision affects networking and connection management. A database placement decision changes latency and disaster-recovery options. Shared VPC or private service access can shape how teams deploy applications. The architect should therefore reason across the stack instead of optimizing each layer in isolation.

Begin with a workload profile

Before choosing a service, describe the workload in operational terms: request pattern, concurrency, CPU and memory shape, startup tolerance, statefulness, runtime requirements, deployment frequency, locality, and failure behavior. The same business function can fit very different compute platforms depending on those details.

A predictable legacy application with licensed software may favor Compute Engine. A containerized service estate that needs Kubernetes APIs and platform extensibility may justify GKE. A stateless HTTP workload with uneven traffic may benefit from Cloud Run. The exam tests whether the platform follows the workload instead of whether the candidate has a favorite service.

Workload profiling should use measured evidence when possible. CPU averages can hide short bursts, and daily traffic totals can hide sharp concurrency peaks. Include percentile latency, queue depth, memory pressure, startup time, request duration, and seasonal patterns so the chosen compute platform is sized for the behavior users actually experience.

Design VPC boundaries around ownership and trust

Network boundaries should make administration and security clearer. Projects, Shared VPC, subnets, firewall policies, and routing domains can separate teams and environments without forcing every application into its own isolated island. The design should also account for centralized services such as DNS, logging, security inspection, and hybrid connectivity.

IP planning remains foundational. The CIDR addressing is useful background because poor address allocation can block peering, hybrid connectivity, or future regional expansion. Address space should be treated as a long-lived architecture resource rather than something assigned casually during the first deployment.

Project and subnet design also affects quota and operational delegation. A clean boundary can let one team manage application resources without gaining authority over shared networking. That separation becomes valuable in larger organizations where central network teams own connectivity while product teams control deployment speed.

Choose public, private, and service connectivity deliberately

Not every managed service requires a public path. Private Service Connect, private IP options, internal load balancing, Identity-Aware Proxy, and service networking patterns can reduce exposure while preserving manageable access. The correct choice depends on which consumer needs the service and whether connectivity should be transitive.

Architects should avoid equating “private” with “secure” or “public” with “insecure.” A well-authenticated public endpoint can be safer than a broadly reachable private network. The right design combines network reachability with identity, authorization, encryption, logging, and application controls.

Private connectivity is especially useful when managed services must be consumed from many projects without exposing broad network paths. Still, endpoint design should be paired with authorization. Restricting reachability does not decide which caller is allowed to perform a sensitive operation once the connection exists.

Map compute control to operational maturity

Compute Engine, GKE, Cloud Run, and functions represent different layers of abstraction. The contrast is similar to the broader distinction in the containers versus hypervisors: more control also means more responsibility. VM-based platforms expose host configuration and patching choices; managed container platforms and serverless products shift more of that work to Google.

Choose the highest abstraction that still satisfies runtime, networking, security, performance, and portability constraints. Reducing undifferentiated operations can improve reliability because fewer platform tasks depend on manual execution. But forcing an incompatible workload into serverless can create new limitations and costly workarounds.

Platform choice should include deployment frequency and rollback needs. A service updated many times per day benefits from immutable images, automated rollout, and rapid rollback. A rarely changed licensed appliance may prioritize stable VM images and maintenance windows instead. The same compute product can be right or wrong depending on how change enters production.

Select storage by semantics, not capacity alone

Object storage, file storage, block storage, and database services solve different problems. Capacity is only one variable. Consider access protocol, metadata, transaction needs, consistency, throughput, latency, lifecycle, replication, and sharing behavior. The Google Cloud storage capacity and scalability adds useful context, but architecture questions usually turn on semantics rather than maximum size.

A media archive and a database data disk may both hold terabytes, yet their correct storage services differ because applications interact with them differently. Designing from access patterns prevents a common mistake: picking the biggest or cheapest storage product and then forcing the application to adapt.

Storage cost is also shaped by request patterns, retrieval frequency, replication, and network transfer. Archival tiers save money only when retrieval behavior matches their assumptions. Frequent restores or cross-region reads can erase apparent savings, so scenario questions should be evaluated using the full access pattern.

Separate operational data from analytical data

Transactional systems prioritize predictable reads and writes, integrity, and application-facing latency. Analytical platforms often optimize scans, aggregation, historical retention, and large-scale transformation. The architect should decide where authoritative operational data lives and how analytical copies are produced, governed, and refreshed.

This separation can reduce contention and make lifecycle policy easier to manage. It also creates a data movement problem that needs explicit design: batch versus streaming transfer, schema evolution, replay behavior, encryption, and observability. The best architecture acknowledges that the pipeline is part of the system.

Analytical copies need clear ownership of freshness. A dashboard that can tolerate hourly data should not force an expensive low-latency streaming architecture. Conversely, fraud detection or operational monitoring may need near-real-time updates. The service objective for data freshness should drive the pipeline.

Design for performance with evidence

Latency and throughput problems are often caused by placement, network path, storage behavior, or data access patterns rather than by insufficient CPU alone. Before scaling up, identify which resource is actually constrained. A larger VM does not fix a cross-region database call, and a faster storage tier does not solve a serialized application workflow.

Professional architects use metrics to validate assumptions. Load tests, profiling, tracing, and representative data volumes help reveal whether a design meets non-functional requirements before production traffic exposes the problem. Performance optimization is therefore an evidence loop, not a one-time sizing exercise.

Performance experiments should resemble production. Testing a small synthetic dataset can hide partition skew, index behavior, or network throughput limits that appear at scale. Professional architects plan benchmark data, expected concurrency, and acceptance thresholds before using a test result to justify a design.

Plan failure domains across all three layers

Compute redundancy is ineffective if every instance depends on a single data copy or a single network path. Conversely, replicated storage cannot save an application that cannot reach it during a routing failure. The high availability versus fault tolerance reinforces why resilience must be evaluated across the complete request path.

Use zones, regions, load balancing, data replication, backup, and failover in combinations that match the actual recovery target. Not every system needs multi-region active-active architecture. The exam expects the candidate to connect failure design to business impact and cost.

Redundancy should be independent enough to matter. Two instances behind a load balancer are not highly available if both run in the same failure domain and depend on the same fragile database. Review each layer for shared dependencies that could collapse the apparent redundancy.

Resolve scenario questions by eliminating mismatches

Many PCA questions present several technically valid services. The fastest way to choose is to look for a mismatch: a platform that cannot satisfy a runtime requirement, storage with the wrong semantics, a network path that violates privacy, or a design whose operational burden exceeds the team’s capabilities.

Then compare the remaining options against cost, reliability, scalability, and management effort. The answer should follow the stated requirements with the fewest unsupported assumptions. That reasoning is more durable than memorizing a one-to-one mapping between workload keywords and product names.

Elimination works particularly well when a scenario includes words such as “fully managed,” “minimal operations,” “existing Kubernetes skills,” “lowest latency,” or “must use POSIX file semantics.” Those phrases are not decoration. They are constraints that should remove otherwise plausible services from consideration.

A simple decision matrix can prevent product-driven architecture. List the workload’s execution model, state, network reachability, storage semantics, latency, data durability, scaling pattern, and operational ownership. Score candidate services against those requirements, then document the important compromises. This produces a design that can be defended when future teams revisit the choice.

This approach also helps during troubleshooting because the original assumptions remain visible. If traffic, data volume, or team skill changes, architects can identify which assumption broke and reconsider only the affected layer instead of redesigning the entire platform from scratch.