azure, Cybersecurity, Microsoft Certification, SC-500, security

Implement and configure security for storage accounts (SC-500 Exam Prep)

 
This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure storage, databases, and networking (25–30%)
   --> Implement security for storage accounts
      --> Implement and configure security for storage accounts

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Storage provides cloud storage for:

  • Blob Storage
  • Azure Files
  • Queue Storage
  • Table Storage
  • Azure Data Lake Storage capabilities

Because storage accounts frequently contain sensitive business, application, backup, and analytical data, they must be protected against:

  • Unauthorized access
  • Accidental exposure
  • Data exfiltration
  • Credential theft
  • Malware uploads
  • Ransomware
  • Accidental deletion
  • Insecure network connections
  • Excessive permissions
  • Configuration drift

For the SC-500 exam, securing an Azure Storage account involves combining:

  1. Identity and access controls
  2. Network security
  3. Encryption and data protection
  4. Monitoring and threat detection
  5. Governance and compliance
  6. Backup, recovery, and data-retention controls

A secure configuration should follow the Zero Trust principles of verifying explicitly, using least-privilege access, and assuming that a breach may occur.

1. Use the Correct Storage Account Configuration

New storage accounts should use the Azure Resource Manager deployment model rather than the classic deployment model.

Azure Resource Manager-based storage accounts support modern security and governance capabilities, including:

  • Azure RBAC
  • Managed identities
  • Microsoft Entra authorization
  • Resource locks
  • Azure Policy
  • Tags
  • Modern deployment and management controls

The storage account configuration selected during creation can affect the security posture of every workload that uses the account. Therefore, account type, redundancy, networking, and endpoint configuration should be selected carefully.

2. Control Network Access

Azure Storage accounts have public endpoints. Network access should be restricted to only the clients and services that require it.

Public network access

If a storage account is intended to be accessed only through private connectivity, disable public network access.

This configuration helps ensure that clients must use private endpoints rather than the public endpoint.

However, creating a private endpoint does not automatically disable the public endpoint. The public endpoint must be separately blocked or restricted.

Private endpoints

A private endpoint provides a private IP address from an Azure virtual network for accessing a storage service.

Traffic travels through Azure Private Link and the Microsoft backbone rather than through the public internet.

Private endpoints are useful when:

  • Applications run in Azure virtual networks
  • Storage should not be publicly reachable
  • On-premises systems connect through VPN or ExpressRoute
  • Data exfiltration risk must be reduced
  • The organization requires private connectivity to PaaS services

A private endpoint can be created for the required storage service, such as Blob Storage, File Storage, Queue Storage, or Table Storage.

Important exam point

A private endpoint does not replace authorization. A client must still have appropriate permissions to access the storage data.

Network access and data authorization are separate controls:

  • Network controls determine whether the client can reach the service.
  • Authorization controls determine what the client can do after reaching it.

Storage firewalls and virtual network rules

When public access is necessary, use storage firewall rules to restrict access.

Possible network rule sources include:

  • Specific virtual network subnets
  • Public IP address ranges
  • Azure resource instances
  • Trusted Azure services

A common secure configuration is:

  1. Set the public network access rule to Selected networks.
  2. Set the default network action to Deny.
  3. Allow only approved IP ranges or virtual network subnets.
  4. Add narrowly scoped exceptions when required.

Virtual network rules generally require a service endpoint on the applicable subnet.

Example

A storage account is used by an application running in a specific subnet.

A secure design might:

  • Enable the Microsoft.Storage service endpoint on the subnet.
  • Add the subnet to the storage account’s virtual network rules.
  • Set the default network action to Deny.
  • Disable public access if a private endpoint is used instead.

Trusted Azure services

Some Azure services may need to access a storage account even though they do not originate from an explicitly approved virtual network or IP address.

A trusted-service exception can allow approved Azure services to access the account.

However, broad trusted-service exceptions increase the trust boundary. Where supported, a resource instance rule can provide a more narrowly scoped alternative by authorizing a specific Azure resource and its managed identity.

