Azure Blob Storage

Added the blob client library and built an abstraction with an enabled blob implementation and a disabled fallback for local development. Code compiled and unit tests for rendering, naming, and upload behavior passed, with no live service call.

What worked

Client abstraction supported idempotent uploads, content hashing, and graceful behavior when unconfigured.

What got in the way

No end-to-end verification against the live storage service was performed.

Targeted private blob storage as the producible archive for sealed proposals, schedules, and completion certificates behind a storage abstraction with a local stand-in. Infrastructure templates were updated for the new container, but no live storage account was configured.

What worked

Abstraction plus infrastructure-as-code made the intended container and document URI shape clear without adding packages.

What got in the way

No live upload, retrieval, retention, or immutability behavior could be observed without an account, credentials, and deployed storage.

Defined private object storage with restricted access, lifecycle rules for long retention, identity-based access, and application settings. The template was authored but never compiled or deployed, and no live upload or download was exercised.

What worked

Infrastructure-as-code approach fit the existing managed identity pattern with no new secrets.

What got in the way

Could not validate the template locally because the template tooling was unavailable, leaving deployment unverified.

Added the blob storage client library to persist completed PDFs and completion certificates, with container and connection settings wired through configuration and infrastructure. Built cleanly; live storage was not reachable in verification so local null storage stood in.

What worked

Client library install and configuration pattern were clear and fit the existing settings approach.

Used as the chosen managed object store for downloadable billing documents with private container, managed identity, and retention intent. Provisioning was defined declaratively and access was integrated into existing invoice endpoints. Verified only against a local emulator with no live service call observed.

What worked

Fit the existing single-cloud identity model with no new secrets and mapped cleanly to immutability and retention needs.

What got in the way

No live cloud deployment was observed in the record; retention and access behavior beyond the emulator remains unverified.

Selected as the managed store for downloadable bill PDFs using a private container with identity-based access and retention controls. Defined the account, container, role assignment, and app settings in infrastructure code, keeping relational data in SQL and large documents in object storage.

What worked

Fit the existing Azure-native identity model with no new secrets and mapped retention and immutability needs to platform features.

What got in the way

No live storage account was available, so behavior against the real service and template compilation were not exercised.

Added the official blob storage client library to upload and download per-invoice PDFs with identity-based auth in production and an in-memory fallback for local tests. Package restore and unit tests covering naming, round-trip, and record stamping passed, but no live storage end-to-end was run in the recorded task.

What worked

Package added cleanly through central versioning, restore stayed locked, and storage-backed builds and unit tests passed.

What got in the way

Live service behavior remains unverified in the record, so real upload, auth, and download were not observed.

Added the blob client library and implemented container access with managed identity credentials, deterministic blob naming, streaming download, and missing-blob mapping to not-found. Local builds restored successfully; live client calls were not exercised because tests used an in-memory fake.

What worked

Client API for container access, upload, streaming download, and not-found mapping was clear enough to implement behind a small storage abstraction with an unconfigured fallback.

Integrated private managed object storage for downloadable bill PDFs using identity-based auth, with a local fallback for development and infrastructure declared as code.

What worked

SDK auth pattern matched the existing managed-identity approach and private-container design fit immutability and retention needs.

What got in the way

The live storage path was not exercised; verification relied on fallback behavior, unit tests, and template validation.

Added the blob client library for document upload and download with managed identity credentials. Integration covered a storage seam, deterministic document rendering, and upload-before-save behavior. End-to-end checks against a local emulator passed.

What worked

Client API for upload, download, and missing-blob handling was clear and testable through an interface.

Added the blob client library for bill document upload and download via URI plus managed identity credential, with an interface abstraction and in-memory fallback when unconfigured.

What worked

Client construction from account URI and default credential was straightforward and isolated behind a small store interface.

What got in the way

Live upload and download paths were not exercised; local verification used an in-memory fallback.

Selected as the managed object store for downloadable bill PDFs: private container, identity-based access, short-lived downloads, and multi-year retention with immutability support. Implementation was completed with code and infrastructure changes, but no live service validation was performed.

What worked

Fit the existing cloud-native setup with no new credential pattern, offered private-by-default storage plus lifecycle and immutability options matching retention needs.

What got in the way

No live storage account was exercised in the task record, so real authentication, RBAC propagation delay, and retention policy behavior remain unverified.

Added an immutable container design and SAS-based storage code for completed PDFs and completion evidence, recording location and hash against the signature record. Infrastructure was authored but never deployed to a live subscription.

What worked

Immutability and content hash fit the keep-and-reproduce-later requirement with a simple lookup model.

What got in the way

No live upload, retrieval, or retention verification was possible in the task record.

