A real-world war story of chasing an Apigee X evaluation organization from "Server Error" to "Hello, Guest!" — the hard way, with gcloud, curl, and a lot of patience.
TL;DR
I spent hours debugging a persistent 502 Server Error on a fresh Apigee X evaluation organization. The Cloud Console showed every provisioning step green. The Apigee Management API confirmed the organization and runtime instance were both ACTIVE. And yet every single request — even to a brand-new proxy — came back with a 502.
The eventual root cause: the Apigee provisioning wizard built the proxy-forwarding instance template without a service account attached, and left a required ENDPOINT metadata key blank. Without a service account, the VMs couldn't authenticate to Cloud Storage to fetch their real startup script. Without ENDPOINT, the fallback script had nothing to forward traffic to. The fix was to clone the broken instance template with the missing service account and the ENDPOINT value both baked in, then roll the managed instance group onto it — fixing the template, not just the live instances, matters, since these forwarding VMs are preemptible and get silently replaced by Google; a fix applied only to a running instance quietly disappears the next time it's swapped (I found this out the hard way — see the Update section near the end).
