Skip to main content

Technical Lab: Configure stored access policies

Questions​

Question 1 — Multiple Choice​

A development team uses a Shared Access Signature (SAS) of service SAS type to grant temporary access to a container in Azure Blob Storage. After deployment to production, the security team requires the ability to revoke access immediately, without needing to recreate the account key.

Which modification solves this requirement?

A) Reduce the SAS expiration time to 1 hour and regenerate it periodically.

B) Associate the SAS with a stored access policy defined on the container, so that revoking the policy invalidates the SAS.

C) Migrate to an account SAS, which supports direct revocation through the Azure portal.

D) Enable Azure Defender for Storage to monitor and block suspicious SAS tokens.

Question 2 — Technical Scenario​

An administrator created the following stored access policy on a container called relatorios:

az storage container policy create \
  --container-name relatorios \
  --name "politica-leitura" \
  --account-name minha-conta \
  --permissions r \
  --expiry 2025-12-31

Then, generated a SAS linked to this policy. Three months later, the administrator needs access to expire immediately. He executes:

az storage container policy delete \
  --container-name relatorios \
  --name "politica-leitura" \
  --account-name minha-conta

What is the expected behavior after deleting the policy?

A) The SAS continues valid until the originally defined 2025-12-31 date, since expiration is written to the token at creation time.

B) The SAS is immediately invalidated, as its validity depends on the existence and permissions of the associated stored access policy.

C) The SAS starts operating with read and write permissions, since without the associated policy it inherits the account key permissions.

D) Azure returns 403 Forbidden error only for new requests initiated after deletion, but completes ongoing requests with the old policy.

Question 3 — Multiple Choice​

When defining permissions in a stored access policy, an administrator intentionally omits the --start and --expiry fields. A SAS is generated without dates defined directly in the token, linked to this policy.

What is the resulting behavior?

A) The SAS is rejected by Azure, since every SAS must contain explicit start and expiration dates in the token.

B) The SAS inherits the start and expiration dates from the stored access policy; since both were omitted, the SAS is valid for 24 hours by default.

C) The SAS remains valid indefinitely until the stored access policy is modified or deleted, since no time restriction was applied.

D) The SAS uses the container creation date as start and the account key expiration date as upper limit.

Question 4 — Technical Scenario​

An administrator needs to update the permissions of an existing stored access policy to add write permission (w) to a policy that currently grants only read (r). He executes:

az storage container policy create \
  --container-name dados \
  --name "politica-rw" \
  --account-name minha-conta \
  --permissions rw \
  --expiry 2026-06-30

Note that the administrator used create instead of update. Considering that a policy with the name politica-rw already exists in this container, what is the result?

A) The command fails with conflict error, since it's not allowed to create a policy with the same name as an existing one.

B) The command overwrites the existing policy with the new parameters, since create functions as upsert for stored access policies.

C) The command creates a second policy with the same name, resulting in two entries with undefined behavior.

D) The existing policy is preserved and a new temporary policy is created with automatic numeric suffix.

Question 5 — True or False​

A single container in Azure Blob Storage can have at most 5 stored access policies defined simultaneously. Attempting to add a sixth policy returns an error and the operation is refused.

Is the statement above true or false?

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

A SAS linked to a stored access policy does not carry all its restrictions embedded in the token autonomously. By associating the SAS with the policy, validity and permissions become dependent on the policy stored in the service. Revoking or deleting the policy immediately invalidates all SAS tokens that reference it, without needing to regenerate the account key.

Alternative A reduces the exposure window but doesn't offer immediate revocation. Alternative C is incorrect: an account SAS also doesn't support direct revocation without an associated policy. Alternative D describes a monitoring service, not an access control mechanism.

The key point is that immediate revocability is the main reason stored access policies exist in relation to ad hoc SAS tokens.

Answer Key — Question 2​

Answer: B

When a service SAS is linked to a stored access policy, Azure evaluates the SAS validity by consulting the policy at the time of each request. If the policy is deleted, the reference that the SAS carries ceases to exist in the service, and Azure immediately rejects the token.

Alternative A describes the behavior of an ad hoc SAS (without associated policy), whose restrictions are embedded in the token and cannot be revoked externally. Alternative C is technically incorrect: the absence of the policy doesn't expand permissions. Alternative D mixes HTTP session control concepts with SAS token functionality, which are validated per request.

Answer Key — Question 3​

Answer: C

Stored access policies allow date fields to be intentionally omitted. When --start and --expiry are omitted from the policy and also not defined directly in the SAS token, Azure doesn't apply any time restriction to the SAS. It remains valid indefinitely while the policy exists and the account key used in the signature isn't rotated.

There's no default value of 24 hours (alternative B). Azure doesn't reject SAS without dates (alternative A). Container and account key dates aren't automatically inherited (alternative D).

This behavior requires attention in production environments: omitting dates is an explicit decision with direct impact on security posture.

Answer Key — Question 4​

Answer: B

In the context of stored access policies, the az storage container policy create command operates as upsert: if a policy with the specified name already exists in the container, it's entirely replaced with the new parameters. There's no operational distinction between creating and overwriting in this context.

Alternative A reflects expected behavior for someone assuming INSERT OR FAIL semantics, which doesn't apply here. Alternatives C and D describe behaviors that don't exist in Azure Storage implementation. This upsert mechanism is, in practice, the recommended way to update existing policies when not explicitly using update.

Answer Key — Question 5​

Answer: True

Azure Storage imposes a limit of 5 stored access policies per container. This limit applies individually to each resource: a container, queue, table, or file share can have at most 5 simultaneous policies. Attempting to create a sixth policy returns an error, and the operation is refused without affecting existing policies.

This limit is relevant in architectures that segment access by user profile or service using distinct policies. Exceeding the limit requires consolidating policies or rethinking the access strategy, possibly combining permissions into a single more comprehensive policy.