Java / Azure Blob Storage Interview questions

Azure Blob Storage is Microsoft's object storage service for large volumes of unstructured data such as images, videos, documents, logs, backups and analytics datasets. You reach it over HTTP/HTTPS through the REST API, client SDKs, the Azure CLI, PowerShell, AzCopy or the portal.

Data lives in a three-level hierarchy: a storage account holds containers, and each container holds blobs (the objects). There is no schema and no query language over the content itself, you simply store and fetch objects by name.

Typical uses include serving media to browsers, backup and archive, log retention, and acting as the storage layer for data lakes and big data jobs.

Azure Blob Storage supports three blob types, and the type is fixed when the blob is created:

• Block blobs - the default for files, media and backups. Built from blocks, up to roughly 190.7 TiB.
• Append blobs - optimized for append-only writes such as log files. Up to roughly 195 GiB.
• Page blobs - a collection of 512-byte pages for random read/write, up to 8 TiB. Used for VHD-based disks.

If you are unsure, pick block blob. The other two cover specific access patterns.

A storage account is the top-level resource that gives you a unique namespace in Azure Storage. Every blob, file share, queue and table you create is addressed through it, and it is the unit where you set redundancy, networking rules, encryption and billing.

The account name must be 3-24 characters, lowercase letters and numbers only, and globally unique because it becomes part of the endpoint, for example https://myaccount.blob.core.windows.net.

For most workloads, use a Standard general-purpose v2 account. For low-latency, high-transaction blob workloads, use a Premium block blob account (kind BlockBlobStorage).

A container groups a set of blobs inside a storage account, much like a top-level folder. An account can hold an unlimited number of containers, and a container can hold an unlimited number of blobs.

Containers cannot be nested. If you want folder-like structure, put slashes in blob names (such as 2026/oct/report.pdf) and list with a delimiter, or enable the hierarchical namespace for real directories.

Several settings are applied per container: the anonymous access level (private by default), stored access policies for SAS, legal holds and immutability policies. Names are 3-63 characters, lowercase letters, numbers and hyphens.

Every blob has an address built from the account, the container and the blob name:

https://shopdata.blob.core.windows.net/invoices/2026/oct/inv-1001.pdf
        |         |                |        |
     account   service endpoint  container  blob name (includes virtual path)

Here shopdata is the account, invoices is the container, and 2026/oct/inv-1001.pdf is the blob name. The slashes are part of the name, not real folders, unless the hierarchical namespace is on.

Blob names are case-sensitive and can be up to 1,024 characters. Accounts with read-access geo-redundancy also expose a -secondary endpoint, and Data Lake accounts add a dfs.core.windows.net endpoint.

An access tier lets you trade storage price against access price based on how often data is read. Frequently used data costs more to store but less to read, rarely used data is the opposite.

The account has a default access tier (Hot or Cool) that new blobs inherit. You can override it per blob, and Cold and Archive can only be set at the blob level. Tiers split into online (Hot, Cool, Cold, readable immediately) and offline (Archive, must be rehydrated first).

You change a tier with the Set Blob Tier operation or automate it with lifecycle management rules.

Redundancy decides how many copies of your data exist and where. Azure offers six options:

• LRS - three copies inside one datacenter.
• ZRS - copies spread across three availability zones in one region.
• GRS - LRS in the primary region plus LRS copy in a paired secondary region.
• GZRS - ZRS in the primary region plus an LRS copy in the secondary region.
• RA-GRS and RA-GZRS - the geo options with read access to the secondary endpoint.

Designed durability rises from 11 nines (LRS) to 12 nines (ZRS) to 16 nines (GRS/GZRS) over a year.

A block blob is the standard blob type for documents, images, video, backups and datasets. It is assembled from blocks that can be uploaded independently and in parallel, then committed together as one blob.

Each block can be up to 4,000 MiB and a blob can have up to 50,000 blocks, giving a maximum size of about 190.7 TiB. Small files can skip blocks entirely and use a single Put Blob call (up to 5,000 MiB).

Because blocks are uploaded separately, a failed block can be retried without restarting the whole transfer.

An append blob is made of blocks like a block blob, but it only allows new blocks to be added at the end. You cannot modify or delete existing blocks, which makes it a safe fit for logs and audit trails.

