GCP Architecture Framework Flashcards
https://cloud.google.com/architecture/frameworkWhat is the foundational category from the Google Cloud Architecture Framework that provides design recommendations and describes best practices and principles to help you define the architecture, components, modules, interfaces, and data on a cloud platform to satisfy your system requirements?
System design is the foundational category of the Google Cloud Architecture Framework. This category provides design recommendations and describes best practices and principles to help you define the architecture, components, modules, interfaces, and data on a cloud platform to satisfy your system requirements. You also learn about Google Cloud products and features that support system design.
https://cloud.google.com/architecture/framework
https://cloud.google.com/architecture/frameworkThe Google Cloud Architecture Framework provides what type of recommendations and describes?
…… best practices to help architects, developers, administrators, and other cloud practitioners design and operate a cloud topology that’s secure, efficient, resilient, high-performing, and cost-effective.
https://cloud.google.com/architecture/framework
What are the Google Cloud Architecture Framework categories (also known as pillars)?
The design guidance in the Architecture Framework applies to applications built for the cloud and for workloads migrated from on-premises to Google Cloud, hybrid cloud deployments, and multi-cloud environments.
The Google Cloud Architecture Framework is organized into six categories (also known as pillars), as shown in the following diagram:
Google Cloud Architecture Framework
architecture System design
This category is the foundation of the Google Cloud Architecture Framework. Define the architecture, components, modules, interfaces, and data needed to satisfy cloud system requirements, and learn about Google Cloud products and features that support system design.
construction Operational excellence
Efficiently deploy, operate, monitor, and manage your cloud workloads.
security Security, privacy, and compliance
Maximize the security of your data and workloads in the cloud, design for privacy, and align with regulatory requirements and standards.
restore Reliability
Design and operate resilient and highly available workloads in the cloud.
payment Cost optimization
Maximize the business value of your investment in Google Cloud.
speed Performance optimization
Design and tune your cloud resources for optimal performance.
https://cloud.google.com/architecture/framework
???????? Which category is the foundational category of the Google Cloud Architecture Framework. This category provides design recommendations and describes best practices and principles to help you define the architecture, components, modules, interfaces, and data on a cloud platform to satisfy your system requirements.
System Design is this category.
You also learn about Google Cloud products and features that support system design.
https://cloud.google.com/architecture/frameworkhttps://cloud.google.com/architecture/framework/system-design
What are the core principles of system design?
Document everything
When you start to move your workloads to the cloud or build your applications, a major blocker to success is lack of documentation of the system. Documentation is especially important for correctly visualizing the architecture of your current deployments.
Simplify your design and use fully managed services
Simplicity is crucial for system design. If your architecture is too complex to understand, it will be difficult to implement the design and manage it over time. Where feasible, use fully managed services to minimize the risks, time, and effort associated with managing and maintaining baseline systems.
Decouple your architecture
Decoupling is a technique that’s used to separate your applications and service components into smaller components that can operate independently. For example, you might break up a monolithic application stack into separate service components. In a decoupled architecture, an application can run its functions independently, regardless of the various dependencies.
Use a stateless architecture
A stateless architecture can increase both the reliability and scalability of your applications.
Stateful applications rely on various dependencies to perform tasks, such as locally cached data. Stateful applications often require additional mechanisms to capture progress and restart gracefully. Stateless applications can perform tasks without significant local dependencies by using shared storage or cached services. A stateless architecture enables your applications to scale up quickly with minimum boot dependencies. The applications can withstand hard restarts, have lower downtime, and provide better performance for end users.
https://cloud.google.com/architecture/framework/system-design
What deployment best practices should you consider when deploying a GCP solution (system design best practice)?
Deploy over multiple regions
Select regions based on geographic proximity
Use Cloud Load Balancing to serve global users
Use the Cloud Region Picker to support sustainability
Compare pricing of major resources
https://cloud.google.com/architecture/framework/system-design
What are 2 ways to design resilient services?
Ensure you standardize deployments and incorporate automation wherever possible
Using architectural standards and deploying with automation helps you standardize your builds, tests, and deployments, which helps to eliminate human-induced errors for repeated processes like code updates and provides confidence in testing before deployment. Understand your operational tools portfolio
https://cloud.google.com/architecture/framework/system-design
What is the high level overview of the design process:
- Understand the overarching goals.
- Identify and itemize objectives.
- Categorize and prioritize objectives.
- Analyze objectives.
- Determine preliminary options.
- Refine options.
- Identify your final solution.
https://cloud.google.com/architecture/framework/system-design
How do you identify the architecture?
Identify Goals
Use existing patterns or designs
Google provides resources at the Cloud Architecture Center that can form the basis for your solution design.
For example, there’s a reference architecture diagram for migrating an on premises data center to Google Cloud
Take each sentence in your case study, and rewrite it as an objective. An objective could be an existing architectural
or a task that needs to be completed.
https://cloud.google.com/architecture/framework/system-design/principles
When you categorize requirements, what are the categories?
business requirements
technical requirements
As we discussed in module 1, we can use the business and technical requirements as watchpoints to use when deciding what we can use to implement a solution.
solution requirements
The solution components may act as equivalents to the existing infrastructure or may replace the existing infrastructure with new components and functionality to achieve Dress4Win’s goals.
After you develop the solution approach, how do you work with the product information?
Professional Cloud Architect, because they will determine howto best use the resources available to you in Google Cloud.
It often helps to start at with a broad approach and decide what products to use, like we did in the last module.
Next, focus on the different products, services, and practices and decide how best implement them in Google Cloud.
What are 5 generic steps for an architect to follow when designing a cloud solution?
Designing a solution infrastructure that meets business requirements
Designing a solution infrastructure that meets technical requirements
Designing network, storage, compute, and other resources
Creating a migration plan
Envisioning future solution improvements
What are core principles that an architect must consider in analyzing data for a solution during the system design aspect?
Identify the pros/cons of the different alternatives:
Dataflow lets you write complex transformations in a serverless approach, but you must rely on an opinionated version of configurations for compute and processing needs.
Alternatively, Dataproc lets you run the same transformations, but you manage the clusters and fine-tune the jobs yourself.
-Processing strategy
In your system design, think about which processing strategy your teams use, such as extract, transform, load (ETL) or extract, load, transform (ELT). Your system design should also consider whether you need to process batch analytics or streaming analytics. Google Cloud provides a unified data platform, and it lets you build a data lake or a data warehouse to meet your business needs.
https://cloud.google.com/architecture/framework/system-design/data-analytics
When you create your system design, you can group the Google Cloud data analytics services around the general data movement in any system, or around the data lifecycle.
The data lifecycle includes the following stages and example services:
Ingestion includes services such as Pub/Sub, Storage Transfer Service, Transfer Appliance, Cloud IoT Core, and BigQuery.
Storage includes services such as Cloud Storage, Bigtable, Memorystore, and BigQuery.
Processing and transformation includes services such as Dataflow, Dataproc, Dataprep, Cloud Data Loss Prevention (Cloud DLP), and BigQuery.
Analysis and warehousing includes services such as BigQuery.
Reporting and visualization includes services such as Looker Studio and Looker.
The following stages and services run across the entire data lifecycle:
Data integration includes services such as Data Fusion.
Metadata management and governance includes services such as Data Catalog.
Workflow management includes services such as Cloud Composer.
https://cloud.google.com/architecture/framework/system-design/data-analytics
What are the different data services that an architect can use during each stage of the data lifecycle? (System Design - Analyze data)
What are the data ingestion best practices an architect should consider during the system design phase?
Determine the data source for ingestion
Data typically comes from another cloud provider or service, or from an on-premises location:
To ingest data from other cloud providers, you typically use Cloud Data Fusion, Storage Transfer Service, or BigQuery Transfer Service.
For on-premises data ingestion, consider the volume of data to ingest and your team’s skill set. If your team prefers a low-code, graphical user interface (GUI) approach, use Cloud Data Fusion with a suitable connector, such as Java Database Connectivity (JDBC). For large volumes of data, you can use Transfer Appliance or Storage Transfer Service.
Consider how you want to process your data after you ingest it. For example, Storage Transfer Service only writes data to a Cloud Storage bucket, and BigQuery Data Transfer Service only writes data to a BigQuery dataset. Cloud Data Fusion supports multiple destinations.
https://cloud.google.com/architecture/framework/system-design/data-analytics
How do architects determine which services to use for data ingestion during the system design phase?
Identify streaming or batch data services to use:
Consider how you need to use your data and identify where you have streaming or batch use cases.
Pub/Sub - used for a global streaming service that has low latency requirements
BigQuery - used when you have a need for analytics and reporting uses.
Kafka to BigQuery Dataflow template- used
if you need to stream data from a system like Apache Kafka in an on-premises or other cloud environment.
Storage Transfer Service -
used for batch workloads. the first step is usually to ingest data into Cloud Storage. Use the gsutil tool or ingest data.
Big Query Transfers
Apart from using above tools, you also have following data pipeline options to load data into BigQuery:
Cloud Dataflow
Dataflow is a fully managed service on GCP built using the open source Apache Beam API with support for various data sources — files, databases, message based and more. With Dataflow you can transform and enrich data in both batch and streaming modes with the same code. Google provides prebuilt Dataflow templates for batch jobs.
Cloud Dataproc
Dataproc is a fully managed service on GCP for Apache Spark and Apache Hadoop services. Dataproc provides BigQuery connector enabling Spark and Hadoop applications to process data from BigQuery and write data to BigQuery using its native terminology.
Cloud Logging
This is not a data pipeline option but Cloud Logging (previously known as Stackdriver) provides an option to export log files into BigQuery. See Exporting with the Logs Viewer for more information and reference guide on exporting logs to BigQuery for security and access analytics.
https://cloud.google.com/architecture/framework/system-design/data-analytics
How can you get around Querying Without Loading Data
As mentioned in the beginning of this post, you don’t need to load data into BigQuery before running queries in the following situations:
Public Datasets: Public datasets are datasets stored in BigQuery and shared with the public. For more information, see BigQuery public datasets.
Shared Datasets: You can share datasets stored in BigQuery. If someone has shared a dataset with you, you can run queries on that dataset without loading the data.
External data sources (Federated): You can skip the data loading process by creating a table based on an external data source.
https://cloud.google.com/blog/topics/developers-practitioners/bigquery-explained-data-ingestion
What services allow you to ingest data using automation?
Ingest data with automated tools
Manually moving data from other systems into the cloud can be a challenge. If possible, use tools that let you automate the data ingestion processes.
Cloud Data Fusion
provides connectors and plugins to bring data from external sources with a drag-and-drop GUI.
Data Flow or BigQuery
If your teams want to write some code, you can automate data ingestion.
Pub/Sub
Helps in both a low-code or code-first approach.
Storage Transfer Service-
To ingest data into storage buckets, use gsutil for data sizes of up to 1 TB. To ingest amounts of data larger than 1 TB, use .
What services do you use to regularly ingest data on a schedule?
Storage Transfer Service and BigQuery Data Transfer Service both let you schedule ingestion jobs. For fine-grain control of the timing of ingestion or the source and destination system, use a workflow-management system like Cloud Composer. If you want a more manual approach, you can use Cloud Scheduler and Pub/Sub to trigger a Cloud Function.
If you want to manage the Compute infrastructure, you can use the gsutil command with cron for data transfer of up to 1 TB. If you use this manual approach instead of Cloud Composer, follow the best practices to script production transfers.sd
https://cloud.google.com/architecture/framework/system-design/data-analytics
How do architects pick the right datastore based on their needs?
Identify which of the following common use cases for your data to pick which Google Cloud product to use:
Data use case Product recommendation
File-based Filestore
Object-based Cloud Storage
Low latency Bigtable
Time series Bigtable
Online cache Memorystore
Transaction processing Cloud SQL
Business intelligence (BI) & analytics BigQuery Batch processing Cloud Storage
Bigtable if incoming data is time series and you need low latency access to it.
BigQuery if you use SQL.
https://cloud.google.com/architecture/framework/system-design/data-analytics
What would an architect use when you need to ingest data from multiple sources?
Use Dataflow to ingest data from multiple sources
To ingest data from multiple sources, such as Pub/Sub, Cloud Storage, HDFS, S3, or Kafka, use Dataflow. Dataflow is a managed serverless service that supports Dataflow templates, which lets your teams run templates from different tools.
Dataflow Prime provides horizontal and vertical autoscaling of machines that are used in the execution process of a pipeline. It also provides smart diagnostics and recommendations that identify problems and suggest how to fix them.
https://cloud.google.com/architecture/framework/system-design/data-analytics
What is the System design category of the architecture framework?
This category is the foundation of the Google Cloud Architecture Framework. Define the architecture, components, modules, interfaces, and data needed to satisfy cloud system requirements, and learn about Google Cloud products and features that support system design.
https://cloud.google.com/architecture/framework
What is the Operational excellence category?
Efficiently deploy, operate, monitor, and manage your cloud workloads.
https://cloud.google.com/architecture/framework
What is the Security, privacy, and compliance category of the architecture framework?
Maximize the security of your data and workloads in the cloud, design for privacy, and align with regulatory requirements and standards.
https://cloud.google.com/architecture/framework
What is the Reliability category of the architecture framework?
Design and operate resilient and highly available workloads in the cloud.
https://cloud.google.com/architecture/framework
What is the Cost optimization category of the architecture framework?d
Maximize the business value of your investment in Google Cloud.
https://cloud.google.com/architecture/framework
What is the Performance optimization category of the architecture framework?
Design and tune your cloud resources for optimal performance.
https://cloud.google.com/architecture/framework
How do you simplify your design and use fully managed services
Simplicity is crucial for system design. If your architecture is too complex to understand, it will be difficult to implement the design and manage it over time. Where feasible, use fully managed services to minimize the risks, time, and effort associated with managing and maintaining baseline systems.
If you’re already running your workloads in production, test with managed services to see how they might help to reduce operational complexities. If you’re developing new workloads, then start simple, establish a minimal viable product (MVP), and resist the urge to over-engineer. You can identify exceptional use cases, iterate, and improve your systems incrementally over time.
https://cloud.google.com/architecture/framework/system-design/principles
How do you decouple your architecture, what if it was a monolithic?
Decoupling is a technique that’s used to separate your applications and service components into smaller components that can operate independently.
For example, you might break up a monolithic application stack into separate service components. In a decoupled architecture, an application can run its functions independently, regardless of the various dependencies.
You can start decoupling early in your design phase or incorporate it as part of your system upgrades as you scale.
https://cloud.google.com/architecture/framework/system-design/principles
What are the benefits of a decoupled architecture?
A decoupled architecture gives you increased flexibility to do the following:
Apply independent upgrades.
Enforce specific security controls.
Establish reliability goals for each subsystem.
Monitor health.
Granularly control performance and cost parameters.
https://cloud.google.com/architecture/framework/system-design/principles
Why use a stateless architecture?
A stateless architecture can increase both the reliability and scalability of your applications.
Stateful applications rely on various dependencies to perform tasks, such as locally cached data. Stateful applications often require additional mechanisms to capture progress and restart gracefully.
Stateless applications can perform tasks without significant local dependencies by using shared storage or cached services. A stateless architecture enables your applications to scale up quickly with minimum boot dependencies. The applications can withstand hard restarts, have lower downtime, and provide better performance for end users.
https://cloud.google.com/architecture/framework/system-design/principles
When you select a region or multiple regions for your business applications, what criteria might you consider for your decision?
When you select a region or multiple regions for your business applications, you consider criteria including:
service availability
end-user latency
application latency
cost
regulatory or sustainability requirements.
Decision Making Process:
To support your business priorities and policies, balance these requirements and identify the best tradeoffs.
For example, the most compliant region might not be the most cost-efficient region or it might not have the lowest carbon footprint.
https://cloud.google.com/architecture/framework/system-design/geographic-zones-regions
Why would you deploy a customer solution over multiple regions?
**Deploy over multiple regions
**
Why choose this strategy?
To help protect against expected downtime (including maintenance) and help protect against unexpected downtime like incidents, we recommend that you deploy fault-tolerant applications that have high availability and deploy your applications across multiple zones in one or more regions. For more information, see Geography and regions, Application deployment considerations, and Best practices for Compute Engine regions selection.
Multi-zonal deployments can provide resiliency if multi-region deployments are limited due to cost or other considerations.
This approach is especially helpful in preventing zonal or regional outages and in addressing disaster recovery and business continuity concerns.
For more information, see Design for scale and high availability.
https://cloud.google.com/architecture/framework/system-design/geographic-zones-regions
Why would an architect select regions based on geographic proximity?
Why choose regions with closer proxiomity?
Latency impacts the user experience and affects costs associated with serving external users.
To minimize latency when serving traffic to external users, select a region or set of regions that are geographically close to your users and where your services run in a compliant way.
For more information, see Cloud locations and the Compliance resource center.
https://cloud.google.com/architecture/framework/system-design/geographic-zones-regions
Why and how would you select regions based on available services?
Not all services are available in every region, you must verify their availability during the design process.
Select a region based on the available services that your business requires. Most services are available across all regions. Some enterprise-specific services might be available in a subset of regions with their initial release.
To verify region selection, see Cloud locations.
https://cloud.google.com/about/locations
https://cloud.google.com/architecture/framework/system-design/geographic-zones-regions
Why would you need to choose regions to support compliance?
Select a specific region or set of regions to meet geographic regulatory or compliance regulations that require the use of certain geographies, for example General Data Protection Regulation (GDPR) or data residency.
To learn more about designing secure systems, see Compliance offerings and Data residency, operational transparency, and privacy for European customers on Google Cloud.
https://cloud.google.com/architecture/framework/system-design/geographic-zones-regions
Why and how must you compare pricing of major resources for a customer solution?
Compare prices across the different options for your regions?
Regions have different cost rates for the same services. To identify a cost-efficient region, compare pricing of the major resources that you plan to use. Cost considerations differ depending on backup requirements and resources like compute, networking, and data storage.
To learn more, see the Cost optimization category.
https://cloud.google.com/architecture/framework/system-design/geographic-zones-regions
How do you pick a region to support sustainability?
Use the Cloud Region Picker to support sustainability
Google has been carbon neutral since 2007 and is committed to being carbon-free by 2030. To select a region by its carbon footprint, use the Google Cloud Region Picker. To learn more about designing for sustainability, see Cloud sustainability.
https://cloud.google.com/architecture/framework/system-design/geographic-zones-regions
How would you create a solution that serves global users?
Use Cloud Load Balancing to serve global users
To improve the user experience when you serve global users, use Cloud Load Balancing to help provide a single IP address that is routed to your application. To learn more about designing reliable systems, see Google Cloud Architecture Framework: Reliability.
https://cloud.google.com/architecture/framework/system-design/geographic-zones-regions
How should an architect create a strategy for folder structure?
Use a simple folder structure
Folders let you group any combination of projects and subfolders. Create a simple folder structure to organize your Google Cloud resources. You can add more levels as needed to define your resource hierarchy so that it supports your business needs.
The folder structure is flexible and extensible.To learn more, see Creating and managing folders.
A common situation is to create folders that in turn contain additional folders or projects, as shown in the image above. This structure is referred to as a folder hierarchy. When creating a folder hierarchy, keep in mind the following:
You can nest folders up to 10 (ten) levels deep.
A parent folder cannot contain more than 300 folders. This refers to direct child folders only. Those child folders can, in turn, contain additional folders or projects.
Folder display names must be unique within the same level of the hierarchy.
You can use folder-level IAM policies to control access to the resources the folder contains. For example, if a user is granted the Compute Instance Admin role on a folder, that user has the Compute Instance Admin role for all of the projects in the folder.
Before you begin
Folder functionality is only available to Google Workspace and Cloud Identity customers that have an organization resource. For more information about acquiring an organization resource, see Creating and managing organizations.
If you’re exploring how to best use folders, we recommend that you:
Review Access Control for Folders Using IAM. The topic describes how you can control who has what access to folders and the resources they contain.
Understand how to set folder permissions. Folders support a number of different IAM roles. If you want to broadly set up permissions so users can see the structure of their projects, grant the entire domain the Organization Viewer and Folder Viewer roles at the organization level. To restrict visibility to branches of your folder hierarchy, grant the Folder Viewer role on the folder or folders you want users to see.
Create folders. As you plan how to organize your Cloud resources, we recommend that you start with a single folder as a sandbox where you can experiment with which hierarchy makes the most sense for your organization. Think of folders in terms of isolation boundaries between resources and attach points for access and configuration policies. You may choose to create folders to contain resources that belong to different departments and assign Admin roles on folders to delegate administrator privilege. Folders can also be used to group resources that belong to applications or different environments, such as development, production, test. Use nested folders to model these different scenarios.
https://cloud.google.com/architecture/framework/system-design/resource-management
https://cloud.google.com/resource-manager/docs/creating-managing-folders
What are the two different options for organizing resourcdes in the customer’s IAM resource heirarchy?
Option 1: Hierarchy based on application environments
In many organizations, you define different policies and access controls for different application environments, such as development, production, and testing. Having separate policies that are standardized across each environment eases management and configuration. For example, you might have security policies that are more stringent in production environments than in testing environments.
Use a hierarchy based on application environments if the following is true:
You have separate application environments that have different policy and administration requirements.
You have use cases that have highly customized security or audit requirements.
You require different Identity and Access Management (IAM) roles to access your Google Cloud resources in different environments.
Avoid this hierarchy if the following is true:
You don’t run multiple application environments.
You don’t have varying application dependencies and business processes across environments.
You have strong policy differences for different regions, teams, or applications.
Option 2: Hierarchy based on regions or subsidiaries
Some organizations operate across many regions and have subsidiaries doing business in different geographies or have been a result of mergers and acquisitions. These organizations require a resource hierarchy that uses the scalability and management options in Google Cloud, and maintains the independence for different processes and policies that exist between the regions or subsidiaries. This hierarchy uses subsidiaries or regions as the highest folder level in the resource hierarchy. Deployment procedures are typically focused around the regions.
Use this hierarchy if the following is true:
Different regions or subsidiaries operate independently.
Regions or subsidiaries have different operational backbones, digital platform offerings, and processes.
Your business has different regulatory and compliance standards for regions or subsidiaries.
Option 3: Hierarchy based on an accountability framework
A hierarchy based on an accountability framework works best when your products are run independently or organizational units have clearly defined teams who own the lifecycle of the products. In these organizations, the product owners are responsible for the entire product lifecycle, including its processes, support, policies, and access rights. Your products are quite different from each other, so only a few organization-wide guidelines exist.
Use this hierarchy when the following is true:
You run an organization that has clear ownership and accountability for each product.
Your workloads are independent and don’t share many common policies.
Your processes and external developer platforms are offered as service or product offerings.
https://cloud.google.com/architecture/framework/system-design/resource-management
https://cloud.google.com/architecture/landing-zones/decide-resource-hierarchy
What are best practices for designing a resource heirarchy for your organization?
Use folders and projects to reflect data governance policies
Use folders, subfolders, and projects to separate resources from each other to reflect data governance policies within your organization. For example, you can use a combination of folders and projects to separate financial, human resources, and engineering.
Use projects to group resources that share the same trust boundary. For example, resources for the same product or microservice can belong to the same project. For more information, see Decide a resource hierarchy for your Google Cloud landing zone.
Use a single organization node
To avoid management overhead, use a single organization node whenever possible. However, consider using multiple organization nodes to address the following use cases:
You want to test major changes to your IAM levels or resource hierarchy.
You want to experiment in a sandbox environment that doesn’t have the same organization policies.
Your organization includes sub-companies that are likely to be sold off or run as completely separate entities in the future.
Use standardized naming conventions
Use a standardized naming convention throughout your organization. The security foundations blueprint has a sample naming convention that you can adapt to your requirements.
Understand resource interactions throughout the hierarchy
Understand which resources interact with the resource hierarchy and how the folder structure works for them.
Organization policies are inherited by descendants in the resource hierarchy, but can be superseded by policies defined at a lower level. For more information, see understanding hierarchy evaluation. You use organization policy constraints to set guidelines around the whole organization or significant parts of it and still allow for exceptions.
IAM policies are inherited by descendants, and cannot be superseded. However, you can add more access controls at lower levels at the hierarchy. See using resource hierarchy for access control for details.
You also need to consider the following:
Cloud Logging includes aggregated sinks that you can use to aggregate logs at the folder or organization level.
Billing is not directly linked to the resource hierarchy, but assigned at the project level. However, to get aggregated information at the folder level, you can analyze your costs by project hierarchy using billing reports.
Hierarchical firewall policies let you implement consistent firewall policies throughout the organization or in specific folders. Inheritance is implicit, which means that you can allow or deny traffic at any level or you can delegate the decision to a lower level.
Keep bootstrapping resources and common services separate
Keep separate folders for bootstrapping the Google Cloud environment using infrastructure-as-code (IaC) and for common services that are shared between environments or applications. Place the bootstrap folder right below the organization node in the resource hierarchy.
Place the folders for common services at different levels of the hierarchy, depending on the structure that you choose. Place the folder for common services right below the organization node when the following is true:
Your hierarchy uses application environments at the highest level and teams or applications at the second layer.
You have shared services such as monitoring that are common between environments.
Place the folder for common services at a lower level, below the application folders, when you have services that are shared between applications but are deployed separately for each deployment environment, for example shared microservices that are used by multiple applications but are updated regularly and require development and testing.
https://cloud.google.com/architecture/framework/system-design/resource-management
https://cloud.google.com/architecture/landing-zones/decide-resource-hierarchy
How and when should you figure out how to use tags and labels?
When?
Use tags and labels at the outset of your project
Use labels and tags when you start to use Google Cloud products, even if you don’t need them immediately. Adding labels and tags later on can require manual effort that can be error prone and difficult to complete.
A tag provides a way to conditionally allow or deny policies based on whether a resource has a specific tag. A label is a key-value pair that helps you organize your Google Cloud instances. For more information on labels, see requirements for labels, a list of services that support labels, and label formats.
Resource Manager provides labels and tags to help you manage resources, allocate and report on cost, and assign policies to different resources for granular access controls.
For example, you can use labels and tags to apply granular access and management principles to different tenant resources and services. For information about VM labels and network tags, see Relationship between VM labels and network tags.
You can use labels for multiple purposes, including the following:
Managing resource billing: Labels are available in the billing system, which lets you separate cost by labels. For example, you can label different cost centers or budgets.
Grouping resources by similar characteristics or by relation: You can use labels to separate different application lifecycle stages or environments. For example, you can label production, development, and testing environments.
Tag inheritance
When a tag key-value pair is attached to a resource, all descendants of the resource inherit the tag. You can override an inherited tag on a descendant resource. To override an inherited tag, apply a tag using the same key as the inherited tag, but use a different value.
https://cloud.google.com/architecture/framework/system-design/resource-management
https://cloud.google.com/resource-manager/docs/tags/tags-overview
What are best practice uses for tags and labels?
Assign labels to support cost and billing reporting
To support granular cost and billing reporting based on attributes outside of your integrated reporting structures (like per-project or per-product type), assign labels to resources. Labels can help you allocate consumption to cost centers, departments, specific projects, or internal recharge mechanisms. For more information, see the Cost optimization category.
Avoid creating large numbers of labels
Avoid creating large numbers of labels. We recommend that you create labels primarily at the project level, and that you avoid creating labels at the sub-team level. If you create overly granular labels, it can add noise to your analytics. To learn about common use cases for labels, see Common uses of labels.
Avoid adding sensitive information to labels
Labels aren’t designed to handle sensitive information. Don’t include sensitive information in labels, including information that might be personally identifiable, like an individual’s name or title.
Apply tags to model business dimensions
You can apply tags to model additional business dimensions like organization structure, regions, workload types, or cost centers. To learn more about tags, see Tags overview, Tag inheritance, and Creating and managing tags. To learn how to use tags with policies, see Policies and tags. To learn how to use tags to manage access control, see Tags and access control.
https://cloud.google.com/architecture/framework/system-design/resource-management
What are best practices for project names?
Establish project naming conventions
Establish a standardized project naming convention, for example, SYSTEM_NAME-ENVIRONMENT (dev, test, uat, stage, prod).
Project names have a 30-character limit.
Although you can apply a prefix like COMPANY_TAG-SUB_GROUP/SUBSIDIARY_TAG, project names can become out of date when companies go through reorganizations. Consider moving identifiable names from project names to project labels.
Anonymize information in project names
Follow a project naming pattern like COMPANY_INITIAL_IDENTIFIER-ENVIRONMENT-APP_NAME, where the placeholders are unique and don’t reveal company or application names. Don’t include attributes that can change in the future, for example, a team name or technology.
https://cloud.google.com/architecture/framework/system-design/resource-management
What factors should an architect consider when they create an organization policy ??
Use the Organization Policy Service to control resources
The Organization Policy Service gives policy administrators centralized and programmatic control over your organization’s cloud resources so that they can configure constraints across the resource hierarchy. For more information, see Add an organization policy administrator.
Use the Organization Policy Service to comply with regulatory policies
To meet compliance requirements, use the Organization Policy Service to enforce compliance requirements for resource sharing and access. For example, you can limit sharing with external parties or determine where to deploy cloud resources geographically. Other compliance scenarios include the following:
Centralizing control to configure restrictions that define how your organization’s resources can be used.
Defining and establishing policies to help your development teams remain within compliance boundaries.
Helping project owners and their teams make system changes while maintaining regulatory compliance and minimizing concerns about breaking compliance rules.
https://cloud.google.com/architecture/framework/system-design/resource-management
What type of best practices should you keep in mind when you organize the hierarchy for your resources?
Google Cloud resources are arranged hierarchically in organizations, folders, and projects. This hierarchy lets you manage common aspects of your resources like access control, configuration settings, and policies.
For best practices to design the hierarchy of your cloud resources, see
Decide a resource hierarchy for your Google Cloud landing zone based on the flowchart and resources.
https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy
https://cloud.google.com/architecture/landing-zones/decide-resource-hierarchy
https://cloud.google.com/architecture/framework/system-design/resource-managementd
Why is selecting compute options so important for an architect to consider?
Computation is at the core of many workloads, whether it refers to the execution of custom business logic or the application of complex computational algorithms against datasets. Most solutions use compute resources in some form, and it’s critical that you select the right compute resources for your application needs.
Google Cloud provides several options for using time on a CPU. Options are based on CPU types, performance, and how your code is scheduled to run, including usage billing.
Google Cloud compute options include the following:
Virtual machines (VM) with cloud-specific benefits like live migration.
Bin-packing of containers on cluster-machines that can share CPUs.
Functions and serverless approaches, where your use of CPU time can be metered to the work performed during a single HTTP request.
https://cloud.google.com/architecture/framework/system-design/compute
When you choose a compute platform for your workload, what should you consider?
The technical requirements of the workload, lifecycle automation processes, regionalization, and security.
Evaluate the nature of CPU usage by your app and the entire supporting system, including how your code is packaged and deployed, distributed, and invoked. While some scenarios might be compatible with multiple platform options, a portable workload should be capable and performant on a range of compute options.
Choose a compute migration approach
If you’re migrating your existing applications from another cloud or from on-premises, use one of the following Google Cloud products to help you optimize for performance, scale, cost, and security.
https://cloud.google.com/architecture/framework/system-design/compute
How does an architect designing workloads for their solutions?
This section provides best practices for designing workloads to support your system.
Evaluate serverless options for simple logic
Simple logic is a type of compute that doesn’t require specialized hardware or machine types like CPU-optimized machines. Before you invest in Google Kubernetes Engine (GKE) or Compute Engine implementations to abstract operational overhead and optimize for cost and performance, evaluate serverless options for lightweight logic.
Decouple your applications to be stateless
Where possible, decouple your applications to be stateless to maximize use of serverless computing options. This approach lets you use managed compute offerings, scale applications based on demand, and optimize for cost and performance. For more information about decoupling your application to design for scale and high availability, see Design for scale and high availability.
Use caching logic when you decouple architectures
If your application is designed to be stateful, use caching logic to decouple and make your workload scalable. For more information, see Database best practices.
Use live migrations to facilitate upgrades
To facilitate Google maintenance upgrades, use live migration by setting instance availability policies. For more information, see Set VM host maintenance policy.
https://cloud.google.com/architecture/framework/system-design/compute
What are the best practices an architect uses for scaling workloads for a solution?
This section provides best practices for scaling workloads to support your system.
Use startup and shutdown scripts
For stateful applications, use startup and shutdown scripts where possible to start and stop your application state gracefully. A graceful startup is when a computer is turned on by a software function and the operating system is allowed to perform its tasks of safely starting processes and opening connections.
Graceful startups and shutdowns are important because stateful applications depend on immediate availability to the data that sits close to the compute, usually on local or persistent disks, or in RAM. To avoid running application data from the beginning for each startup, use a startup script to reload the last saved data and run the process from where it previously stopped on shutdown. To save the application memory state to avoid losing progress on shutdown, use a shutdown script. For example, use a shutdown script when a VM is scheduled to be shut down due to downscaling or Google maintenance events.
Use MIGs to support VM management
When you use Compute Engine VMs, managed instance groups (MIGs) support features like autohealing, load balancing, autoscaling, auto updating, and stateful workloads. You can create zonal or regional MIGs based on your availability goals. You can use MIGs for stateless serving or batch workloads and for stateful applications that need to preserve each VM’s unique state.
Use pod autoscalers to scale your GKE workloads
Use horizontal and vertical Pod autoscalers to scale your workloads, and use node auto-provisioning to scale underlying compute resources.
Distribute application traffic
To scale your applications globally, use Cloud Load Balancing to distribute your application instances across more than one region or zone. Load balancers optimize packet routing from Google Cloud edge networks to the nearest zone, which increases serving traffic efficiency and minimizes serving costs. To optimize for end-user latency, use Cloud CDN to cache static content where possible.
Automate compute creation and management
Minimize human-induced errors in your production environment by automating compute creation and management.
https://cloud.google.com/architecture/framework/system-design/compute
What would you consider doing as an architect to manage compute operations to support your system?
This section provides best practices for managing operations to support your system.
Use Google-supplied public images
Use public images supplied by Google Cloud. The Google Cloud public images are regularly updated. For more information, see List of public images available on Compute Engine.
You can also create your own images with specific configurations and settings. Where possible, automate and centralize image creation in a separate project that you can share with authorized users within your organization. Creating and curating a custom image in a separate project lets you update, patch, and create a VM using your own configurations. You can then share the curated VM image with relevant projects.
Use snapshots for instance backups
Snapshots let you create backups for your instances. Snapshots are especially useful for stateful applications, which aren’t flexible enough to maintain state or save progress when they experience abrupt shutdowns. If you frequently use snapshots to create new instances, you can optimize your backup process by creating a base image from that snapshot.
Use a machine image to enable VM instance creation
Although a snapshot only captures an image of the data inside a machine, a machine image captures machine configurations and settings, in addition to the data. Use a machine image to store all of the configurations, metadata, permissions, and data from one or more disks that are needed to create a VM instance.
When you create a machine from a snapshot, you must configure instance settings on the new VM instances, which requires a lot of work. Using machine images lets you copy those known settings to new machines, reducing overhead. For more information, see When to use a machine image.
https://cloud.google.com/architecture/framework/system-design/compute
What are best practices to support best practices for managing capacity, reservations, and isolation to support your system design.
Capacity, reservations, and isolation
This section provides best practices for managing capacity, reservations, and isolation to support your system.
Use committed-use discounts to reduce costs
You can reduce your operational expenditure (OPEX) cost for workloads that are always on by using committed use discounts. For more information, see the Cost optimization category.
Choose machine types to support cost and performance
Google Cloud offers machine types that let you choose compute based on cost and performance parameters. You can choose a low-performance offering to optimize for cost or choose a high-performance compute option at higher cost. For more information, see the Cost optimization category.
Use sole-tenant nodes to support compliance needs Sole-tenant nodes are physical Compute Engine servers that are dedicated to hosting only your project’s VMs. Sole-tenant nodes can help you to meet compliance requirements for physical isolation, including the following:
Keep your VMs physically separated from VMs in other projects.
Group your VMs together on the same host hardware.
Isolate payments processing workloads.
For more information, see Sole-tenant nodes.
Use reservations to ensure resource availability Google Cloud lets you define reservations for your workloads to ensure those resources are always available. There is no additional charge to create reservations, but you pay for the reserved resources even if you don’t use them. For more information, see Consuming and managing reservations.
https://cloud.google.com/architecture/framework/system-design/compute
What are the best practices an architect must consider to support VM Migration for a solution?
Evaluate built-in migration tools
Evaluate built-in migration tools to move your workloads from another cloud or from on-premises. For more information, see Migration to Google Cloud. Google Cloud offers tools and services to help you migrate your workloads and optimize for cost and performance. To receive a free migration cost assessment based on your current IT landscape, see Google Cloud Rapid Assessment & Migration Program.
Use virtual disk import for customized operating systems
To import customized supported operating systems, see Importing virtual disks. Sole-tenant nodes can help you meet your hardware bring-your-own-license requirements for per-core or per-processor licenses. For more information, see Bringing your own licenses.
https://cloud.google.com/architecture/framework/system-design/compute
