The organization and the runtime instance are control-plane records. What answers a request is a group of proxy-forwarding VMs, and every step of the repair described in the dev.to writeup lands on those: a cloned instance template, a rolling update of the managed instance group onto it, a hand-patched metadata key, a startup script re-run per instance [7]. ACTIVE on the org and ACTIVE on the instance were therefore true statements about objects that do not carry traffic [18].
Two holes sat in one template and they interacted. A VM with no service account attached has no identity to authenticate to Cloud Storage, so it never retrieves its real startup script and comes up on the fallback instead [5]. The fallback forwards to whatever the ENDPOINT metadata key names, and that key was blank [6]. Had ENDPOINT been populated, the missing service account would have degraded into a working fallback; had the service account been attached, the blank key would never have been read [22]. Together they produce a forwarder with nowhere to forward.
The ordering of the fix is forced by the resources involved. The sequence starts with a clone rather than an edit, which is what you do when the service account cannot be added to the template that already exists [23]. Only after the group is rolling on the new template are there instances whose metadata is worth patching. That is four manual operations against resources the wizard created [20], after which the proxy answered [24].
Before crediting the wizard, rule out the account's own history. The same setup attempt earlier produced a resource-locked error and an org step that never finished [13], but the 502 org was built in a brand-new project after both earlier projects were shut down [19], so the stuck operation is not in the causal chain. What would make this finding transfer is a second run: the same wizard, an unrelated project, and a template that again comes up with no service account. On the published evidence there is one instance.
The other failure in the same run shows what a diagnosable defect looks like. Step three returned a generic "Something went wrong" with a Try Again button [9], and the retry completed in about nine minutes [10] because org creation is an asynchronous operation layered on API enablement, with the expensive networking and VPC peering from step two already done [12]. Google's installation troubleshooting guide names that case and tells you to wait for propagation and retry [11].
One habit from the earlier mess is worth copying: run setup in separate browser profiles or windows rather than tabs [17], after the Console displayed one project's Apigee org name on another project's setup page, which the author reads as a UI caching artifact [16]. When the dashboard is the least reliable narrator in the room, isolation is cheap.
The readiness check here is one authenticated call through the runtime host. It fails in seconds and points at the data plane, which is more than the four checkmarks [8] and two ACTIVE fields managed between them [3].
