Cool! Instead of doing gcloud compute list disks though, you can directly look at the disks attached to the instance via the metadata server (https://cloud.google.com/compute/docs/metadata) and in the case of setting ZONE just do it with instance/zone.

Disclosure: I work on Compute Engine.

Nice catch! But aren't gcloud calls correct info without having to parse JSON in Bash?

Yes, of course they're correct; however, invoking gcloud is comparatively much slower than just curl'ing against the metadata server (you know, no Python code to interpret in the latter case).

With regards to JSON, not sure what you mean, since getting e.g. instance zone from metadata server gives you a plain text string like "projects/<PROJECT_NUMBER>/zones/europe-west1-d". AFAIK, the only way to get JSON-like results is by making recursive requests, such as:

  $ curl -H 'Metadata-Flavor: Google' "http://metadata/computeMetadata/v1/instance/?recursive=true"

And even in that case, you can choose plain text format by appending "alt=text" as query string parameter:

  $ curl -H 'Metadata-Flavor: Google' "http://metadata/computeMetadata/v1/instance/?recursive=true&alt=text"

Awesome, thanks for that, I'll dive deeper into Metadata.

Rather than IAM, you can as well just associate the service account with the VM, in which case you don't have to copy around the json file with the private key. Any gcloud calls from the VM will not need explicit authorization.

I had some issues with the service account approach. (Might have been me being dumb.) I'll give that a shot.

Before IAM, the issue I had with service accounts is that I forgot to give the account Edit permissions. It seems the new way is like how @i_have_to_speak mentioned to use service account for an instance, which can only be done during creation of the instance, if you don't want to distribute keys. Then the newest way, that's still in beta, is to use IAM roles to further restrict the access scopes of that instance service account.