4 of the 7 questions we have for this objective, shown with the answer and the reasoning.
Configure and manage storage accounts
Corvane Telemetry ingests sensor data into a premium block blob storage account named stcorvaneingest in the Japan East region. An analytics team in the Australia East region needs a continuously updated copy of the blobs in a standard general-purpose v2 account named stcorvaneanalytics, which it will query locally to reduce latency and egress. The solution must minimize administrative effort and must not require code changes in the ingestion pipeline.
What should you do?
- AChange the redundancy of stcorvaneingest to geo-redundant storage (GRS)Premium block blob accounts support only LRS and ZRS, and GRS would replicate to the paired region (Japan West), not Australia East.
- BConfigure an object replication policy with stcorvaneingest as the source and stcorvaneanalytics as the destination, and enable blob versioning on both accountsObject replication asynchronously copies block blobs between any two accounts across regions and account types, requires versioning on both accounts and change feed on the source, and runs with no application changes.
- CCreate an Azure Automation runbook that runs azcopy copy every hourThis works but requires ongoing scripting, scheduling, and monitoring, which is more administrative effort than the built-in replication policy.
- DEnable blob versioning on stcorvaneingest onlyVersioning keeps prior versions in the same account; by itself it copies nothing to another account.
Why: Object replication is the built-in answer when you need blobs copied to a different storage account that you choose, including across regions, subscriptions, or account types; geo-redundancy only ever copies to the fixed paired region and is not available on premium block blob accounts. Object replication requires blob versioning on both source and destination and change feed on the source, and it replicates block blobs only. The deciding constraints are the specific destination region, minimal administrative effort, and no code changes.
Configure and manage storage accounts
Wrenfield Games plans to host a build cache on an SMB file share that will be accessed by 40 build agents in Azure. The share must deliver consistent low latency and high IOPS backed by solid-state storage, and the team does not need blob, queue, or table services in the same account.
Which storage account type should you create?
- AStandard general-purpose v2 (StorageV2)Standard accounts host standard file shares on HDD-backed media, which do not provide the premium latency and IOPS required.
- BPremium block blob (BlockBlobStorage)Premium block blob accounts support only blob storage; they cannot host Azure Files shares.
- CPremium file shares (FileStorage)FileStorage accounts are purpose-built for premium SSD-backed SMB and NFS file shares with provisioned performance.
- DPremium page blob (StorageV2 with Premium performance)A premium general-purpose v2 account supports page blobs only (for example, unmanaged disks); it cannot host file shares.
Why: Storage account kind and performance tier decide which services and media you get. Standard StorageV2 covers all four services on HDD-backed storage. The premium tier is split by purpose: BlockBlobStorage for high-transaction blobs, FileStorage for SSD-backed file shares, and premium StorageV2 for page blobs. Because the requirement is a premium SMB share, FileStorage is the only kind that fits. Recognizing that premium is not a single account type is the key recall here.
Configure and manage storage accounts
Nordwick Publishing keeps 8 TB of image files in the container originals in the storage account stnordwicksrc. A new storage account named stnordwickdst in another subscription will host a copy. After the initial copy, a nightly job must bring the destination up to date by transferring only files that are new or changed in the source, and it must not re-transfer unchanged files. Data must flow directly between the two accounts and not through the administrator's workstation.
What should you use for the nightly job?
- AThe azcopy sync command with the source and destination container URLsazcopy sync compares last-modified times and copies only new or changed blobs server-to-server, which is exactly the incremental behavior required.
- BThe azcopy copy command with the --recursive and --overwrite=true flagsazcopy copy with overwrite re-transfers every blob each night, including unchanged ones.
- CAzure Storage Explorer to download the container to the workstation and upload it to the destinationThis routes 8 TB through the workstation, which the scenario prohibits, and is a manual rather than scheduled process.
- DAzure Import/Export to ship a disk containing the changed filesImport/Export is for offline bulk transfer with physical drives; it is not suited to a nightly incremental update.
Why: AzCopy supports two transfer verbs. copy moves everything you point it at (optionally skipping existing files with --overwrite=false, but it does not detect changes); sync compares source and destination and transfers only new or changed files, and it can optionally delete files that no longer exist in the source. Both work blob-to-blob so data never touches the client. Storage Explorer is a GUI for interactive work (and uses AzCopy under the hood) but is not a scheduling tool. The deciding constraints are incremental transfer and no workstation in the data path.
Configure and manage storage accounts
Selwyn Capital must comply with a regulation that requires the encryption keys protecting data at rest in the storage account stselwynvault to be owned and controlled by the company, with the ability to revoke Microsoft's access to the key. The company has an existing Azure Key Vault named kv-selwyn-prod in a different resource group. You plan to configure customer-managed keys for the storage account.
Which configuration is required on kv-selwyn-prod before the storage account can use a key from it?
- ASoft delete and purge protection must be enabled on the key vaultAzure Storage requires both properties so that an accidentally deleted or purged key cannot leave data permanently unreadable.
- BThe key vault must be moved to the same resource group as the storage accountThe key vault and storage account can be in different resource groups, subscriptions, and even regions within the same tenant.
- CThe key vault must use the Premium SKU so that the key is HSM-protectedBoth software-protected keys in the Standard SKU and HSM-protected keys are supported; Premium is not required.
- DA stored access policy must be created on the key vault for the storage accountStored access policies are a storage SAS concept; the storage account's managed identity needs key permissions (get, wrapKey, unwrapKey) through RBAC or a vault access policy instead.
Why: By default Azure Storage encrypts all data with Microsoft-managed keys. Customer-managed keys let you bring your own key in Azure Key Vault or a managed HSM, which gives you the ability to rotate or revoke it. The hard prerequisites on the vault are soft delete and purge protection, which guard against losing the key and therefore the data. The storage account also needs a managed identity with get, wrapKey, and unwrapKey permissions on the key. Location, SKU, and stored access policies are plausible-sounding but not requirements.