AZ-104
Deep Dive
Azure's tools for protecting data against accidental deletion, ransomware, and unauthorized access. The AZ-104 tests versioning, soft delete, immutability, encryption with customer-managed keys, and Microsoft Defender for Storage.
Contents
Azure Blob Storage offers multiple layers of protection that can be enabled independently. Combining them is recommended for defense in depth: Versioning + Soft Delete + Immutability.
| Feature | Protects against | Level | Recovery |
|---|---|---|---|
| Blob Versioning | Accidental data overwrite | Individual blob | Promote a previous version to current |
| Blob Snapshots | Manual point-in-time backup | Individual blob (manual) | Copy snapshot to the base blob |
| Soft Delete (blob) | Accidental deletion of a blob or version | Individual blob | Undelete within the retention period |
| Soft Delete (container) | Accidental deletion of a container | Entire container | Restore the container within the period |
| Immutable Storage | Deletion/modification (compliance, ransomware) | Container or account | Not applicable — data cannot be deleted until it expires |
| Point-in-time restore | Massive data corruption, ransomware | Entire account (block blobs) | Restore all blobs to a previous point |
Blob Versioning (automatic)
When versioning is enabled, every write (PUT, COPY, overwrite) to a blob automatically creates a new version. The current version is always the most recent. Previous versions are retained indefinitely (or removed with lifecycle policies).
Blob Snapshots (manual)
A snapshot is a read-only copy of the blob at a specific point in time. Unlike versioning (automatic), snapshots are created manually or via the API. The snapshot is immutable — it cannot be modified.
Versioning vs Snapshots — when to use each
Use Versioning when:
Use Snapshots when:
Soft Delete for Blobs
When a blob is deleted, it is retained in a "deleted" state for the configured retention period (1-365 days). It can be restored within that period.
Soft Delete for Containers
Protects the entire container (and all blobs inside it). If someone deletes a whole container, it is retained with all its blobs for the configured period.
WORM (Write Once, Read Many) prevents data from being modified or deleted for a period. Crucial for regulatory compliance: SEC 17a-4, FINRA, HIPAA.
Time-based Retention Policy
Blobs cannot be deleted or modified during the defined retention period (in days). After the period, they can be deleted normally.
Unlocked
Configurable — can be extended (not reduced) or removed
Locked
Irrevocable — cannot be disabled or have the period reduced. Required for SEC 17a-4 compliance.
Legal Hold Policy
Indefinite retention with no defined period. Data cannot be deleted until the legal hold is explicitly lifted. Used for litigation or investigations.
Active
Blobs cannot be deleted or modified until the legal hold tag is removed
Multiple tags
A container can have multiple legal holds for different cases/projects
Policy application levels
Container-level
Applies to all blobs in the container. Configured on the container.
Version-level (default)
Each blob version has its own immutability. More granular.
Account-level (default retention)
Default retention policy for all new containers in the account.
Always Encrypted
End-to-end encryption where the keys NEVER leave the client. The SQL engine only ever sees encrypted data — not even DB admins can see the plaintext.
The master key (Column Master Key) lives on the client (Windows certificate, Azure Key Vault). The engine receives data that is already encrypted.
Ultra-sensitive data: card numbers, SSNs, passwords. Requires a compatible client (ODBC, JDBC with the right driver).
Transparent Data Encryption (TDE)
Encrypts the DB, backups, and log files at rest. The engine encrypts/decrypts automatically — the app needs no changes.
Unlike Always Encrypted, with TDE the DB engine can see the plaintext data (it decrypts it to process it). It protects physical storage, not access at the engine.
Baseline protection for any DB. Enabled by default on Azure SQL.
Row-Level Security (RLS)
Controls row access based on the user running the query. Rows invisible to the user simply don't appear in the results — no errors.
Implemented with Security Policies and T-SQL predicate functions. Transparent to the application.
Multi-tenant: each tenant only sees its own rows with no changes to the app.
Dynamic Data Masking (DDM)
Masks columns for users without privilege. The real data exists and privileged users see it in full.
Not encryption — it is presentation. The real data remains unencrypted in the DB. A DBA always sees the real data.
Limit exposure of sensitive data to technical support or low-privilege reports.
Azure Key Vault centralizes the management of cryptographic keys, secrets, and certificates. It is the centerpiece of Azure's data security strategy.
Secrets
Text strings: connection strings, API keys, passwords. Versioned. Can have an expiration date.
db_connection_string: Server=sql.database.windows.net;...
Keys
Cryptographic keys (RSA, EC). Operations happen inside the HSM — the key never leaves Key Vault in plaintext.
Customer-managed key for Storage Account, SQL TDE, Cosmos DB CMK
Certificates
TLS/SSL certificates. Manages creation and automatic renewal with Let's Encrypt or your own CAs.
TLS certificate for App Service or Application Gateway
Key Vault tiers
Standard
Software-protected keys. Keys are stored in encrypted software inside the service. Lower cost.
Premium
HSM-protected keys. Keys are generated and stored in FIPS 140-2 Level 2 certified Hardware Security Modules. The key never leaves the HSM.
Managed HSM
Dedicated single-tenant HSM. FIPS 140-2 Level 3. Full control — not even Microsoft can access it. For the strictest compliance requirements.
Key Vault access control
Management plane (who can administer the vault):
→ Azure RBAC: Key Vault Contributor, Reader (configuration control)
Data plane (who can use secrets/keys):
→ RBAC (recommended): Key Vault Secrets User, Key Vault Crypto User, Key Vault Certificates Officer
→ Access Policies (legacy): granular per-principal permissions (Get, List, Set, Delete, etc.)
Best practice: Managed Identity + Key Vault
Instead of storing secrets in the app or in environment variables: assign a Managed Identity to the VM/App Service, grant that identity the Key Vault Secrets User role on the vault, and the app reads secrets directly with no credentials in the code.
Microsoft Defender for Storage
Detects anomalous access patterns on Storage Accounts: mass data download, access from TOR, known malware hashes in uploaded files (Malware Scanning).
Microsoft Defender for SQL
Includes Advanced Threat Protection (ATP) and Vulnerability Assessment. Detects anomalous activity and evaluates the DB's security posture.
Did you get this topic?
Test what you just learned
A financial services company needs to store transaction records in Blob Storage so they cannot be modified or deleted for 7 years, to meet regulatory requirements. What configuration should they use?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.