Zero Trust is a security model that assumes no communication can be trusted implicitly, even between components that live inside the same VPC, the same project, or the same application. Every request has to prove who it is, prove it is allowed to do what it is asking to do, and travel over an encrypted channel. There is no concept of a trusted internal network where services can call each other without authentication.
The older model that Zero Trust replaces is sometimes called the castle-and-moat model. You build a strong perimeter, and once a request is inside the perimeter you treat it as safe. The problem is that an attacker who breaches the perimeter, or an insider who already has access, can move laterally between systems with very little resistance. Zero Trust removes the assumption that being inside means being trusted.
When you read Google documentation or exam questions through a Zero Trust lens, you are looking for three properties on every interaction.
The first is strict authentication. The caller has to present a verifiable identity. On GCP that identity is almost always a service account, a user identity from Cloud Identity, or a workload identity from GKE or another workload platform.
The second is explicit authorization. Having a valid identity is not enough. The identity has to hold IAM permissions for the specific operation on the specific resource. A service account that can read one bucket cannot read another bucket just because both buckets live in the same project.
The third is encryption in transit. Internal traffic between services is encrypted, not just traffic that leaves the Google network. This protects against an attacker who somehow gets visibility into internal links.
The most common place Zero Trust shows up in a GCP architecture is service-to-service authentication. When one service calls another, the calling service attaches an Identity Token, often called an ID Token, that proves which service account is making the call. The receiving service validates that token before doing any work.
This matters because it removes the implicit trust between internal services. Without ID Tokens, a service might accept any request that arrived on its internal network and assume the caller was legitimate. With ID Tokens, the receiving service checks the signature of the token, confirms which service account it represents, and then checks IAM to see if that service account is allowed to perform the operation. Every hop is authenticated. Every hop is authorized. Lateral movement becomes much harder because compromising one service does not give you free access to the next one.
Cloud Run, Cloud Functions, and any other service that supports IAM-authenticated invocation will reject calls that do not present a valid ID Token from a service account with the right invoker role. That is Zero Trust applied to serverless.
Zero Trust handles trust between services. A Trusted Platform Module, or TPM, handles trust at the device level. A TPM is a hardware-based security feature that verifies the integrity of a system's firmware and software, particularly during boot and during cryptographic operations. It makes sure the machine itself has not been tampered with before it is allowed to participate in your network.
On GCP, the equivalent capability is Shielded VM, which uses a virtual TPM along with secure boot and integrity monitoring. Shielded VM verifies that a VM booted from a trusted bootloader and that its kernel has not been modified. If you need confidence that the underlying compute platform is honest before you let it talk to other services, Shielded VM is the lever you reach for.
The relationship between Zero Trust and TPM is complementary. Zero Trust secures the conversations between systems. TPM secures the systems themselves. You want both. A perfectly authenticated request from a compromised machine still leaks data. A trusted machine that talks to anyone without authentication still gets exploited.
For the Professional Cloud Architect exam, you should be able to recognize Zero Trust in three forms. First, when a question describes a sensitive workload and asks how to prevent lateral movement between services, the answer involves IAM-authenticated service-to-service calls with ID Tokens, not network-only controls. Second, when a question describes verifying the integrity of a compute instance before it joins a sensitive workload, Shielded VM is the answer. Third, when a question contrasts perimeter security with per-request verification, Zero Trust is the model being described.
BeyondCorp Enterprise and Identity-Aware Proxy are the user-facing expression of the same idea. Instead of putting applications behind a VPN where any authenticated user on the corporate network can reach them, IAP authenticates and authorizes every request to the application based on user identity and context. Same principle. Different surface.
My Professional Cloud Architect course covers Zero Trust alongside the rest of the architecture and compliance material.
