Forum Discussion
Is setting an index tag in Azure Defender for Cloud during file write an atomic operation?
Hi,
When using Azure Defender for Cloud, is setting an index tag at the same time as writing a file considered an atomic operation? Or is there a propagation delay before the tag becomes fully available and effective for search and policy enforcement?
Any insights or official documentation references would be appreciated!
2 Replies
Hi vitoiacono,
Setting an index tag at the same time as writing a file in Azure (including scenarios where Defender for Cloud later uses those tags) is not considered an atomic operation from a platform perspective. While the blob write and tag assignment can be submitted together, index tags are indexed asynchronously, which means there can be a short propagation delay before the tag is fully available for search queries, policy evaluation (like ABAC), or automation.
Because of this eventual consistency, there’s a small window where the file exists but the tag isn’t yet effective. This behavior is part of how Azure Storage indexing works and isn’t specific to Defender for Cloud itself (Defender just reads or writes tags based on scan results). Best practice is to design workflows with this in mind - for example, add retries, delays, or validation checks before enforcing logic that depends on those tags.
Hi Aladin,
thank you for the clarification — I fully understand and agree with the point about index tags being indexed asynchronously and therefore not being search-atomic.
However, I’m currently designing a security-critical flow that relies on Azure Blob Storage + Defender for Cloud + ABAC, and there is one specific aspect that is still unclear to me, and I couldn’t find any official documentation that answers it explicitly.
Scenario:
A blob is uploaded using a single PUT request (or SDK equivalent)
The request includes x-ms-tags, so the blob content and its index tags are submitted together
An ABAC rule controls read access using a condition like NOT (
Exists @Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Malware Scanning scan result<$key_case_sensitive$>]
)
Key question (straight to the point):
When a blob is uploaded with index tags in the same request, is ABAC evaluation guaranteed to see the presence of that tag key when enforcing read access — or can ABAC temporarily evaluate the blob as having no index tags due to tag indexing propagation delay? And
In other words:
Does ABAC read index tags from the write path / transactional metadata, or
Does it rely exclusively on the asynchronously indexed tag store, potentially allowing a short window where exists(tagKey) evaluates to false even though the tag was provided in the upload request?
This distinction is extremely important for security-by-design scenarios (e.g., blocking downloads until Defender scanning completes), because relying on exists semantics becomes unsafe if ABAC can observe a “tag-less” state after a tagged upload.
If the behavior is documented somewhere (or if there is an architectural guarantee that ABAC will never observe a tagged blob as untagged when tags are sent in the same request), a reference to the official documentation would be greatly appreciated.
Thanks again — this clarification would unblock a critical design decision.
