Azure AZ-104: Implement and manage storage Practice Questions

Creating a private endpoint in the target VNet satisfies requirement 1 (only accessible from specific VNets via the private IP), requirement 2 (a private endpoint provides a private IP address that is registered in a private DNS zone such as privatelink.blob.core.windows.net, enabling DNS resolution within the VNet), and requirement 3 (setting public network access to 'Disabled' on the storage account completely blocks all public internet traffic). VNet service endpoints do not assign a private IP to the storage account — the storage account still has its public endpoint; service endpoints just route traffic through the Azure backbone and allow the firewall to restrict access to specific VNets. However, the public endpoint is still technically accessible unless the firewall denies all other traffic. More importantly, service endpoints do NOT provide a private IP address, so requirement 2 is not met. Azure AD Conditional Access can restrict sign-ins based on network location but does not provide a private IP for the storage account and does not completely disable public internet access at the network level. An Application Gateway is a Layer 7 load balancer for web applications and is not designed to front Azure Storage for private access; it does not provide a private IP for the storage service itself and introduces unnecessary complexity.

Immutable blob storage with a time-based retention policy in the locked state is the only Azure feature that enforces WORM (Write Once, Read Many) compliance. Once locked, the policy cannot be shortened or deleted—not by administrators, not by Microsoft—guaranteeing data cannot be overwritten or deleted for the full retention period. This satisfies SEC 17a-4(f) and similar regulatory requirements. Blob soft delete retains deleted blobs for up to 365 days (not 2,555 days / 7 years) and, critically, a storage account administrator can permanently delete a soft-deleted blob by purging it; it does not provide immutability. Azure Backup for blobs provides operational backup and recovery but does not prevent deletion of the original data and is not an immutability control. Blob versioning retains prior versions but does not prevent an administrator from deleting all versions, including the current version; it is a data protection feature, not a compliance lock.

The three required steps are: (1) Install the Azure File Sync agent on the Windows Server and register it with the Storage Sync Service — this creates a trusted relationship between the server and the sync infrastructure. (2) Create a cloud endpoint by associating the existing Azure file share with the sync group — this defines the cloud side of the sync relationship. (3) Configure a server endpoint by specifying the local folder path on the registered server — this defines which local directory participates in the sync group. Enabling Azure AD DS authentication is optional and pertains to identity-based access control for Azure Files; it is not a required step for Azure File Sync to function. Installing the NFS client is irrelevant; Azure File Sync uses SMB and its own sync protocol, not NFS. Creating a VNet service endpoint for the Storage Sync Service subnet is an optional network security hardening step but is not required to complete basic Azure File Sync configuration.

azcopy sync compares the source and destination and transfers only files that are new or different (based on last-modified time or MD5 hash), skipping files that already exist in the destination. It also maintains a journal file that allows interrupted operations to be automatically resumed. Setting --delete-destination=false ensures that files already in the destination but not in the source are not deleted, making it a safe incremental copy. azcopy copy with --overwrite=false will skip existing files but does not support resumption from interruption—if the job is interrupted, AzCopy copy jobs can be resumed via the job ID, but the flag alone does not filter by existence as efficiently as sync. azcopy copy with --recursive only copies all files recursively but will overwrite existing destination blobs by default and does not inherently handle resumption for incremental scenarios. azcopy make creates a container and azcopy copy with --check-md5 validates integrity but does not skip existing files or provide built-in resumption logic.

Object replication has two mandatory prerequisites beyond blob versioning: blob versioning (already enabled) AND change feed must be enabled on the source account. Change feed provides an ordered log of all changes to blobs, which the replication engine uses to identify which objects need to be copied to the destination. Without change feed, the service cannot detect new or modified blobs and replication will silently not occur. Object replication is explicitly designed to work across regions, including cross-geography replication between East US and West Europe. The destination account's redundancy level (LRS, ZRS, GRS, etc.) does not affect compatibility with object replication. The source account's redundancy level is also irrelevant; object replication works regardless of whether the source uses LRS, ZRS, GRS, or any other option.