Azure Container Apps: how should lifecycle=None identity isolation be verified when the token endpoint returns HTTP 400?

Treat the control-plane identitySettings.lifecycle: None configuration as the authoritative isolation setting; the observed HTTP 400 confirms only that no token was returned, not that lifecycle enforcement specifically caused the failure.

Interpretation of the HTTP 400

• identitySettings.lifecycle controls the Container App lifecycle stages in which an assigned identity is available; supported values are All, Init, Main, and None.^1^
• Container Apps documentation says API version 2024-02-02-preview or later can scope an identity to those stages.^2^
• No cited Container Apps documentation defines a status code, structured error code, response message, or header that uniquely represents lifecycle: None.
• Therefore, a message-only HTTP 400 is compatible with the identity being unavailable, but is not proof of that reason. HTTP 400 can also represent malformed parameters, an invalid resource audience, an incorrect identity selector, or another token-request/configuration problem. Managed-identity endpoints on other Azure platforms document several distinct conditions that can produce HTTP 400, reinforcing that status alone is not a unique denial signal.^3^

The selector-free request does not strengthen the conclusion in this case: with no system-assigned identity and no container-available identity, failure is expected, but its HTTP status still does not establish why it failed.

Supported verification boundary

For this scenario, record these independent results:

1. Control-plane configuration
   • The intended UAMI remains assigned to the Container App.
   • The registry configuration references that identity.
   • properties.configuration.identitySettings contains that identity’s full resource ID with lifecycle: None.
   • No system-assigned identity is enabled.
   • Query the active revision/app resource after deployment rather than relying only on the submitted template.
2. Platform use succeeds
   • Confirm the revision was created and the private image was pulled successfully.
   • In Azure portal, use Container App → Observe → Log Stream → System logs and check for image-pull or registry-authentication errors.
   • System logs contain platform events such as image-pull and identity errors.^2^
3. Container use does not succeed
   • Record that the explicitly selected token request returned no token.
   • Treat the HTTP status and response shape as diagnostic evidence only.
   • Do not classify the response as a documented lifecycle_denied result because no such ACA response contract is published.

This establishes the supported configuration, successful platform image-pull use, and absence of demonstrated container token issuance. It does not prove from the HTTP response alone that the lifecycle policy generated that particular 400.

Validate the test harness without exposing the restricted identity

To separate request-construction errors from lifecycle isolation, use a disposable Container App and a different test UAMI:

1. Configure the test UAMI with lifecycle: Main.
2. Issue the same request format, API version, audience, and client_id.
3. Verify only whether a successful response was received, then immediately discard the body and token.
4. Change the test UAMI to lifecycle: None, redeploy/read back the configuration, and confirm the same harness no longer receives a token.

This A/B test validates the request path without making the production image-pull identity available to production application code. It still should not be used to assert that a particular 400 body is a stable platform contract.

For application integrations generally, Microsoft recommends the Azure Identity SDK instead of calling the local endpoint directly, but switching clients would not create a lifecycle-specific machine-readable denial signal.^2^

When a formal attestation is required

Open an Azure support request for Azure Container Apps and provide:

• subscription, resource group, app, revision, region, and workload-profile type;
• deployment/control-plane API version;
• sanitized identitySettings and registry configuration;
• UTC timestamps and replica/revision identifiers;
• HTTP status, response schema, and a hash or redacted classification of the message;
• relevant Container Apps system-log events.

Ask specifically whether the observed response is implementation-defined and whether the team can correlate the request with platform telemetry. Without a published ACA error contract, support-side correlation is the appropriate route for attributing that individual HTTP 400 to lifecycle enforcement.

References

1. Microsoft.App containerApps 2025-01-01 (deployment-language-terraform)
2. Troubleshoot common deployment failures in Azure Container Apps (azure-portal)
3. How to use managed identities for Azure resources on an Azure VM to acquire an access token