Exam consideration

Do not automatically select “Allow trusted Microsoft services” when the requirement is to allow only one specific Azure resource. A resource instance rule may provide a narrower security boundary.

Network security perimeter

A network security perimeter can establish a broader security boundary around supported PaaS resources.

It can help control:

  • Inbound traffic
  • Outbound traffic
  • PaaS-to-PaaS communication
  • Data-exfiltration paths

A perimeter may be useful when multiple storage accounts and other PaaS resources need to be governed as a group rather than through independent account-level rules.

3. Require Secure Connections

Secure transfer required

Enable the Secure transfer required setting to reject requests made over HTTP.

This setting applies to:

  • Storage REST endpoints
  • Azure Files SMB access

Secure transfer helps protect data in transit against interception and other network attacks.

Minimum TLS version

Configure the storage account to require TLS 1.2 or later.

This prevents clients from negotiating older, deprecated TLS versions.

A strong baseline is:

  • Secure transfer required: Enabled
  • Minimum TLS version: TLS 1.2 or later

These controls work together:

  • Secure transfer prevents unencrypted HTTP access.
  • Minimum TLS controls the strength of the encrypted connection.

4. Prevent Anonymous Public Blob Access

Blob containers can potentially be configured for anonymous public access.

Anonymous access should be disabled unless there is a documented business requirement for public content.

Important controls include:

  • Disable public blob access at the storage-account level.
  • Avoid configuring containers for anonymous access.
  • Use authenticated access for private data.
  • Use Azure Front Door and a Web Application Firewall when publicly serving appropriate content through a controlled application architecture.

Public access is especially dangerous when a storage account contains:

  • Customer information
  • Internal documents
  • Backups
  • Application data
  • AI training data
  • Logs
  • Personally identifiable information

A storage account can have network restrictions and still expose data anonymously if public blob access is enabled. Network security and authorization must both be evaluated.

5. Use Microsoft Entra ID and Azure RBAC

Azure RBAC is generally preferred over shared account keys for identity-based access to Azure Storage data.

RBAC assignments can be made to:

  • Users
  • Security groups
  • Managed identities
  • Service principals
  • Other supported workload identities

Assign roles at the narrowest scope required:

  • Storage account
  • Container
  • Resource group
  • Subscription, only when necessary

Use groups instead of assigning roles individually where practical.

Common data-access roles

Examples of storage data roles include:

  • Storage Blob Data Reader
  • Storage Blob Data Contributor
  • Storage Blob Data Owner
  • Storage Queue Data Contributor
  • Storage Table Data Contributor
  • Storage File Data SMB Share Reader
  • Storage File Data SMB Share Contributor

The correct role depends on the service and the required operations.

Reader versus Contributor

A principal that only needs to read blobs should not receive a data-contributor role.

A contributor role may allow the principal to create, modify, or delete data. Therefore, it should be used only when those capabilities are required.

Control-plane versus data-plane access

Azure RBAC permissions can relate to two different areas:

Control plane

Control-plane permissions manage the storage account resource itself.

Examples include:

  • Creating the storage account
  • Changing networking settings
  • Modifying account configuration
  • Deleting the account

Data plane

Data-plane permissions control access to the data stored in the account.

Examples include:

  • Reading blobs
  • Writing blobs
  • Deleting blobs
  • Reading queue messages
  • Accessing file shares

A user may have permission to manage the storage account without having the required data-plane role, or may have data access without being able to modify the storage account configuration.

6. Prefer Managed Identities for Applications

Applications running in Azure should generally use managed identities instead of storing storage account keys or client secrets.

Managed identities can be used by supported Azure resources to obtain Microsoft Entra tokens without requiring developers to manage credentials.

A typical design is:

  1. Enable a managed identity on the application.
  2. Assign the required storage data role to the identity.
  3. Scope the assignment to the storage account or container.
  4. Configure the application to authenticate using Microsoft Entra ID.
  5. Remove unnecessary account-key usage.

