Service account assignment is one of those configuration steps on Compute Engine that looks trivial in the console and turns into an exam topic precisely because most people skip past it. The Professional Cloud Architect exam expects you to know what gets assigned by default, why that default is risky, and how to fix the most common permissions error you will see on a VM.
When you create a VM on Compute Engine, you should assign a service account to the instance rather than relying on manual authentication or a JSON key file embedded in your code. The service account is what lets the VM call other Google Cloud services like Cloud Storage or BigQuery without you having to ship credentials with the application.
If you do not pick one explicitly, Compute Engine will attach the Compute Engine default service account for you. That is convenient, but it is not the recommended setup. The default service account ships with broader permissions than most workloads need, and that gap between what your application requires and what the service account can do is exactly the attack surface you want to shrink.
The best practice is to create a unique service account for each VM or application and give it only the permissions that workload actually requires. This is the principle of least privilege applied at the instance level. If the VM is running a script that reads from one Cloud Storage bucket, the service account on that VM should be able to read from that bucket and not much else.
Two things fall out of this when you do it correctly. You stop hardcoding credentials anywhere. And if a VM is ever compromised, the blast radius is bounded by the permissions on that single service account rather than the broader defaults.
The exam scenario you should be ready for goes like this. You have a script running on a VM that needs to read or write data in Cloud Storage, and the script is failing with a permissions denied error. What do you do?
The fix has two steps. First, create a service account and grant it the permissions it needs, such as the appropriate read or write role on Cloud Storage. Keep the grant scoped to what the script actually does. Second, attach that service account to the VM running the job. Once the service account is on the instance, the VM authenticates to Google Cloud automatically when the script makes API calls, and the permissions denied error goes away.
Notice what is not in that answer. You do not generate a JSON key, you do not paste credentials into a config file, and you do not give the default service account broader access. The Professional Cloud Architect exam consistently rewards the answer that uses an attached service account with least-privilege permissions over any answer that involves manual credentials.
For Compute Engine specifically, three things should be locked in. Always assign a service account during instance creation. Prefer a purpose-built service account over the default one. When you see a permissions error from a script running on a VM, the answer is almost always to create a properly scoped service account and attach it to the instance, not to add credentials to the application.
My Professional Cloud Architect course covers service account assignment on Compute Engine alongside the rest of the compute material.
