Version française

GCP Professional Cloud Architect (PCA)

Design for Business Outcomes

KPIs, cost optimization, and aligning architecture with business goals.

Design for Business Outcomes

Product Strategy and Success Measurements

Before designing infrastructure, start with the business use case and the product strategy:

• Business use case = what problem you want to solve
• Product strategy = how the product will solve it

Example:

• Use case: offer personalized product recommendations to increase sales
• Strategy: build an AI-powered recommendation system that learns from user behavior

Success should be measured with both business and technical metrics.

Business KPIs

• Total Cost of Ownership (TCO)
• Return on Investment (ROI)
• Time to market / agility
• Revenue
• Monthly active users

Technical KPIs

• Availability / uptime
• Response time
• Error rate
• Saturation
• Mean time to recovery (MTTR)

Business KPIs measure business outcomes directly. Technical KPIs show whether the architecture supports those outcomes.

Cost Optimization

Cost optimization is about getting the best value, not only reducing spend:

• Value = business outcomes delivered relative to the resources consumed
• Cost optimization = eliminating waste, right-sizing, and choosing the right pricing models

Example:

• Problem: idle VMs running 24/7 with no workload
• Optimization: shut them down, schedule them, or use autoscaling

Cost decisions should account for both direct cloud bills and operational overhead.

Core practices

• Do not pay for unused resources (for example, idle VMs).
• Right-size compute, storage tiers, and capacity.
• Use Spot VMs for fault-tolerant workloads.
• Use committed use discounts when predictable usage exists.

Total cost of ownership

Always evaluate total cost of ownership. A cheaper unmanaged setup can cost more overall if it requires heavy operational staffing. In exam scenarios, low admin overhead usually points to managed services.

Cost visibility

• Use Cloud Billing reports and BigQuery billing export for analysis.
• Use labels/tags for attribution and chargeback.
• Configure quotas, budgets, and alerts.

Budgets do not cap spend automatically. Alerts notify you, but resources keep running unless you take action.

Supporting the Application Design

Architecture decisions must include non-functional requirements:

• Architecture style (monolith vs microservices)
• Scalability, performance, reliability
• Security and compliance
• Data model and storage behavior

Design examples by architecture pattern

• Microservices: GKE + Apigee
• Monolithic web app: Cloud Run or App Engine
• Batch workloads: Compute Engine, Batch, Dataproc
• Event-driven: Pub/Sub, Eventarc, Cloud Run Functions

Scalability, performance, and reliability practices

• Deploy across multiple zones.
• Eliminate single points of failure.
• Use elastic/scalable infrastructure.
• Prefer managed services when possible.
• Place resources close to users.
• Choose the right performance tiers.

Security and compliance practices

• Encrypt data at rest and in transit.
• Use IAM with least privilege.
• Enforce guardrails with Organization Policy.
• Configure VPC firewalls and service perimeters.

Data model considerations

• Choose storage based on data type and access patterns.
• Configure backup and point-in-time recovery.
• Apply access controls and encryption for sensitive data.

Integration with External Systems and Moving Data

Integrations are commonly:

• Private (systems you own)
• Public (third-party/SaaS systems)

Private integration options

• IPsec VPN / Cloud Interconnect (hybrid connectivity)
• VPC Peering
• Private Service Connect
• Authenticated APIs
• Pub/Sub
• Cloud Data Fusion

Public integration options

• Internet access (for example via Cloud NAT)
• Authenticated partner APIs
• Private Service Connect endpoints
• Pub/Sub

Data movement and transfer time

Transfer duration depends on:

• Data size
• Network bandwidth

Example: transferring 10 TB can vary dramatically (hours vs minutes) depending on bandwidth.

Google Cloud data transfer services

Storage Transfer Service

• Transfers data across Google Cloud, AWS, Azure, and on-premises
• Encrypts data in transit
• Uses checksums for integrity
• Supports incremental and scheduled transfers

Transfer Appliance

• Physical, high-capacity, tamper-resistant device
• Trusted Platform Module and attestation checks
• AES-256 encryption
• Available in 7 TB, 40 TB, and 300 TB sizes

gsutil (Cloud Storage CLI)

• Move/copy/rename objects
• Multi-threaded transfers
• Composite uploads for large files

Quick service selection guidance

• Cloud-to-cloud provider transfers: Storage Transfer Service
• On-premises small transfers (< 1 TB): gsutil
• On-premises larger transfers (> 1 TB): Storage Transfer Service or Transfer Appliance (depends on bandwidth)
• Cross-region Cloud Storage small transfers (< 1 TB): gsutil
• Cross-region Cloud Storage larger transfers (> 1 TB): Storage Transfer Service

Database migration services

• Database Migration Service: migrate MySQL/PostgreSQL/Oracle/SQL Server to Cloud SQL or AlloyDB, with optional continuous replication for low downtime.
• BigQuery Data Transfer Service: move data from sources like Cloud Storage, Amazon S3, Teradata, and more into BigQuery; supports scheduled recurring transfers.

Buy vs Build and Design Decision Trade-offs

Most architecture decisions are trade-offs:

• Performance vs cost
• Security vs flexibility
• Reliability vs agility
• SQL (consistency) vs NoSQL (scalability/flexibility)

Some decisions are constrained:

• Regulatory requirements (for example, data residency)

Some decisions are clearly favorable:

• A cheaper option that still meets all requirements

Reasons to buy

• Lower operational overhead
• Potentially more mature product
• More predictable pricing models

Reasons to build

• More customization and control
• Better internal integration
• Potential long-term cost amortization

Refactor vs retire

Refactor when:

• Feature set can be extended
• Existing expertise is valuable
• Positive ROI is expected

Retire when:

• System is obsolete or low-value
• Equivalent outcome is available at lower cost
• Legacy stack is too expensive/risky to modernize

Compliance and Observability

Using Google Cloud does not make a workload automatically compliant.

Key resources:

• Compliance Resource Center
• Compliance Reports Manager

Common compliance considerations:

• Encryption at rest and in transit
• IAM least-privilege access control
• VPC Service Controls for sensitive boundaries
• Audit logging and retention strategy
• Region selection and data residency

Monitoring vs observability

• Monitoring: tells you *if* something is wrong (predefined indicators)
• Observability: helps you understand *why* it is wrong and how to fix it

Three observability pillars:

• Metrics (health/performance)
• Logs (events/context)
• Traces (request flow and bottlenecks)

Google Cloud Operations Suite mappings:

• Metrics: Cloud Monitoring / Managed Service for Prometheus
• Logs: Cloud Logging
• Traces: Cloud Trace

Cloud Audit Logs types

• Admin Activity logs: enabled by default, cannot be disabled
• System Event logs: enabled by default, cannot be disabled
• Data Access logs: disabled by default, must be enabled; can incur significant ingestion costs

← Back to GCP PCA learning path