This reduces the risk of:

  • Secrets being stored in code
  • Credentials appearing in configuration files
  • Secret rotation failures
  • Long-lived credentials being compromised

7. Understand Shared Key Authorization and SAS

Storage account keys

Storage account keys provide broad access to storage services. Anyone who obtains a valid key may be able to access data or perform operations allowed by that key.

Risks include:

  • Broad permissions
  • Difficult attribution to individual users
  • Credential leakage
  • Long-lived access
  • Difficult rotation processes

Where possible, use Microsoft Entra authorization and Azure RBAC instead.

Shared Access Signatures

A Shared Access Signature, or SAS, grants delegated access to storage resources.

A SAS can restrict:

  • Resource
  • Permissions
  • Start time
  • Expiration time
  • Allowed protocol
  • IP address, where supported

SAS is useful when a client needs limited, temporary access without receiving the storage account key.

However, a SAS is still a bearer token. Anyone who obtains it may use it until it expires or is revoked through the applicable mechanism.

SAS best practices

  • Use the shortest practical expiration period.
  • Grant only the required permissions.
  • Restrict the resource scope.
  • Require HTTPS.
  • Avoid exposing SAS tokens in URLs, logs, or source control.
  • Prefer user delegation SAS for Blob Storage when appropriate because it is authorized through Microsoft Entra credentials rather than the storage account key.
  • Have a revocation strategy for compromised tokens.

Important distinction

A SAS does not bypass network restrictions. A request must satisfy both:

  1. Storage network access rules
  2. SAS or identity authorization requirements

8. Consider Disabling Shared Key Authorization

If an organization wants to require Microsoft Entra-based authorization, it can disable shared key access where supported.

Disabling shared key authorization also affects account-key-based and service SAS access because those SAS types depend on shared keys.

Before disabling shared key authorization, verify that all applications and services have been migrated to supported alternatives, such as:

  • Microsoft Entra ID
  • Azure RBAC
  • Managed identities
  • User delegation SAS

The change should be tested carefully because legacy applications may still depend on account keys.

9. Protect Data at Rest

Azure Storage encrypts data at rest by default using Microsoft-managed keys.

Additional controls may be required for sensitive or regulated data.

Customer-managed keys

Customer-managed keys allow the organization to control the encryption key used for storage encryption.

Keys can be managed through:

  • Azure Key Vault
  • Azure Key Vault Managed HSM

Customer-managed keys can support requirements involving:

  • Customer control of encryption keys
  • Key rotation
  • Key access auditing
  • Key revocation
  • Regulatory compliance

Customer-managed keys introduce additional responsibilities. The organization must protect the key-management service and ensure that the storage account can access the key when required.

If the key becomes unavailable or access is revoked incorrectly, storage operations may be affected.

Infrastructure encryption

Infrastructure encryption provides an additional service-managed encryption layer.

It is sometimes described as double encryption because data receives an additional encryption layer beyond the primary storage encryption.

Infrastructure encryption must be enabled when the storage account is created and may not be available as a setting that can be enabled later for an existing account.

Encryption scopes

Encryption scopes allow different encryption keys or key-management policies to be applied to specific containers or blobs.

They can be useful when:

  • Multiple tenants share a storage account
  • Different data sets require separate key control
  • Data classification requires different encryption arrangements

10. Protect Data from Accidental or Malicious Deletion

Encryption does not protect against deletion. Additional data-protection features are required.

Blob soft delete

Blob soft delete allows deleted blobs to be retained for a configured period so they can be recovered.

It helps protect against:

  • Accidental deletion
  • Malicious deletion
  • Application errors
  • Ransomware-related deletion activity

Container soft delete

Container soft delete protects deleted containers and their contents during the retention period.

Versioning

Blob versioning automatically maintains previous versions of blob data when supported operations modify or overwrite blobs.

Versioning can help recover from:

  • Accidental overwrites
  • Malicious changes
  • Application defects
  • Data corruption

Immutable blob storage

Immutable storage can enforce write-once, read-many behavior.

