Azure Integration Services Interview Prep Part 3: Managed Identity, Key Vault, VNet , Private Endpoints, NSGs, RBAC and Token Validation

Part 1 covered the messaging services - Service Bus, Storage Queues, Event Hub, Event Grid. Part 2 covered the orchestration layer that processes what those services move - Logic Apps, Function Apps, Durable Functions. Neither part addressed a question every panel interview eventually asks: how does any of this actually get secured. This part covers exactly that, and deliberately ties every concept back to the specific services already covered, rather than treating security as an abstract, separate topic. Topic 1: Managed Identity Managed Identity is a feature that gives an Azure resource, a Function App, a Logic App, a VM, its own automatically-managed identity in Azure AD, letting it authenticate to other Azure services without any developer ever storing, rotating, or managing a password, connection string secret, or certificate. Think of a hotel employee's own building access badge, versus needing to carry a physical master key that could be lost, copied, or stolen. The badge is tied to that specific employee's identity, can be individually revoked without affecting anyone else, and nobody needs to manage a shared physical key that everyone has to protect. There are two types of Managed Identity. System-assigned is tied directly to one specific resource's lifecycle - created when the resource is created, deleted when the resource is deleted, and cannot be shared across multiple resources. User-assigned is created as its own standalone Azure resource, then assigned to one or more other resources, surviving independently of any single resource's lifecycle - useful when several Function Apps need to share the same identity and permission set. // Enabling system-assigned identity - Azure Portal: // Function App -> Identity -> System assigned -> On -> Save // Using it in C# - DefaultAzureCredential automatically // discovers and uses the Managed Identity when running // in Azure, no connection string, no client secret using Azure.Identity; using Azure.Security.KeyVault.Secrets; var client = new SecretClient( new Uri("https://your-vault.vault.azure.net/"), new DefaultAzureCredential() ); KeyVaultSecret secret = await client.GetSecretAsync("SqlConnectionString"); // No password anywhere in this code. The Function App's // Managed Identity IS the credential. // Granting access - Azure RBAC, not a stored key // Key Vault -> Access control (IAM) -> Add role assignment // Role: Key Vault Secrets User // Assign to: the Function App's Managed Identity The tradeoff: Managed Identity is genuinely close to strictly better than a stored secret for Azure-to-Azure authentication - the honest limitation is that it only works for authenticating to Azure services, or anything supporting Azure AD auth. A third-party, non-Azure API that only accepts an API key still needs that key stored somewhere, which is exactly where Key Vault comes in next. How this connects to Parts 1 and 2: a Function App with a Service Bus Trigger, authenticates to Service Bus, using Managed Identity rather than a stored Shared Access Signature connection string - the same pattern applies to that Function App writing to Azure SQL as an exit point, or a Logic App's Azure Function connector calling into a Function App. Every service-to-service hop in the pipelines built across Parts 1 and 2 is a candidate for Managed Identity instead of a stored credential. Topic 2: Azure Key Vault Azure Key Vault is a managed service for storing secrets, encryption keys, and certificates securely, covered in depth in an earlier post on this blog. Worth revisiting here specifically in relation to Managed Identity: Key Vault is where the secrets that genuinely can't be eliminated by Managed Identity still need to live. Think of a bank vault, with your application holding a key card, the Managed Identity, that lets it walk in and request a specific secret, rather than holding the secret itself. Managed Identity eliminates the need to store Azure SQL connection strings when using Azure AD auth, Service Bus connection strings when using RBAC and identity, and Storage account access keys when using RBAC and identity. What still needs to live in Key Vault includes a partner's external API key, since Salesforce or ServiceNow don't know what an Azure Managed Identity is, a third-party webhook signing secret, and any credential for a system outside Azure entirely. // Key Vault reference in App Service Configuration - // no SDK code needed for this pattern // App Service -> Configuration -> Application settings // Name: SalesforceApiKey // Value: @Microsoft.KeyVault(SecretUri=https://your-vault.vault.azure.net/secrets/SalesforceApiKey/) // Read exactly like any other configuration value var apiKey = builder.Configuration["SalesforceApiKey"]; // App Service resolves the Key Vault reference at // startup automatically, using ITS OWN Managed Identity // to authenticate to Key Vault - the two concepts // working together directly The tradeoff: Key Vault has real per-operation costs and API rate limits - it's for genuine secrets, not general configuration values like a page size or a feature flag, which belong in normal App Service Configuration instead. How this connects to Parts 1 and 2: in the Part 2 Logic Apps problem scenario, polling a partner's REST API, the partner's API key is exactly the kind of secret that belongs in Key Vault - Managed Identity can't eliminate it, since the partner system has no concept of Azure AD identity. Topic 3: VNet Integration VNet Integration is a feature that lets Azure PaaS services, Function Apps, Logic Apps Standard, App Service, send their outbound traffic through a Virtual Network, rather than over the public internet, meaning they can reach resources that are locked down to only accept traffic from within a specific private network. Think of the difference between mailing a letter through the public postal system versus using a company's internal, private courier route between two buildings on the same secured campus. The destination might be completely unreachable to the public postal system at all - only the private internal route can get there. Without VNet Integration, a Function App reaches Azure SQL over the public internet, and Azure SQL's firewall must allow some public IP range to reach it, even if narrowly scoped. With VNet Integration, the Function App reaches Azure SQL through a private VNet route, paired with a Private Endpoint covered next, and Azure SQL can be configured to reject all public internet traffic entirely, reachable only via the private network path. // Enabling VNet Integration - Azure Portal: // Function App -> Networking -> VNet Integration -> Add VNet // Select an existing VNet and a delegated subnet // This affects OUTBOUND calls FROM the Function App - // calls made to Azure SQL, Service Bus, Key Vault, or // any other service can now route through the VNet // instead of the public internet, IF those services // are also configured to accept that private path // (via Private Endpoints, covered next) The tradeoff: VNet Integration requires a Premium or higher App Service or Function App plan - it's not available on the Consumption tier, so it's a genuine cost and architecture decision, not just a checkbox. How this connects to Parts 1 and 2: a Function App processing sensitive order data, from the Part 2 problem scenarios, can use VNet Integration to reach Azure SQL entirely privately, meaning even if the Function App's HTTP endpoint were somehow compromised, an attacker still couldn't reach the database over the public internet at all - the network path itself doesn't exist publicly. Topic 4: Private Endpoints vs Service Endpoints, the Interview Trap Both features let traffic from a VNet reach an Azure PaaS service more directly than the general public internet path, but they work in genuinely different ways, and mixing them up is a common, specific interview trap. A Service Endpoint means traffic still travels to the service's public IP address - it just takes an optimized route while doing so, and the service can be configured to only accept traffic originating from specific VNet subnets. The service still has a public IP and public DNS name, and a firewall rule on the service, such as Azure SQL's firewall, is what actually restricts access. A Private Endpoint means the Azure service gets an actual private IP address, genuinely inside your VNet's address space. DNS resolution for the service now resolves to that private IP, not a public one, when queried from within the VNet. The service can be configured to reject all public internet traffic entirely - not just restrict it by source, but genuinely have no public path at all. Think of a Service Endpoint as a VIP lane at a public building's entrance - you still arrive at the same public building, just through a faster, monitored door. A Private Endpoint is like the building itself being moved entirely inside a private, gated campus - there is no public entrance to speak of anymore. // Private Endpoint setup - Azure Portal: // Azure SQL Server -> Networking -> Private access // -> Create a Private Endpoint -> select VNet + subnet // After this, the SQL server's DNS name resolves to // a PRIVATE IP address (e.g. 10.0.1.5) when queried // from inside the VNet, instead of its public IP // The SQL Server can then have "Deny public network // access" enabled entirely - genuinely unreachable // from the public internet, regardless of firewall // rules, since there is no public path left at all The tradeoff: Private Endpoints cost more, a per-hour charge per endpoint, and add real DNS configuration complexity, often requiring a Private DNS Zone to resolve correctly. Service Endpoints are simpler and free, but offer a weaker security boundary since the service technically remains publicly reachable in principle. How this connects to Parts 1 and 2: Service Bus, Azure SQL, and Key Vault, every exit point and dependency across the Part 1 and Part 2 pipelines, can each indiv