A cloud-based identity and access management service for securing user authentication and resource access
The CLI result is useful evidence that PowerShell 7.6 is currently being advertised as an available Flex Consumption runtime in your subscription/region, but I would not use that result alone as proof that Microsoft has declared the runtime generally available.
Those are two different questions:
- Can Azure currently offer/deploy this runtime in East US?
- What lifecycle/support status has Microsoft assigned to it, such as GA or Preview?
"az functionapp list-flexconsumption-runtimes" is useful for answering the first question because it queries the runtimes currently exposed for Flex Consumption.
If PowerShell 7.6 is returned as the default runtime, I would capture the complete result rather than only the runtime version:
az functionapp list-flexconsumption-runtimes `
--runtime powershell `
--location eastus `
-o json
Also record the Azure CLI version:
az version
That gives you a reproducible snapshot of what Azure's control plane is advertising to your subscription in East US.
However, I would be cautious about concluding:
«"The CLI lists 7.6, therefore PowerShell 7.6 on Flex Consumption is GA."»
Runtime discovery and product lifecycle designation are not necessarily the same thing. A capability can be exposed through a control-plane/API surface while its documentation, regional rollout, tooling, or support status is still being updated.
For a production decision, I would therefore verify three things independently:
- the runtime is returned for the target region and subscription;
- a test Flex Consumption app can actually be created using that runtime;
- Microsoft's Functions documentation/release information explicitly identifies the support status you require.
For example, after confirming runtime discovery, I would deploy a minimal non-production PowerShell 7.6 Flex Consumption Function App and verify the effective runtime configuration after deployment rather than relying only on the default returned by the discovery command.
I would also avoid changing a production workload based solely on the fact that 7.6 appears as the default. "Default currently returned by the API" and "supported production lifecycle status" are separate assertions.
So, based on the evidence in your question:
PowerShell 7.6 appears to be available through the Flex Consumption runtime-discovery surface in East US for your environment.
But I don't think that observation alone is sufficient to authoritatively label the feature GA. If the current Microsoft documentation does not explicitly resolve the GA/Preview status, Microsoft would need to confirm the lifecycle designation or update the documentation.
Your CLI output is actually valuable evidence for that documentation discrepancy, so I would include the complete JSON result, CLI version, subscription type, and the timestamp of the test when escalating it.
For anyone working with Azure Functions who wants a deeper understanding of Functions development and deployment, Microsoft Learn provides the Azure Functions training material here:
That distinction between runtime discovery, successful deployment, and documented support status is important when deciding whether a newly exposed runtime is appropriate for production.