Security Best Practices and IAM for Networking. It solves the fundamental question of who or what gets to touch your cloud network — and what they are allowed to do once they're there. For the PCNE exam, understanding this is non-negotiable because you will be asked to design networks that are both functional and locked down, and IAM is the tool that makes that possible.
Jump to a section
A simple way to picture Security Best Practices and IAM for Networking
What if anyone who walked into your apartment building could wander straight up to your front door and try the handle?
That's what a network without IAM (Identity and Access Management) is like. IAM is the security desk in a large condominium complex. You, the building manager, get to decide exactly who can enter, which floor they can access, and whether they can open specific doors.
Think about how the desk works. Every visitor must present valid ID (authentication) — proving they are who they say they are. The guard checks a list (authorisation) to see if that person is allowed on Floor 5. Some people get a master key — network admins who need to go everywhere. Others get a one-day pass for the pool — a temporary access token that expires. The guard doesn't just let in anyone wearing a uniform; they check the specific permission tied to that individual's ID.
Now, the critical part: the guard never gives a resident more access than they need for their job. The plumber gets basement and your unit only, not the roof. This is the Principle of Least Privilege. In networking, you apply the same logic. A virtual machine that only needs to serve web pages should not have permission to delete databases. The security desk enforces that boundary — just like IAM roles in the cloud enforce boundaries between network resources. If someone steals a contractor's badge, the desk can revoke just that one badge without changing everyone else's access. That's exactly what IAM lets you do: adjust permissions for one user or service without breaking anything else.
Let's start with the bare bones. IAM stands for Identity and Access Management. In Google Cloud, IAM is the system that controls who (a user, a group, or a service) has what access to which resources. A resource in Google Cloud is anything you create and manage — a Virtual Private Cloud (VPC) network, a firewall rule, a Cloud Router, a subnet, or a VPN gateway. Every time you try to do something to a resource — like deleting a subnet or modifying a firewall rule — IAM checks whether you are allowed to perform that action.
IAM has three core parts: the principal, the role, and the resource. The principal is the who — it can be a human user account, a Google Group, a service account (an automated identity used by applications), or even an entire Google Workspace domain. The role is a collection of permissions. A permission is a single action you can perform, like "compute.firewalls.delete" to delete a firewall rule. Roles bundle dozens or hundreds of permissions together. The resource is the thing you are acting on — for example, a specific VPC network called "my-vpc".
There are three types of roles in Google Cloud IAM:
Basic roles (also called primitive roles): Owner, Editor, and Viewer. These are broad and apply across all resources in a project. An Editor can change anything in the project — including deleting networks. These roles are too powerful for most real-world work and violate the Principle of Least Privilege.
Predefined roles: Google has created hundreds of specific roles that match job functions. For networking, there is roles/compute.networkAdmin (full control over network resources), roles/compute.securityAdmin (control over firewall rules and SSL certificates), and roles/compute.viewer (read-only access). These roles are much safer than basic roles because they only grant the permissions needed for a specific job.
Custom roles: you create your own role by picking exactly which permissions you want to include. This gives you fine-grained control, but it also means you must maintain the role definition yourself.
The most important concept for PCNE is the resource hierarchy. Google Cloud organises everything into a hierarchy: an Organisation node sits at the top (your company), then Folders (departments), then Projects (each project is a container for resources like VPCs), and finally Resources (the actual VPC, subnet, firewall, etc.). IAM policies are inherited downwards. If you grant a principal the Network Admin role at the Organisation level, they have that role on every project in the organisation. If you grant it at the Project level, they only have it in that specific project. If you grant it on a single VPC, they only control that VPC. This inheritance is a trap on the exam — you must know exactly where a policy is applied to determine who can do what.
Service accounts deserve special attention because they are a major exam topic. A service account is a special kind of Google account that belongs to an application or a virtual machine (VM), not a human. For example, if you run a web server on a Compute Engine VM, that VM can use a service account to authenticate to Google Cloud APIs. You grant roles to that service account, not to the VM directly. If you give the service account permissions to write to Cloud Storage, then the application running on that VM can write to Cloud Storage. This is how you securely connect network resources to other services without embedding passwords in code.
Firewall rules and IAM work together but are different. IAM controls who can create, modify, or delete firewall rules. Firewall rules themselves control traffic flowing through the network — which IP addresses and ports are allowed. Both are essential for security, but they operate at different levels. IAM is about administrative control; firewall rules are about network traffic control.
Why does all this matter? Without IAM, anyone with access to your cloud console could delete your entire network. With proper IAM, you give a junior engineer only the "Firewall Admin" role so they can add firewall rules but cannot delete the VPC itself. You give a database server a service account that can only talk to Cloud SQL, not read your secrets. This is how you build a secure, multi-tenant network in the cloud.
Identify the Principal
Determine who or what needs access. This could be a human user (using their Google account), a Google Group, a service account for an application, or an entire Google Workspace domain. Each principal is assigned a unique email-style identifier.
Select the Appropriate Role
Choose a role that grants exactly the permissions needed. Prefer predefined roles like roles/compute.networkAdmin or roles/compute.securityAdmin. Avoid basic roles. If no predefined role fits, create a custom role with only the required permissions.
Define the Scope
Decide where to apply the IAM policy — at the Organisation, Folder, Project, or individual Resource level. Remember that policies inherit downwards. For networking, you often apply roles at the Project level or directly on a VPC resource to limit scope.
Attach Conditions (Optional)
Use conditional IAM to add restrictions based on resource name, resource type, or time. For example, grant the networkAdmin role only for VPCs whose name starts with 'prod-' and only between 9 AM and 5 PM. This adds a security layer even if the role itself is broad.
Test and Audit
Use the IAM policy simulator in Google Cloud to verify that the intended access works and no unintended permissions are granted. Regularly review IAM policies using the Cloud Asset Inventory and enable audit logs to monitor all IAM changes.
Document and Review
Document every role assignment, including the principal, role, scope, and condition. Schedule periodic reviews (e.g., quarterly) to remove unused roles or principals. For service accounts, rotate keys or use Workload Identity Federation to avoid long-lived credentials.
Hannah is a cloud engineer at a retail company called ShopFast. The company has three environments: development, staging, and production. Each environment is a separate Google Cloud project. Hannah uses IAM to enforce strict separation between these environments.
First, she creates a custom role called "network-monitor" that includes only two permissions: compute.subnetworks.list and compute.firewalls.list. She assigns this role to the on-call operations team in all three projects. Those team members can see what exists but cannot change anything. This reduces risk if someone accidentally runs a destructive command.
Next, she creates a service account for the production web application. She names it "prod-web-sa@shopfast-project.iam.gserviceaccount.com". She grants this service account the role "roles/compute.loadBalancerAdmin" so the application can register itself with the HTTPS load balancer. She does not grant any other roles — the service account cannot touch databases, storage buckets, or other networking components. If an attacker compromises the web application, they cannot pivot to other resources because the service account lacks those permissions.
Then, Hannah needs to allow a DevOps contractor to modify firewall rules for a specific VPC called "prod-vpc". She does not give the contractor the Network Admin role (which would let them delete subnets). Instead, she uses conditional IAM — a feature that lets you grant access only when certain conditions are met. She creates a condition that restricts the role to resources with the name prefix "prod-vpc" and only during business hours (9 AM to 5 PM). Now the contractor can only touch that one VPC, and only during working hours.
Finally, Hannah notices that the security audit requires that no single human has the ability to delete a production network alone. She implements "Break Glass" access — a custom role with full network admin permissions that is only granted to a specific group, and a manager must approve each use via an automated request. The role is not assigned permanently; it is granted temporarily through an access approval system.
In total, Hannah uses:
Custom roles to limit permissions to exactly what is needed.
Service accounts with minimal roles for each application.
Conditional IAM to restrict access by resource name and time.
Break glass procedures for emergency scenarios.
All of these practices come directly from the IAM and security best practices that the PCNE exam tests.
The PCNE exam loves to test your understanding of IAM inheritance and the Principle of Least Privilege. You will see scenario-based questions where a user performs an action (like creating a firewall rule) and you must determine whether the action is allowed based on the IAM policies in place. The trap is often that the user has a role at the project level but the resource is in a different project, or vice versa.
Key exam topics include:
The difference between basic (primitive) roles and predefined roles. They will ask you which role to recommend for a security admin who only needs to manage firewalls. The answer is roles/compute.securityAdmin, not roles/compute.admin or roles/editor.
Service account best practices. Questions will test whether you know to create a dedicated service account per application rather than reusing the same one. They also test that you should not disable a service account that is still in use by a running VM — this will break the application.
Conditional IAM. You must understand that conditions can be based on resource name, resource type, or time. They might ask: a user needs access to a specific VPC but not others in the same project — what do you do? The answer: grant the role with a condition that filters by resource name.
Resource hierarchy inheritance. A common trap: if a user has the Network Admin role at the Organisation level but no roles at the Project level, they still have Network Admin across all projects. If you later grant them the Viewer role at the Project level, they now have both — Viewer plus Network Admin. The more permissive role wins.
Firewall rule permissions. IAM controls who can create firewalls, but the firewall rules themselves control traffic. The exam will test that you understand the boundary: IAM = admin access, firewall = traffic filtering.
Trap patterns to watch for:
They give a long scenario where a user seems to lack permission, but the answer is that the role is inherited from a higher level in the hierarchy.
They ask about granting access to a subnet directly — this is not possible in Google Cloud. You grant access to the VPC, and subnet access follows.
They present a service account key and ask about best practices — you should never download and share service account keys if you can avoid it. Use Workload Identity Federation instead.
Key definitions to memorise:
Principal: the identity (user, service account, group, domain).
Role: a set of permissions.
Permission: a specific allowed action.
Resource hierarchy: Organisation > Folders > Projects > Resources.
Service account: an identity for applications, not humans.
Conditional IAM: granting access only when a condition (like resource name or time) is met.
IAM uses a three-part model: principal (who), role (what they can do), and resource (what they do it to).
The Principle of Least Privilege means granting only the minimum permissions necessary for a job — never use basic roles like Editor or Owner in production.
Service accounts are identities for applications, not humans; each application should have its own service account with minimal roles.
Conditional IAM allows you to restrict access based on resource attributes (like name) or time (like business hours), adding a fine-grained security layer.
IAM policies are inherited down the resource hierarchy: Organisation → Folder → Project → Resource, so a role at a higher level applies to all lower levels.
IAM controls administrative access to network resources, while firewall rules control network traffic — they serve different purposes and must be used together.
Custom roles give you precise control but require maintenance; prefer predefined roles unless you have a specific need that they do not cover.
The PCNE exam frequently tests the resource hierarchy and inheritance — pay close attention to where a role is assigned in scenario questions.
These come up on the exam all the time. Here's how to tell them apart.
Basic Roles (Primitive)
Includes Owner, Editor, Viewer across all resources in a project
Too broad — grants permissions beyond what a network admin needs
Cannot be customised; you get all or nothing
Predefined Roles
Designed for specific job functions like Network Admin or Security Admin
Grant only the permissions needed for that job, following least privilege
Created and maintained by Google, with no customisation unless you use custom roles
IAM Policy at Project Level
Applies to all resources within the project, including all VPCs
Easier to manage when you want uniform access across the project
Higher risk of over-permissioning because scope is broad
IAM Policy at Resource Level (VPC)
Applies only to a specific VPC resource, not to other VPCs in the same project
More granular and secure for multi-team environments
Requires explicit policy attachment per resource, more management overhead
Firewall Rules
Controls network traffic (source IP, destination, port, protocol)
Applied to VPCs or subnets, not to users
Evaluated per packet flow through the network
IAM Roles
Controls who can create, modify, or delete resources
Assigned to principals (users, groups, service accounts)
Evaluated when an API call is made to change a resource
Service Account
Used by applications and VMs, not by humans
Has no password; uses keys or Workload Identity Federation
Cannot be used to log into the Google Cloud Console directly
User Account
Used by human operators to log into the console or use CLI
Protected by password and MFA (Multi-Factor Authentication)
Can have its own IAM roles separate from service accounts
Mistake
IAM roles on a VPC network automatically apply to all subnets within that VPC.
Correct
IAM roles applied to a VPC network apply to the VPC resource itself (ability to modify the VPC, add subnets, etc.) but do not directly control access to individual subnets. Subnet-level permissions are not a separate IAM concept; you manage traffic at the subnet level through firewall rules, not IAM.
People confuse administrative control (IAM) with network traffic control (firewalls). The VPC role lets you manage the network, but traffic within subnets is governed by firewall rules.
Mistake
A service account must have the same permissions as the human who created it.
Correct
A service account is a separate identity with its own set of roles. The human who creates the service account does not automatically get its permissions, and the service account does not inherit the human's permissions. They are completely independent.
Newcomers think the service account is an extension of the user, but it is a distinct principal in IAM.
Mistake
If you grant a role at the project level, it applies to all current and future resources in that project, including those in other organisations.
Correct
A project-level role applies only within that specific project. Resources in different projects (even under the same organisation) are not affected unless the role is granted at the organisation level.
People misunderstand the scope of the resource hierarchy and think a project is higher in the hierarchy than it actually is.
Mistake
Using a basic role (like Editor) is acceptable for a network admin because they need broad access.
Correct
Using basic roles is a security anti-pattern. The Editor role grants full control over all resources, including creating or deleting networks, which violates the Principle of Least Privilege. Predefined roles like roles/compute.networkAdmin are far more secure and specific.
Basic roles are easy to understand and seem convenient, so beginners gravitate toward them without realising the risk.
Mistake
IAM policies are evaluated at the resource level only, not at the organisation level.
Correct
IAM policies can be set at any level of the resource hierarchy — Organisation, Folder, Project, or individual Resource. Policies are inherited downwards, so a policy at the Organisation level affects all child folders and projects.
Many beginners assume IAM is only about individual resources and miss the inheritance model, which is a core exam concept.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
IAM controls who can create, modify, or delete network resources (like VPCs and firewall rules). Firewall rules control which network traffic (source IP, destination IP, port, protocol) is allowed or denied through the network. They work together but operate at completely different levels.
No, IAM does not support granting access to individual subnets. You can grant IAM roles on a VPC network resource, which then allows management of the entire VPC, including all its subnets. To control traffic to a specific subnet, you use firewall rules, not IAM.
The principal gets the union of all permissions from all assigned roles. There is no conflict resolution — having a less permissive role does not cancel out a more permissive one. If one role allows deleting firewall rules and another does not, the principal can still delete firewall rules because the more permissive permission wins.
No. The default service account has broad permissions (Editor role) by default and is shared across multiple VMs. Best practice is to create dedicated service accounts with minimal roles for each application or VM and avoid using the default service account entirely.
Grant the user the roles/compute.securityAdmin role at the project level. This role allows them to create, modify, and delete firewall rules within that project but does not allow them to delete VPCs or manage subnets. For even finer control, use conditional IAM to restrict by resource name.
A service account key is a downloaded JSON file that contains a private key allowing authentication as the service account. If this file is leaked or stored insecurely (e.g., in source code), anyone with the file can impersonate the service account. Prefer using Workload Identity Federation or attaching the service account directly to a resource (like a VM) to avoid keys.
You've finished Security Best Practices and IAM for Networking. Continue through the PCNE study guide to build a complete picture of the exam.
Done with this chapter?