Exam Professional Cloud Developer topic 1 question 104 discussion

https://cloud.google.com/blog/products/containers-kubernetes/introducing-workload-identity-better-authentication-for-your-gke-applications A Cloud IAM service account is an identity that an application can use to make requests to Google APIs. As an application developer, you could generate individual IAM service accounts for each application, and then download and store the keys as a Kubernetes secret that you manually rotate. Not only is this process burdensome, but service account keys only expire every 10 years (or until you manually rotate them). In the case of a breach or compromise, an unaccounted-for key could mean prolonged access for an attacker. This potential blind spot, plus the management overhead of key inventory and rotation, makes using service account keys as secrets a less than ideal method for authenticating GKE workloads.

I assume that nobody read through the official docs and GCP Best practices for K8s and Cloud SQL. https://cloud.google.com/sql/docs/mysql/connect-kubernetes-engine#secrets "A database credentials Secret includes the name of the database user you are connecting as, and the user's database password." The best answer here is B, having K8s Secrets is the go-to method to configure and store sensitive information within a cluster such as Spanner credentials

The best answer here is A. Configure the appropriate service accounts, and use Workload Identity to run the pods. Here's why: Workload Identity: Workload Identity is a Google Cloud feature that allows Kubernetes service accounts to act as Google Cloud IAM service accounts. This means your pods can authenticate to Spanner without needing to store credentials directly within the pod.

Option A is the recommended approach for securely configuring your microservice-based application to retrieve Spanner credentials on Google Kubernetes Engine (GKE)

This approach involves configuring service accounts with the necessary permissions to access the Spanner database. By using Workload Identity, you can associate these service accounts with your Kubernetes Engine pods, allowing them to authenticate and retrieve Spanner credentials automatically.

i go for B question is about how to RETRIEVE db creds https://cloud.google.com/sql/docs/mysql/connect-kubernetes-engine#secrets A is about how to connect to spanner

Google recommends using service accounts and work load identity whenever possible

A. Configure the appropriate service accounts, and use Workload Identity to run the pods. Workload Identity is a way to associate Kubernetes service accounts with Google Cloud IAM service accounts, allowing your pods to authenticate to Google Cloud services using their IAM identity. This means that you don't have to store application credentials in your code or in Kubernetes Secrets, and you can manage the permissions of your application in Google Cloud IAM. You would need to create service account in cloud IAM and a Kubernetes service account and then map them to use Workload Identity. You can also use gcloud command line to map the Kubernetes service account to the desired IAM service account. Then in your application, you can use the Kubernetes service account to authenticate to Spanner, which will authenticate as the mapped IAM service account. This way you don't have to hardcode credentials in your code, and you can easily manage the permissions of your application using Google Cloud IAM.

A is the answer. https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity#what_is Applications running on GKE might need access to Google Cloud APIs such as Compute Engine API, BigQuery Storage API, or Machine Learning APIs. Workload Identity allows a Kubernetes service account in your GKE cluster to act as an IAM service account. Pods that use the configured Kubernetes service account automatically authenticate as the IAM service account when accessing Google Cloud APIs. Using Workload Identity allows you to assign distinct, fine-grained identities and authorization for each application in your cluster.

Answer is A Store the application credentials as Kubernetes Secrets, and expose them as environment variables

I think A is correct

A and B ,both are correct. Curently in my project we are using A for allowing pods to query Bigquery. So A and B both seems to be correct.

B. The question is not about how to connect/access Cloud Spanner, but is how to "retrieve Spanner *credentials*".

A and B -> It should be select 2 best options question.

I think B is more suitable in this situation

Yes A is the option

I vote A https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity