Skip to main content

Technical Lab: Configure object replication

Questions​

Question 1 — Multiple Choice​

An operations team needs to configure object replication between two storage accounts in Azure. When reviewing the prerequisites, the responsible engineer lists the following items:

  1. Both accounts must have blob versioning enabled
  2. The change feed must be enabled on the source account
  3. The two accounts must be in the same Azure region
  4. The accounts must be of type StorageV2 (general-purpose v2) or Block Blob Storage

How many items on this list are correct?

  • A) Only 1 item is correct
  • B) Only 2 items are correct
  • C) 3 items are correct
  • D) All 4 items are correct

Question 2 — Technical Scenario​

An organization configured object replication between two storage accounts. After configuration, a developer observes that new objects added to the source container do not appear in the destination, while objects that existed before configuration were also not copied.

The engineer checks the replication rule and finds the following definition:

{
  "filters": {
    "minCreationTime": "2024-06-01T00:00:00Z"
  },
  "sourceContainer": "dados-producao",
  "destinationContainer": "dados-backup"
}

What is the most likely cause for new objects not being replicated?

  • A) Object replication does not support filters by creation date; the entire rule is ignored when this field is present
  • B) The minCreationTime field limits replication to objects created from that date, and new objects may be taking up to 30 minutes to be replicated asynchronously
  • C) The destination container needs to have the same name as the source container for replication to work
  • D) Blob versioning was disabled after rule creation, silently interrupting the replication process

Question 3 — True or False​

Statement: Object replication in Azure Blob Storage is synchronous by default, ensuring that any object written to the source account is immediately available in the destination account before the write operation returns success to the client.

  • True
  • False

Question 4 — Technical Scenario​

An architect is planning object replication between two storage accounts in different regions. He needs to ensure that only files with the prefix relatorios/financeiro/ are replicated to the destination. When creating the replication policy via the Azure portal, he tries to include two simultaneous filters in the same rule:

  • Prefix: relatorios/financeiro/
  • Prefix: relatorios/juridico/

What is the expected behavior of this configuration?

  • A) The two prefixes are combined with OR logic, replicating objects that match either of the two prefixes within a single rule
  • B) Only the first prefix is applied; the second is silently ignored by the service
  • C) The configuration is invalid; each prefix must be defined in a separate rule within the same policy
  • D) The two prefixes are combined with AND logic, replicating only objects whose name contains both patterns simultaneously

Question 5 — Multiple Choice​

When configuring object replication, which of the following statements correctly describes the behavior related to blobs encrypted with customer-managed keys (CMK)?

  • A) Blobs encrypted with CMK in the source account are decrypted during transfer and re-encrypted with the destination account's CMK automatically, without additional configuration
  • B) Object replication does not support blobs encrypted with CMK; only blobs encrypted with Microsoft-managed keys can be replicated
  • C) Blobs encrypted with CMK in the source arrive at the destination encrypted with the key configured in the destination account, which can be a different CMK or the Microsoft-managed key
  • D) The CMK from the source account needs to be explicitly shared with the destination account for replication to complete successfully

Answer Key and Explanations​

Answer Key — Question 1​

Answer: C

Explanation:

  • Items 1, 2, and 4 are correct. Blob versioning is mandatory on both accounts. The change feed must be enabled on the source account, as it is the mechanism that allows tracking blob writes and deletions that trigger replication. The account type must be StorageV2 or Block Blob Storage, as legacy accounts (like general-purpose v1) do not support the feature.
  • Item 3 is incorrect: object replication is precisely designed for cross-region scenarios. There is no region restriction; accounts can be in any supported region, including different subscriptions.
  • The misconception represented by distractors marking 2 or 4 items reflects confusion with other Azure redundancy features (like GRS and RA-GRS), which are indeed restricted to the same account and have internally managed region restrictions.

Answer Key — Question 2​

Answer: D

Explanation:

  • Object replication fundamentally depends on two mechanisms: the change feed and blob versioning. If versioning is disabled after rule creation, the service cannot track object versions and replication stops silently, without emitting visible errors in the portal or standard diagnostic logs.
  • Alternative B describes a real behavior of the minCreationTime field and asynchronous delay, making it a plausible distractor. However, it doesn't explain why new objects (created after that date) are also not being replicated.
  • Alternative A is incorrect: creation date filters are supported and do not invalidate the rule.
  • Alternative C is incorrect: source and destination containers can have different names.
  • The practical consequence of ignoring versioning disablement is creating a false sense of protection, where the policy exists and appears configured, but no data is actually replicated.

Answer Key — Question 3​

Answer: False

Explanation:

  • Object replication in Azure Blob Storage is strictly asynchronous. This means that after a successful write to the source account, the object will be replicated to the destination at some later time, without guarantee of immediate time or arrival order.
  • Azure does not expose a replication latency SLA for this feature. The process depends on the change feed being processed and the availability of the internal replication pipeline.
  • This behavior is critical for architecture decisions: scenarios requiring immediate consistency across regions should consider other approaches, such as using RA-GRS or multi-account write logic at the application layer.
  • Confusing object replication with synchronous replication is a common error that can lead to designs with incorrect assumptions about data availability at the destination.

Answer Key — Question 4​

Answer: C

Explanation:

  • Each rule within a replication policy accepts only one prefix filter. To replicate objects with different prefixes, you need to create a separate rule for each prefix within the same policy.
  • Alternative A represents the most common misconception: assuming that multiple prefixes in a rule work with OR logic, which is not the case.
  • Alternative D represents another classic error: assuming that multiple filters work as intersection (AND), which is also not supported and would be semantically useless for distinct directory prefixes.
  • In practice, a replication policy can contain up to 10 rules, allowing coverage of multiple prefixes with individual rules without needing separate policies.

Answer Key — Question 5​

Answer: C

Explanation:

  • During replication, the blob content is transferred and stored at the destination using the destination account's encryption configuration. If the destination account uses a different CMK, the blob will arrive encrypted with that key. If the destination account uses Microsoft-managed keys, the blob will be stored with that encryption.
  • Alternative A is incorrect because it suggests Azure automatically manages the exchange between different CMKs during transfer. The process does not decrypt and re-encrypt with the source CMK as an explicit step in the client's replication pipeline.
  • Alternative B is incorrect: blobs encrypted with CMK are supported in object replication.
  • Alternative D represents a serious security misconception: sharing CMK keys between accounts would violate Azure Key Vault's isolation model and is neither a requirement nor a supported practice.
  • Understanding this behavior is essential for architectures that need to maintain key control per account or per region, ensuring the destination's CMK policy is properly configured before enabling replication.