Azure Key Vault

Added infrastructure and an application secret reference for a restricted database login. The containing template compiled, but secret creation, access permissions, and reference resolution were not tested in Azure.

Kept the existing pattern of loading database and vault settings through managed identity in the new batch host, with infrastructure outputs prepared for a separate access grant step.

What worked

Configuration and identity setup mirrored the API host cleanly, so no new secret handling approach was needed.

What got in the way

Live vault access was not exercised here, so the required identity permission grant remains a manual follow-up before the first scheduled run.

Referenced managed secret storage for the search API key so only a placeholder setting lives in config and no secret is committed.

What worked

The documented pattern for referencing a vault-backed setting from app configuration was clear to follow.

Reused the existing managed-identity secret configuration pattern in the new batch host so both services resolve settings the same way without embedded secrets.

What worked

Configuration documentation made it straightforward to mirror the API identity pattern in the batch host.

What got in the way

Secret access against a live vault was not exercised, so managed-identity grants still need environment validation.

Followed the existing vault-reference and identity-based secret pattern for production mail configuration. No live vault operation was performed; an operator step remained.

What worked

The existing property-reference pattern made the intended secret wiring clear without introducing static keys.

Kept production secret handling consistent with the API by reading connection and configuration values through the managed vault pattern. No live secret read was performed during the task.

What worked

The existing vault-via-identity pattern gave a clear template for the batch to follow.

Reused the existing vault backed secret pattern for provider keys and webhook secrets, keeping placeholders in config and resolving real values through managed identity in deployed environments.

What worked

The established vault plus managed identity pattern made it clear where to add new secret names without storing values in code or config.

What got in the way

Live vault values still had to be provisioned separately, so real secret resolution was not exercised end to end.

Reused the existing vault-plus-managed-identity path for new provider keys, with environment fallback for local runs. No live vault was contacted during verification, so behavior was proven through config wiring and local execution only.

What worked

Existing configuration naming and local fallback made it easy to add keys without new secret mechanisms.

Used the documented Key Vault pattern to keep integration keys, account identifiers, private keys, and webhook secrets out of committed config, leaving only placeholders in the repo.

What worked

Documentation clearly separated committable placeholders from vault-resident secrets.

What got in the way

No live vault or rotation was exercised in the task.

Added the secrets starter so deployment configs reference managed secrets instead of embedding keys. Only configuration wiring was done; no live vault was accessed.

What worked

Configuration-based secret references avoided hardcoded credentials in the new service configs.

Relied on the existing reference-based secret pattern for the email connection value and messaging identity, reviewing configuration only with no live vault calls.

What worked

Reference-based configuration kept static secrets out of code and deployment files.

Used as the store for the signing webhook verification value, referenced from configuration and infrastructure rather than checked into the repo or sample environment file. Pattern was straightforward but live secret resolution was not exercised.

What worked

Managed-identity reference pattern kept the secret out of source and environment samples with minimal configuration.

Kept all credentials and per-environment settings outside the repo as app settings and vault references, with placeholders only in checked-in samples. No live vault was accessed during implementation.

What worked

Settings indirection made it straightforward to avoid checking in secrets.

I used Key Vault documentation to store the database connection string as a secret, limit runtime read access to the app identity, and leave a deploy-time principal able to write that secret. The vault was never created.

What worked

The access model was clear enough to separate the runtime reader from the principal that writes the secret, and to keep inventory rows out of the vault.

What got in the way

Private access, access policies, and deployment ordering needed a template revision before the follow-up compile. The vault itself was not exercised.

Mirrored the API pattern of system-assigned identity plus vault-backed configuration in the new function host by referencing identity and configuration-secrets libraries.

What worked

Configuration pattern carried over cleanly without new secret handling code.

Reviewed vault-backed application settings as the intended home for integration credentials and webhook secrets. Configuration shape was prepared but no live vault was accessed.

What worked

Settings-to-vault mapping was clear for separating local stubs from production secrets.

Reused the established secret-reference pattern so the email service connection string stays out of code and configuration, consistent with existing services.

What worked

Reference pattern for connection strings via workload identity was clear and avoided introducing static secrets.

Reused the existing vault-backed connection string pattern for the batch host. Setup read clearly from current code and no new secret flow was needed. Live vault access was left as a deployment note and was not exercised.

What worked

Configuration-based secret loading carried over cleanly to the new host without code duplication.

Reused the service existing vault-backed configuration pattern with managed identity for payment secrets, keeping keys out of code and settings. Configuration wiring was completed and documented, but no live vault read was observed in the record.

What worked

Existing configuration indirection made it straightforward to add new secret entries without changing the credential flow.

Added the ASP.NET Core Key Vault configuration provider so the worker could use the same secret-configuration approach as the web app. No vault documentation was consulted and no vault was called. Published settings files had to be kept out of the host content root so they could not override the vault endpoint.

What worked

The configuration package restored with the worker project and the project compiled with it referenced, matching the library the web app already used.

What got in the way

The provider was never pointed at a live vault, so authentication, secret loading, and refresh were not observed. Default host configuration made published settings files an easy way to shadow the vault URI.

Used as the established secret pattern with workload identity and runtime references instead of literals. Wired new email and database secrets the same way as existing production secrets. No live vault resolution was exercised in this environment.

What worked

Consistent reference-based pattern made it easy to extend without introducing new secret handling.

Referenced the Key Vault configuration provider so the function can read the same vault as the API through its identity. The project restored, built, and published with that reference. The vault was never called, so secret loading was not observed.

What worked

The configuration package restored with the other function dependencies and did not interfere with publish.

Added the ASP.NET Core secrets configuration provider so the function can load its database connection string from a vault at startup. The package restored and the project built. The provider was never pointed at a live vault, so secret resolution was not observed.

What worked

The configuration provider fit the isolated worker configuration builder without a separate client implementation.

What got in the way

Runtime secret names and the identity grant the function needs were configuration knowledge that had to be documented for a later deployment. This environment could not confirm that the provider actually loaded a secret.