az_setup_github_oidc

• The target web app must already exist — run az_create_resources first.
• You're authenticated as an identity with permission to create managed identities and assign roles on the resource group / web app.
• The GitHub repository and environment name you're setting this up for — defaults match this project's own repository and a Development environment.

$encodedEnvironment = $GitHubEnvironment.Replace(':', '%3A')
$FederatedSubject = "repo:gdzierzon@9723466/cohort-d-dzierzong-metals-simple-deploy@1361521533:environment:${encodedEnvironment}"

The exact same computed value as main.tf's local.oidc_subject — a fixed string identifying “GitHub Actions, running in this exact repository, in this exact environment.” For any repository other than this project's own, you have to pass -FederatedSubject explicitly with the value GitHub's own azure/login action prints in its log — the script can't safely guess another repository's immutable owner/repo IDs.

$app = Invoke-Az webapp show --resource-group $resourceGroup --name $appName `
    --query '{id:id,location:location}' --output json | ConvertFrom-Json

Needs the web app's ID (to scope the role assignment) and location (to create the identity in the same region) — both read directly from the resource that az_create_resources already created.

$identity = Invoke-Az identity create --resource-group $resourceGroup --name $identityName `
    --location $app.location --output json | ConvertFrom-Json

The manual equivalent of github_oidc.tf's azurerm_user_assigned_identity — an empty identity, with no permissions yet.

Invoke-Az identity federated-credential create `
    --resource-group $resourceGroup --identity-name $identityName --name github-development `
    --issuer 'https://token.actions.githubusercontent.com' --subject $FederatedSubject `
    --audiences 'api://AzureADTokenExchange'

Same issuer, audience, and subject concepts covered on the github_oidc.tf page — this is the trust rule itself, deciding exactly which GitHub Actions tokens Azure will accept.

Invoke-Az role assignment create `
    --assignee-object-id $identity.principalId --assignee-principal-type ServicePrincipal `
    --role 'Website Contributor' --scope $app.id

The same least-privilege pattern as github_oidc.tf's role assignments: Website Contributor, scoped to $app.id — this one web app — not the resource group and not the subscription.

One assignment, on the API app only. That was sufficient when the API was the only deployable thing; it no longer covers everything the workflows need. See the gap below.

Write-Host "AZURE_CLIENT_ID = $($identity.clientId)"
Write-Host "AZURE_TENANT_ID = $($identity.tenantId)"
Write-Host "AZURE_SUBSCRIPTION_ID = $subscriptionId"

The same three identifiers Terraform's outputs.tf publishes as its github_secrets output — ready to paste into the repository's Development environment secrets.

If the identity and role assignment already exist, but the trusted subject was wrong (a common cause of authentication failures), pass -UpdateCredentialOnly to update just the federated credential's subject, without recreating the identity or re-granting the role. This trades the safety of Terraform's plan/apply cycle for a narrower, faster fix — there's no equivalent single-purpose “just fix the subject” command in the Terraform workflow; you'd change the relevant variable and run terraform apply again instead.