Secure storage, databases, and networking practice questions

Azure Policy effects: Deny rejects a non-compliant request, Modify alters it to be compliant, Audit only reports it.

The requirement is preventive and visible: the non-compliant deployment itself must fail. Assigning the built-in public-access policy with Deny at the management group covers every subscription below it and refuses non-compliant creates and updates with a policy error. The same policy with Audit only reports. The separate built-in 'Configure your Storage account public access to be disallowed' policy uses Modify: it alters the request so the account ends up compliant, which is a valid hardening choice but doesn't make the deployment fail. Defender for Storage is a detection plan and blocks nothing.

1. Identify the requirement: the deployment must fail with an error.
2. Choose Azure Policy for configuration rules across subscriptions.
3. Separate the effects: Audit reports, Modify rewrites, Deny rejects.
4. Scope it at the management group so every subscription inherits it.

Exam tip: Report it: Audit. Silently fix it: Modify. Make the deployment fail: Deny.

Metrics count Shared Key/SAS requests; resource logs (via a diagnostic setting) identify the clients making them.

Microsoft's guidance is to measure before you disallow Shared Key. Metrics Explorer gives aggregate counts by authentication type, which is useful but anonymous. To see per-client detail such as caller IP and user agent you need resource logs, which require a diagnostic setting sending StorageBlobLogs to Log Analytics. Resource Graph only reports configuration, and Defender for Storage alerts on anomalies rather than listing every caller.

1. Note what's needed: per-client detail (IP, user agent).
2. Separate metrics (counts) from logs (request detail).
3. Recall that resource logs need a diagnostic setting.
4. Query the logs by authentication type to find key and SAS callers.

Exam tip: How many key/SAS requests? Metrics. Who sends them? Resource logs via a diagnostic setting.

Disallowing Shared Key denies every key-signed request (account key, service SAS, account SAS) and leaves Microsoft Entra authorization, including user delegation SAS, working.

Sort each client by how its request is signed. The service SAS is signed with an account key, so it fails. A user delegation SAS is signed with a user delegation key obtained with Entra credentials, and the Logic App uses its managed identity, so both keep working. The subtle one is Azure Files in the portal: it uses Shared Key by default, so operators with no Azure Files data roles can no longer browse the share. Microsoft recommends assigning those roles, moving the files, or not disabling Shared Key on accounts that serve file shares.

1. List how each client authorizes: account key, SAS type, or Entra ID.
2. Mark key-signed SAS (service, account) as denied.
3. Keep user delegation SAS and managed identity as allowed.
4. Remember the portal's default Shared Key use for file shares.

Exam tip: Shared Key off: service and account SAS die, user delegation SAS and Entra ID live; check Azure Files in the portal.

Customer-managed keys for Azure Storage need a vault with soft delete and purge protection, and an identity with wrap/unwrap rights on the key.

Two facts combine here. First, Azure Storage refuses a key from a vault that lacks purge protection; soft delete alone isn't enough. Second, the identity needs only to get, wrap and unwrap the key, which is exactly Key Vault Crypto Service Encryption User scoped to that key. Secrets User grants the wrong data type, Crypto Officer is far broader than required, and infrastructure encryption is a separate, creation-time-only setting.

1. Check vault prerequisites: soft delete and purge protection.
2. Identify the key operations storage needs: get, wrap, unwrap.
3. Map them to the narrowest built-in role, scoped to the key.
4. Discard creation-time settings and over-broad roles.

Exam tip: CMK for storage: purge protection on the vault + Key Vault Crypto Service Encryption User on the key.

Immutable storage offers time-based retention (locked or unlocked) and legal holds; only a locked time-based policy guarantees a fixed period that can't be shortened.

The requirement has two parts: a fixed period, and no one able to shorten it. A time-based retention policy supplies the period, and locking it makes the policy compliant with regulations such as SEC 17a-4(f): the interval can be extended but never reduced or deleted. An unlocked policy is the near-twin that fails the second part. A legal hold has no period and can be cleared, and resource locks don't protect blob data.

1. Note the need for a fixed retention period.
2. Note that even Owners must not shorten it.
3. Choose a time-based retention policy over a legal hold.
4. Lock it, because only a locked policy can't be shortened.

Exam tip: Fixed period that nobody can shorten = locked time-based retention policy.

Storage firewall virtual network rules admit traffic from subnets that have the Microsoft.Storage service endpoint enabled.

To restrict the account to one subnet without a private IP or extra charges, enable the Microsoft.Storage service endpoint on snet-app and add a virtual network rule for it; the firewall then denies everything else. A private endpoint also works but adds the hourly cost the stem rules out. IP rules can't contain private addresses, and an NSG controls the VMs' outbound traffic, not who can reach the account.

1. Note the constraints: no private IP needed, no hourly charge.
2. Recall that firewall virtual network rules rely on service endpoints.
3. Rule out private ranges in IP rules.
4. Remember that an NSG on the client side doesn't lock down the account.

Exam tip: Subnet-only access, no private IP, no hourly fee: service endpoint + virtual network rule.