DevOps KB Pages

  1. Microsoft-Owned APIs behave differently The App Registration lives in Microsoft’s tenant (hidden from you) You only see the Service Principal (SP) in your tenant The Microsoft API SP never shows API permissions This is expected and correct Example: Power Platform API → AppID 8578e004-a5c6-46e7-913e-12f58912df43 (Microsoft-owned) 2. API permissions are ALWAYS stored on the client application , not on the Microsoft API When you grant a permission like: CopilotStudio.Copilots.Invoke It gets added to the client application's SP/App Registration , e.g.: "My Application" —not— Power Platform API SP So the client app will show: ✔ API permissions ✔ Delegated permissions ✔ Admin consent The Microsoft API SP will show: ❌ Nothing ❌ No API permissions ❌ No scopes ❌ No roles 3. Why? Because permissions are modeled as: Client App → requests → permission → from → Resource API The resource API (Microsoft-owned SP) does NOT keep track of who...

  The “Tape Head” Analogy for Git HEAD version control   HEAD = The read/write head on a cassette tape Think of your entire Git repository like an old cassette tape with multiple tracks (branches). ✔️ HEAD is the physical read/write head. It doesn’t store music itself — it just points to where on the tape you want to read or write. ✔️ Switching branches = moving the tape head When you run: git switch feature/login You’re not changing the branch itself — you’re just moving the tape head to read/write on that track. HEAD only exists once There is one tape head , but many tracks. The head points to whichever track you choose. Branches = multiple tracks on the same cassette Each branch is like its own “audio track” that ends at a different timestamp (commit): main -> Commit A feature/ login -> Commit C bugfix -> Commit F All those tracks exist, but the HEAD can point only to ONE at a time . Commits = positions on the track When you rewind to an old...

OIDC (OpenID Connect) is the glue that binds the Kubernetes Service Account (SA) → Azure Managed Identity (MI) → Federated Credential chain. Here’s what’s really happening behind the scenes in AKS + Microsoft Entra ID (formerly Azure AD). 🔐 The Role of OIDC in the AKS–Azure Identity Chain 1. OIDC Issuer: The Cluster’s Identity Provider When you enable OIDC on your AKS cluster, Azure assigns it an OIDC issuer URL , like: https: //eastus.oic.prod-aks.azure.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/ This URL acts like a mini identity provider (IdP) for your cluster. Inside the cluster, Kubernetes Service Accounts can issue JWT tokens that are signed by this OIDC issuer. Each token includes claims like: iss → the OIDC issuer URL sub → system:serviceaccount:<namespace>:<serviceaccount> aud → the audience you request when you create the token Those claims prove “This token was issued by this AKS cluster for this Service Account.” 2. Federated Cr...

Quick decision tree (what to do) Have resource in Azure but not in state? → terraform import (Row 4, 8, 13). Have resource in state but not in config (and you want to keep it in Azure)? → terraform state rm (Row 6). Renamed/moved resources in code? → terraform state mv to map old address to new (Row 14–15). Portal edits conflict with .tf? → Let TF overwrite, or add ignore_changes for specific fields (Row 2, 10–11). Plan wants to destroy & recreate but you need continuity? → Check if the change really requires replace; if yes, consider create_before_destroy (when supported), or a migration strategy (Row 9). # .tf declares resource? In state ? Exists in Azure ? Situation / Drift terraform plan shows apply result Typical fix / notes 1 ✅ ✅ ✅ No drift No changes N/A Happy path. 2 ✅ ✅ ✅ (props changed in portal) Property drift Update in-place (change block) Terraform updates Azure to match .tf Or use lifecycle { ignore_changes = [...] } if portal edits are intentional. 3 ✅ ✅ ❌ Resou...