Does Pulumi automatically refresh expired Azure AD service‑principal secrets?

Short answer

No. Pulumi does not automatically refresh or rotate expired Azure AD (Microsoft Entra ID) service-principal secrets—neither the credentials Pulumi uses to authenticate to Azure, nor secrets it manages as resources such as azuread.ApplicationPassword. Pulumi is a declarative provisioning tool, not a secret lifecycle manager. Rotation must be triggered externally, typically by a scheduled CI job.

Two separate cases, both manual

It is important to distinguish between the two types of secrets involved:

• Provider authentication credentials: If Pulumi authenticates to Azure with a static client secret (e.g., ARM_CLIENT_SECRET), the Azure SDK refreshes short-lived access tokens during a run, but the underlying client secret is never renewed. When it expires, pulumi up fails with an authentication error until the environment or Pulumi ESC/config is updated.
• Secrets managed as resources: An azuread.ApplicationPassword has a fixed endDate. When that date passes, Pulumi does nothing automatically; the resource only changes if you modify its inputs and execute a stack update.

Answering your specific sub-questions

1. Pre-command credential hook: There is no Pulumi CLI callback to re-fetch a secret immediately before a command. Pulumi ESC can reference a secret store (like Azure Key Vault) to resolve values at runtime, but ESC resolves the current value; it does not rotate an expired secret.
2. DefaultAzureCredential: Yes, the Azure provider can use the standard Azure SDK credential chain (Azure CLI, Managed Identity, or OIDC federation). Switching to OIDC workload identity federation or Managed Identity eliminates expiring secrets entirely, which is the recommended path for provider authentication.
3. External rotation pattern: For secrets managed as resources, the common pattern is to store a rotation timestamp or counter in stack config and wire it into the password resource (using rotateTriggers or replace_triggered_by, depending on your provider version). A scheduled CI job then bumps the value and runs pulumi up before the secret expires.

Verification and caveats

Verify your installed provider version with pulumi plugin ls, as rotation-related input names vary across pulumi-azuread releases. Note that replacing an ApplicationPassword invalidates the old secret immediately; ensure consumers can pick up the new value to avoid downtime. You can verify the lack of auto-rotation by creating a password resource with a very short endDate and running pulumi preview after it expires; no change will be detected.

One diagnostic detail to consider: if your goal is strictly provider authentication, moving to OIDC federation is generally preferable to building a custom rotation pipeline.