Update blog 5.9: add VS Manage User Secrets section and three-environment secret flow

Author: workcontrolgit

blogs/series-5-devops-data/5.9-azure-key-vault-secrets.md

@@ -25,7 +25,8 @@ This article is part of the **AngularNetTutorial** series covering Angular 20, .
 * **`DefaultAzureCredential`** — how one credential works for both local development and Azure production with no code changes
 * **`AddAzureKeyVault()` in .NET** — how to wire Key Vault into `IConfiguration` so existing code requires zero changes
 * **`SecretClient`** — reading a specific secret directly in code when you need it on demand
-* **Local development** — using `dotnet user-secrets` locally, Key Vault in production
+* **Visual Studio Manage User Secrets** — the local development equivalent of Key Vault, stored in AppData and never committed to git
+* **Three secret sources, one IConfiguration key** — how user secrets, GitHub Secrets, and Key Vault work together across environments
 
 ---
 
@@ -343,6 +344,70 @@ public class MyService(SecretClient secretClient)
 
 ---
 
+## 🖥️ Local Development: Visual Studio Manage User Secrets
+
+During local development you don't need Key Vault — it requires Azure network access and adds friction for every team member. Visual Studio has a built-in equivalent called **Manage User Secrets** that stores secrets outside the project folder so they're never committed to git.
+
+### How to Open It
+
+Right-click the `TalentManagementAPI.WebApi` project in Solution Explorer → **Manage User Secrets**
+
+This opens a `secrets.json` file stored at:
+
+```
+C:\Users\{you}\AppData\Roaming\Microsoft\UserSecrets\d7dba4fb-c08e-453d-9e13-d7d0f8ba8ff0\secrets.json
+```
+
+The GUID is the `<UserSecretsId>` value already in `TalentManagementAPI.WebApi.csproj`. Each developer has their own copy — the file never appears in git.
+
+### What to Put in secrets.json
+
+```json
+{
+  "ConnectionStrings": {
+    "DefaultConnection": "Server=localhost;Database=TalentManagementApiDb;Trusted_Connection=True;MultipleActiveResultSets=true"
+  },
+  "JWTSettings": {
+    "Key": "YourLocalJwtSigningKeyMinimum32Characters"
+  },
+  "Sts": {
+    "ServerUrl": "https://localhost:44310",
+    "ValidIssuer": "https://localhost:44310"
+  }
+}
+```
+
+These values override `appsettings.json` automatically in the `Development` environment — no code change required.
+
+### The Full Picture: Three Secret Sources, One IConfiguration Key
+
+The same `ConnectionStrings:DefaultConnection` key is read by the .NET app in every environment. What changes is where the value comes from:
+
+**Local development — Visual Studio Manage User Secrets:**
+* Stored in `AppData` on your machine
+* Never in git, never in source control
+* Overrides `appsettings.json` automatically
+
+**GitHub Actions deploy — GitHub Secrets:**
+* Used to log in to Azure and run Bicep
+* Writes `@Microsoft.KeyVault(...)` references to App Service settings
+* The actual database password is never in GitHub Secrets at all
+
+**Azure App Service runtime — Key Vault:**
+* App Service resolves `@Microsoft.KeyVault(...)` references via managed identity
+* The running app receives the real connection string value
+* Never visible in plain text in the Portal
+
+```
+Local dev        → VS Manage User Secrets  → AppData on your machine
+CI/CD deploy     → GitHub Secrets          → Azure login + KV reference URIs
+Azure runtime    → Azure Key Vault         → managed identity, resolved at startup
+```
+
+**The application code never changes across environments.** `builder.Configuration["ConnectionStrings:DefaultConnection"]` works the same way whether the value came from `secrets.json`, an App Service setting, or a Key Vault reference.
+
+---
+
 ## 🔄 When to Use Each Approach
 
 **App Service Key Vault references** (`@Microsoft.KeyVault(...)` in settings):