Each append block can be up to 4 MiB, and a blob holds up to 50,000 blocks, so the maximum size is about 195 GiB. The Append Block operation is atomic, so concurrent writers never interleave half-written entries.

Use it when you write sequentially and never update earlier data. For anything else, a block blob is more flexible.

A page blob is a collection of 512-byte pages designed for frequent random reads and writes. You can write to any page range without touching the rest, which is why it backs VHD files for unmanaged VM disks.

The maximum size is 8 TiB. Writes must be aligned to 512-byte boundaries, and the blob is created at its full size up front, though you are billed for the pages you actually write.

Today most VMs use managed disks, so page blobs show up mainly in older setups and in specialized scenarios that need sparse random-access files.

A Shared Access Signature (SAS) is a signed URL token that grants limited access to storage resources without sharing your account key. The token encodes what is allowed, for how long, and optionally from which IP addresses.

A typical SAS defines the resource (blob or container), permissions such as read, write or delete, a start and expiry time, and the allowed protocol. You append it to the resource URL as a query string:

https://shopdata.blob.core.windows.net/invoices/inv-1001.pdf?sv=2024-11-04&sp=r&se=2026-10-12T10:00:00Z&sig=...

Anyone holding the URL gets exactly those rights until it expires, so keep lifetimes short.

Azure Storage supports three SAS types, differing in how they are signed and what they cover:

• User delegation SAS - signed with Microsoft Entra credentials through a user delegation key. Blob storage only, and the recommended option.
• Service SAS - signed with the account key, scoped to one service such as Blob, and optionally tied to a stored access policy.
• Account SAS - signed with the account key, can span several services and operations at the account level.

Only service SAS can reference a stored access policy, which lets you revoke or change many tokens by editing one policy.

Each storage account has two access keys, key1 and key2. Either one gives full control of all data in the account, so they work like a root password.

Having two keys exists for rotation: you move applications to key2, regenerate key1, then switch back, all without downtime. Microsoft recommends storing keys in Azure Key Vault and rotating them regularly.

Better still, avoid them. You can set allowSharedKeyAccess to false so that only Microsoft Entra authorization (and user delegation SAS) is accepted.

AzCopy is a command-line tool for fast, scriptable data transfer to and from Azure Storage. It handles parallel uploads, resumable jobs, wildcards and recursive folder copies, which makes it the usual choice for bulk migrations.

azcopy login
azcopy copy "./reports" "https://shopdata.blob.core.windows.net/invoices" --recursive
azcopy sync "./reports" "https://shopdata.blob.core.windows.net/invoices"

It can also copy between storage accounts server-side, so data moves over Azure's network instead of through your machine. Authenticate with azcopy login or a SAS appended to the URL.

Use az storage blob upload and name the account, container, blob and local file. Adding --auth-mode login uses your Microsoft Entra sign-in instead of an account key, which needs a role such as Storage Blob Data Contributor.

az login
az storage blob upload \
  --account-name shopdata \
  --container-name invoices \
  --name inv-1001.pdf \
  --file ./inv-1001.pdf \
  --auth-mode login

For a whole folder, use az storage blob upload-batch with --source and --destination. Add --overwrite if the blob already exists.

With the Azure.Storage.Blobs package, create a BlobServiceClient, get a container client, then a blob client, and call UploadAsync. DefaultAzureCredential keeps secrets out of your code.

var service = new BlobServiceClient(
    new Uri("https://shopdata.blob.core.windows.net"),
    new DefaultAzureCredential());

var container = service.GetBlobContainerClient("invoices");
var blob = container.GetBlobClient("inv-1001.pdf");

await blob.UploadAsync("./inv-1001.pdf", overwrite: true);

The SDK automatically splits large files into blocks and uploads them in parallel. Without overwrite: true, uploading to an existing name throws an error.

Blob soft delete keeps deleted or overwritten blobs (and snapshots) recoverable for a retention period you choose, from 1 to 365 days. Instead of being removed, the blob is marked as soft-deleted and hidden from normal listings.

To bring it back, call Undelete Blob or use the portal's Show deleted blobs toggle. After the retention window ends, the data is permanently removed. A separate container soft delete setting protects whole containers.

