Cloud IAP, short for Identity-Aware Proxy, is one of GCP's more interesting access control services. This article covers what IAP does, what kinds of resources it can protect, the BeyondCorp model it is built on, and how the Associate Cloud Engineer exam tests it.
It does not cover the deep configuration of IAP-protected applications, OAuth client setup, or the IAP TCP forwarding feature for SSH tunneling into private VMs. Those are real features but the ACE exam coverage of IAP is high level, and that is what I am focused on here.
IAP sits in front of your application and checks every incoming request. Before the request gets to your application, IAP asks two questions. Who is the user. Are they allowed to access this resource. If both answers check out, the request goes through. If not, the user is redirected to a sign-in page.
That is it. IAP is a gatekeeper that authenticates and authorizes users before they touch your application. The application itself does not have to handle any of that logic. It can just trust that anybody whose request reaches it has already been verified.
IAP can sit in front of four kinds of GCP resources. Cloud Run services, App Engine apps, HTTPS Load Balancers (which means anything behind an HTTPS load balancer, including Compute Engine instance groups), and Compute Engine VMs directly. The exam mostly cares that you know IAP is a general-purpose application access proxy that works across these compute targets, not that you memorize a specific configuration for each.
The architectural idea behind IAP is what Google calls BeyondCorp, which is the security model that says network location should not be the primary thing that determines whether a user can access an application. Traditionally, you put applications inside a corporate network, and access control was implicit. If you were on the VPN, you were trusted. If you were not, you were blocked.
BeyondCorp says throw that model out. Trust nothing based on network location. Every request, from every user, anywhere, gets authenticated and authorized based on user identity. The user's IAM identity, plus the resource they are trying to access, plus the policy attached to that resource, determines whether the request is allowed.
IAP is the GCP-native implementation of that idea. Instead of a VPN that gates network access, you have IAP that gates application access by IAM identity. The user can be anywhere, on any network, and the access decision is the same.
The biggest practical benefit is that you can stop exposing applications to the public internet just to make them reachable. With IAP, you do not need a public IP on a backend service. You do not need open ports for HTTPS, SSH, or other TCP services on the resources themselves. The attack surface that port scanners and brute force tools look for is gone, because IAP is the only thing facing the internet, and it only lets identified users through.
That is a real reduction in exposure. A typical internal admin tool that would have lived behind a VPN can instead live behind IAP, with no VPN to set up, no client software to install, and no network configuration to maintain.
The Associate Cloud Engineer exam tests IAP in scenario form. The pattern looks like this. A team has an internal application. They want to give certain employees access without putting it on the public internet and without standing up a VPN. The right answer is Cloud IAP.
If you see in the question something about controlling access by user identity, granting application access without a VPN, reducing attack surface by eliminating public IPs, or protecting an application that should only be reachable to authorized users, think Cloud IAP.
The contrast the exam will sometimes draw is against firewall rules and VPN. Firewall rules gate by IP address. VPNs gate by network connection. IAP gates by user identity. If the question emphasizes user identity over network controls, it is testing IAP.
Cloud IAP is a managed proxy that sits in front of your application and checks user identity before letting requests through. It works for Cloud Run, App Engine, HTTPS Load Balancers, and Compute Engine VMs. The architectural idea is BeyondCorp, which means access decisions are based on who the user is, not where they are connecting from.
For the Associate Cloud Engineer exam, the things to recognize are the four protected resource types and the scenario pattern of application access without a VPN.
My Associate Cloud Engineer course covers Cloud IAP alongside firewall rules, VPC Service Controls, and the rest of the network security topics that show up on the ACE exam.
