An Azure team using HCP Terraform currently stores ARM_CLIENT_SECRET as a sensitive workspace variable. They want the same no-stored-secrets model the AWS teams use with dynamic provider credentials, covering both the plan and apply phases. What setup achieves this?
Select an answer to reveal the explanation.
Short Explanation
Same idea as AWS, different paperwork: Azure trusts HCP Terraform's token through federated identity credentials on an app registration. Here's the trap, though: Azure matches the subject as an exact string, so you need one credential for plan and one for apply. Wildcards that work in an AWS trust policy won't save you here.
Full Explanation
Azure dynamic provider credentials use workload identity federation with Microsoft Entra ID. An application registration and its service principal receive the required role assignments, and federated identity credentials of the Other issuer type are added with the HCP Terraform address as issuer and the workspace's subject string, for example organization:org:project:proj:workspace:ws:run_phase:plan. The workspace sets TFC_AZURE_PROVIDER_AUTH to true and TFC_AZURE_RUN_CLIENT_ID to the application's client ID, and each run exchanges its token for a short-lived Entra ID access token. Because the subject is compared as a direct string match, plan and apply each need their own federated credential. A rotated client secret is still a stored, long-lived secret, which is exactly what the team wants to remove. Managed identities exist only for workloads running on Azure resources; HCP Terraform's hosted runs are not Azure resources and cannot use the metadata endpoint. A wildcard subject does not match in Entra ID, so a single run_phase:* credential would reject both phases. Exam caveat: the audience defaults to api://AzureADTokenExchange and must match any custom TFC_AZURE_WORKLOAD_IDENTITY_AUDIENCE. Operational check: remove ARM_CLIENT_SECRET, queue a run, and confirm both plan and apply authenticate in the Entra ID sign-in logs.