GCP Security Foundations and Identity Concepts define who is responsible for what when you store data or run applications in Google Cloud. This matters for the PCSE exam because every security decision you make rests on understanding where Google's job ends and yours begins. Without this foundation, you cannot correctly configure access controls, manage encryption, or pass the certification.
Jump to a section
A simple way to picture GCP Security Foundations and Identity Concepts
An apartment building is a shared security environment. The landlord owns the building, the external walls, the roof, the main entrance, and the infrastructure like plumbing and electricity. The tenant owns everything inside their rented flat: their furniture, their laptop, their jewellery, and their personal safety choices like locking the door or installing a chain.
When you rent a flat, the landlord provides a secure front door to the building and a working lock on your apartment door. However, the landlord cannot and does not secure your jewellery box or decide who you let inside your flat. If you leave your front door wide open and someone steals your laptop, that is your responsibility. Similarly, if the building's main door is broken and a thief walks in and kicks down your apartment door, that is the landlord's responsibility.
This maps directly to GCP Security Foundations and Identity Concepts. Google Cloud (the landlord) secures the physical data centres, the network cables, the hypervisor that runs virtual machines, and the basic storage infrastructure. You (the tenant) are responsible for securing your data, managing who has access to your cloud resources, configuring your virtual machines' operating systems, and setting up firewalls for your applications. Understanding exactly where your responsibility ends and Google's begins is the foundation of cloud security. This boundary is called the shared responsibility model.
Cloud security is built on a model called the shared responsibility model. This model is a legal and operational boundary that splits security tasks between the cloud provider and the customer. In Google Cloud Platform (GCP), Google is responsible for security of the cloud, and you are responsible for security in the cloud.
Security of the cloud means everything Google controls. This includes the physical data centres with their guards, fences, biometric scanners, and backup generators. It includes the network cables, routers, and switches that connect everything together. It includes the hypervisor, which is the software that creates and runs virtual machines. It includes the storage hardware and the basic software that runs GCP services like Cloud Storage and Compute Engine. Google also handles the security of their global network backbone, their encryption at rest and in transit for infrastructure layers, and the physical disposal of old hard drives.
Security in the cloud means everything you control as a customer. This is your data itself, including who can access it, how it is encrypted, and where it is stored. It includes your user accounts, passwords, API keys, and service accounts. It includes the configurations of your virtual machines, such as which operating system you install, which patches you apply, and which firewall rules you set. It also includes your network configurations, like Virtual Private Cloud (VPC) firewalls, load balancer settings, and Cloud VPN tunnels.
Identity Concepts form the second pillar of this chapter. Identity refers to the digital representation of a person, service, or application that needs access to GCP resources. In GCP, the primary identity and access management system is called Cloud IAM. Cloud IAM lets you define who (identity) has what access (role) to which resource.
The core components of Cloud IAM are:
Member: An identity that can be a Google Account (gmail user), a Google Group, a service account (for applications), a Google Workspace domain, or a Cloud Identity domain.
Role: A collection of permissions. A permission is an action that can be performed on a resource, like "compute.instances.create" or "storage.objects.get". Roles are pre-defined by Google (e.g., Viewer, Editor, Owner) or custom-built.
Policy: A binding that attaches a role to a member for a specific resource. Policies are inherited through a resource hierarchy: organisation, folder, project, and resource (like a storage bucket or VM).
Why does this matter? Before cloud computing, companies managed user access with physical security guards and on-premise servers. Every employee had a key to the server room, and network access was controlled by firewalls inside the company building. Cloud changes everything. Now, anyone with internet access and valid credentials can reach your infrastructure from anywhere. This makes identity the new security perimeter. Instead of guarding a building, you guard identities.
The shared responsibility model also applies to identity. Google is responsible for the security of Cloud IAM itself — the service that stores policies and enforces access. You are responsible for who you grant access to and what roles you assign. If you accidentally grant "Editor" role to a random stranger, Google will enforce that permission and let that stranger delete your data. That is your fault, not Google's.
Understanding this model is essential for the PCSE exam. You will be asked to determine who is responsible for specific tasks. For example, if a question asks who is responsible for patching the operating system of a virtual machine you created in GCP, the answer is you, because the operating system is part of your security in the cloud. If the question asks who is responsible for patching the hypervisor that runs your virtual machine, the answer is Google, because the hypervisor is part of the security of the cloud.
Finally, Google Cloud's security foundation rests on nine key principles called the Security Foundations. These include principles like "defence in depth" (multiple layers of security), "least privilege" (give only the minimum access necessary), and "separation of duties" (no single person has too much power). The PCSE exam expects you to know these principles and how they relate to the shared responsibility model.
Define the Resource Hierarchy
Start by planning your organisation's resource hierarchy in GCP. This means creating a root Organisation node (if you have Google Workspace or Cloud Identity), then adding Folders for departments (like Engineering, Finance), then Projects for workloads (like Production, Development). This hierarchy determines how IAM policies are inherited. For example, a policy applied to the Engineering folder automatically applies to all projects within it. Getting this right is critical because restructuring later is difficult.
Identify Your Workload Type
Classify each workload as IaaS, PaaS, or SaaS. This determines your security responsibilities. For a Compute Engine virtual machine (IaaS), you handle the OS, firewall, and patches. For a Cloud Run service (PaaS), Google handles the underlying infrastructure, and you focus on your application code and access controls. For Google Workspace (SaaS), Google handles nearly everything except your user access policies. Document this classification for each workload.
Define Roles and Permissions
Decide what access each member needs using the principle of least privilege. Do not use basic roles (Viewer, Editor, Owner) for production workloads. Instead, use predefined roles like 'roles/storage.objectViewer' for read-only access to storage buckets, or create custom roles with exactly the permissions needed. This reduces the attack surface. For example, a developer who only needs to deploy code should not have permission to delete databases.
Attach IAM Policies to Resources
Create IAM policies by binding a role to a member at the appropriate level in the hierarchy. For example, bind the 'roles/compute.instanceAdmin' role to the 'engineering-team' group at the Project level, not the Organisation level. Use groups instead of individual users to simplify management. Then use the Policy Analyzer tool to verify that only the intended members have access. This step ensures that the access you designed is actually enforced.
Enable Audit Logging and Monitoring
Turn on Cloud Audit Logs to record all IAM changes, resource modifications, and data access. Configure Cloud Monitoring alerts to notify you of suspicious activity, like a service account accessing resources from an unexpected geographic region. Regularly review logs to detect misconfigurations. For example, if someone accidentally makes a storage bucket public, the logs will show a change to the IAM policy, allowing you to revert it quickly.
Review and Rotate Access Regularly
Set a recurring schedule (e.g., quarterly) to review all IAM policies. Remove members who have left the company or changed roles. Rotate service account keys and user passwords. Use the Policy Analyzer to identify over-privileged accounts and reduce their access. This step prevents privilege creep, where users accumulate permissions over time that they no longer need.
Imagine you work at a medium-sized company called "BrightData Analytics". The company collects customer survey data and stores it in Google Cloud Storage. You are the first cloud security engineer hired, and the company has just migrated from on-premise servers to GCP.
Your first task is to understand who is responsible for what. You start by mapping out the infrastructure. The company has two projects in GCP: 'production' and 'development'. You quickly realise that Google already handles the physical security of the data centre where your data resides. You don't need to worry about locks on server racks or securing the building. Google also secures the network between GCP services, so you don't need to worry about someone intercepting data as it moves between Cloud Storage and Compute Engine.
However, you are responsible for several critical things. You need to set up Cloud IAM policies so that only authenticated employees can access the storage buckets. You must ensure that the 'development' project has a different set of permissions than 'production'. Developers should only be able to read production data, not delete it. You also need to configure encryption for the data at rest. Google provides default encryption, but you may choose to use Customer-Managed Encryption Keys (CMEK) for compliance.
A real scenario unfolds when a new data analyst, Sarah, joins the team. You need to give her access to the 'production' storage bucket. Here is your step-by-step actions:
You create a Google Group called 'data-analysts@brightdata.com' and add Sarah to it.
You go to Cloud IAM in the GCP Console and add the group to the 'production' project with the role 'Storage Object Viewer'.
You test access by asking Sarah to list the contents of the bucket from her workstation. She can see the files but cannot delete them or upload new ones.
Three months later, Sarah leaves the company. You remove her from the group, and her access is immediately revoked.
Now consider a security incident. A developer named Tom accidentally uploaded a configuration file with a hardcoded API key to a public Cloud Storage bucket. This is your responsibility because you configured the bucket's access control. Google did not make it public; you did. You must immediately review the bucket's IAM policies and the bucket's ACLs, revoke public access, rotate the API key, and audit the logs using Cloud Logging to see who accessed the file.
Another real-world task is setting up service accounts for applications. Your company uses a web application running on Compute Engine that needs to write data to Cloud SQL. You create a service account (a special identity for the application) and grant it the 'Cloud SQL Client' role. You do not give it broader permissions like 'Editor'. This follows the least privilege principle. The application can only do exactly what it needs to do, nothing more.
Finally, you will regularly audit your IAM policies. You use the Policy Analyzer tool in GCP to see who has access to critical resources. You look for accounts with overly permissive roles like 'Owner' or 'Editor' and reduce them to more specific roles. You also set up alerts using Cloud Monitoring to detect unusual access patterns, like a service account being used from an unexpected IP address.
The PCSE exam tests your understanding of the shared responsibility model directly and indirectly. You will see scenario-based multiple-choice questions where you must decide which responsibility belongs to Google and which belongs to the customer. The trap is that Google includes some customer responsibilities in their documentation as recommendations, not requirements. The exam expects you to know the hard boundary.
Common exam topics include:
Shared responsibility model: Know the exact boundary for IaaS, PaaS, and SaaS. In IaaS (like Compute Engine VMs), the customer has more responsibility (OS, apps, data). In PaaS (like App Engine), Google handles the runtime and middleware. In SaaS (like Google Workspace), Google handles almost everything except the user's data and access policies.
Cloud IAM: Understand the difference between roles, permissions, and policies. Know that there are three types of roles: basic (Viewer, Editor, Owner), predefined (e.g., roles/storage.admin), and custom. The exam loves testing that basic roles are too permissive and should be avoided.
Resource hierarchy: Understand how policies are inherited. A policy set at the organisation level applies to all folders and projects underneath it. A policy set at the project level does not apply to other projects. The exam will test which policy wins when there is conflict: a more specific policy overrides a less specific one.
Service accounts: Know that service accounts are not users; they are identities for applications. You can grant them roles just like a human user. The exam tests that you should not use your personal Google Account for automation; use a service account.
Google Cloud Security Foundations: Know the nine principles: security by design, defence in depth, least privilege, separation of duties, etc. The exam may ask you to identify which principle a specific practice aligns with.
Traps to watch for:
The exam sometimes describes a scenario where a customer encrypts their data with a key stored in Cloud KMS. They then ask who is responsible for the key rotation. Many beginners think Google handles it, but the exam will clarify: if you use Customer-Managed Encryption Keys (CMEK), you are responsible for rotating and managing the keys. If you use Google-managed keys, Google rotates them.
Another trap is around hypervisor patching. A question might say "who patches the operating system of a VM?" The correct answer is the customer. But they might add a distractor that says "Google patches the hypervisor, which is different." Pay close attention to the wording.
The exam tests that Cloud IAM policies are global, not regional. You cannot set a policy that applies only to resources in one zone. If you need that, you need separate projects or organisation policies.
They also test that the 'Owner' role on a project can delete the entire project. This is a common trap: beginners think Owner is safe, but it is extremely dangerous.
Key definitions to memorise:
Member: A user, group, service account, or domain.
Role: A collection of permissions.
Permission: The ability to perform a specific action on a resource.
Policy: A binding of a role to a member for a resource.
Resource hierarchy: Organisation > Folder > Project > Resource.
Defence in depth: Multiple layers of security controls.
Least privilege: Grant only the minimum permissions needed.
Separation of duties: No single person has complete control over a critical task.
The shared responsibility model defines Google's security responsibilities (security of the cloud) and your responsibilities (security in the cloud).
Cloud IAM uses three core components: members (identities), roles (collections of permissions), and policies (bindings of roles to members for resources).
Basic roles (Viewer, Editor, Owner) are overly permissive and should be avoided in favour of predefined or custom roles for least privilege.
Policies are inherited through the resource hierarchy: Organisation, then Folder, then Project, then Resource, with more specific policies overriding less specific ones.
Service accounts are non-human identities for applications and automation, not substitutes for user accounts.
Defence in depth, least privilege, and separation of duties are foundational security principles that directly shape GCP architecture decisions.
In IaaS, the customer is responsible for the operating system and application patches; in PaaS, Google handles the runtime environment.
Customer-Managed Encryption Keys (CMEK) place key rotation and management responsibilities on the customer, not Google.
These come up on the exam all the time. Here's how to tell them apart.
Basic Roles (Viewer, Editor, Owner)
Too broad: Viewer can read all resources in a project
Editor can modify and delete most resources
Owner can delete the entire project
Predefined Roles (e.g., roles/storage.admin)
Specific: roles/storage.admin only grants storage permissions
Follows least privilege principle
Recommended for production workloads
User Account (Human)
Authenticates with password and 2FA
Used by a real person
Should have limited, reviewed permissions
Service Account (Application)
Authenticates with a private key or metadata server
Used by applications and automation
Managed separately with key rotation
IaaS (Compute Engine VM)
Customer manages OS and applications
Customer patches the operating system
Customer configures firewalls and network
PaaS (App Engine)
Google manages runtime and middleware
Google patches underlying infrastructure
Customer focuses only on code and access
Google-Managed Encryption Keys
Google creates, stores, and rotates keys
Customer has no key management responsibility
Simpler but less control
Customer-Managed Encryption Keys (CMEK)
Customer creates and manages keys in Cloud KMS
Customer is responsible for key rotation and access
More control for compliance requirements
Mistake
Google is responsible for everything once I upload data to GCP, because it is their infrastructure.
Correct
Google is responsible for the security of the infrastructure, but you are responsible for securing your data, configuring access, and managing user identities.
This misconception arises because on-premise IT teams were used to being fully responsible for everything, and the idea of shared responsibility is new. The marketing around cloud often emphasises 'Google handles security' without clarifying the boundary.
Mistake
Cloud IAM roles are the same as permissions.
Correct
Roles are collections of permissions. A permission is a single action (e.g., 'storage.objects.delete'), while a role is a bundle of related permissions (e.g., 'Storage Admin' includes many permissions).
The exam documentation uses both terms, and beginners often treat them interchangeably. Learning the distinction is critical for answering policy-based questions.
Mistake
If I grant someone 'Editor' role on a project, they can only edit resources, not delete them.
Correct
The 'Editor' role includes permissions to delete most resources (like VMs and storage buckets), but not delete the project itself. It is still highly permissive.
The name 'Editor' sounds like it only allows modification, but in Google Cloud, it includes destructive permissions. Beginners assume it is safe.
Mistake
Service accounts are the same as user accounts and should be treated identically.
Correct
Service accounts are non-human identities designed for applications and automation. They have no password and are authenticated via key files or metadata. They should never be used as a substitute for human user accounts.
The word 'account' leads people to think of it as a regular user. Also, managing keys for service accounts is different from managing passwords.
Mistake
The shared responsibility model is the same for all cloud services (IaaS, PaaS, SaaS).
Correct
The boundary shifts dramatically depending on the service type. With IaaS you manage the OS and apps; with PaaS, Google manages the runtime; with SaaS, Google manages almost everything except your data and access policies.
Beginners often generalise from one experience. They may have only used SaaS (like Gmail) and assume the same level of responsibility applies to IaaS like Compute Engine.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
It is a framework that splits security responsibilities between Google and the customer. Google secures the infrastructure (data centres, networks, hypervisors), and you secure your data, identities, and configurations.
Cloud IAM is Google's system for managing access to resources. You need it to control who can do what with your cloud assets, like who can read a storage bucket or start a virtual machine.
A permission is a single action (e.g., 'compute.instances.delete'). A role is a bundle of permissions (e.g., 'Compute Admin' includes many compute permissions). You assign roles, not individual permissions, to members.
You are responsible. Google patches the hypervisor, but the OS running inside your virtual machine is your responsibility under the shared responsibility model.
A service account is a digital identity for an application or service, not a human. Use it when an application needs to authenticate to GCP APIs, for example, a web app that writes to Cloud SQL.
Not recommended. You should use Cloud Identity or Google Workspace accounts tied to your organisation, and use service accounts for automation. Personal accounts lack organisational controls and can be compromised.
You've finished GCP Security Foundations and Identity Concepts. Continue through the PCSE study guide to build a complete picture of the exam.
Done with this chapter?