Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Gauge your current knowledge
Gauge your current knowledge
Identity Federation links an organization’s existing identity system with Google Cloud so users can keep their current credentials. By using Cloud Identity, businesses manage users and groups in one central place while connecting to external providers. This setup ensures consistent security policies across on-premises and cloud environments during a migration. An External Identity Provider (IdP) such as Active Directory or Okta acts as the Source of Truth for all user information. The IdP synchronizes data with Google Cloud, enabling Single Sign-On (SSO) so employees use one set of credentials for all services, which reduces administrative work and improves user experience.
Creating a Migration Plan for user accounts requires choosing the right strategy. Some organizations use Federation with User Account Consolidation to merge personal consumer accounts into managed corporate accounts. Others use Delayed Federation, which migrates all users before turning on SSO to avoid locking people out. Careful planning prevents conflicting accounts and ensures operational continuity during the transition. The SAML Assertion is a secure message sent from the IdP to Google to prove a user’s identity. Administrators should align session lengths between the IdP and Google so users are prompted to sign in at the right times, and minimize the data sent in these messages for efficiency. Using google.com as the standard issuer helps maintain compatibility across all Google services.
Multi-Factor Authentication (MFA) adds a second form of verification, such as a phone code, to protect accounts. For Super-Admin Users, it is a best practice to enforce Google 2-Step Verification because these accounts can bypass standard SSO settings. Disabling SSO for high-level accounts also reduces risk if the external IdP is compromised. Automated User Provisioning ensures the lifecycle of a user account in Google Cloud matches the external system: when an employee joins or leaves, a provisioning tool automatically creates or suspends the account. This reduces manual errors and prevents orphaned accounts. Key tools include Google Cloud Directory Sync (GCDS) for Active Directory, built-in connectors for Okta or Microsoft Entra ID, and HRIS integrations for syncing data from Human Resources systems.
When integrating solutions with existing systems, the gated ingress pattern manages how data enters the cloud. Using Apigee as an API platform provides security, rate limiting, and analytics for traffic coming from on-premises or other clouds. This setup allows legacy applications to communicate with modern cloud services without compromising safety or performance. To ensure seamless data flow, several networking tools work together. A Private Service Connect endpoint enables private communication between VPCs, while an Internal Load Balancer exposes application APIs safely. Architects also use Cloud VPN to create secure, encrypted tunnels over the public internet, Cloud Interconnect for a direct high-speed physical connection, and Firewall Rules to control and filter traffic.
For stricter security, a Transit VPC can perform deep packet inspection on all incoming traffic. This layer often includes Next Generation Firewalls and Intrusion Prevention Services to identify and block threats before they reach the application. By separating security tasks into a dedicated network, organizations maintain high standards during a phased migration. The Apigee Adapter for Envoy is a lightweight API gateway that runs close to backend applications in on-premises or multi-cloud settings. It handles authentication and authorization locally, which reduces network latency for users by avoiding unnecessary trips to the cloud. This tool allows the data plane to stay within the company’s network while using the cloud for high-level management. Using the Envoy adapter provides advantages for interoperability and operational continuity: it uses asynchronous communication to send analytics data to the cloud management plane without slowing down API traffic, and even if the internet connection is lost, the Envoy proxy can continue to process calls normally using cached security keys and configurations.
Cloud Interconnect links an on-premises network to Google Cloud through a high-availability, low-latency connection. Three primary options exist: Dedicated Interconnect for a direct physical connection, Partner Interconnect through a third-party provider for those who cannot connect directly, and Cross-Cloud Interconnect for a direct link between Google Cloud and another cloud provider like AWS or Azure. Selecting the right connection type depends on bandwidth needs and physical proximity to Google’s data centers. To ensure high availability, the architecture must be designed for a Service Level Agreement (SLA) of 99.99% or more. Achieving this requires at least four VLAN attachments spread across two different regions and two metropolitan areas. Using multiple Edge Availability Domains ensures scheduled maintenance does not disrupt the entire connection.
Security for hybrid connectivity is a top priority. HA VPN over Cloud Interconnect encrypts traffic using IPsec tunnels while still benefiting from the high capacity of a physical connection. Private Service Connect lets you access Google APIs and services privately, keeping sensitive data off the public internet. These tools help maintain compliance with industry regulations. Efficient data flow relies on the Cloud Router, which uses the Border Gateway Protocol (BGP) to automatically exchange routing information between networks. By enabling Global Dynamic Routing, the cloud network can share routes across all regions, making hybrid environments easier to manage. Properly configured BGP sessions prevent connection issues like flapping and ensure stable communication. Organizations often use a Shared VPC to centralize network management and maintain consistent security policies across multiple projects. For modern applications, Cloud Service Mesh uses Hybrid Network Endpoint Groups (NEGs) to route traffic to services running on-premises or in other clouds, creating a seamless experience for users regardless of where the backend data is physically stored.
A successful cloud migration starts by separating the Data Storage layer from the Data Computation layer. Architects evaluate storage options based on data type: Cloud Storage handles unstructured files, BigQuery supports large-scale analytics, and Cloud SQL or Spanner manage relational data. This separation gives teams flexibility and reduces costs because processing tools only run when needed. To move large datasets securely, architects use specialized tools like the Storage Transfer Service for moving objects between cloud providers or across regions, and Database Migration Service (DMS) for migrating relational databases like Oracle while maintaining data integrity. These managed services handle complex logic internally and provide monitoring to track migration health.
When migrating data pipelines, teams choose between a lift-and-shift approach or rearchitecting. Cloud Data Fusion provides visual pipeline development, Dataflow handles serverless batch and streaming processing, and Cloud Composer manages workflow orchestration. These tools automate the ETL process and ensure data flows correctly between source and target systems. The final cutover requires careful planning to maintain availability and avoid data loss. Continuous replication keeps databases synchronized until the switch, DNS TTL reduction speeds up network redirection, and post-migration testing verifies data consistency. These steps minimize service disruption during the transition.
Before migrating, architects perform a thorough assessment by creating a comprehensive inventory of all data pipelines, infrastructure, and datasets. Understanding these components helps identify application dependencies and business constraints that could impact the move. This step ensures the migration plan is based on accurate data. Three main migration strategies exist: Rehosting (lift and shift) moves applications with minimal changes, Replatforming moves to managed services like Cloud Data Fusion to improve efficiency, and Refactoring rearchitects the application fully for the cloud. The right choice balances cost, time, and the technical requirements of the legacy system.
A key architectural recommendation is keeping the data storage layer separate from the data computation layer. This separation provides flexibility and allows resources to scale independently. Storing data and computation in the same zone reduces network latency and lowers transfer costs. When planning data transfer, architects evaluate cost, transfer time, and security factors. Mapping network latency and bandwidth availability ensures the migration does not disrupt daily business operations. This dependency mapping determines whether an online or offline transfer method works best and helps set realistic timelines. Tools like Google Cloud Migration Center and Database Migration Service simplify the transition while maintaining data integrity and minimizing downtime. A strong migration plan includes dry runs to test the process, clear success criteria, and fallback plans to roll back if issues occur.
The assessment phase begins with Inventory Discovery, which creates a complete list of all data pipelines, infrastructure, and datasets. The Google Cloud Migration Center automates this discovery to ensure no critical components are missed. A thorough inventory categorizes resources into the data storage layer (databases, file systems like Cloud Storage, BigQuery, Cloud SQL) and the data computation layer (processing tools like Dataflow, Dataproc, Google Kubernetes Engine). Architects also evaluate network latency, measuring the speed for data to move between source and target environments.
Calculating Total Cost of Ownership (TCO) evaluates the financial impact of moving to the cloud. TCO assessment estimates long-term expenses compared to current on-premises costs. Networking costs include charges for moving data out of existing providers (egress fees). Operation costs cover ongoing fees for storage, compute, and management within Google Cloud. Personnel costs include training staff and managing the migration team. Beyond discovery, architects analyze resource utilization metrics to ensure efficiency. This involves examining how much CPU, memory, and storage legacy systems actually use to avoid over-provisioning. Google Cloud Migration Center provides insights that help rightsize cloud infrastructure, ensuring the organization only pays for resources it needs. The final goal is a robust migration plan with technical documents that define dependencies and the order for moving workloads, ensuring a smooth transition and allowing for future optimization.
Dependency mapping discovers how applications, services, and hardware rely on each other. This is done during the assessment phase by building a complete inventory. Understanding these connections prevents breaking services left on-premises when you move other parts to the cloud. Once dependencies are clear, workloads are organized into migration waves—groups of applications moved in stages, often broken into smaller move groups for easier management. Grouping by dependencies minimizes service disruptions and ensures complex systems move only when the environment is ready. Choosing the right first-movers is a key strategy: low-risk applications with few dependencies, like stateless microservices or non-critical internal tools, let teams build Google Cloud knowledge safely.
Network and data consistency are major factors in deciding the migration order. You must account for network latency and ensure data stays synchronized between on-premises and the cloud. Establishing strong connectivity using Cloud Interconnect or Cloud VPN is crucial so migrated workloads can still talk to resources left behind. Before the final move, a Proof of Concept (POC) validates the plan. This small-scale test identifies edge cases and confirms data completeness and performance, lowering the risk for the final cutover.
The first step is the assessment phase, where teams build a comprehensive inventory and perform dependency mapping. This deep knowledge of how services connect helps avoid unexpected failures. You must choose the right migration strategy for each workload: Rehosting (lift and shift) moves the application exactly as is, Replatforming makes small optimizations for the cloud, and Refactoring changes the code to use cloud-native features. Selecting the correct method balances speed with long-term efficiency.
Network planning is vital for secure connectivity. This involves setting up Virtual Private Clouds (VPCs) and planning IP address management to prevent overlaps between on-premises and cloud networks. Dependency planning ensures connected services are moved in the correct order. A solid network foundation enables reliable communication. A Proof of Concept (POC) is used for validation of migration feasibility. It allows workload testing protocols in a low-risk environment to check performance, scalability, and functional integrity. These tests help identify risks and estimate potential downtime. Rigorous validation ensures the application will work correctly after the final move. The final plan organizes the move into batches or waves, each containing a move group of related applications that must transition together. Every step needs a rollback strategy in case of issues. Post-migration validation confirms all data is complete and the new system is healthy.
The Assess Phase involves building a full inventory and performing dependency mapping. This identifies which applications are loosely coupled and easier to migrate without breaking other systems, helping decide the migration order. To link your data center to Google Cloud, you must choose a Hybrid Connectivity method: Cloud VPN provides a secure connection over the public internet suitable for lower traffic volumes, Cloud Interconnect offers a direct physical connection for higher reliability and speed, and Cross-Cloud Interconnect allows private links between different cloud providers like AWS or Azure. Selecting the correct bandwidth ensures large-scale data transfers don’t slow down operations.
Network Planning requires understanding that while Virtual Private Clouds (VPCs) are global, subnets are regional. You must plan new IP address ranges to avoid overlaps with your on-premises network. Using Cloud DNS with features like DNS peering or forwarding allows you to route traffic smoothly to new cloud locations, ensuring users can still find your services after the move. A successful Migration Plan organizes workloads into migration waves based on business value and technical difficulty. Prioritizing non-critical workloads first lets your team build experience before moving mission-critical systems, reducing the risk of major outages. Each wave should include a clear rollback strategy. Before the final move, create a Proof of Concept (POC) to validate feasibility in a test environment. Workload testing includes functional testing to check if the application works and load testing to ensure it handles real-world traffic. These tests help estimate downtime and confirm the new network architecture meets performance and security goals.
Bring Your Own License (BYOL) allows organizations to move existing software licenses to the cloud instead of purchasing new ones. This approach avoids extra hourly fees for premium cloud images and can significantly reduce Total Cost of Ownership (TCO) by reusing current software investments. For software with strict hardware requirements, Google Cloud provides sole-tenant nodes—physical servers dedicated to a single customer. These dedicated nodes are essential when a software vendor requires the application to run on specific, non-shared hardware to satisfy licensing agreements. Using sole-tenant nodes ensures compliance with original legal agreements while benefiting from cloud flexibility.
The migration plan must include several technical steps: creating node templates and node groups to define dedicated hardware, activating software licenses within the cloud environment, provisioning virtual machines on the correct node groups, and tracking usage to report consumption back to the software vendor. Not all software requires dedicated hardware; architects must carefully evaluate licensing terms for each application. Some Microsoft applications can use License Mobility to move to shared cloud environments without needing sole-tenant nodes, while older versions of Windows or specific enterprise databases might strictly require dedicated servers. Tools like the Google Cloud Pricing Calculator and Cloud Billing help track license consumption and monitor physical core and processor usage to ensure the cloud solution remains cost-effective over time.
When designing a cloud architecture, experts must calculate the Total Cost of Ownership (TCO) to understand the financial impact of moving to the cloud. The Google Cloud Pricing Calculator estimates costs of compute, storage, and networking across different regions, while Cloud Billing tracks and projects spend. Budgets and Alerts prevent unanticipated overspending, and the Rapid Assessment & Migration Program (RAMP) provides professional cost evaluations. Software license implications are critical because legacy enterprise software like SAP or Oracle often requires a BYOL model. Architects must ensure these workloads follow strict contractual obligations to avoid legal or financial penalties. If third-party license fees are no longer economical, the migration plan might recommend refactoring or rebuilding toward open-source or cloud-native options.
There is a direct relationship between resource right-sizing and software licensing costs. Many vendors charge fees based on the number of virtual CPUs (vCPUs), so over-provisioning hardware leads to unnecessary license expenses. The Recommender tool helps identify idle VMs or oversized instances that should be scaled down. Optimization strategies include autoscaling to match resource capacity with demand, Committed Use Discounts (CUDs) for predictable long-term workloads, and Spot VMs for flexible, fault-tolerant tasks at reduced prices. To maintain license compliance, organizations must implement auditing mechanisms using Labels and Tags to categorize resources by department or project. Cloud Asset Inventory detects drift, ensuring the current cloud state stays aligned with the original migration plan and vendor agreements.
When moving software to Google Cloud, architects must choose between License-Included models and Bring Your Own License (BYOL) options. License-included images bundle software cost directly with the virtual machine price, offering a simple pay-as-you-go approach with high flexibility and no need for large upfront purchases. This model scales easily as costs automatically rise and fall with usage. The BYOL model allows organizations to use existing software investments on cloud infrastructure, often resulting in lower hourly infrastructure costs because the license fee does not appear on the Google Cloud bill. However, certain enterprise software may require sole-tenant nodes, and architects must verify whether current contracts allow cloud migration and if dedicated hardware is required for compliance.
Comparing these models requires analyzing total cost of ownership, including scalability and operational overhead. BYOL might involve fixed costs and manual license tracking, while License-Included provides automatic scaling. The chosen migration strategy directly impacts licensing costs—for example, moving to a managed service like Cloud SQL includes the database license in the service fee, reducing manual maintenance workload. The Google Cloud Pricing Calculator and Migration Center help project future costs across different cloud regions, enabling comparative analysis of different licensing paths before migration begins. Using these resources ensures the final cloud architecture aligns with both the organization’s budget and technical goals.
Identity Federation allows organizations to link their existing identity systems with Google Cloud. By using Cloud Identity, businesses can manage users and groups in one central place while con…
Identity Federation allows organizations to link their existing identity systems with Google Cloud. By using Cloud Identity, businesses can manage users and groups in one central place while con…
A successful cloud migration starts with separating the Data Storage layer from the Data Computation layer. Architects evaluate storage options based on the type of data being moved: **Cloud S…
A successful cloud migration starts with separating the Data Storage layer from the Data Computation layer. Architects evaluate storage options based on the type of data being moved: **Cloud S…
Dependency mapping is the process of discovering how applications, services, and hardware rely on each other. This is done during the assessment phase by building a complete inventory. Understandi…
Dependency mapping is the process of discovering how applications, services, and hardware rely on each other. This is done during the assessment phase by building a complete inventory. Understandi…
Bring Your Own License (BYOL) allows organizations to move existing software licenses to the cloud instead of purchasing new ones through the cloud provider. This approach helps avoid the extra ho…
Bring Your Own License (BYOL) allows organizations to move existing software licenses to the cloud instead of purchasing new ones through the cloud provider. This approach helps avoid the extra ho…
StudyCerts
StudyCerts