GCP Professional Cloud Security Engineer Practice Question

Using Identity-Aware Proxy (IAP) for HTTPS is the simplest way to publish an internal web service securely to the internet without adding external IPs to the backend VMs. You create an external HTTPS load balancer whose backend service points at the existing Internal HTTP(S) Load Balancer via a regional internal backend service or an internal passthrough Network Endpoint Group; the external load balancer terminates TLS and forwards traffic privately to the ILB over the VPC. Enabling IAP on the external HTTP(S) load balancer lets Google handle user authentication and inject an identity token on each request. Granting the IAP-secured Web App User role (roles/iap.httpsResourceAccessor) on the load balancer to the auditors' Google Workspace group restricts access to those users.

To add context-aware constraints (such as allowed IP ranges and device status), you create an Access Level in Access Context Manager that defines the required conditions, then bind that access level to the IAP policy. The combined effect is that only authenticated group members coming from trusted IPs and managed devices can connect. No external IPs are assigned to the VMs, and the solution reuses the existing ILB, satisfying the requirement to minimize architectural changes.

Alternative answers fall short:

• Deploying Cloud VPN would encrypt traffic but still requires auditors to set up tunnels and does not enforce user identity or device context.
• Exposing the ILB through a TCP proxy with IAP for TCP would not work for HTTP layer-7 policies and would require client connector software.
• Cloud Endpoints secures APIs, not generic web apps, and cannot enforce device-based context access without additional components.