Fix Azure CycleCloud Errors: Credentials & Setup Guide
Why This Is Happening
I've seen this exact situation play out on dozens of Azure HPC deployments: you've stood up an Azure CycleCloud server, configured everything, and then the moment you try to spin up compute nodes or validate your credentials, everything grinds to a halt. The error message you get back is either cryptic, filled with GUIDs, or blaming you for something you didn't intentionally break. Sound familiar?
Azure CycleCloud troubleshooting almost always traces back to two root causes: expired client secret keys and incorrectly assigned role permissions. These two issues account for the overwhelming majority of credential failures, VM provisioning errors, and load balancer creation failures I see in enterprise HPC environments.
Here's why the first one catches people off guard. When you set up a service principal in Microsoft Entra ID (formerly Azure Active Directory), client secret keys are created with an expiration date. The default is often one or two years. Developers create the secret during initial setup, commit it to their CycleCloud configuration, and then completely forget about it , until one Tuesday morning when nobody can launch a cluster job. The error code you'll see is AADSTS7000222. That specific code means the secret has expired. It's not your infrastructure that's broken, it's a credential management problem.
The second root cause, AADSTS7000215, is a permissions problem. When CycleCloud tries to perform actions on your Azure subscription, creating VMs, allocating storage accounts, managing network resources, it needs the right level of authorization. Whether you're using a service principal or managed identities, the Contributor role at the subscription level is what CycleCloud requires. If that role assignment was skipped, misapplied to the wrong resource scope, or assigned to the wrong identity, you'll get an "Invalid Azure credentials provided" error every single time.
What makes Azure CycleCloud credential errors extra frustrating is that the error messages don't explain what to fix or where to fix it. They throw correlation IDs, tenant GUIDs, and timestamp strings at you that are only useful if you're already inside a Microsoft support case. That's exactly why this guide exists, to translate those wall-of-text errors into plain English and walk you through every fix step.
Both issues are completely fixable, usually in under 15 minutes once you know where to look. I'll cover the expired secret scenario first (most common), then walk through the role assignment fix for both service principal and managed identity setups. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep into permissions audits and service principal archaeology, try this. In most Azure CycleCloud troubleshooting cases involving credential errors, the fastest path to resolution is regenerating the client secret and updating the CycleCloud portal with the new value. If your error contains the code AADSTS7000222, this single action will solve your problem.
Here's what to do right now:
- Open the Azure portal and navigate to Microsoft Entra ID (search "Entra" in the top search bar).
- Click App registrations in the left panel, then find and click your CycleCloud application by name.
- In the left panel, select Certificates & secrets.
- Under the Client secrets section, you'll see your existing secret listed, almost certainly showing an Expired status. Click + New client secret.
- Give it a description (something like "CycleCloud-2026-renewed") and choose an expiration period. I recommend 24 months, long enough to be practical, short enough to still be managed.
- After clicking Add, the new secret value appears in the Value column. Copy it immediately, you won't be able to see it again after you navigate away.
- Now go to your CycleCloud portal, click Configure in the top menu, select your cloud account under Cloud Provider Accounts, and click Credentials > Edit.
- Paste the new secret into the Application Secret field and click Validate. If validation passes, click Save.
If the validation succeeds immediately, you're done. Your VMs should deploy normally now.
If validation still fails after the new secret, meaning you see a different error, or the same error but with the code AADSTS7000215, don't panic. That means you've got a permissions problem on top of (or instead of) an expired secret, and the step-by-step section below covers exactly that scenario.
Azure CycleCloud credential errors split into two distinct failure modes, and the fix is different for each. Before touching anything, confirm which error code you have. This saves you from chasing the wrong solution.
The two errors you'll encounter during Azure CycleCloud troubleshooting are:
- AADSTS7000222, "The provided client secret keys are expired." This appears during VM deployment or termination, often buried inside a longer error that starts with
Azure.Cell.CreateLoadBalancer. The full message references creating a load balancer and will include a Trace ID and Correlation ID. - AADSTS7000215, "Invalid client secret is provided." This one shows up when you manually validate credentials in the CycleCloud portal under Configure > Cloud Provider Accounts > Credentials.
There's a third error that looks similar but has a different cause, it reads: "The client '<guid>' with object id '<guid>' does not have authorization to perform action 'Microsoft.Storage/storageAccounts/read'". This one is a role assignment problem, not an expired secret. Note the key phrase: Microsoft.Storage/storageAccounts/read. That's CycleCloud trying to access storage and being told it doesn't have permission.
To check which error you have, log into the CycleCloud portal and navigate to Configure > Cloud Provider Accounts. Select your account and click Credentials > Edit, then hit Validate. The specific error message returned here will tell you exactly which category you're in.
If you see AADSTS7000222 or AADSTS7000215, expired or invalid secret, proceed to Steps 2 and 3. If you see the storage authorization error, proceed directly to Steps 4 and 5 for role assignment fixes.
This step handles the expired or invalid client secret error codes. You're going to create a fresh credential in Microsoft Entra ID and pull that value into CycleCloud.
Sign in to the Azure portal at portal.azure.com. In the top search bar, type "Microsoft Entra ID" and select it from the results. You'll land on the Entra ID overview page.
In the left navigation panel, look for App registrations, it's under the Manage section. Click it. You'll see a list of registered applications. Find the application that your CycleCloud instance uses. If you're unsure which one it is, look for an app name that matches what was created when you ran the service principal setup commands, it's often something like "cyclecloud" or whatever name your team gave it during initial provisioning.
Click the application name to open it. From there, select Certificates & secrets in the left panel. Under the Client secrets tab, you'll see existing secrets with their status, look for one marked Expired.
Click + New client secret. Fill in a description and choose your expiration. Click Add. The new secret's value appears in the table under the Value column.
Copy this value right now. It will never be shown again after you leave or refresh the page. If you miss it, you'll need to create yet another new secret.
Store this value somewhere secure temporarily, a password manager, a secrets vault, whatever your team uses. You'll need it in the next step. You should also record the Application (client) ID shown on the app registration's Overview page, CycleCloud needs this too.
If the step worked: you'll see a new secret entry in the Client secrets table with a future expiration date and a status of Active.
You've got a fresh client secret. Now you need to tell CycleCloud about it. This is where a lot of people trip up, they regenerate the secret in Entra ID but forget to update it in CycleCloud, and the errors keep coming.
Open your CycleCloud web portal. The URL is typically something like https://<your-cyclecloud-vm-ip> or a custom DNS name your team configured. Log in with your admin credentials.
In the top navigation bar, click Configure. This opens the configuration settings panel. In the left side of the configuration panel, look for Cloud Provider Accounts and click it. You'll see a list of configured cloud accounts, select the one associated with your Azure subscription.
Click Credentials, then click Edit next to the credential set you're updating. A dialog box titled Edit Credential will appear.
Find the field labeled Application Secret and clear the existing value. Paste your new client secret value here. Make sure there are no extra spaces, leading or trailing whitespace will cause the validation to fail silently.
Click Validate. Give it 10–15 seconds to make the call back to Azure. If validation succeeds, you'll see a green confirmation message. Click Save to commit the change.
After saving, try deploying a test VM or running a small cluster job to confirm end-to-end functionality. If you're still seeing errors after the secret update, specifically errors about missing authorization to read storage accounts or create VMs, move on to Steps 4 and 5, which address the role assignment side of Azure CycleCloud troubleshooting.
If your error reads something like: "does not have authorization to perform action 'Microsoft.Storage/storageAccounts/read' over scope '/subscriptions/<guid>'", the problem is not your secret, it's that your service principal doesn't have the right role on the subscription.
Here's how to check and fix it.
Log in to the Azure portal and search for Subscriptions in the top search bar. Click on the subscription that CycleCloud is deployed into. If you have multiple subscriptions, make sure you're in the right one, this is a common mistake in environments with dev, staging, and production accounts.
In the subscription's left panel, click Access Control (IAM). Then select the Role assignments tab. You'll see a filterable list of every identity assigned to this subscription and their roles.
Search for your service principal name in the filter box. Look for it under the Contributor role. If it's not there, or if it shows up under a different role, like Reader, that's your problem.
To add the Contributor role, you need either the Owner role or the User Access Administrator role on the subscription. The standard Contributor role itself doesn't grant Microsoft.Authorization/roleAssignments/write permission, so if you only have Contributor, you'll need to ask someone with Owner access to do this step.
Click + Add > Add role assignment. Select Contributor from the role list, then search for your service principal under Members. Select it, click Review + assign, and confirm. Role assignments typically take one to two minutes to propagate. After that, go back to CycleCloud and validate your credentials again.
If your CycleCloud setup uses managed identities instead of a service principal, the fix follows a slightly different path, but the underlying issue is the same: the Contributor role hasn't been assigned to the managed identity at the subscription level.
Managed identities are the newer, more secure approach that Microsoft recommends for CycleCloud deployments because they don't require you to manage secrets manually. The tradeoff is that the role assignment step is easy to miss during initial setup.
To fix this, log into the Azure portal and navigate to the Virtual Machines section. Find your CycleCloud server VM and click on it. In the VM's left navigation panel, scroll down to Settings and click Identity.
Under the System assigned tab, verify that the status is set to On. If it's Off, managed identity isn't enabled at all, toggle it on and save before continuing.
Once managed identity is confirmed as enabled, click Azure role assignments, this button appears within the Identity panel. Then click + Add role assignment.
In the dialog that appears, set the Scope dropdown to Subscription, and set the Role dropdown to Contributor. Click Save.
According to the official documentation, it can take one to two minutes for the new assignment to propagate. After waiting, head back to CycleCloud, navigate to Configure > Cloud Provider Accounts > Credentials > Edit, and click Validate. A successful validation confirms your managed identity now has the right permissions to manage subscription resources, VMs, storage, networking.
If validation still fails after the role assignment, wait another two minutes and try again. Azure's role assignment propagation is usually fast but occasionally lags.
Advanced Troubleshooting
If you've worked through every step above and you're still hitting walls with Azure CycleCloud troubleshooting, there are a few deeper-level diagnostics worth running. These scenarios come up most often in enterprise environments with custom policies, multiple tenants, or security-hardened subscriptions.
Check for Azure Policy Restrictions Blocking Role Assignments
In many enterprise Azure environments, Azure Policy is configured to restrict or audit role assignments. If your organization has a "deny" policy on broad Contributor assignments, which some security teams enforce to limit blast radius, your role assignment may appear to succeed in the portal but be silently denied at enforcement time. To check this, navigate to Policy > Compliance in the Azure portal and filter for your subscription. Look for any assignment denial events timestamped around when you added the Contributor role.
Multi-Tenant and Multi-Subscription Scenarios
One of the most common "invisible" causes of Azure CycleCloud credential failures in larger organizations is a mismatch between tenants. Your service principal may have been created in Tenant A but the subscription you're deploying CycleCloud resources into belongs to Tenant B. The Contributor role assignment you made in the portal was made in the wrong tenant, so it has zero effect on the actual deployment target. Verify by checking the Directory (tenant) ID shown on your App Registration's Overview page, it must match the Tenant ID associated with your target subscription. You can verify the subscription's tenant by clicking on it in Subscriptions and looking at the Directory field.
Using Custom Roles Instead of Contributor
The official documentation acknowledges that the Contributor role carries more privilege than CycleCloud strictly needs. In security-sensitive environments, a custom role is worth building. At minimum, CycleCloud requires permissions to read and write VMs, storage accounts, networks, load balancers, and scale sets. If you're scoping a custom role, start from the Contributor definition and trim down, don't build up from scratch. Any missing permission will show up as a new authorization error with the specific action name that failed, like Microsoft.Network/virtualNetworks/read, which you can then add to the custom role definition.
Diagnosing Failed Deployments with Azure Activity Logs
When CycleCloud can't create a resource and the error message isn't clear enough, the Azure Activity Log is your best friend. Go to your subscription and select Activity log from the left panel. Filter by Failed operations and look for entries in the timeframe when your CycleCloud deployment attempt occurred. The detailed view of each failed operation shows the exact authorization error, the calling identity, and the resource it tried to act on, far more useful for diagnosis than the error surface in CycleCloud itself.
AADSTS90002 (tenant not found) or AADSTS700016 (application not found in the tenant), those indicate a deeper identity configuration issue that Microsoft Support will need to trace through their back-end systems. Open a support request via Microsoft Support and include your Correlation ID from the error message, that ID lets the support team pull the exact authentication trace from their logs within minutes.
Prevention & Best Practices
The best Azure CycleCloud troubleshooting session is the one you never have to run. Most credential failures are entirely preventable with a few proactive habits. After spending time with teams that have had to do emergency secret rotations on production HPC clusters, here's what the well-run ones do differently.
Track secret expiration dates aggressively. When you create a new client secret in Entra ID, immediately create a calendar reminder or monitoring alert for 30 days before it expires. Azure doesn't send you a warning email by default. You are responsible for knowing when it expires. If you use Azure Monitor, you can build an alert rule against the Entra ID audit logs that fires when a secret is within 30 days of expiry. That early warning is the difference between a planned 10-minute rotation and a 2am incident.
Move to managed identities where possible. The entire class of "expired secret" errors goes away when you use managed identities instead of service principals with client secrets. Managed identities are rotated automatically by Azure, you never touch the credential. For new CycleCloud deployments, the official docs recommend managed identities for this exact reason. If you're on an older service principal setup, plan a migration window.
Document your role assignments. It sounds simple, but a significant number of role assignment failures I've seen happen because a team member removed the Contributor assignment as part of a "permission cleanup" without knowing CycleCloud depended on it. Keep a runbook entry that explicitly lists what role is required, which identity holds it, and why. Tag your role assignments with a "managed-by: cyclecloud" label so they're harder to accidentally remove.
Validate credentials after every infrastructure change. Any time someone touches your Entra ID app registrations, role assignments, or CycleCloud VM identity settings, run a manual credential validation in the CycleCloud portal immediately. Catching a misconfiguration right after a change is infinitely easier than diagnosing it three weeks later when someone runs a cluster job.
- Set calendar alerts 30 days before every client secret expiration, Azure won't notify you automatically
- Migrate to managed identities on new deployments to eliminate manual secret management entirely
- Tag role assignments in Azure IAM with a description noting their dependency on CycleCloud
- After any change to Entra ID or subscription permissions, always re-validate credentials in the CycleCloud portal before your next cluster launch
Frequently Asked Questions
What does the Azure CycleCloud error AADSTS7000222 actually mean?
AADSTS7000222 means the client secret key tied to your CycleCloud service principal has passed its expiration date. Azure simply stopped accepting it as valid authentication. The fix is to generate a new client secret under your app registration in Microsoft Entra ID, go to Certificates & secrets, click New client secret, then copy the new value and update it in CycleCloud under Configure > Cloud Provider Accounts > Credentials > Edit. This is the most common Azure CycleCloud credential error and it's fully self-serviceable.
Why does CycleCloud say "Invalid Azure credentials provided" even after I reset the secret?
If you're still seeing "Invalid Azure credentials provided" after updating the secret, you're most likely dealing with a second distinct issue: the error code AADSTS7000215, which means the secret itself was entered incorrectly, possibly with a leading space or truncated value, or the role assignment is missing entirely. Go back to the Edit Credential dialog and re-paste the secret carefully. If validation still fails, check that the Contributor role is assigned to your service principal at the subscription level under Access Control (IAM) in the Azure portal.
Does CycleCloud need the Contributor role, or can I use a custom role?
CycleCloud works with the built-in Contributor role, which is the simplest option because it covers all required actions: creating VMs, managing storage, allocating network resources, and working with load balancers. That said, the official documentation acknowledges that Contributor grants slightly more permission than CycleCloud strictly requires. For security-sensitive environments, a custom role scoped to the specific resource actions CycleCloud uses is a valid approach, but it requires careful testing, because any missing permission shows up as a new authorization error at runtime. Start with Contributor to confirm your setup works, then narrow it with a custom role if your security policy demands it.
How long does a CycleCloud role assignment take to propagate after I add it?
Per Microsoft's official documentation, role assignments typically propagate within one to two minutes. In practice, most take under 60 seconds in standard subscriptions. However, in environments with heavy Azure Policy evaluation or high subscription activity, propagation can occasionally take longer. If you validate credentials in CycleCloud immediately after saving the role assignment and it still fails, wait two full minutes and try again before concluding something is wrong with the configuration.
Can I use managed identities instead of a service principal for Azure CycleCloud?
Yes, and Microsoft's documentation explicitly supports this path. To use managed identities, enable the system-assigned managed identity on your CycleCloud server VM (VM > Settings > Identity > toggle On), then assign the Contributor role to that managed identity at the subscription level via Azure role assignments. The advantage is that managed identities eliminate the need to manage client secrets entirely, Azure handles credential rotation automatically. This makes managed identities the better long-term choice for avoiding the expired secret class of Azure CycleCloud troubleshooting problems.
Where is the Application Secret field in the CycleCloud portal?
It's not on the main dashboard, you have to navigate to it. From the CycleCloud portal top menu, click Configure, then select Cloud Provider Accounts in the left panel. Click on your Azure account, then look for the Credentials section and click Edit. The Edit Credential dialog box has a field labeled Application Secret, that's where you paste the new client secret value. After pasting it, always click Validate first to confirm it works before clicking Save.