It is useful for data that must not be modified or deleted during a retention period, such as:

  • Compliance records
  • Financial records
  • Legal evidence
  • Audit logs
  • Regulatory archives

Immutable storage can use:

  • Time-based retention
  • Legal holds

Important exam distinction

Soft delete helps recover deleted data. Immutable storage helps prevent modification or deletion during a protected retention period. They address different risks and may be used together.

11. Use Resource Locks Carefully

Resource locks protect the storage account resource from accidental deletion or modification.

Common lock types include:

  • CanNotDelete
  • ReadOnly

A CanNotDelete lock helps prevent deletion of the storage account.

A ReadOnly lock prevents modification and deletion operations against the locked resource, although it can interfere with normal management operations.

Resource locks:

  • Apply to the resource configuration
  • Do not protect individual blobs by themselves
  • Do not replace soft delete
  • Do not replace immutable storage
  • Do not replace RBAC
  • Do not replace backups

Locks should be included in IaC where appropriate, but deployment pipelines must account for the restrictions imposed by the locks.

12. Enable Microsoft Defender for Storage

Microsoft Defender for Storage provides threat detection and security capabilities for storage accounts.

Depending on the enabled capabilities and supported services, Defender for Storage can help detect:

  • Suspicious access patterns
  • Malicious IP addresses
  • Unusual authentication activity
  • Potential data exfiltration
  • Malware uploaded to blobs
  • Sensitive data-related risks

Defender for Storage can include malware scanning for blob uploads and sensitive data discovery capabilities.

It can be enabled at the subscription level or for selected storage accounts, depending on the required configuration.

Defender for Storage complements preventive controls. It does not replace:

  • RBAC
  • Network restrictions
  • Encryption
  • Secure transfer
  • Public-access controls
  • Data-retention features

13. Enable Logging and Monitoring

Storage accounts should be monitored continuously.

Diagnostic settings can send logs and metrics to services such as:

  • Log Analytics
  • Microsoft Sentinel
  • Event Hubs
  • Storage accounts for archival purposes

Important events to monitor include:

  • Storage account key regeneration
  • Changes to firewall rules
  • Changes to public network access
  • Changes to encryption settings
  • Role-assignment changes
  • Shared Key usage
  • Anonymous access
  • Storage read operations
  • Storage write operations
  • Storage delete operations
  • Defender for Storage alerts

Storage logs can indicate how a request was authorized, such as through:

  • Microsoft Entra ID
  • Shared Key
  • SAS
  • Anonymous access

This information can help identify unexpected authentication methods or unauthorized access patterns.

14. Apply Azure Policy

Azure Policy can enforce or audit storage security requirements across subscriptions and management groups.

Examples of useful policy requirements include:

  • Require secure transfer
  • Require TLS 1.2 or later
  • Deny public network access
  • Deny public blob access
  • Require infrastructure encryption
  • Require customer-managed keys
  • Require diagnostic settings
  • Require approved locations
  • Require specific tags
  • Restrict allowed resource types

Common policy effects include:

EffectPurpose
AuditReports noncompliant resources
DenyBlocks noncompliant creation or updates
ModifyChanges resource properties during deployment
DeployIfNotExistsDeploys missing supporting configuration
AuditIfNotExistsReports missing related configuration

For example, a policy with a Deny effect can prevent the deployment of a storage account that permits public network access.

An Audit policy is useful when the organization needs to discover existing noncompliance without immediately blocking deployments.

15. Use Infrastructure as Code for Secure Storage Deployments

Storage accounts should be deployed through approved infrastructure-as-code templates or modules.

IaC can define:

  • Network access settings
  • Private endpoints
  • Firewall rules
  • Secure transfer
  • Minimum TLS version
  • Encryption settings
  • Diagnostic settings
  • Role assignments
  • Blob versioning
  • Soft-delete retention
  • Public access settings
  • Resource locks
  • Tags