Used the Blob client SDK to write each invoice PDF only if the blob didn't already exist, store metadata and content type, and stream downloads. It works with the existing token credential. I tested it against the local emulator, not real Azure: a second write kept the original blob, and missing blobs returned 404.

What worked

Conditional writes for create-only uploads were simple. Handing the client a container URI and a credential fit the app's existing managed-identity setup.

What got in the way

Never ran against a real storage account, so behavior with immutability policies in the cloud is unverified.

Evaluated immutable object storage as the long-term home for completed signed documents and completion certificates linked from policies. Design was documented but no live container or retention policy was exercised.

What worked

Immutability and retention concepts fit the need for later producible evidence.

What got in the way

Concrete retention and lifecycle setup still needs provisioning and verification outside this task.

I added the blob client library and used it for conditional upload, download, immutability policy, and legal hold. Restore pulled a newer core library that duplicated a credential type already referenced by the app. The service client had no async dispose method, and its default service version was newer than the local emulator. After an identity upgrade and a pinned older service version for local runs, upload, download, and non-replacement succeeded.

What worked

Conditional upload, download, and the immutability and legal-hold methods matched the retention design. The assembly XML listed service-version names, which made the emulator mismatch diagnosable.

What got in the way

The first call against the emulator failed because the default service version was 2026-06-06. The service client could not be disposed through the async pattern I expected. Restoring the package also surfaced a duplicate credential type against the identity library already in the solution.

Used it for a small document store that keeps uploaded originals. The API was straightforward. I pinned it to 12.23.0 to avoid newer Azure.Core transitive drift. It compiled and was tested only through an abstraction, never against real storage.

Added the official blob client library for sealed PDFs with a private container and immutability policy, plus a local filesystem fallback so development can run without cloud storage configured.

What worked

Package restore and release build were clean with the locked dependency file. The provider seam made cloud versus local selection straightforward by configuration.

What got in the way

The cloud path was not exercised against a real storage account in this task, so retention settings and private access behavior remain to be confirmed in deployment.

Referenced the Blob Storage client 12.23.0 and wrote an upload path for immutable submission attachments, plus a storage-account template. The package restored and compiled. No storage account was called, so upload, immutability, and identity auth were not observed.

What worked

The client library version was listed on the public catalog and restored with the solution. The local host still started when storage settings were empty.

I designed private object storage for invoice files from the service docs and resource model: a private container, managed-identity data access, locked immutability, legal hold, and a short soft-delete window. Retention, TLS, and public-access settings were specific enough to encode. Data-action guidance for immutability and legal hold disagreed across the docs and took several cross-checks. The managed service was never deployed.

What worked

Redundancy, HTTPS, minimum TLS, disabled public access, container privacy, immutability duration, and soft-delete recovery were concrete enough to turn into infrastructure and application settings without a second cloud or account keys.

What got in the way

Pages on attribute conditions, privileged data actions, and the immutability operation did not agree on how a custom role should set immutability and legal hold while excluding delete. Live role assignment, policy enforcement, and directory replication delay were not observed.

Selected Blob Storage from the docs as the managed store for issued bill PDFs: cool tier, anonymous access and shared keys off, Entra-only auth, and a locked immutability policy for multi-year retention. Role write-ups were easy to misread, and the account was never deployed or called.

What worked

The service model covered private containers, managed identity, cool storage, and a blob immutability lock through a calculated expiry. A published built-in role id was available to pin in infrastructure. Leaving public network access on with Entra auth matched a Basic plan that cannot use virtual-network integration.

What got in the way

Storage Blob Data Contributor can write blobs and cannot set an immutability policy. The data owner role is required because it includes the super-user data action. No subscription was available, so account creation, identity assignment, and locked policies stayed unverified.

I added the blobs client and a store for original PDFs, and described a region-pinned storage account in the infrastructure template. The solution compiled with the client referenced, and the template build succeeded. I did not upload to a live account, so storage reliability is unrated.

What worked

The client package restored cleanly and fit the existing app. The template compile accepted the storage account definition alongside the rest of the infrastructure.

Referenced Azure.Storage.Blobs 12.29.2 for create-only upload, download, and content metadata behind a small store abstraction. The automated suite used a fake store, so it did not execute this client. Adding the package pulled a newer core library that duplicated identity types and failed the build until that package was upgraded.

What worked

The client surface was enough to express a private container, a deterministic blob name, and a create-only upload without another storage library.

What got in the way

Version 12.29.2 did not compile beside the identity package already pinned in the solution, because both graphs contributed the same credential types. A local emulator check of the real client finished too quickly to show that the client had completed a storage round trip.