TechnicalFree to read online

Google Cloud Platform Basics: A Working Mental Model

Name: Google Cloud Platform Basics: A Working Mental Model
Availability: InStock
Author: Ahmed Hassan Khan

Hierarchy, identity, compute, storage, networking and cost control on Google's public cloud

This ebook builds a mental model of Google Cloud Platform before you open a console. It explains how organizations, folders and projects organize resources and govern billing and access, how Identity and Access Management binds roles to members, and how compute options range from virtual machines to serverless runtimes. It then covers storage and database choices, the networking building blocks of virtual networks, subnets, routes and firewall rules, and practical habits for keeping spending under control. The final pages apply these ideas to design decisions, common mistakes and a closing review.

Ahmed Hassan Khan, Academic Expert, Technical
18 min read
25 pages

Start reading

What you will learn

Describe how organizations, folders and projects structure Google Cloud resources and billing
Explain how IAM roles bound to members control access without shared passwords
Compare virtual machines, containers and serverless compute options
Choose storage and database services based on structure, latency and durability
Identify networking building blocks and basic cost control practices

vaayaa Guide

vaayaa

Technical · Reference Guide

Google Cloud Platform Basics: A Working Mental Model

Hierarchy, identity, compute, storage, networking and cost control on Google's public cloud

Ahmed Hassan KhanAcademic Expert, Technical

Orientation

001

What Google Cloud Provides

Google Cloud Platform is a public cloud. Instead of buying servers, racks and cooling for your own building, you rent computing power, storage and networking from Google's data centers over the internet. You pay for what you use, and you can ask for more capacity or release it within minutes rather than months.

The catalog is broad, but most work falls into a few families. Compute services run your code or virtual machines. Storage and database services keep files and structured data. Networking services connect everything and control who can reach what. Analytics, machine learning and developer tools sit on top of these foundations.

Public cloud means renting shared, measured infrastructure instead of owning it.

Google describes its platform in terms of role-based certifications, which hints at how the vendor thinks about the work. Its foundational knowledge covers cloud concepts, products and use cases, and it expects learners to understand what a cloud is for before they configure anything. That is the approach taken here.

Think of the platform as a set of building blocks you assemble, not a single product. The rest of this ebook introduces the blocks in a deliberate order, starting with how they are grouped and governed.

Compute 35%
Storage 25%
Networking 20%
Data 20%

Main service families on the platform (Illustrative)

Orientation

002

Cloud Concepts Compared

Three words come up constantly and are often confused. Availability describes whether a service is up when you need it. Scalability describes whether a system can handle more load by adding resources. Elasticity describes whether capacity can grow and shrink automatically as demand changes. A system can be scalable without being elastic if you must add capacity by hand.

Fault tolerance is a separate idea. A fault-tolerant design keeps working when a component fails, usually by running copies in more than one place. Google organizes its infrastructure into regions and zones for this reason, so a single failure does not take an application offline.

Availability, scalability and elasticity are related but distinct, and mixing them up leads to poor designs.

The shared responsibility model is the other concept every beginner should hold. Google secures the physical facilities, the hardware and much of the underlying platform. You remain responsible for your data, your configuration, who has access and how your applications are coded. Misunderstanding this boundary causes many security gaps.

These terms form the vocabulary for the rest of the book. When later pages mention elastic scaling or zonal failure, they assume you can place each word correctly.

Uptime

Scalability

Elasticity

Related but distinct cloud terms

Orientation

003

The Resource Hierarchy

Google Cloud arranges resources in a hierarchy with three levels that matter most. An organization sits at the top and represents your company, tied to a Google Workspace or Cloud Identity domain. Folders sit beneath it and group projects by department, environment or team. Projects are the base containers where resources actually live.

Each project has its own identifier, its own set of enabled APIs and its own resources such as virtual machines, buckets and databases. Access and billing are inherited downward. A policy set on a folder applies to every project inside it unless a narrower rule overrides it. This inheritance is why a well-shaped hierarchy saves effort.

The project is the container that holds resources and links them to billing.

Projects are also the main unit of billing. Charges accrue to a billing account, which can be linked to one or more projects. Separating workloads into projects makes costs easier to attribute and limits the blast radius of mistakes.