Soft-deleted data still counts toward storage cost until it expires.

Blob versioning automatically keeps the previous state of a blob every time it is modified or deleted. Each earlier state becomes a read-only version identified by a version ID (a timestamp).

You can read, promote or delete any version. To restore an older one, copy it over the current blob. Versions are billed as extra storage, so pair versioning with lifecycle rules that delete old versions after a set number of days.

Versioning is a prerequisite for features such as object replication and point-in-time restore.

A snapshot is a read-only copy of a blob captured at a specific moment. You create it manually with Snapshot Blob, and it is identified by a DateTime value appended to the blob URI.

Snapshots only store blocks or pages that changed since the base blob, so they are space-efficient. They can be read, copied or deleted, but not modified, and you cannot delete a base blob that has snapshots unless you also remove them.

The key difference from versioning: snapshots are taken on demand, while versions are created automatically.

The hierarchical namespace (HNS) turns a flat blob account into a real file-system-style structure with directories. It is the feature that makes an account Azure Data Lake Storage Gen2.

With HNS you get atomic directory rename and delete, POSIX-style ACLs on files and folders, and the abfss:// driver used by Spark and Hadoop. Without it, renaming a folder means copying and deleting every blob under that prefix.

It is normally enabled when you create the account. An upgrade path exists for supported accounts, but it is one-way.

All four tiers hold the same data. What changes is the price curve, the minimum storage time and whether the data is instantly readable.

Moving or deleting a blob before the minimum period triggers an early deletion charge. Pick Hot for active data, Cool or Cold for backups and older content you still read now and then, and Archive for compliance data you almost never touch.

LRS keeps three synchronous copies inside a single datacenter. ZRS keeps three synchronous copies across three separate availability zones in one region.

Choose ZRS when you need the data to stay available through a zone outage. Neither protects against losing a whole region, for that you need a geo option.

Both copy your data asynchronously to a secondary region hundreds of miles away. The difference is how the primary region is protected.

GZRS gives you the zone resilience of ZRS and the regional protection of GRS together, at higher cost. Add read access (RA-GRS or RA-GZRS) if your app must read from the secondary during an outage.

The practical rule: block blob for general data, append blob when you only add records, page blob when something needs in-place random writes. Only block blobs can use Hot, Cool, Cold and Archive tiering.

An access key is a full-power secret for the entire account. A SAS is a derived token with a narrow scope and an expiry.

Hand out SAS tokens to clients, never the key. Even better, use Entra ID roles for your own apps and user delegation SAS for external parties, since both tie access back to an identity.

Blob Storage is object storage accessed mainly through REST APIs and SDKs. Azure Files offers managed file shares you mount like a network drive using SMB or NFS.

If a legacy app expects a drive letter or a mounted path, Azure Files fits. If you are building a cloud-native app that serves or processes objects, use Blob Storage.

A user delegation SAS is signed with a key obtained using Microsoft Entra credentials, not with the storage account key. That means the token can never exceed the permissions of the identity that created it, and no account key is exposed.

It also leaves a better audit trail and is easier to cut off: you can revoke the user delegation key, or remove the identity's role, and all tokens derived from it stop working. The delegation key lasts at most 7 days.

The caller needs the Storage Blob Delegator role (or equivalent) to request the key. The limitation is that it works for Blob and Data Lake storage only.

Lifecycle management is a rule engine at the storage account level. You define JSON rules with filters (container, blob prefix, blob type, index tags) and actions based on days since modification, creation or last access.

{
  "rules": [{
    "name": "age-out-logs",
    "enabled": true,
    "type": "Lifecycle",
    "definition": {
      "filters": { "blobTypes": ["blockBlob"], "prefixMatch": ["logs/"] },
      "actions": { "baseBlob": {
        "tierToCool":    { "daysAfterModificationGreaterThan": 30 },
        "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
        "delete":        { "daysAfterModificationGreaterThan": 365 } } }
    }
  }]
}

Rules run once a day and can tier, delete, or clean up old versions and snapshots. Changes may take up to a day to take effect.

An archived blob is offline, so you must bring it back to an online tier before reading it. There are two ways:

