How to deal with outdated PowerShell and Azure PS in Azure Automation?
Azure Automation is a service for running scripts in the cloud, intended for the automation of administration tasks. While using it, I came across strangely outdated technologies being used under the hood. How can I live with them while staying productive and safe from security issues and acummulating technical debt? PowerShell's current version is 7.5 and current LTS is 7.4 but the service does not allow using anything newer than 7.2. Azure PS (PowerShell module Az) current version is 13.3.0 and current LTS is 12.5.0 but the service does not allow using anything newer than 11.2.0. The docs on learn.microsoft.com are no longer available for such old versions of these technologies. In practice, I tried using a specific example from Azure PS docs related to Azure Storage but it failed with "Create Shared Access Signature is not supported while using OAuth." -- and similarly the types returned by many of the cmdlets are from different namespaces and assemblies than documented for the newer versions. I had to implement quite a bit more complicated solution that breaks best practices and even generates warnings about the dangers of storage account key use. As far as I know and managed to find, the Azure Automation service nor the features I use are not deprecated but there is no way to update the aforementioned technologies used inside. The modules have a documented path for version change, but it serves mostly just as a downgrade path as only a fixed list of versions is available and the latest one of them was selected by default for me. What are my options for dealing with this situation? I consider switching to a different service a last-resort solution as the service is quite commonly used and it fits my needs well overall. Also, my team already has an Azure subscription and attempts to use services outside Azure lead to a bureaucratic hell taking months to get approved. Currently, I try to extrapolate from current documentation based on what I see in the runtime (inspecting error messages, actually available types, etc.) but that feels pretty unproductive. I expect more from an actively supported service.

Azure Automation is a service for running scripts in the cloud, intended for the automation of administration tasks. While using it, I came across strangely outdated technologies being used under the hood. How can I live with them while staying productive and safe from security issues and acummulating technical debt?
PowerShell's current version is 7.5 and current LTS is 7.4 but the service does not allow using anything newer than 7.2. Azure PS (PowerShell module Az) current version is 13.3.0 and current LTS is 12.5.0 but the service does not allow using anything newer than 11.2.0. The docs on learn.microsoft.com are no longer available for such old versions of these technologies. In practice, I tried using a specific example from Azure PS docs related to Azure Storage but it failed with "Create Shared Access Signature is not supported while using OAuth." -- and similarly the types returned by many of the cmdlets are from different namespaces and assemblies than documented for the newer versions. I had to implement quite a bit more complicated solution that breaks best practices and even generates warnings about the dangers of storage account key use.
As far as I know and managed to find, the Azure Automation service nor the features I use are not deprecated but there is no way to update the aforementioned technologies used inside. The modules have a documented path for version change, but it serves mostly just as a downgrade path as only a fixed list of versions is available and the latest one of them was selected by default for me.
What are my options for dealing with this situation? I consider switching to a different service a last-resort solution as the service is quite commonly used and it fits my needs well overall. Also, my team already has an Azure subscription and attempts to use services outside Azure lead to a bureaucratic hell taking months to get approved. Currently, I try to extrapolate from current documentation based on what I see in the runtime (inspecting error messages, actually available types, etc.) but that feels pretty unproductive. I expect more from an actively supported service.