A common pattern is to create folders for production and non-production, then projects inside each. The structure is not fixed, but the rule is consistent: the hierarchy governs access and billing, so design it before filling it.

Organization

Folder

Project

Resource

Levels of the resource hierarchy

Orientation

004

Working Through the Console

Google Cloud offers several ways to work with resources: a web console, a command-line tool, and client libraries for programming languages. The console is the most visual and suits learning. The command-line tool suits repeatable tasks and scripts. Every action you take in the console corresponds to an underlying API call.

Before creating anything, a learner should establish a working cycle. Assess what you need, plan the resources and their location, act by creating or changing them, and then review the result, checking logs, costs and access. Repeating this loop keeps mistakes small and visible.

Work in a cycle of assess, plan, act and review, and clean up what you create.

The cycle also applies to learning. Read the concept, try it in a project you can delete, observe what appears in the billing and activity views, and adjust. Treating each change as an experiment with a clear review step builds reliable habits early.

Set expectations about cost and clean-up from the first session. Delete resources you no longer need, because idle virtual machines and stored data continue to generate charges even when nobody uses them.

Assess

Plan

Act

Review

Repeating work cycle

Core Concepts

005

Identity and Access Management

Identity and Access Management, usually shortened to IAM, decides who can do what on which resource. The model has three parts. A member is an identity, such as a Google account, a service account for an application, or a group. A role is a named collection of permissions, such as the ability to view or create instances. A policy binds members to roles on a resource.

Permissions are never granted to a person in isolation. You bind a role to a member at a level of the hierarchy, and it applies to everything beneath that level. Granting a role at the organization level affects every folder and project, which is powerful and risky. Granting at project level is more contained.

Bind narrow roles to members at the lowest sensible level, and avoid broad basic roles.

Predefined roles come from Google and bundle permissions for common jobs. Basic roles such as owner, editor and viewer are broad and should be used sparingly. Service accounts let applications authenticate without a human password, which is the preferred pattern for automation.

The principle to hold is least privilege: give each member only the roles needed for the task, and review them when responsibilities change.

Member

Role

Policy

Resource

Parts of an IAM binding

Core Concepts

006

Members, Roles and Policies

Consider how the parts fit in a concrete case. A developer needs to read files from a storage bucket but must not delete them. Rather than sharing an administrator account, you add the developer's Google identity as a member and bind a viewer-style storage role to that bucket or its project.

An application that runs on a virtual machine follows the same logic, but its member is a service account. You grant that service account only the storage permissions it requires. If the application is compromised, the damage is limited to what that identity can reach.

Trace each permission back to the binding that grants it, including inherited ones.

Policies are inherited, and an inherited allow can be surprising. A role granted at a folder reaches every project below it, so checking the effective policy at the resource you care about is a habit worth building. Tools in the console show where a permission comes from.

Good practice treats role assignments as code-like records that are reviewed, documented and removed when no longer needed.

Request

Find member

Check roles

Allow deny

Process flow of an access decision

Core Concepts

007

Choosing Compute Options

Compute options sit on a spectrum from full control to full abstraction. Compute Engine provides virtual machines where you manage the operating system, patches and runtime. It suits lift-and-shift workloads and software that expects a traditional server. You choose a machine type that sets processors and memory, then control everything inside.

Containers package an application with its dependencies. Google Kubernetes Engine runs containers in a managed cluster and suits teams that need orchestration, scaling policies and portability. Cloud Run runs containers without you managing the cluster, scaling instances on demand and charging for the time requests actually run.

Move up the abstraction ladder only as far as the workload's control needs allow.

Serverless functions go further. Cloud Functions runs small units of code triggered by events, such as a file upload or a message, with no servers to configure. These are attractive for glue logic and event handlers but less suited to long, stateful processes.

The trade-off is control against operational effort. More abstraction means fewer decisions to manage, but less freedom to tune the environment. Match the option to the workload's requirements, not to fashion.

Virtual machines

Containers

Serverless

Common compute options by abstraction (Illustrative)

Core Concepts

008

Storage and Database Services