1. Set Blob Tier - change the same blob to Hot, Cool or Cold in place.
2. Copy Blob - copy the archived blob to a new blob in an online tier, leaving the archive copy untouched.

You also pick a rehydration priority. Standard can take up to 15 hours. High priority is usually under an hour for objects smaller than 10 GB, but costs more. Copying is safer if you want to keep the archived original and avoid early-deletion issues.

A lease puts a lock on a blob or container so only the holder of the lease ID can write to or delete it. Reads are still allowed. It is the simplest way to prevent two processes from modifying the same blob at once.

You acquire the lease with a duration of 15 to 60 seconds, or infinite. A finite lease must be renewed before it expires, otherwise it lapses. The lease can also be changed, released by the holder, or broken by an administrator.

Writes without the correct lease ID fail with a 412 error.

Both protect against mistakes, but they work differently. Soft delete keeps deleted or overwritten data for a limited retention window. Versioning keeps every previous state of a blob for as long as you keep the versions.

Most production accounts enable both, plus a lifecycle rule to prune old versions.

Security is layered, so use several controls together:

• Identity - prefer Microsoft Entra ID with RBAC roles, and disable shared key access where possible.
• Network - restrict traffic with the storage firewall, service endpoints or private endpoints.
• Transport - require HTTPS (secure transfer) and set a minimum TLS version.
• Anonymous access - disable blob public access at the account level unless you truly host public content.
• Encryption - on by default, optionally with customer-managed keys.
• Protection - soft delete, versioning, immutability and resource locks.

Add Microsoft Defender for Storage and diagnostic logging to detect abuse.

All data written to Azure Storage is encrypted automatically with 256-bit AES (Storage Service Encryption). It cannot be turned off, and decryption is transparent to the caller.

By default the keys are Microsoft-managed. You can switch to customer-managed keys held in Azure Key Vault or Managed HSM, giving you control over rotation and revocation. Encryption scopes let you apply different keys per container or blob, and clients can also send a customer-provided key on each request.

For compliance needs, optional infrastructure encryption adds a second layer of encryption with a separate key.

Assign an Azure RBAC data role to the user, group or managed identity at the account, container or subscription scope. Common roles are Storage Blob Data Reader, Storage Blob Data Contributor and Storage Blob Data Owner.

The app then authenticates with Entra ID, for example through DefaultAzureCredential, and sends a bearer token with each request. No secrets are stored in the app when a managed identity is used.

A common trap: management roles like Owner or Contributor do not grant access to blob data. You must assign one of the data roles, and propagation can take a few minutes.

Use a private endpoint when traffic to the account must stay on your virtual network and never touch the public internet. It gives the storage account a private IP address inside your VNet, and you can then turn off public network access entirely.

It is the right choice for regulated data, hybrid setups where on-premises networks connect through VPN or ExpressRoute, and when you need to block data exfiltration. You also need a private DNS zone (privatelink.blob.core.windows.net) so the account name resolves to the private IP.

A service endpoint is simpler and free, but the account keeps its public IP and cannot be reached from on-premises over private links.

Object replication asynchronously copies block blobs from a container in a source account to a container in a destination account, which may be in another region or subscription. You define it with a policy containing one or more rules, each optionally filtered by blob prefix.

Prerequisites: blob versioning on both accounts and change feed on the source account. New writes and deletes after the policy is created are replicated, and the destination is meant to be treated as read-only.

Typical uses are reducing read latency for users in another region and keeping a copy for compliance or analytics.

Immutable storage provides WORM (write once, read many) protection. Blobs can be created and read, but not modified or deleted for as long as the policy applies.

There are two mechanisms. A time-based retention policy blocks changes for a set number of days. A legal hold blocks changes until the hold is cleared, with no end date. Both can be applied at container level or at the individual version level.

Once a time-based policy is locked, it cannot be removed and the retention period can only be extended. This is what satisfies regulations like SEC 17a-4.

Both attach key-value pairs to a blob, but they serve different purposes.

Use metadata for descriptive information that travels with the blob, and tags when you need to find or filter blobs across containers without listing everything.

Enable the static website feature on the storage account, then upload your HTML, CSS, JavaScript and images to the special $web container.