A secure deployment pipeline should:

  1. Store templates in source control.
  2. Require peer review.
  3. Scan templates for insecure settings.
  4. Prevent secrets from being embedded in code.
  5. Validate policy compliance.
  6. Review deployment plans.
  7. Require approval for production changes.
  8. Deploy using a least-privileged identity.
  9. Monitor the deployed resources.
  10. Detect and remediate configuration drift.

IaC is not inherently secure. An insecure template can reproduce the same vulnerability across many storage accounts.

16. Recommended Secure Storage Baseline

A general secure baseline may include:

  • Use Azure Resource Manager-based storage accounts.
  • Disable public network access when private connectivity is sufficient.
  • Use private endpoints for internal workloads.
  • Set public network rules to deny by default.
  • Require secure transfer.
  • Require TLS 1.2 or later.
  • Disable public blob access.
  • Prefer Microsoft Entra ID and Azure RBAC.
  • Use managed identities for applications.
  • Avoid account keys where possible.
  • Use short-lived, narrowly scoped SAS tokens when required.
  • Enable encryption at rest.
  • Use customer-managed keys for applicable compliance requirements.
  • Enable infrastructure encryption when required.
  • Enable soft delete and versioning.
  • Use immutable storage for protected records.
  • Enable Defender for Storage.
  • Configure diagnostic settings.
  • Apply Azure Policy.
  • Monitor role assignments and network changes.
  • Protect storage configuration with resource locks where appropriate.

Common Exam Traps

Trap 1: A private endpoint automatically disables public access

It does not. Public network access must be separately disabled or restricted.

Trap 2: A firewall rule grants data access

A firewall rule controls network reachability. The client still needs appropriate authorization.

Trap 3: Contributor provides blob data access

The Contributor role is primarily a management-plane role. Data access generally requires an appropriate storage data role.

Trap 4: SAS is always secure

SAS tokens can be leaked and may provide access until expiration or revocation. They must be narrowly scoped and short-lived.

Trap 5: Encryption prevents deletion

Encryption protects confidentiality of data at rest. It does not prevent deletion or overwriting.

Trap 6: Soft delete prevents all changes

Soft delete helps recover deleted data. It does not provide the same protection as immutable storage.

Trap 7: Resource locks protect blobs

Resource locks protect the storage account resource. They do not independently protect individual blobs from deletion.

Trap 8: Trusted Azure services is always the best option

A resource instance rule may provide a narrower exception when only one specific Azure resource needs access.

Trap 9: Azure RBAC replaces network security

RBAC and network controls solve different problems. Both may be required.

Trap 10: Defender for Storage prevents every attack

Defender for Storage provides detection and protection capabilities, but it does not replace preventive configuration controls.

Practice Exam Questions

Question 1

A company has a storage account that is used only by applications running inside an Azure virtual network. The security team requires that the account not be accessible through the public internet.

What should the company implement?

A. A storage firewall rule allowing all public IP addresses
B. A private endpoint and disabled public network access
C. A SAS token with a one-year expiration
D. A resource lock

Correct answer: B

Explanation: A private endpoint provides private connectivity from the virtual network. Public network access should also be disabled because creating a private endpoint does not automatically block the public endpoint.

Question 2

An application needs to read blobs from one container but must not upload, modify, or delete blobs.

Which access configuration should be used?

A. Storage Blob Data Owner at the subscription scope
B. Storage Blob Data Contributor at the storage-account scope
C. Owner at the resource-group scope
D. Storage Blob Data Reader at the narrowest appropriate scope

Correct answer: D

Explanation: Storage Blob Data Reader provides read access without granting write or delete permissions. The assignment should be scoped to the container or storage account as appropriate.

Question 3

A storage account must allow access from only two corporate public IP ranges. All other public network traffic must be blocked.

Which configuration should be used?

A. Create a resource lock
B. Enable anonymous blob access
C. Assign the Reader role to the corporate users
D. Set the default public network action to Deny and add the two IP ranges

Correct answer: D

Explanation: Storage firewall rules can restrict public endpoint access to specified IP ranges. The default action should be Deny so that only explicitly permitted sources can connect.

Question 4

A company wants to prevent applications from using storage account keys and require Microsoft Entra-based authorization instead.

