A script needs cloud CLI credentials (like AWS/Azure/gcloud auth) that are normally provided by an interactive session's environment. How do you handle that for a cron-scheduled script?

Don't rely on anything tied to an interactive session (SSO sessions, manually-run aws sso login, environment variables set by a shell startup file cron never sources) — instead, give the cron job its own explicit, non-interactive credential source: an IAM role if the script runs on AWS compute (instance profile, ECS task role), or a dedicated service credential (an IAM user scoped tightly to just what the script needs, or a stored SSO/OIDC-based short-lived credential refreshed by the script itself) referenced explicitly in the cron job's own environment, not inherited from wherever it happens to run.

The reason this breaks specifically for cron is the same root cause as the general cron-environment-mismatch problem: cron doesn't source shell startup files, so any credential setup that lives there (an export AWS_PROFILE=... in .bashrc, an SSO login performed once per day in an interactive terminal) simply isn't present when cron runs the script — the script has no idea those credentials were ever configured, because from cron's non-interactive shell's perspective, they never were.

The fix depends on where the script actually runs and what's available:

If running on cloud compute (an EC2 instance, an ECS task, a Lambda function on a schedule): use the compute's own IAM role mechanism (instance profile, task role, execution role) — this is the cleanest fix, since credentials are automatically available to any process on that compute via the metadata service, with no explicit configuration needed in the cron job itself, and no static credential to manage or leak at all.

If running somewhere without a native cloud identity (an on-prem server, a personal machine, a non-cloud CI runner): a dedicated, narrowly-scoped credential is required — either a static IAM user's access keys (accepting the trade-offs of a long-lived credential, scoped tightly and rotated, per the earlier third-party-app pattern) stored securely (a secrets manager, an encrypted credentials file readable only by the account the cron job runs as) and referenced explicitly (AWS_SHARED_CREDENTIALS_FILE=/path/to/creds set directly in the crontab or the script itself, not relying on a default location that assumes interactive-session setup), or a short-lived credential obtained via an automated, non-interactive auth flow (e.g. an OIDC-based exchange) that the script itself performs before making any cloud API calls, rather than assuming credentials are already present.

Explicit over inherited, in all cases: whatever the credential source, it should be referenced explicitly within the cron job's own execution context (set directly in the crontab's environment, or sourced from a file the script explicitly reads) rather than assumed to be inherited from "whatever's normally configured" — since cron's minimal environment guarantees nothing is inherited by default.

• Cron's non-interactive, non-login shell doesn't inherit interactive-session credential setup (SSO sessions, environment variables from shell startup files) — the same root cause as the general cron-environment-mismatch problem.
• On cloud compute, the IAM role mechanism (instance profile, task role) is the cleanest fix — no static credential needed, automatically available to any process.
• Off cloud compute, a dedicated, narrowly-scoped credential (stored securely, referenced explicitly) or an automated non-interactive auth flow is required.
• Credentials for a cron job should always be referenced explicitly within its own execution context, never assumed to be inherited from interactive-session state.

• AWS CLI: Configuration and credential file settings
• AWS: IAM roles for Amazon EC2