1. Enable static website hosting in the portal or CLI.
2. Set the index document name (for example index.html) and an optional error document.
3. Upload files to $web.
4. Browse to the primary web endpoint, which looks like https://myaccount.z13.web.core.windows.net.

az storage blob service-properties update \
  --account-name shopsite --static-website \
  --index-document index.html --404-document 404.html

The web endpoint differs from the normal blob endpoint. For a custom domain with HTTPS, put Azure Front Door or Azure CDN in front.

When blobs are created or deleted, the storage account publishes events like BlobCreated and BlobDeleted to Azure Event Grid. Event Grid then pushes them to subscribers such as Azure Functions, Logic Apps, Event Hubs, Storage Queues or a webhook.

flowchart LR
  A["Client uploads blob"] --> B["Storage account"]
  B -->|BlobCreated event| C["Event Grid topic"]
  C --> D["Azure Function"]
  C --> E["Storage Queue"]
  C --> F[Webhook]

Events carry metadata (blob URL, content type, size) but not the blob content itself. This push model replaces polling and lets you build reactions like image resizing or virus scanning without running a server.

A large block blob upload is a two-phase process. First the client stages data as uncommitted blocks, then it commits them as the blob with a block list. Nothing is visible to readers until the commit succeeds.

sequenceDiagram
  participant C as Client
  participant S as Blob service
  C->>S: Put Block (ID=1, data)
  C->>S: Put Block (ID=2, data)
  C->>S: Put Block (ID=3, data)
  Note over S: Blocks held as uncommitted
  C->>S: Put Block List (1,2,3)
  S-->>C: 201 Created + ETag

1. Split the file into blocks (up to 4,000 MiB each, up to 50,000 per blob).
2. Give each block a unique, same-length Base64 block ID and send it with Put Block, in parallel if you like.
3. Call Put Block List naming the IDs in the order they should appear. Each ID can be taken from the committed, uncommitted or latest set.
4. The service atomically replaces the blob's content and returns a new ETag.

Uncommitted blocks that are never committed are garbage collected after a week. Because a failed block can simply be re-sent, uploads are resumable, and you can also update a blob by committing a list that reuses old block IDs plus a few new ones.

Every blob has an ETag that changes whenever the blob is modified. Optimistic concurrency uses it to detect conflicting writes without locking anything.

The client reads the blob and remembers the ETag. When writing back, it sends a conditional header If-Match: <etag>. If the blob changed in the meantime, the ETag no longer matches and the service answers 412 Precondition Failed, so the client re-reads, merges and retries.

var conditions = new BlobRequestConditions { IfMatch = props.Value.ETag };
try {
    await blob.UploadAsync(stream, conditions: conditions);
} catch (RequestFailedException e) when (e.Status == 412) {
    // someone else updated it, reload and retry
}

If-None-Match: * does the opposite: it makes the write succeed only if the blob does not exist, giving you a safe create-only operation. Use leases instead when you want pessimistic locking, for example a single leader-election worker.

A 403 means the request was understood but rejected. The error code in the response body tells you which layer refused it, so start there.

Then confirm the basics: you assigned a data role and not just Contributor, the SAS permissions match the operation, and the request comes through the expected network path. Enable diagnostic logs to see the caller, auth type and exact failure reason.

A 503 ServerBusy (or 500 OperationTimedOut) means the account or a single partition has hit a scalability target and the service is throttling you. It is a signal to slow down and spread load, not usually a service outage.

1. Check metrics in Azure Monitor: transactions, ingress/egress, and throttling responses by API and by time.
2. Retry with exponential backoff. The Azure SDK retry policy does this by default, so make sure it was not disabled.
3. Avoid hot partitions. Blob partitions are range-based on account, container and blob name, so names that increase sequentially (such as timestamp prefixes) push all traffic to one partition. Add a hash or random prefix to spread writes.
4. Spread the load over time, reduce tiny requests by batching, or split across multiple storage accounts or containers if you are at account limits.
5. Verify the client is not in a retry storm that multiplies traffic.

If a workload truly needs higher limits, you can request a quota increase for some limits or move to a Premium block blob account.

Throughput depends on parallelism, block size, and network distance. Tuning these usually matters more than the service itself.

