storage-access-keys

Storage access keys & connection strings

What it is

Each storage account has two 512-bit access keys (key1, key2). They are the master credentials granting full control over every data service in the account — equivalent to root. Tools/auth use them via Shared Key authorization or in connection strings.

Why it exists

You need a simple, high-privilege credential to authenticate admin/data operations against your storage account. Two keys let you rotate one without downtime (rotate key1 while clients still use key2, etc.).

Key ideas

• Full access: ownership-level read/write on blobs, files, tables, queues. Guard them like passwords.
• Connection string = account name + key (+ endpoint suffix) — what apps/tools (AzCopy, Storage Explorer) use.
• Regeneration immediately invalidates the old key — re-fetch before rotating to avoid breaking clients.
• Prefer lower-privilege access:
  • SAS tokens for scoped, time-limited delegated access (don’t share keys).
  • Managed identity / RBAC (Azure AD) — the modern preferred auth (e.g., Storage Blob Data Reader role).
• Rotate keys periodically; consider Microsoft Entra ID auth where possible.

How it fits (diagram)

Exam notes

• Two keys enable trouble-free rotation/regeneration.
• Keys = full control; SAS = scoped + expiring; Azure AD/RBAC = identity-based, best practice.
• Regenerating a key invalidates anything using it (including SAS issued from it in some models).
• Never embed keys in code — use managed identities or SAS.

Related

storage-account · sas-token · storage-network-rule · rbac · entraid

📘 Source: Microsoft Learn — Storage Access Keys