Data encryption and access control are the two main ways you stop unauthorised people from reading or tampering with your data. Without them, any file stored in the cloud is as exposed as a postcard sent through the mail — anyone who intercepts it can read the whole message. For the DP-203 exam, you need to know how to lock down Azure storage so that only the right identities, with the right keys, can get to the data, and how to prove that the data has not been changed in transit.
Jump to a section
A simple way to picture Implement Data Encryption and Access Control
You walk into a busy bank branch. The teller asks for your ID, then leads you to a private room lined with small, grey metal boxes. You slide your key into lock number 247, and the teller inserts a separate bank key into the same box. Only when both keys turn does the heavy door swing open. Inside, you place a sealed envelope containing your grandmother's will. You lock the box, and the teller takes her key back. The will is now protected by two layers: you cannot open the box without the bank's key, and the bank cannot open it without yours.
Later, you go to a large office. The filing cabinet there has six drawers, each with a different coloured tab. Your manager hands you a key ring with only two keys — one for the green drawer marked 'Sales', and one for the blue drawer marked 'Marketing'. You can open those drawers and read any file inside, but the red 'HR' drawer stays locked. Nobody in the office has a key to all six drawers at once. Each person gets only the keys they need to do their job.
This is exactly how data encryption and access control work. The safety-deposit-box double-key system is like encrypting data so that even if someone steals the storage disk, they cannot read it without the correct decryption key. The filing-cabinet key ring is like role-based access control — you give each employee only the permissions they actually require.
Encryption is the process of scrambling readable data (called plaintext) into an unreadable format (called ciphertext) using a secret value called a key. To reverse the process and make the data readable again, you need the correct decryption key. Think of it like a combination lock: the data is the lock, and the key is the combination. Without the correct combination, you cannot open the lock.
Azure offers encryption at two main points: at rest and in transit. Encryption at rest means the data is scrambled when it is sitting on a disk inside an Azure data centre. Even if a hard drive is stolen or a data-centre technician plugs the wrong drive into a server, they see only meaningless gibberish. Azure Storage automatically encrypts all data at rest using a technology called Storage Service Encryption (SSE). By default, Azure manages the encryption keys for you (platform-managed keys). However, you can choose to supply your own keys (customer-managed keys) using a service called Azure Key Vault, which is a secure, cloud-based safe for storing secrets like keys, passwords, and certificates.
Encryption in transit scrambles data while it is moving between your computer and Azure, or between two Azure services. This uses protocols like TLS (Transport Layer Security) and HTTPS (Hypertext Transfer Protocol Secure). When you see the padlock icon in a web browser, that means the connection is encrypted in transit. Azure enforces HTTPS for all its storage endpoints by default.
Now let us talk about access control. Access control is the process of deciding who can do what to which data. It answers three questions: \"Who are you?\" (authentication), \"What are you allowed to do?\" (authorisation), and \"What actions are you performing?\" (auditing). In Azure, the main tool for access control is Role-Based Access Control (RBAC). RBAC lets you assign roles to users, groups, or applications. Each role is a collection of permissions. For example, the 'Storage Blob Data Reader' role lets someone read blobs (files) inside a storage account, but not delete them or change their contents. The 'Storage Blob Data Contributor' role lets someone read, write, and delete blobs. The 'Storage Account Contributor' role lets someone manage the storage account itself (change settings, add networking rules) but not read the actual data inside it. These roles are applied at a specific scope: the whole subscription, a resource group, or an individual storage account.
A related concept is Azure Key Vault. Key Vault is a service for safely storing and managing cryptographic keys, secrets (like database connection strings), and certificates. You can control who has access to a Key Vault by using Key Vault's own access policy or by using RBAC (which is now the recommended method). When you use customer-managed keys for encryption, you store the key in Key Vault, and Azure Storage uses that key to encrypt and decrypt your data.
Another important layer is network-level access control. You can configure Azure Storage firewalls and virtual network (VNet) rules to allow traffic only from specific IP addresses or from within a specific virtual network. This prevents anyone on the public internet from even attempting to connect to your storage account, unless they are coming from an approved location.
Finally, there is immutable storage. This is a feature that prevents data from being modified or deleted for a user-specified retention period. It is commonly used for compliance with regulations like SEC 17a-4, which requires financial firms to store records in a write-once, read-many (WORM) state. Once you set a time-based retention policy, no one — not even the subscription administrator — can delete or overwrite the data until the policy expires.
Create an Azure Storage account
You begin by creating a storage account in the Azure portal. This is the container that will hold your blobs, files, tables, and queues. At this stage, you choose redundancy options and the kind of storage. Encryption at rest is automatically enabled on this account using platform-managed keys.
Configure Azure Key Vault for customer-managed keys
If you want to use your own encryption key, you need an Azure Key Vault. You create the vault, enable the 'Soft Delete' and 'Purge Protection' features (required by Microsoft for customer-managed keys), and then generate a new key inside the vault. This key will be used by your storage account to encrypt and decrypt data.
Grant the storage account permission to use the Key Vault key
Azure Storage needs permission to read the key from Key Vault when encrypting and decrypting data. You do this by going to the Key Vault's 'Access policies' section, selecting 'Azure Disk Encryption for Volumes' (or 'Key Management' depending on the version), and choosing your storage account's system-assigned managed identity.
Set up network access control
To restrict who can even reach your storage account, you configure the firewalls and virtual networks blade. You can add IP address ranges (like your office IP) and Azure Virtual Network subnets. Once you enable 'Selected networks', all traffic from the public internet is blocked unless it matches one of your rules.
Assign RBAC roles for data access
Now you decide who can read and write the actual data. You create a user group (e.g., 'DataAnalysts') and assign it the 'Storage Blob Data Reader' role scoped to the storage account or a specific container. Alternatively, you could assign 'Storage Blob Data Contributor' to a group that needs to upload files. This separates who can see the data from who can manage the account.
Enable immutable storage for compliance (if needed)
If regulations require that data cannot be deleted for a certain period, you navigate to the container where the data lives, access the 'Immutable storage' blade, and create a time-based retention policy. You can set the retention period in days, and optionally lock the policy to make it irreversible. Once locked, no user can delete or modify blobs until the period expires.
Generate a Shared Access Signature (SAS) for limited access (if needed)
If you need to give a temporary download link to someone who does not have a Microsoft Entra ID account, you can generate a SAS token. In the storage account, navigate to 'Shared access signature', choose allowed services (e.g., Blob), set an expiry time, and generate the token. You then append that token to the storage URL to create a temporary access URL. Treat this URL like a password — do not share it broadly.
An IT professional working for a healthcare company named MedSecure needs to store patient records in Azure. MedSecure is subject to strict regulations like HIPAA, which require that patient data be encrypted both at rest and in transit, and that only authorised doctors and nurses can access the records.
First, the IT professional creates an Azure Storage account called medsecurepatients. He configures it to use Storage Service Encryption with customer-managed keys stored in Azure Key Vault. He creates a new Key Vault instance named medsecure-keyvault and generates a new encryption key called patient-key. He then grants the storage account permission to use this key by configuring the key vault's access policy.
Next, he sets up network access control. He creates an Azure Virtual Network (VNet) for MedSecure's internal systems and adds a service endpoint for Azure Storage. He then configures the storage account firewall to block all public traffic and allow traffic only from that VNet. He also whitelists the IP addresses of MedSecure's two office locations.
Then he tackles access control with RBAC. He creates a role called 'Patient-Data-Reader' and gives it the 'Storage Blob Data Reader' permission. He assigns this role to the group 'Doctors-Group'. He creates another role called 'Patient-Data-Writer' with 'Storage Blob Data Contributor' and assigns it to 'Nurses-Group'. He ensures that the IT team themselves have only 'Storage Account Contributor' role on the storage account (to manage settings) but no 'Storage Blob Data Contributor' role (so they cannot read or write the actual patient records).
Finally, to comply with a regulatory requirement that patient records must not be altered for seven years, he enables immutable storage on the container that holds the records. He sets a time-based retention policy of 2,555 days (7 years). Now, even if a doctor accidentally tries to delete a file, Azure will reject the request until the retention period expires.
Every day, the IT professional uses Azure Monitor and Azure Activity Log to audit who accessed which blob, from which IP address, and whether any attempts to change permissions or delete records were made. This audit log is essential for proving compliance during a regulatory inspection.
The DP-203 exam tests 'Implement Data Encryption and Access Control' in several specific ways. You will see questions that ask you to choose the correct encryption method for a given scenario, select the correct RBAC role, or configure Key Vault permissions.
Topics that appear frequently:
The difference between platform-managed keys (default) and customer-managed keys (stored in Key Vault). The exam loves to test that customer-managed keys require you to enable 'Soft Delete' and 'Purge Protection' on the Key Vault.
The specific RBAC roles for storage: 'Storage Blob Data Reader', 'Storage Blob Data Contributor', 'Storage Blob Data Owner', and 'Storage Account Contributor'. You must know which role allows reading data versus managing the account.
The difference between encryption at rest (always on for Azure Storage) and encryption in transit (HTTPS).
How Azure Key Vault supports key rotation, and what happens when a key is disabled or deleted.
Immutable storage: when to use time-based retention versus legal hold.
Shared access signatures (SAS): a URI that grants limited access to storage resources. Common trap: a SAS token can be a service-level SAS, an account-level SAS, or a user delegation SAS. The exam tests when to use each.
Microsoft Entra ID (Microsoft Entra ID) authentication for storage: you can use Entra ID instead of storage account keys to authenticate. This is more secure because you can use RBAC.
Trap patterns:
The exam will present a scenario where someone needs to store encryption keys. The wrong answer will suggest storing keys in the same storage account as the data. The correct answer is always 'Azure Key Vault'.
A question might ask how to grant an application access to a storage account. The wrong answer will say 'give the application the storage account key'. The correct answer is 'use a managed identity' or 'use an RBAC role'.
The exam will test that you must enable 'Soft Delete' on a Key Vault before using customer-managed keys for Azure Storage. If you do not, you risk losing access to your data permanently if the key is deleted.
A question about data in transit might offer 'SSE' as an option. SSE is for at-rest encryption, not in-transit. The correct answer for in-transit is 'HTTPS' or 'TLS'.
Key definitions to memorise:
SSE (Storage Service Encryption): always enabled for Azure Storage.
CMEK (Customer-Managed Encryption Key): key stored in Key Vault.
RBAC: Role-Based Access Control.
SAS: Shared Access Signature.
Immutable storage: WORM (Write Once, Read Many) policy.
Azure Storage automatically encrypts all data at rest using Storage Service Encryption (SSE), using AES-256. This encryption cannot be turned off.
Encryption in transit is enforced by default on all Azure Storage endpoints via HTTPS/TLS, preventing eavesdropping on the network.
Customer-managed keys must be stored in Azure Key Vault, and Key Vault must have Soft Delete and Purge Protection enabled before you can use the key for storage encryption.
Role-Based Access Control (RBAC) uses roles like 'Storage Blob Data Reader' to grant fine-grained permissions to data, separate from management roles like 'Storage Account Contributor'.
A Shared Access Signature (SAS) token grants access based on a secret key, not a user identity, making it risky if leaked; use Microsoft Entra ID authentication for more secure, identity-based access.
Immutable storage with a time-based retention policy protects data from deletion or modification for a set period, and when locked, even administrators cannot remove it.
Network-level access control (firewalls and VNet service endpoints) can block all internet traffic to a storage account, allowing only requests from trusted networks.
Azure Key Vault is the only approved service for storing customer-managed encryption keys, connection strings, and certificates for Azure services.
These come up on the exam all the time. Here's how to tell them apart.
Platform-Managed Keys (PMK)
Azure generates and manages the encryption keys automatically.
No extra cost; key rotation is handled by Microsoft.
You cannot rotate the key on a custom schedule.
Customer-Managed Keys (CMK)
You create and manage the key in Azure Key Vault.
You pay for Key Vault operations and key storage.
You can rotate the key on your own schedule for compliance.
Storage Blob Data Reader
Can read and list blobs and containers.
Cannot write new blobs or delete existing ones.
Used for read-only access, e.g., reporting tools.
Storage Blob Data Contributor
Can read, write, and delete blobs and containers.
Cannot manage the storage account's configuration.
Used for data engineers who upload and process files.
Storage Account Key
A single, permanent key that grants full access to all data.
If it is leaked, anyone can use it indefinitely until you regenerate it.
Similar to a master key to the entire building.
Shared Access Signature (SAS)
A time-limited, permission-restricted URI string.
If leaked, the damage is limited to the scope and duration specified.
Similar to a hotel room keycard that expires at checkout.
Time-Based Retention Policy (Immutable Storage)
Data is protected for a fixed number of days (e.g., 365 days).
Once locked, the retention period cannot be shortened or removed.
Automatically starts counting from the time you set the policy.
Legal Hold (Immutable Storage)
Data is protected indefinitely until the legal hold is manually cleared.
Used for active litigation or investigation (no fixed end date).
You must specifically remove the hold tag to allow deletion.
RBAC (Role-Based Access Control)
Assigns roles to Microsoft Entra ID identities (users, groups, apps).
Works at the subscription, resource group, or resource level.
Is the recommended way to control access to Azure resources.
Access Control Lists (ACLs)
Assigns permissions directly to specific files and folders (like NTFS).
Works only on individual blobs and containers within storage.
Is an older method, used when you need granular file-level control.
Mistake
Because Azure Storage encrypts data at rest by default, I don't need to do anything else for security.
Correct
Encryption at rest protects data if the physical disk is stolen, but it does not control who can access the data over the network. You still need access control (RBAC) and network rules to prevent unauthorised users from reading the data while it is served to legitimate users.
People see 'encrypted by default' and assume the job is done. They forget that encryption at rest does not verify identity or block network requests — it only scrambles the raw bytes on disk.
Mistake
Roles like 'Storage Account Contributor' let you read and write data inside the storage account.
Correct
'Storage Account Contributor' only lets you manage the storage account's configuration (like setting firewalls, changing replication). It does not grant permission to read or write blobs. To access data, you need a 'Data' role like 'Storage Blob Data Reader'.
The name 'Contributor' sounds broad and powerful. Beginners think it implies data access, but Azure separates management plane roles (control data) from data plane roles (actual data).
Mistake
If I delete a customer-managed key from Key Vault, the data it encrypted just becomes permanently unreadable.
Correct
When the key is deleted, the data does not become unreadable immediately — it becomes effectively unreadable because Azure Storage can no longer call Key Vault to decrypt it. However, with 'Soft Delete' enabled, you can recover the key within the retention window. If 'Purge Protection' is also enabled, the key cannot be permanently deleted until the retention period expires.
People think of encryption as a one-time operation, not as an ongoing dependency. They don't realise that Azure Storage must fetch the decryption key from Key Vault every time it reads data. Without that ongoing access, the data is useless.
Mistake
A Shared Access Signature (SAS) token is a secure way to share access with anyone, including users who are not in my organisation.
Correct
A SAS token grants access to anyone who possesses it, for the duration and permissions specified. If it leaks, anyone can use it. It is not identity-based — it is key-based. The more secure alternative for authenticated users is to use Microsoft Entra ID RBAC.
SAS tokens look like a simple solution (just a URL with a token), so beginners think they are safe. They confuse convenience with security. The exam loves to test when to use SAS vs. Entra ID.
Mistake
Immutable storage means no one can modify or delete the data, including the storage account owner.
Correct
Yes, once a time-based retention policy is locked, no user (including subscription administrators) can delete or overwrite the data until the retention period expires. The policy can be made 'locked' (irreversible) or 'unlocked' (can be shortened but not lengthened). The locked version is the one used for compliance.
People think 'immutable' is a soft setting that can be bypassed by an admin. They don't realise that locked immutable policies are enforced at the storage platform level to comply with legal and regulatory requirements.
Mistake
You must always use customer-managed keys for encryption because it is more secure than platform-managed keys.
Correct
Platform-managed keys are just as secure from a cryptographic standpoint. The choice is about control and compliance, not cryptographic strength. Customer-managed keys are used when you need to rotate keys on your own schedule, or when your organisation must have exclusive control over the key material for compliance reasons.
The phrase 'you manage the key' sounds inherently more secure. In reality, Microsoft's platform-managed keys use the same AES-256 encryption. The difference is in governance, not encryption quality.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Encryption at rest is enabled by default for all Azure Storage accounts. You cannot turn it off. It uses Azure-managed keys (platform-managed keys) unless you configure customer-managed keys.
If you delete the key, Azure Storage will not be able to decrypt your data, making it effectively inaccessible. However, if you have Soft Delete enabled on Key Vault, you can recover the key within the retention window (default 90 days) and regain access. Purge Protection prevents permanent deletion during that period.
A storage account key is a master key that grants full access to everything in the storage account (like the bank's master key). A SAS token is a time-limited, permission-restricted URL that gives access to only specific blobs or containers (like a hotel keycard). SAS is safer for giving access to third parties because you can set expiry and limit permissions.
You need to assign the 'Storage Blob Data Reader' role at the appropriate scope (storage account, container, or blob). This role permits reading and listing blobs, but not modifying or deleting them.
Immutable storage prevents data from being modified or deleted for a customer-defined retention period. It is used for compliance with regulations like SEC 17a-4 (financial records) or HIPAA (healthcare records) where records must be stored in a WORM (Write Once, Read Many) state.
Yes. Azure Storage supports Microsoft Entra ID authentication for blobs and queues. This is more secure because you can assign RBAC roles to users and groups, and you can revoke access instantly by removing the role assignment, without needing to rotate a key.
Azure Storage enforces HTTPS by default for all REST API calls. You can also enable 'Require secure transfer' in the storage account settings to enforce that clients must use HTTPS. No additional configuration is needed for most cases.
You've finished Implement Data Encryption and Access Control. Continue through the DP-203 study guide to build a complete picture of the exam.
Done with this chapter?