The word doing the work in the token path is `--audiences`. IAP will accept a bearer token, but only one carrying the right audience [3], and the test command in the walkthrough pins that audience to the IAP client ID [7]. So every non-browser caller picks up two things it did not need before: an identity Google will sign, and that client ID as deployed configuration [18]. For a manual check it is one gcloud invocation [7]. In application code it becomes a service-account-signed JWT or an OIDC client credential exchange [8], which is a token lifecycle you now own: mint, cache, refresh.
The failure mode is not a clean 401. A caller with no token is redirected to the Google login page [9], and a caller that cannot hold a cookie or follow a redirect has nothing to do with that redirect [5]. A JSON client gets HTML [16]. The source is explicit that the browser path stays an interactive flow, and names headless browsers and most testing tools as the things that cannot complete it [15].
Granularity is the other line item. IAP is enabled per backend service, not per URL path, so everything routed to that backend is gated once the switch is on [2]. There is no exempting `/healthz` or a webhook receiver in place; a route that must stay open has to move to a different backend service [17]. That is a load balancer edit, not a checkbox.
For the "costs almost nothing" claim [19] to transfer, a few things have to hold in your environment. The gated surface has to be browser-only. Your people have to already exist as Google Workspace identities that IAM can name [12]. And nothing behind that backend service can be answering machine callers, because those are exactly the clients with no redirect to follow and no cookie to carry [5].
Where that holds, the engineering is good and worth saying so. No VPN to distribute and no login layer to maintain [10]. A browser hits the sign-in redirect once and a session cookie carries the rest of the day [4]. Removing a person is one IAM edit that applies immediately, everywhere that backend is used [13]. Access decisions land in Cloud Audit Logs, so who reached staging is a query [14]. And nothing else grants access, project owner included [6], which teams tend to discover with the console already open.
The problem IAP is built for is the ordinary one: a staging URL a crawler indexed and an ex-employee's bookmark still reaches [11]. Requiring a verified Google identity at the load balancer, before the request touches the backend at all [1], is the cheapest honest fix I know of on GCP for that case. In my context I would still keep machine traffic on a separate backend service rather than teach four repositories to sign audience-scoped tokens, because the browser saving is real and the token work is the part that lands in code review.