Storage services differ by structure, latency and durability. Cloud Storage holds unstructured objects such as images, backups and logs in buckets. It is accessed over an API, scales without provisioning disks, and offers storage classes that trade retrieval speed for lower cost on rarely used data.

Persistent Disk provides block storage attached to virtual machines, behaving much like a physical disk to the operating system. It suits boot volumes and databases you run yourself. Its performance depends on the disk type and size you select.

Pick storage by data shape, latency requirement and tolerance for loss, not by brand familiarity.

Managed databases cover structured data. Cloud SQL runs familiar relational engines as a managed service. Firestore stores documents for applications that need flexible schemas and real-time updates. Bigtable handles very large, sparse datasets with low latency. Spanner offers relational structure with global consistency.

Choose by asking three questions: what shape is the data, how quickly must it be read or written, and how much loss can you tolerate if something fails. The answers usually point to one service.

Data shape

Latency

Loss tolerance

Pick service

Choosing storage by three questions

Core Concepts

009

Networking Building Blocks

Every project has a Virtual Private Cloud, or VPC, which is a software-defined network. A VPC is global, meaning it spans regions, while subnets are regional and carry IP address ranges. Virtual machines and other resources attach to subnets and receive internal addresses from them.

Routes determine where traffic goes. Each VPC has routes for internal traffic and for reaching the internet through a default gateway. You can add custom routes to direct traffic to specific destinations. Traffic between subnets in the same VPC is routed automatically.

Subnets are regional, routes direct traffic, and firewall rules decide what is allowed.

Firewall rules control which traffic is allowed in and out. Rules are stateful and apply to instances through network tags or service accounts. A typical design allows web traffic to a front-end group and blocks direct access to a private database group.

Load balancers distribute requests across instances and can route by path or region. Together, VPCs, subnets, routes, firewall rules and load balancers form the layers most applications depend on.

	Allow	Restrict	Monitor
Subnets	●●	●●	●
Routes	●●	●●●	●
Firewall	●●●	●●●	●●

Layers of network control

Core Concepts

010

A Mental Model of Resources

Pulling the earlier pages together gives a working map. Resources live in projects, projects live in folders, and folders live under an organization. Each resource is reached through a network, protected by firewall rules, and touched by identities holding roles. Billing attaches to projects.

Think of it as concentric rings. The outer ring is governance: organization, folders and policies. The next ring is identity: who holds which roles. Inside that sit networks that connect compute and storage. At the center are the workloads themselves.

When something fails, check governance, then identity, then network, then the workload.

This model explains many confusing moments. A user who cannot see a resource often lacks a role at the correct level, or the resource sits in a project they cannot reach. A bill surprise usually traces to a project nobody was watching. An outage often traces to a firewall rule or route.

Keep the ring model as a checklist when you troubleshoot. Start with the outer ring and move inward until you find the layer that explains the symptom.

GCP
Resources

Projects

Folders

IAM roles

Subnets

Firewall

Billing

Core ideas connected to resources

Methods

011

Planning Regions and Zones

Google Cloud places infrastructure in regions, which are independent geographic areas, and zones, which are isolated locations within a region. A zone is a deployment area for resources such as virtual machines and disks. Zonal resources exist in one zone. Regional resources are spread across zones within a region.

Location affects latency, data residency and resilience. Placing an application close to its users reduces delay. Placing it in a region that meets legal or contractual requirements keeps data where it must be. Spreading a service across zones protects against a single zone failing.

Choose regions for latency and residency, and spread across zones for fault tolerance.

Some services are global, such as the VPC network itself and many load-balancing front ends. Others are fixed to a region or zone. Knowing which is which prevents designs that quietly depend on a single location.

Document the chosen region and zone for each resource as part of planning. Changing location later often means rebuilding rather than moving.

Global 30%
Regional 40%
Zonal 30%

Illustrative mix of placement scopes (Illustrative)

Methods

012

Designing Identity Boundaries

Identity boundaries decide how far a group of members can reach. A boundary is usually drawn at the folder or project level, matching the hierarchy. Development, testing and production are classic boundaries, because a mistake in one should not affect the others.

