Exam domain 5, 'Compute Security', is the heart of the Google Professional Cloud Security Engineer exam because it tests how you protect the actual computers that run your applications. This chapter breaks down the three main compute services on Google Cloud – Compute Engine (VMs), Google Kubernetes Engine (GKE), and serverless options (Cloud Run, Cloud Functions) – and explains exactly how to harden each one, a skill that separates a good engineer from a great one.
Jump to a section
A simple way to picture Compute Security: Hardening VMs, GKE, and Serverless
An office park contains three distinct buildings, each with a different security approach. Building A is a single-family house converted into an office. You own the entire house. You must lock every door and window yourself, install your own alarm system, and check every visitor personally because you control the entire property. This is a Virtual Machine (VM) – you manage the operating system, applications, and security patches. Building B is a managed apartment block. The landlord handles the building's structure, plumbing, and exterior security, but you are responsible for locking your own apartment door and setting the inside alarm. This is a Google Kubernetes Engine (GKE) cluster – Google manages the underlying servers (the node pool), but you must secure your containers (your apartments) and configure network policies (your door locks). Building C is a fully serviced executive suite. You rent a desk and a phone line. The building management handles absolutely everything – locks, alarms, cleaning, even the coffee machine. You just bring your laptop and work. This is serverless computing (Cloud Run, Cloud Functions). You only upload your code, and Google secures the entire runtime environment. The core lesson is knowing which building you operate in, so you apply the correct level of security effort. A security engineer must know whether they are locking the front gate of the estate (VM), the door to their flat (GKE), or just their laptop case (serverless).
The mistake beginners make is assuming all three buildings use the same key. They don't. Each demands a different security mindset.
To understand compute security, you first need to understand the three types of compute offered by Google Cloud. Each places a different level of responsibility on you, the customer. This is often visualised as the 'Shared Responsibility Model'.
1. Compute Engine (Virtual Machines or VMs)
Think of a VM as a simulated computer running inside Google's data centres. You choose the operating system (OS) – Windows or Linux – and then you are responsible for everything inside that OS. This includes: - Operating System patches: Installing security updates to fix known vulnerabilities. - Application software: Securing the code your application runs (e.g., a web server like Apache or Nginx). - Firewall rules: Controlling which network traffic can reach your VM. Google Cloud provides VPC firewall rules, but you configure them. - Identity and Access Management (IAM): Controlling who can SSH into the VM or who can use APIs to stop/start it. - Disk encryption: Ensuring data on the VM's boot disk is encrypted. Google Cloud provides default encryption at rest, but you can also bring your own keys (Customer-Managed Encryption Keys, CMEK) or even your own encryption (Customer-Supplied Encryption Keys, CSEK).
Hardening a VM means proactively reducing its attack surface. Typical actions include:
Removing unnecessary software (e.g., if it's a web server, uninstall the email client).
Disabling root login over SSH and using key-based authentication only.
Applying the principle of least privilege to IAM roles.
Using Shielded VMs which verify the boot process integrity using UEFI firmware, Secure Boot, and vTPM (virtual Trusted Platform Module).
Using Confidential VMs which encrypt data in use, protecting it even from Google's own infrastructure.
2. Google Kubernetes Engine (GKE)
GKE is a managed service that runs containerised applications. Containers are like lightweight, portable packages for your code and its dependencies. Kubernetes is the orchestrator that manages where containers run, how they scale, and how they talk to each other.
With GKE, Google manages the control plane – the brain of the Kubernetes cluster – for you. However, you are responsible for securing the workloads (the containers) and the node configuration.
Key security areas for GKE include: - Node hardening: The nodes are VMs that run your containers. You can use a hardened OS image called Container-Optimized OS (COS). You must keep the nodes patched (GKE offers auto-upgrades and auto-repair). - Pod security policies: These control what containers are allowed to do (e.g., cannot run as root, cannot use host network). PodSecurityAdmission is the current Google-recommended way to enforce these. - Network policies: Within a cluster, you use Kubernetes Network Policies to restrict which pods can talk to each other. This is micro-segmentation. - Workload Identity: A way for pods to authenticate to Google Cloud services without storing static service account keys inside the container. This is far more secure. - Binary Authorization: Ensures only trusted, signed container images are deployed. You sign an image after it passes security tests; if it isn't signed, it cannot run. - Private clusters: Use internal IP addresses for nodes and the control plane, so no node traffic goes over the public internet.
3. Serverless (Cloud Run, Cloud Functions)
Serverless means you never see the underlying server. You simply upload your code (or a container image) and Google runs it on demand. Google is fully responsible for the OS, the runtime, the scaling, and the patching. Your job is purely to secure your code and your data.
Hardening serverless involves: - Least privilege IAM for the service account: The serverless function or service runs as a service account. Give it only the permissions it absolutely needs. - Input validation: Since serverless functions often handle HTTP requests, you must validate all input to prevent injection attacks (SQL injection, command injection). - Secure environment variables: Never hardcode secrets like passwords. Use Secret Manager to store them and retrieve them at runtime. - VPC connectivity: Use Serverless VPC Access to allow your function to reach private resources (like a Cloud SQL database) without going over the public internet. - Ingress controls: Restrict who can invoke your function. Cloud Run allows you to require authentication (IAM-based) and restrict ingress to internal traffic only.
All three compute types share some common security principles: encrypt data at rest and in transit, use Identity and Access Management (IAM) to grant minimal permissions, and enable logging and monitoring (Cloud Logging, Cloud Audit Logs) to detect suspicious activity.
Inventory all compute resources
Before hardening, you need to know what exists. Identify every VM, GKE cluster, Cloud Run service, and Cloud Function in your project. This step is often skipped, but the exam assumes you do it. Use Cloud Asset Inventory or simple queries via Cloud Console.
Classify data sensitivity per resource
Not all compute resources handle the same data. The loan calculator might handle low-risk data; the database VM might handle PII. Classifying data helps determine which security features (like Confidential VMs or VPC Service Controls) are necessary.
Apply minimum IAM permissions for each service account
For each compute resource, create a dedicated service account with only the permissions it needs. For example, a Cloud Run service that reads a bucket gets the 'Storage Object Viewer' role, not 'Storage Admin'.
Configure network isolation for each compute type
VMs should be in subnets with tight firewall rules. GKE should use private clusters or network policies. Serverless services should use VPC connectors and ingress restrictions. This step prevents lateral movement if one component is compromised.
Enable logging and monitoring for all compute resources
Turn on Cloud Audit Logs for data access and admin activity. Set up alerts for unusual patterns (e.g., many failed SSH logins on a VM, spikes in Cloud Function invocations, pods crashing repeatedly in GKE). Without this step, you won't know if hardening is working.
Consider the scenario of 'FinServ Ltd', a financial technology company that is migrating a legacy monolithic application to Google Cloud. The application consists of three parts:
A customer-facing loan calculator web app (needs to be highly scalable, so they choose serverless Cloud Run).
A backend database processing engine that handles sensitive customer data (needs a predictable environment, so they use a Compute Engine VM with a hardened OS).
A batch processing pipeline that calculates monthly interest (they containerise it and run it on a GKE cluster for orchestration).
As the security engineer, your job is to secure all three without creating friction for the developers.
Step-by-step walkthrough:
Assess the environment: You begin by mapping out what resources exist. You ask the team: what data does each component handle? The loan calculator only needs customer names and loan amounts (not national insurance numbers). The database processor handles full personal identifiable information (PII). The batch pipeline handles aggregated totals only.
2. Harden the VM (Database Processor): - You provision a Compute Engine VM running Ubuntu LTS. - You enable Shielded VM and Confidential VM to protect data in use. - You create a custom image with unnecessary packages removed and an intrusion detection agent installed. - You configure VPC firewall rules to allow traffic only from the GKE cluster and the Cloud Run service (via VPC peering), blocking all other incoming traffic. - You set up OS Login instead of SSH keys, so access is controlled via IAM.
3. Secure the GKE cluster (Batch Pipeline): - You create a private cluster with nodes in a custom subnet. - You enable Workload Identity so containers can access Cloud Storage (to read input files) without storing keys. - You implement PodSecurityAdmission to forbid privileged containers. - You set up Binary Authorization. The CI/CD pipeline builds the container image, runs vulnerability scanning, signs the image, and only then allows it to be deployed. - You define a Kubernetes Network Policy that allows only the batch pods to talk to the database pods, blocking lateral movement.
4. Lock down the serverless service (Loan Calculator): - You deploy the Cloud Run service with a minimal service account that only has access to one Cloud Storage bucket (for static assets) and BigQuery (for aggregated loan data). - You use Ingress Settings to set 'Internal only' because the application is only used by employees on the corporate VPN. You also set 'Require authentication'. - You move all configuration secrets to Secret Manager and reference them via environment variables. - You enable request logging and set up alerts for unusual invocation patterns.
Audit and monitor: You set up Cloud Audit Logs for all compute services. You create a dashboard in Cloud Monitoring that shows failed login attempts on the VM, pod restarts in GKE, and invocation errors on Cloud Run. You set up a weekly scan for container vulnerabilities using Artifact Analysis.
The result: a secure, auditable, and efficient architecture. The developers can deploy quickly because security is built in, not bolted on. The company passes its security audit and the system remains compliant with financial regulations.
The PCSE exam tests compute security extensively. Here is exactly what you must know.
Core Exam Topics: - Shielded VMs vs. Confidential VMs: Know the differences. Shielded VMs protect boot integrity. Confidential VMs protect data in memory. - GKE security features: Binary Authorization, PodSecurityAdmission, Workload Identity, Network Policies, private clusters. - Serverless security: Ingress controls, service account best practices, VPC connectors, Secret Manager usage. - Shared Responsibility Model: Understand what Google secures vs. what you secure for each compute service. - OS Login vs. SSH keys: OS Login is preferred because it ties to IAM. - Container-Optimized OS: The default, hardened OS for GKE nodes. - VPC Service Controls: Reduces data exfiltration risk for compute resources.
Common Trap Patterns: - They ask: 'Which GKE feature ensures only signed images can be deployed?' The answer is Binary Authorization, not Container Registry or IAM. - They ask: 'Which VM type protects data in use?' The answer is Confidential VMs, not Shielded VMs. Beginners confuse the two. - They ask: 'For a Cloud Function that needs to access a private Cloud SQL instance, what must you configure?' The answer is Serverless VPC Access (or VPC Connector). Newbies often think IAM alone is sufficient. - They present a scenario where a developer stored a service account key in a container image. The correct fix is Workload Identity. - They ask about 'OS Login' vs 'SSH keys'. OS Login is preferred because it uses IAM permissions and can be centrally managed.
Key Definitions to Memorise: - Shielded VM: Uses Secure Boot, measured boot, and vTPM to ensure the VM has not been tampered with. - Confidential VM: Uses AMD SEV (Secure Encrypted Virtualization) to encrypt memory. - Binary Authorization: Enforces signed container images only. - PodSecurityAdmission: Replaces the deprecated PodSecurityPolicy. - Workload Identity: Allows pods to impersonate a GCP service account without static keys. - Private GKE cluster: Nodes and control plane have only private IP addresses.
Exam Question Style: - Scenario-based multiple-choice. A company has X requirement. Which feature meets it? - 'Choose two' questions (e.g., select two actions to secure a GKE cluster). - 'Which statement is true?' about Shared Responsibility. - Ordering steps (e.g., 'What is the correct sequence to deploy a secure container?'). - Very rarely, a case study with a multi-part question.
Trap Patterns: - They give you a feature name that almost fits but is wrong (e.g., 'Container Security Scanner' vs. 'Binary Authorization'). - They describe a scenario where the easiest answer (allow all traffic) is presented alongside the correct, more restrictive answer. - They test 'least privilege' but in a tricky context – e.g., a pod only needs to read from a bucket, but the correct role is 'Storage Object Viewer', not 'Storage Object Admin'.
What to Practise: - Draw the shared responsibility model from memory. - Compare Shielded vs. Confidential VMs in a table. - List the steps to secure a GKE cluster end-to-end. - Explain why Workload Identity is better than service account keys. - Describe how to connect a Cloud Function to a private VPC.
The Shared Responsibility Model means Google secures the infrastructure, but you must secure your data, identities, and workloads.
Shielded VMs protect against boot-level tampering; Confidential VMs protect data in use by encrypting memory.
GKE's Binary Authorization enforces that only signed, trusted container images can be deployed to a cluster.
Workload Identity eliminates the need to store service account keys inside containers by allowing pods to impersonate a Google Cloud service account.
For serverless Cloud Run and Cloud Functions, you must use Ingress controls and service account least privilege instead of worrying about OS patching.
OS Login is preferred over static SSH keys for VM access because it ties authentication to IAM and can be centrally audited.
A private GKE cluster is not a security silver bullet – it requires careful networking configuration and can complicate certain operations.
These come up on the exam all the time. Here's how to tell them apart.
Shielded VM
Protects boot integrity using Secure Boot and measured boot.
Uses vTPM to attest the boot process.
Does not encrypt data in memory.
Confidential VM
Protects data in use by encrypting memory with AMD SEV.
Does not protect the boot process.
Recommended for workloads handling highly sensitive data like PII.
Binary Authorization
Enforces deployment-time control – blocks unsigned images.
Requires a policy and a signer to operate.
Focuses on trust (who signed the image).
Container Analysis (Artifact Analysis)
Scans container images for known vulnerabilities.
Provides a risk score based on CVEs.
Focuses on vulnerability scanning, not image signing.
Workload Identity
Pods impersonate a Google Cloud service account without storing keys.
Keys are never exposed in the image or at runtime.
Google-managed rotation of underlying credentials.
Service Account Key stored in Container Image
A static JSON key is bundled inside the container image.
If the image is pulled from a registry, the key is exposed.
Key rotation requires rebuilding and redeploying the image.
OS Login
Authentication is IAM-based (user must have roles/compute.osLogin).
Centrally managed – can disable a user in IAM without touching VMs.
Auditable via Cloud Audit Logs.
Static SSH Keys (metadata-based)
SSH keys are added to project or instance metadata.
If a key is stolen, you must remove it from all instances manually.
Harder to audit – keys are not tied to individual IAM users.
Mistake
Shielded VMs and Confidential VMs are the same thing.
Correct
Shielded VMs protect against boot-level malware; Confidential VMs protect data in memory using encryption.
Both names contain 'secure/confidential' and both are VM-level features, so beginners conflate them. The exam explicitly tests the difference.
Mistake
If I use GKE, Google is responsible for all security, so I don't need to do anything.
Correct
Google secures the control plane, but you are responsible for securing the nodes, containers, network policies, IAM, and application code.
The term 'managed' is misleading. Beginners think 'managed' equals 'fully managed'. GKE is 'managed Kubernetes', not 'managed security'.
Mistake
Serverless means I don't have to think about security at all.
Correct
You are still responsible for your code, your dependencies, your IAM roles, and your secrets. Google secures the runtime environment.
The word 'serverless' sounds effortless, so beginners assume the vendor handles everything. The shared responsibility model still applies.
Mistake
Private GKE clusters are always more secure than public ones, so I should always use them.
Correct
Private clusters are more secure for most use cases, but they introduce complexity (e.g., you need VPC peering or Cloud NAT for outbound traffic, and you lose some management features like the ability to run kubectl from the internet).
Beginners often think 'private = always better' without weighing trade-offs. The exam tests understanding of when private is appropriate and when a public cluster with firewall rules might be acceptable.
Mistake
I can store a service account key inside my container image – it's fine because the container is only deployed internally.
Correct
Container images are often stored in registries. If that registry is compromised, keys are exposed. Use Workload Identity instead.
It seems convenient to ship keys with the image, and many tutorials from a few years ago did this. The exam specifically tests the modern best practice.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A Shielded VM protects the integrity of the boot process using Secure Boot, measured boot, and vTPM. A Confidential VM encrypts the memory (data in use) using AMD SEV technology. They are complementary – you can use both together for maximum security.
You need to configure a Serverless VPC Access connector. This creates a bridge between your serverless environment and your VPC, allowing the function to reach the database via a private IP without going over the public internet.
Workload Identity allows pods in GKE to authenticate to Google Cloud services by impersonating a Google Cloud service account, without needing to store static keys inside the container. It is more secure than storing keys because keys can be stolen from the container image or at runtime.
Not always. Private clusters are more secure for most workloads because nodes and the control plane have only private IP addresses. However, they introduce complexity: you need Cloud NAT for outbound internet access, and you cannot run 'kubectl' from outside the VPC without a bastion host or proxy.
Binary Authorization is a deploy-time security control that ensures only container images signed by trusted authorities are allowed to run in your GKE cluster. You configure a policy that requires a signature; if the image is not signed, the deployment is blocked.
No. Google secures the underlying runtime environment (the OS, the execution environment), but you are responsible for the security of your code, your application dependencies (libraries), your IAM roles, and your secrets. The shared responsibility model still applies.
You've finished Compute Security: Hardening VMs, GKE, and Serverless. Continue through the PCSE study guide to build a complete picture of the exam.
Done with this chapter?