What should the company consider?

A. Enable anonymous public access
B. Disable all diagnostic settings
C. Disable shared key authorization after migrating dependent applications
D. Assign Owner to every application identity

Correct answer: C

Explanation: Disabling shared key authorization can require applications to use Microsoft Entra ID, managed identities, Azure RBAC, or supported alternatives. The organization must first identify and migrate applications that depend on account keys or key-based SAS.

Question 5

A storage account contains financial records that must not be modified or deleted for seven years.

Which feature is most appropriate?

A. Blob versioning only
B. Immutable blob storage with time-based retention
C. A storage firewall
D. A private endpoint

Correct answer: B

Explanation: Immutable storage with time-based retention is designed to prevent modification or deletion during a defined retention period. Versioning helps recover previous versions but does not provide the same write-once, read-many protection.

Question 6

An Azure application needs temporary access to upload files to a specific blob container. The application should not receive the storage account key.

Which option is most appropriate?

A. A narrowly scoped, short-lived SAS token
B. Subscription-level Owner access
C. Anonymous public access to the container
D. A ReadOnly resource lock

Correct answer: A

Explanation: A SAS token can provide limited permissions to a specific resource for a defined period. It should be short-lived, restricted to the required operations, and transmitted only over HTTPS.

Question 7

A security team wants Azure to block the deployment of storage accounts that permit public blob access.

Which control should be used?

A. Microsoft Sentinel workbook
B. Azure Monitor metric alert
C. Azure Policy with the Audit effect
D. Azure Policy with the Deny effect

Correct answer: D

Explanation: The Deny effect blocks creation or updates that violate the policy. Audit identifies noncompliant resources but does not prevent deployment.

Question 8

A company wants to detect suspicious access patterns, malware uploaded to blobs, and unusual authentication activity.

Which service should it enable?

A. Azure Resource Locks
B. Microsoft Defender for Storage
C. Azure Private DNS
D. Azure Policy only

Correct answer: B

Explanation: Microsoft Defender for Storage provides threat-detection capabilities for storage accounts, including supported malware scanning and detection of suspicious access activity.

Question 9

A storage account uses a private endpoint, but users can still access the account through its public endpoint.

What is the most likely explanation?

A. Private endpoints do not provide encryption
B. Azure RBAC is disabled
C. Public network access was not separately disabled or restricted
D. Blob versioning is not enabled

Correct answer: C

Explanation: Creating a private endpoint does not automatically disable the public endpoint. The storage account’s public network access must be disabled or restricted separately.

Question 10

An organization wants to require secure connections and prevent clients from using outdated encryption protocols.

Which configuration should it use?

A. Enable Secure transfer required and require TLS 1.2 or later
B. Enable anonymous blob access and SAS
C. Create a CanNotDelete resource lock
D. Assign Storage Blob Data Reader to all users

Correct answer: A

Explanation: Secure transfer required rejects HTTP requests, while the minimum TLS version setting prevents clients from negotiating older TLS versions. Together, they strengthen protection for data in transit.

Final Takeaways

For the SC-500 exam, remember the following:

  • Use private endpoints and disable public network access when public connectivity is unnecessary.
  • If public access is required, use firewall rules with a default Deny action.
  • Network access does not replace authorization.
  • Prefer Microsoft Entra ID, Azure RBAC, and managed identities.
  • Use SAS only when temporary delegated access is required.
  • Keep SAS permissions and expiration periods narrow.
  • Require secure transfer and TLS 1.2 or later.
  • Disable anonymous public blob access unless explicitly required.
  • Use customer-managed keys when additional key control is necessary.
  • Use soft delete for recovery and immutable storage for retention enforcement.
  • Enable Defender for Storage and diagnostic logging.
  • Apply Azure Policy to enforce storage security baselines.
  • Use infrastructure as code to deploy consistent, reviewable configurations.
  • Monitor for unauthorized changes and configuration drift.

Go to the SC-500 Exam Prep Hub main page

Leave a Reply