You have a Linux VM that must connect to Cloud SQL. You created a service account with the appropriate access rights. You want to make sure that the VM uses this service account instead of the default Compute Engine service account. What should you do?
To ensure that a Linux VM uses a specific service account instead of the default Compute Engine service account, you should specify the desired service account under the 'Identity and API Access' section when creating the VM via the web console. This ensures the VM is configured to use the correct service account from the outset, adhering to best practices for manageability and security.
A is correct
How can this be? It says you HAVE a VM, meaning it's already created. A cannot be the solution.
As the comment says: "To change an instance's service account and access scopes, the instance must be temporarily stopped ... After changing the service account or access scopes, remember to restart the instance." So we can stop the instance, change the service account, then start it up again.
I vote A https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances Changing the service account and access scopes for an instance If you want to run the VM as a different identity, or you determine that the instance needs a different set of scopes to call the required APIs, you can change the service account and the access scopes of an existing instance. For example, you can change access scopes to grant access to a new API, or change an instance so that it runs as a service account that you created, instead of the Compute Engine default service account. However, Google recommends that you use the fine-grained IAM policies instead of relying on access scopes to control resource access for the service account. To change an instance's service account and access scopes, the instance must be temporarily stopped. To stop your instance, read the documentation for Stopping an instance. After changing the service account or access scopes, remember to restart the instance. Use one of the following methods to the change service account or access scopes of the stopped instance. Hope this helps :)
A seems legit, the answer is worded poorly but is the most correct. --- https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#changeserviceaccountandscopes --- "To change an instance's service account and access scopes, the instance must be temporarily stopped ... After changing the service account or access scopes, remember to restart the instance." So we can stop the instance, change the service account, then start it up again.
Either the question or the answers are wrong. The question says that we HAVE a Linux VM, so we should strike all the answers that include "when creating the VM.." - on the other hand, adding JSON Tokens to VM metadata is terrible because it's readable in clear-text for everyone. So, what do we need to do here?
compute-engine-service-account is not a valid metadata key, therefore its A
A is correct
A is correct. No idea why you'd add anything to metadata of an instance https://cloud.google.com/compute/docs/metadata/overview The SA can be specified in the web console during creation of the VM and also if the VM is stopped. This SA will then be used for everything that VM does. Therefore, A is correct.
A is correct
C is the possible correct answer. Already VM instance created.
A is correct
The correct answer is D. This is the recommended approach, because it allows you to specify the service account that you want to use without having to modify the VM's metadata. The other options are not as good: Option A is not as good, because it requires you to specify the service account when creating the VM. This can be inconvenient if you need to update the service account later. Option B is not as good, because it requires you to modify the VM's metadata. This can be complex and error-prone. Option C is not as good, because it requires you to modify the VM's custom metadata. This is not a recommended approach, because custom metadata is intended for use by custom applications.
we have to use the newly created account rather VM default/attached SA.
A is correct Answer
the key is not directly provided to the VM (normally) only Service account to use https://docs.bridgecrew.io/docs/bc_gcp_iam_2
A is correct
A is recommended way. C is correct but A is the recommended approach.
What documentation do you have on B, C, and D?
select the service account directly in vm options, when creating or editing the VM. JSON private key? what are you talking about. You are all wrong
The question implies that a Linux VM already exists and needs to be configured to use a specific service account instead of the default Compute Engine service account. This is crucial because it eliminates option A, which focuses on setting the service account during VM creation. Why Option C is Correct: Custom Metadata : Custom metadata is designed for VM-specific configuration. It's the ideal place to store service account credentials. compute-engine-service-account : This is the specific metadata key used to tell the VM which service account to use. JSON Private Key : This is the standard format for storing service account credentials.