Articles

Workload Identity Federation Interview Questions: Trust Conditions and Token Exchange

Prepare workload identity federation interview answers with audience checks, GitHub claim conditions, token exchange, and resource authorization.

Workload identity federation interview questions test whether you can explain a trust path without treating every valid token as permission to access production. A deployment job can obtain a signed identity token, pass token exchange, and still correctly receive a denial from a storage API. Each step answers a different question.

This guide grounds platform behavior in official Google Cloud, GitHub, and Microsoft documentation, checked on September 30, 2026. The trust table and failure trace are original preparation exercises, not candidate reports or claims about a particular employer's interview. For an adjacent implementation exercise, start with Build an Auth0-protected MCP server and identify the authority that validates each token.

What does federation replace, and what does it retain?

Federation lets an external workload use an identity established by another system to obtain cloud credentials. In Google Cloud, Workload Identity Federation supports external identities and short-lived access without distributing a service-account key. That removes one long-lived credential from the deployment workflow. It retains trust configuration, permissions, token handling, and the responsibility to secure the runner. Google Cloud federation overview

A strong interview answer names the parties: the workload, the external issuer, the configured cloud provider, the token-exchange service, and the resource API. Then trace the artifacts between them. “We use OIDC” is incomplete unless you can say whose assertion is accepted and what that assertion is allowed to become.

The security improvement is narrower than “there are no secrets.” A compromised authorized job can still obtain its permitted credentials. The original threat model must cover workflow edits, dependencies, runner isolation, logs, and the ability to request an identity token. Short lifetimes reduce exposure; they do not establish that the job is trustworthy.

Which audience are you checking?

There are several destinations in a federated flow, and the word audience can refer to different fields. Keep their names on the diagram rather than saying “set the audience correctly” once.

The external OIDC token contains an aud claim. The configured Google Cloud OIDC provider checks that claim against its accepted audiences. With the documented default configuration, it expects the provider's canonical resource name, with or without the HTTPS prefix. Separately, the Google Security Token Service request contains an audience parameter identifying the workload identity provider. It is not the final bucket URL. OIDC provider audience reference, STS token request

The resulting cloud credential is then presented to the intended cloud API. Do not reuse the external identity token merely because its signature was valid. Token types, validation rules, and consumers belong to their respective stages.

In an interview, label an example as Google-specific. Microsoft Entra uses its own federated-credential configuration and token endpoint. Copying a Google provider resource name into an Entra audience setting does not reproduce the same trust relationship.

Why is trusting the issuer insufficient?

GitHub Actions uses an issuer shared across repositories and organizations. Trusting that issuer establishes where an assertion came from, but does not restrict it to your repository. GitHub documents claims describing the repository, owner, reference, event, and workflow context. These claims let the cloud trust policy distinguish eligible jobs from other jobs signed by the same issuer. GitHub OIDC reference

An original practice requirement might be: only repository ID 200, owned by owner ID 100, running on refs/heads/main, may exchange a token for the production path. These are dummy identifiers, expressed as strings to match the example claim values.

Write the business rule before its syntax. Decide whether deployment should require a protected environment, a specific reusable workflow, or an approved release tag instead. A branch-only condition is not a complete production deployment policy; the permissions of people who can modify that branch remain part of the boundary.

Google recommends numeric repository and owner identifiers because deleted names can be reclaimed. Repository names are useful to humans, but a reusable name should not accidentally carry an old trust grant to a new owner. Federation security practices

Can you defend a trust condition with negative cases?

For the exercise above, the central CEL condition is:

assertion.repository_owner_id == '100' &&
assertion.repository_id == '200' &&
assertion.ref == 'refs/heads/main'

For example, map google.subject from assertion.sub and the three custom attributes from their corresponding claim fields. Check the provider's required mapping rules when deploying the condition; the predicate alone is not a complete provider configuration.

Configure the required mappings and provider validation separately. This condition is not a replacement for signature, issuer, audience, or time validation. It illustrates an admission rule after the platform has established the token's authenticity.

The following original truth table makes the intended rejection behavior reviewable:

Assertion change	Admission decision and reason
Owner `100`, repository `200`, main reference	Accept this condition; resource access still needs authorization.
Owner `999`, repository `200`, main reference	Reject: repository identity alone does not satisfy ownership policy.
Owner `100`, repository `201`, main reference	Reject: another repository in the organization is outside scope.
Owner `100`, repository `200`, feature reference	Reject: the deployment reference is outside scope.
Required repository claim absent	Reject or fail condition evaluation; never substitute a permissive default.

A useful follow-up changes only the repository's display name. Under this ID-based rule, the identity can still match. That is deliberate. If ownership changes, the owner condition should reject the new context even if the repository identifier is retained.