• Parallel transfers - upload many blocks at once. In the .NET SDK set StorageTransferOptions (MaximumConcurrency, MaximumTransferSize). With AzCopy, raise AZCOPY_CONCURRENCY_VALUE.
• Right-sized blocks - larger blocks (for example 8-100 MiB) mean fewer requests for big files, while smaller blocks recover faster from errors.
• Stay close - run compute in the same region as the account, and use Private Link or ExpressRoute for predictable bandwidth.
• Range reads - download only the byte ranges you need and fetch ranges in parallel.
• Avoid tiny files - bundle small objects, because per-request overhead dominates.
• Spread partitions - avoid sequential name prefixes for very high request rates.

For server-to-server copies use Put Blob From URL or AzCopy's service-side copy, so bytes do not travel through your client at all. Measure before and after, since the bottleneck may be your disk or network rather than Azure.

With RA-GRS, writes go to the primary region and are copied asynchronously to the secondary. Between failovers, your app can read from the read-only -secondary endpoint, for example https://shopdata-secondary.blob.core.windows.net.

In a regional disaster you (or Microsoft) can trigger an account failover. The secondary is promoted to primary, the DNS endpoints are repointed, and the account typically becomes LRS in its new region until you re-enable geo-redundancy.

flowchart LR
  A["App writes"] --> B["Primary region"]
  B -->|async copy| C["Secondary region"]
  A -.reads on outage.-> C
  B -. failover .-> D["Secondary becomes primary"]

Because replication is asynchronous, anything not yet copied is lost on failover. Check the account's Last Sync Time to know your exposure. Replication lag is typically small but not guaranteed by default. Design apps to fall back to the secondary for reads, and to tolerate stale data there.

With versioning enabled, an overwrite never destroys the old content. The service takes the existing blob and stores it as a previous version, identified by a version ID that is the timestamp of its creation. The newly written data becomes the current version with its own version ID.

A delete behaves similarly: the current version turns into a previous version, and the blob name has no current version, so a normal GET returns 404 until you restore one.

Every version is billed as stored data, but identical blocks are shared, so only changed blocks add cost. Add a lifecycle rule to delete old versions, otherwise storage grows without limit. Versions can be deleted individually, even while the current version remains.

Point-in-time restore (PITR) rolls block blobs in one or more containers back to an earlier state, for example just before a bad deployment or a ransomware event. It works by replaying the change feed backwards and using versions and soft delete to recover data.

1. Enable soft delete, change feed and versioning on the account.
2. Enable point-in-time restore and choose a retention period. It must be shorter than the soft delete retention period.
3. Start a restore for a chosen UTC time, for all containers or specific blob ranges.

Only block blobs in standard general-purpose v2 accounts are restored. Page and append blobs are not affected, and a restore is blocked if there are conflicting immutability rules. The operation is asynchronous, and blobs written after the restore point are reverted.

PITR is a recovery tool for logical corruption, not a replacement for geo-redundancy or a separate backup.

Choose a Premium block blob account when the workload is dominated by many small, latency-sensitive operations and you care about consistently low latency. It runs on SSD-based hardware, so request latency is lower and more predictable than Standard.

Good fits include interactive web and mobile back ends, AI and machine learning pipelines that read lots of small files, IoT telemetry ingestion, and analytics steps with heavy small-file I/O.

If you mostly store large files and read them rarely, Standard with tiering is cheaper. The break-even depends on how many transactions you run per GB stored.

Cost has four drivers: capacity, transactions, data transfer and extra copies. Attack each one in turn.

1. Right tier - use lifecycle rules to move aging data from Hot to Cool, Cold and Archive, and watch the 30/90/180-day minimums to avoid early deletion charges.
2. Clean up - delete old versions, snapshots and incomplete uploads, which silently grow the bill.
3. Right redundancy - do not pay for GZRS on easily reproducible data, but do not cut it from critical data.
4. Watch transactions - lots of small writes or frequent listings add up, and reads from cooler tiers cost more per operation. Batch small files.
5. Limit egress - keep compute in the same region and use a CDN for popular content.
6. Commit - reserved capacity for 1 or 3 years lowers the price for predictable volumes.

Use Azure Cost Management and storage metrics to see where spend comes from. Archive is cheapest to store but the most expensive to read, so never archive data you may need quickly.