Groups simplify administration. Instead of binding a role to dozens of individuals, bind it once to a group and manage membership separately. Groups also make onboarding and offboarding faster and less error-prone.

Draw boundaries that match the hierarchy, and give each application its own service account.

Service accounts form their own boundaries for applications. Each service should have its own account with only its own permissions, so one compromised component cannot act as another. Sharing a single powerful service account across many applications removes this protection.

Reviewing boundaries periodically keeps them honest. Roles accumulate over time when people change jobs and rarely shrink on their own.

Projects

Groups

Service
accounts

Three kinds of identity boundary

Methods

013

Architecture Pattern Choices

Architecture patterns are repeatable answers to common problems. A three-tier web application separates a front end, an application layer and a data layer, each on its own subnet with firewall rules that permit only the adjacent tier. This limits exposure of the database to the internet.

Autoscaling uses instance groups that add or remove virtual machines as load changes. Pairing a managed instance group with a load balancer lets the platform absorb traffic peaks. Instance templates ensure each new machine starts identically.

Start with the simplest pattern that meets the requirement, then add scaling and decoupling only when justified.

Event-driven designs connect services through messages. A file upload can trigger a function, which writes a record and notifies another service. Decoupling reduces the chance that one slow component stalls the others.

Choose patterns based on the workload's demand shape and failure tolerance. Simple applications often need only a single region with a managed service, and adding complexity without need costs money and attention.

Front end

Application

Data

Storage

Tiers of a three-tier application

Methods

014

Operating With a Cycle

Operating a cloud environment is a continuing loop. You assess current state, plan changes, treat issues by deploying or adjusting resources, and review outcomes. The loop repeats indefinitely, because workloads, costs and threats keep changing.

The assess step reviews utilization, logs, access and spending. The plan step sets targets, such as a cost ceiling or a latency goal. The treat step changes configuration, such as resizing a machine or tightening a rule. The review step checks whether the change worked and whether anything else moved.

Operations is a loop of assess, plan, treat and review, repeated on a schedule.

Keeping this loop visible prevents drift. Environments that are never reviewed accumulate unused disks, excess roles and forgotten projects. A scheduled review, even brief, catches these before they grow.

Record each cycle's findings so the next one starts from evidence rather than memory.

Assess

Plan

Treat

Review

The operating loop

Methods

015

Deployment Process Steps

A deployment moves a change from design to running service in predictable stages. Begin by defining the resources and their settings, typically in a version-controlled file so the definition can be reviewed and repeated.

Next, deploy into a non-production project first. Test that the application starts, that roles grant what they should, and that firewall rules allow only the intended traffic. Problems found here are cheap to fix.

Test in a non-production project, promote the same definition, and keep a tested rollback.

Then promote the same definition to production, changing only the values that must differ such as project name or region. Keeping the definition identical across environments reduces surprises.

Finally, monitor the live service and keep a rollback path. A rollback that has never been tested is a hope rather than a plan.

Define

Test

Promote

Monitor

Stages of a safe deployment

Methods

016

Data Flow Through a Stack

Follow a request through a typical stack to see the layers interact. A user's browser sends a request that first reaches a global load balancer. The balancer forwards it to a regional group of instances in a subnet that allows only web traffic.

The instance reads configuration and secrets using its service account, which holds a narrow role. It then queries a database in a private subnet. Firewall rules block any route from the internet directly to that database.

Trace each request across balancer, subnet, identity and database to locate problems.

The database returns results, the application responds, and logs record the transaction. Each hop is a place where identity, network or cost decisions apply.

Tracing a request this way helps you find the layer responsible for a slow response or a denied call.

Browser

Load balancer

Instance

Database

Request path through a stack

Applications

017

Cost Control in Practice

Cost control starts with visibility. Billing reports break down charges by project, service and label. Labels are key-value tags you attach to resources so spending can be grouped by team, environment or application. Applying labels consistently from the beginning makes later analysis far easier.

Budgets and alerts notify you when spending approaches a threshold. An alert does not stop charges by itself, but it prompts action. Pair alerts with a named owner for each project so someone responds.

Label resources, set budget alerts with owners, and remove what nobody uses.