We checked these accept/reject decisions with a small local predicate model. That verifies the exercise's intended logic, not JWT validation, CEL runtime semantics, or a real STS exchange. A cloud integration test must use actual provider configuration and approved test identities.

Does a successful exchange authorize the resource?

No. Admission into the configured trust relationship and permission to perform an API operation are separate decisions. A successful exchange proves that a credential was issued through that path. It does not prove that the caller can read a bucket, decrypt a key, or deploy a service.

In Google Cloud, you can grant supported resources access directly to the federated principal, or use service-account impersonation where appropriate. Google recommends direct resource access when supported and describes impersonation for APIs with limitations. With impersonation, the external identity needs permission to impersonate the chosen service account, and that service account needs the resource permissions. Google Cloud federation overview

Draw the additional impersonation hop explicitly. Otherwise, a candidate may propose broad resource roles on the external principal when the actual request is made as the service account. Conversely, granting the service account a bucket role does not by itself authorize an external job to impersonate it.

For a production design, scope the grant to the smallest required operation and resource. Test both successful reading and denied writing. An allow-only demonstration cannot show that an overbroad grant has been avoided.

How would you diagnose a deployment that exchanges successfully but cannot read?

Use this original trace: a job gets an external token, STS returns a cloud token, an impersonation request succeeds, and the subsequent object read returns a permission denial.

First establish the final principal. In this scenario, it is the impersonated service account. Inspect the resource request, exact operation, and target project or bucket. Then compare those facts with that account's effective resource authorization. Do not modify the provider's issuer condition merely because the final request failed.

Now change the trace: STS succeeds, but impersonation fails. Investigate the permission to impersonate that specific account and the federated subject or attribute set covered by its grant. The resource role is not yet the failing gate.

Finally, move the failure earlier: STS rejects the assertion. Inspect provider selection, token type, configured issuer, expected audience, expiry, attribute mappings, and the evaluated condition. Obtain redacted claim summaries rather than copying bearer tokens into logs or a support conversation.

This staged approach is interview reasoning, not an assertion that one HTTP status uniquely identifies a cause. Record the service that returned the error and its structured diagnostic details. A generic “403” stripped of its request context is weak evidence.

What changes when the destination is Microsoft Entra?

Microsoft's workload identity federation connects a trusted external issuer to an application or supported identity using a federated identity credential. Its documentation describes matching issuer, subject, and audience for the external assertion. These fields are case-sensitive in the documented matching behavior. Microsoft Entra workload identity federation

Explain the chosen configuration rather than promising that every cloud accepts the same arbitrary claim expression. Google's pool/provider, mappings, and CEL conditions are one implementation. An Entra federated credential and its supported matching rules are another. Confirm current product and identity-type support before choosing a deployment pattern.

The shared principle survives the platform change: constrain which external workload can obtain which destination identity, then authorize that destination identity separately. “Federation is configured” is not evidence that an Azure data-plane role or a network route exists.

How should you handle expiry, retries, and emergency revocation?

Treat credential acquisition as a bounded operation with observable failures. Prefer a maintained authentication library that refreshes credentials according to their lifetime, and test a job whose execution outlasts one credential. Do not assume a token obtained at startup remains valid for a long-running deployment.

When a request fails around expiry, separate refresh failure from downstream permission failure. Retry only where the operation is safe to repeat, and preserve enough request context to correlate credential acquisition with resource access. Repeating an entire deployment after an ambiguous timeout can have consequences unrelated to federation.

For an incident, distinguish blocking future exchanges from invalidating credentials already issued. Google explicitly documents that disabling a provider prevents new exchanges while existing tokens still grant access. Removing a trust grant therefore does not justify a promise of instantaneous cancellation of every in-flight request. Provider state reference Review the destination's documented token and authorization behavior, and narrow resource permissions or disable the affected identity where the response plan requires it.

An original migration plan uses a restricted test path first, verifies allowed and forbidden jobs, switches the production credential source, observes successful refresh, and removes the old stored key after confirmed adoption. Keeping both paths forever preserves the credential exposure you intended to remove.

Which exercises sharpen the explanation?

Practice question	Federation follow-up
Build an Auth0-protected MCP server	Identify issuer, consumer, and the boundary around untrusted claims.
Build an OAuth-based data migration client	Distinguish an external assertion from a downstream access token.
Design Secure Token Authorization and Large-File Transfer	Explain what an accepted token permits at the resource layer.
Design a production file storage service	Verify read access and unnecessary write denial separately.
How do you perform a thorough code review?	Find a shared-issuer policy that forgot the tenant restriction.

Continue with Build an Auth0-protected MCP server. Draw the token path, change one trusted claim at a time, and explain which gate should reject each request. A clear answer connects the failed gate to the smallest justified correction.