An enterprise DevOps team is configuring automated data migration from Microsoft Azure Blob Storage into Cloud Storage buckets. The organization's security policy enforces strict governance rules across all cloud environments: User-managed service account keys and static cloud credentials (such as Azure Shared Access Signatures or access keys) are strictly prohibited. Authentication between cloud providers must rely entirely on short-lived OpenID Connect (OIDC) tokens and keyless federated identities. The principle of least privilege must be maintained for all automated service identities. Which strategy should the team implement to fulfill these requirements for Storage Transfer Service?

Grant the Service Account Token Creator role to the Storage Transfer Service service agent in Google Cloud, register an application in Azure with a federated credential specifying the service agent's OIDC issuer, and grant that Azure application read access to the storage container.: ### What Workload Identity Federation for Storage Transfer Service Is **Workload Identity Federation** enables Google Cloud services and external workloads to securely exchange identity credentials without managing or storing static, long-lived API keys, client secrets, or private key JSON files. For **Storage Transfer Service**, Google Cloud uses its managed **service agent** identity to generate short-lived **OpenID Connect (OIDC) ID tokens** that external identity providers (such as Microsoft Entra ID / Azure AD) validate natively. ### How It Meets the Security and Migration Requirements - **Eliminates Long-Lived Keys**: No static Azure Storage access keys, SAS tokens, or downloadable Google Cloud service account keys are created or stored. - **Enforces Short-Lived Tokens**: Granting the **Service Account Token Creator** (`roles/iam.serviceAccountTokenCreator`) role to the managed Storage Transfer Service service agent (`service-PROJECT_NUMBER@gcp-sa-storagetransfer.iam.gserviceaccount.com`) allows it to create ephemeral OIDC ID tokens on demand. - **Establishes Trust via Azure Federated Credentials**: Registering an application in Azure and attaching a federated credential with Google's OIDC issuer URL and the service agent's unique subject ID allows Azure to authenticate incoming transfer requests securely. - **Follows Least Privilege**: Permissions on Azure Blob Storage are granted directly to the registered Azure application identity, scoping access exclusively to the target source containers. ### Key Advantages and Capabilities - **Zero Secret Sprawl**: Eliminates operational overhead and security exposure associated with manual key rotation, secret leaking, and compromised long-lived credentials. - **Native Integration**: Works directly with **Storage Transfer Service** transfer jobs without custom proxy infrastructure. - **Auditable Lifecycle**: All token exchanges and access requests are logged within Cloud Audit Logs and Azure Activity/Sign-in logs. - **Standardized Multi-Cloud Architecture**: Follows industry-standard OIDC federation patterns across heterogeneous cloud providers. ### Why This Is Optimal Federating the native Google Cloud service agent with Azure App Registration creates a completely keyless architecture. It satisfies the strict prohibition against static secrets while ensuring minimal administrative maintenance.

Storage Transfer Service Workload Identity Azure | Professional Cloud DevOps Engineer

Storage Transfer Service Workload Identity Azure

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise DevOps team is configuring automated data migration from Microsoft Azure Blob Storage into Cloud Storage buckets. The organization's security policy enforces strict governance rules across all cloud environments:

User-managed service account keys and static cloud credentials (such as Azure Shared Access Signatures or access keys) are strictly prohibited.
Authentication between cloud providers must rely entirely on short-lived OpenID Connect (OIDC) tokens and keyless federated identities.
The principle of least privilege must be maintained for all automated service identities.

Which strategy should the team implement to fulfill these requirements for Storage Transfer Service?

Enable Workload Identity on a GKE cluster, create a Kubernetes Service Account bound to a Google Service Account, and execute scheduled transfer jobs inside container pods.

Grant the Service Account Token Creator role to the Storage Transfer Service service agent in Google Cloud, register an application in Azure with a federated credential specifying the service agent's OIDC issuer, and grant that Azure application read access to the storage container.

Deploy an Active Directory Federation Services (AD FS) farm behind an HTTPS Load Balancer with token binding disabled to issue Kerberos tickets to the service agent.

Generate an Azure SAS token, store the token as a secret in Google Cloud Secret Manager, and reference the secret's resource ID in the transfer job's credentialsSecret specification.

Professional Cloud DevOps Engineer

Storage Transfer Service Workload Identity Azure

Related questions