Right-sizing matches machine types to actual use. An oversized virtual machine costs money every hour it runs. Storage classes also matter: data rarely accessed belongs in a colder, cheaper class, while frequently read data belongs in a standard one.

Clean-up completes the picture. Stop or delete idle resources, remove unused disks and snapshots, and close projects that are no longer needed.

Right-sizing

Idle removal

Storage class

Commitments

Share of cost levers (illustrative) (Illustrative)

Applications

018

A Timeline for Adoption

Adopting Google Cloud is easier when it moves in stages. The first stage is learning the vocabulary and hierarchy on a throwaway project, which costs little and teaches a great deal. Google's foundational certification path reflects this emphasis on cloud concepts before configuration.

The second stage establishes governance: folders, billing structure, baseline roles and labels. Doing this before workloads arrive prevents a tangle of unowned projects later.

Adopt in stages: learn, govern, move one workload, then expand with reviews between steps.

The third stage moves a first workload, usually a single service with clear boundaries. Success here builds confidence and a repeatable pattern for others.

The fourth stage expands, adding automation, monitoring and more complex architectures. Each stage ends with a review, and each review feeds the next.

Learn basics

Set governance

Move workload

Expand

Review

Stages of cloud adoption

Applications

019

Rating Options for Different Needs

No single service fits every situation, so comparing options against needs is essential. Consider control, operational effort and cost predictability for each candidate. A virtual machine offers high control but demands patching. A managed service reduces effort but limits tuning.

Rating each option across these dimensions makes the trade-off explicit. The scores below are qualitative judgments for learning, not benchmarks, and should be replaced by the team's own assessment for real decisions.

Compare options on control, effort and predictability, because labor is part of total cost.

The exercise reveals that the cheapest option is not always the lowest total cost, because operational labor is a real cost. Include the time spent maintaining a system when comparing.

Record the reasoning behind each choice so future teams can revisit it when requirements change.

	Control	Effort	Predictability
Virtual machines	●●●	●●●	●●
Containers	●●	●●	●●
Serverless	●	●	●●●

Qualitative fit of options (1 low, 3 high)

Applications

020

Mindmap of Decision Areas

Most decisions on Google Cloud fall into a small set of areas. Governance decides structure and billing. Identity decides access. Compute and storage decide where work runs and where data lives. Networking decides how components reach each other and the outside world. Operations decides how the environment is watched and maintained.

These areas interact. A choice in compute affects which identities it needs and which network paths it uses. A storage choice affects backup and cost. Mapping the areas together helps you see the knock-on effects of each decision before committing.

Walk each decision area before deploying, and note the open questions in every one.

Use the map as a review tool. For any new workload, ask a question in each area and note what you have not yet decided. Gaps in the map usually become problems later.

The goal is not completeness on day one but awareness of which decisions remain open.

Workload
Design

Governance

Identity

Compute

Storage

Networking

Operations

Decision areas for a workload

Applications

021

Where Spending Concentrates

Spending on a typical environment is not evenly spread. Compute usually accounts for a large share, followed by storage and data services, with networking charges depending heavily on how much data leaves the platform. The shares shift with each workload, so measure your own rather than assuming.

The donut below uses illustrative proportions to show the idea of concentration. It is not a benchmark. Your billing reports show the true split for your environment.

Optimize the cost categories that dominate your own billing report, not a generic average.

Understanding the split tells you where optimization pays off. Reducing a large compute line by a modest percentage can outweigh eliminating a small storage line entirely.

Revisit the split after each major change, because a new workload can move the balance quickly.

Compute 50%
Storage 25%
Networking 15%
Other 10%

Illustrative cost concentration by category (Illustrative)

Practice and Review

022

Common Mistakes to Avoid

The most frequent beginner mistake is granting broad roles because they are convenient. An owner role on a project lets its holder change nearly everything, and sharing it widely turns small errors into large incidents. Narrow roles take slightly longer to set up and prevent far more trouble.

Another mistake is building everything in one project. Without separation, billing becomes hard to attribute, permissions spread unpredictably and a single error can reach production. Separate projects by environment and by team.

Avoid broad roles, shared projects, forgotten resources and single-zone designs.

