Identity-Aware Proxy Study Notes
Identity-Aware Proxy (IAP) verifies a user's identity and the context of their request before granting access to applications and VMs. It enables zero-trust access over the public internet, so users do not need a VPN to reach internal web apps, SSH, or RDP.
Key facts
- IAP sits in front of load-balanced web applications and checks Google identity plus IAM conditions on every request before forwarding traffic.
- Access is granted with the IAP-secured Web App User role on the specific resource, separate from roles that manage the underlying infrastructure.
- IAP TCP forwarding creates encrypted tunnels to VM instances for SSH and RDP without assigning those instances external IP addresses.
- The gcloud compute ssh command uses IAP tunnels automatically when configured, so port 22 does not need to be open in firewall rules to the internet.
- Context-aware access levels from Access Context Manager can add conditions such as device type, IP range, or geographic location to an IAP policy.
- For on-premises or non-Google applications, IAP connectors and secured backends extend the same identity check to external resources.
- IAP supports programmatic access using OAuth clients and service accounts for automation that needs to call IAP-protected applications.
- When a user is not authorized, IAP returns an access error page rather than exposing the application login screen to unauthenticated visitors.
- IAP is enabled per backend service or per VM access method, and enabling it requires an OAuth brand and consent configuration for the project.
What the exam expects you to know
- Choose IAP when a scenario asks for access to internal apps or SSH without a VPN and without public IP addresses on VMs.
- Grant roles/iap.tunnelResourceAccessor for SSH/RDP tunneling and roles/iap.httpsResourceAccessor or the web app user role for web applications.
- Explain that IAP authenticates the user identity first, while the application still performs its own authorization and business logic checks.
- Pair IAP with context-aware access levels when requirements mention managed devices, office networks, or location-based restrictions.
- Recognize that removing external IPs and broad firewall rules is part of the IAP design, reducing the attack surface of VMs.
- Know that IAP works with external and internal Application Load Balancers for web apps deployed on Compute Engine, GKE, or App Engine.
Identity-Aware Proxy vs Cloud VPN: when to use which
Use IAP when named users need access to a specific application, SSH, or RDP session and you want per-user, per-request identity checks with no network-level trust. Use Cloud VPN when entire networks need encrypted connectivity, such as linking an on-premises data center to a VPC so many systems and protocols can communicate privately. VPN grants network reachability, IAP grants application access. Exam scenarios saying 'employees reach this internal web app from home without VPN software' point to IAP, while 'connect our office network to the VPC' points to VPN or Interconnect. See also the Cloud VPN notes.
Useful gcloud commands
gcloud compute ssh vm-1 --tunnel-through-iap
gcloud compute start-iap-tunnel vm-1 22 --local-host-port=localhost:2222
gcloud iap web add-iam-policy-binding --resource-type=backend-services --service=web-backend --member=user:alice@example.com --role=roles/iap.httpsResourceAccessorCommon exam traps
- IAP does not replace application authentication design entirely; the app still receives the authenticated identity and must enforce its own permissions.
- Opening firewall port 22 to 0.0.0.0/0 alongside IAP defeats the model; IAP tunnel traffic arrives from a Google-managed range you allow instead.
- Granting IAP access to allUsers or a whole domain by default is too broad; access should target specific users or groups per resource.
- IAP protects Google Cloud and connected backends, but a workload with no load balancer or tunnel configuration does not gain IAP protection automatically.
Frequently asked questions
Does IAP require VMs to have external IP addresses?
No, removing external IPs is the point of the design. IAP TCP forwarding tunnels traffic through Google's infrastructure to the instance's internal interface, and web traffic reaches backends through a load balancer. Instances stay private, firewall exposure shrinks, and access is decided by identity rather than network location.
How does IAP decide whether to let a request through?
IAP first requires a Google identity sign-in, then checks the IAM policy on the protected resource for that identity, then evaluates any context-aware access level such as device or network conditions. Only if all checks pass is the request forwarded, with identity information passed to the application in headers.
Can IAP protect applications outside Google Cloud?
Yes, IAP can secure on-premises applications by routing traffic through an IAP connector deployed in your environment connected to Google Cloud. Users get the same identity and context checks before reaching the internal app. This extends zero-trust access during migrations without publishing the application directly to the internet.
Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.