Leaving resources running after a test is the costliest common error. A forgotten virtual machine or large disk accrues charges silently. Scheduling clean-up and using budget alerts reduces this risk.

Finally, many learners assume a region or zone is permanent and fail to plan for failure. Spreading critical resources across zones costs more but prevents a single location from becoming a single point of failure.

Broad
roles

Shared
projects

Forgotten
resources

Frequent beginner mistakes to avoid

Practice and Review

023

Review of Core Vocabulary

Review the terms that anchor everything else. An organization is the top of the hierarchy. A folder groups projects. A project holds resources and links to billing. A member is an identity, a role is a bundle of permissions, and a policy binds members to roles on a resource.

Availability, scalability and elasticity describe system behavior. Regions and zones describe location. A VPC is the global network, a subnet is a regional range within it, a route directs traffic, and a firewall rule permits or blocks it.

Explain each term and its neighbors in your own words to confirm the model is sound.

Compute ranges from virtual machines through containers to serverless functions. Storage ranges from objects and block disks to managed databases, chosen by shape, latency and durability.

If you can explain each term in your own words and connect it to a neighbor, the mental model is in place.

Organization

Folder

Project

Resource

Terms that form the core set

Practice and Review

024

Closing Review and Next Steps

This ebook has built a mental model in stages. You saw what the platform provides, how the hierarchy governs resources and billing, how IAM binds roles to members, how compute and storage options differ, how networking is layered, and how cost and operations stay under control.

Each part depends on the one before. Governance shapes identity, identity shapes access to compute and storage, and networking connects them all. Operations keeps the arrangement healthy over time.

Apply the model in a disposable project, then remove everything you created.

The next step is to apply the model in a sandbox project. Create a folder and a project, bind a narrow role to a test identity, launch a small virtual machine, observe its billing, and then remove everything. The exercise is short and covers the whole model.

Revisit the vocabulary and the operating cycle whenever a new service feels confusing. The concepts stay constant even as the catalog changes.

Assess

Plan

Treat

Review

The closing operating cycle

References

025

References and Learning Sources

vaayaa References

vaayaa Statistics, vaayaa Sprouter discourses on Google Cloud Platform Basicshttps://vaayaa.com/sprouter
vaayaa Editorial Team, vaayaa News on Azure Cloud Fundamentalshttps://vaayaa.com/news
vaayaa Research Desk, vaayaa Sprouter discourses on Cloud Architecture Planninghttps://vaayaa.com/sprouter
vaayaa Subject Matter Review, vaayaa News on Cloud Computing and DevOps Engineeringhttps://vaayaa.com/news

Learning Sources

Micro Degree Google Cloud Platform Basicshttps://vaayaa.com/course/google-cloud-platform-basics
Micro Degree Azure Cloud Fundamentalshttps://vaayaa.com/course/azure-cloud-fundamentals
Micro Degree Cloud Architecture Planninghttps://vaayaa.com/course/cloud-architecture-planning
Micro Degree Cloud Computing and DevOps Engineeringhttps://vaayaa.com/course/cloud-computing-and-devops-engineering
Micro Degree AI Solution Developmenthttps://vaayaa.com/course/ai-solution-development

Google Cloud Platform Basics: A Working Mental Model

What you will learn

Contents

What Google Cloud Provides

Cloud Concepts Compared

The Resource Hierarchy

Working Through the Console

Identity and Access Management

Members, Roles and Policies

Choosing Compute Options

Storage and Database Services

Networking Building Blocks

A Mental Model of Resources

Planning Regions and Zones

Designing Identity Boundaries

Architecture Pattern Choices

Operating With a Cycle

Deployment Process Steps

Data Flow Through a Stack

Cost Control in Practice

A Timeline for Adoption

Rating Options for Different Needs

Mindmap of Decision Areas

Where Spending Concentrates

Common Mistakes to Avoid

Review of Core Vocabulary

Closing Review and Next Steps

References and Learning Sources

vaayaa References

Further Reading

Learning Sources

More in Technical

IT Service Management: A Practical Field Guide

IT Service Management and Enterprise Operations Explained

Infrastructure as Code: A Practical Reference

Large Language Models: A Working Reference