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 individually be configured with a Private Endpoint, meaning the entire pipeline from Part 2's complete picture diagram can be rebuilt to never touch the public internet at any internal hop, with only the true entry point, APIM, if external-facing, remaining publicly reachable.
Topic 5: Network Security Groups, NSGs
A Network Security Group is a set of firewall rules applied at either a subnet level or an individual network interface level, controlling inbound and outbound traffic by source and destination IP, port, and protocol.
Think of a building's security desk with a specific list of who's allowed in, through which door, carrying what. Traffic that doesn't match an explicit allow rule, and doesn't match a higher-priority deny rule, simply doesn't get through.
A few core NSG concepts worth knowing precisely: rules have priority numbers from 100 to 4096, where lower numbers are evaluated first, and the first matching rule wins with evaluation stopping there. Rules specify direction, inbound or outbound, source, destination, port, protocol, and allow or deny. Default rules exist automatically and cannot be deleted, only overridden by a higher-priority custom rule - these include allowing VNet-to-VNet traffic, allowing Azure Load Balancer traffic, and denying all other inbound traffic by default. NSGs can be applied at two levels simultaneously, subnet level affecting everything in that subnet, and network interface level affecting one specific resource - both are evaluated if both exist, and traffic must pass both to actually get through.
// Example NSG rule (conceptual, via Azure Portal or CLI)
Priority: 100
Name: Allow-HTTPS-Inbound
Direction: Inbound
Source: Internet
Destination: 10.0.1.0/24 (a specific subnet)
Port: 443
Protocol: TCP
Action: Allow
Priority: 200
Name: Deny-All-Other-Inbound
Direction: Inbound
Source: Any
Destination: Any
Port: Any
Action: Deny
// (this duplicates default behavior, but shown
// explicitly here for clarity)
The tradeoff: NSGs are coarse-grained, IP, port, and protocol, compared to something like APIM's subscription key or OAuth validation, covered in the APIM posts on this blog. NSGs control whether traffic can reach a network destination at all, not who is making an authenticated request once it arrives. Real architectures layer both.
How this connects to Parts 1 and 2: if Function Apps and Logic Apps in the Part 2 pipeline are deployed with VNet Integration into a specific subnet, an NSG on that subnet is what actually restricts which other subnets or IP ranges those services can communicate with - the network-level enforcement underneath the VNet Integration and Private Endpoint configuration already discussed.
Topic 6: Encryption in Transit vs At Rest
These are two genuinely different protections, both necessary, neither substituting for the other. Encryption in transit protects data while it's actively moving between two points over a network. Encryption at rest protects data while it's sitting stored somewhere, on disk, in a database.
Think of a sealed, tamper-evident courier bag that protects a letter while it travels, in transit, but once it arrives and gets filed away, the bag itself does nothing to protect the letter sitting in an unlocked filing cabinet, at rest. Both protections are needed, and they protect against different threats at different moments.
Encryption in transit covers HTTPS and TLS for API calls, which APIM, Function Apps, and Logic Apps all enforce by default for their endpoints, and Service Bus and Azure SQL connections, encrypted via TLS by default. This is mostly already on by default across Azure services - the interview-relevant knowledge is knowing it's the default, and knowing how to verify it hasn't been accidentally disabled somewhere.
Encryption at rest covers Azure Storage, Azure SQL, and Service Bus messages at rest, all encrypted by default using Microsoft-managed keys. Customer-managed keys, via Key Vault, are available for organizations needing to control their own encryption keys specifically - a real, sometimes compliance-driven choice, not the default.
The tradeoff: Microsoft-managed keys, the default, require zero setup and are genuinely secure for most scenarios. Customer-managed keys add real operational overhead, since you're now responsible for key rotation and availability, in exchange for direct control - typically only worth it when a specific compliance requirement mandates it.
How this connects to Parts 1 and 2: every message sitting in a Service Bus queue, from Part 1, every order record written to Azure SQL by a Function App, from Part 2, is encrypted at rest by default without any explicit configuration - worth knowing this is already true, rather than assuming it needs to be manually enabled.
Topic 7: Azure RBAC, Role-Based Access Control
Azure RBAC is the actual mechanism that decides what a given identity, a Managed Identity, a user, a group, is allowed to do once it has authenticated. Every grant-access step mentioned so far, a Function App reading a Key Vault secret, a Managed Identity publishing to Service Bus, has been RBAC quietly doing the actual authorization work underneath.
Think of a hospital ID badge system, distinct from the building access badge used earlier for Managed Identity. The badge, the identity, gets you through the front door, but RBAC is the separate system deciding whether that specific badge lets you into the pharmacy, the operating room, or only the waiting area. Having a valid badge and being authorized for a specific room are two different checks.
A few core RBAC concepts matter here. A Role Definition is a named set of permissions - "Key Vault Secrets User" can read secrets but not manage access policies, while "Key Vault Administrator" can do both. A Role Assignment binds a specific identity to a specific role at a specific scope - "this Managed Identity has the Storage Blob Data Reader role on this storage account." Scope determines where a role assignment applies, running from Management Group down through Subscription, Resource Group, to an individual Resource, and a role granted at a higher scope is inherited by everything underneath it.
# Granting RBAC access via Azure CLI - conceptually
# what happens when you click "Add role assignment"
# in the portal
az role assignment create \
--assignee <function-app-managed-identity-object-id> \
--role "Service Bus Data Sender" \
--scope /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.ServiceBus/namespaces/{namespace}
# This Function App's Managed Identity can now SEND
# messages to this specific Service Bus namespace -
# nothing more, nothing less, and no connection
# string was involved anywhere in granting this access
The principle of least privilege, made concrete: a Function App that only ever needs to send messages to Service Bus should get the "Service Bus Data Sender" role specifically, not the broader "Service Bus Data Owner" role - even though both would technically make the code work, the narrower role means a compromised Function App identity still can't delete queues or read messages meant for other consumers.
The tradeoff: RBAC role assignments add real setup overhead compared to a shared connection string that just works everywhere - the honest payoff is that a leaked or compromised identity has precisely bounded damage potential, rather than full access to whatever the shared secret happened to unlock.
How this connects to everything already covered: RBAC is the actual authorization layer underneath every Managed Identity example in this post - granting the Function App access to Key Vault, or the Managed Identity being able to publish to Service Bus, are both RBAC role assignments happening behind the portal UI. Managed Identity answers who is this, RBAC answers what are they allowed to do, the same Authentication vs Authorization distinction covered in depth in an earlier post on this blog, now applied specifically to Azure resource-to-resource access.
Topic 8: Token Validation, Revisited in This Context
The JWT validation happening at the APIM gateway, covered in real depth in the APIM Part 1 post on this blog, deserves an explicit callback here, since Topic 7's RBAC and this token validation answer genuinely parallel questions at two different layers of the same pipeline.
There are two layers here, answering two different questions, running at two different points in the same request. APIM's validate-jwt policy, the external entry point, validates a token presented by an external caller - is this token signed correctly, not expired, issued for the right audience - covered in depth in the APIM Part 1 post. Azure RBAC, internal and resource-to-resource, operates once inside the pipeline, deciding what an already-authenticated Azure resource, via Managed Identity, is allowed to do to another Azure resource. Both are genuinely "authorization" in the AuthN and AuthZ sense covered in an earlier dedicated post - one happens at the public edge, checking an external caller's claims; the other happens entirely within Azure's own control plane, checking a resource's own identity against RBAC role assignments.
Where this distinction actually gets tested in an interview: being asked how an API is secured and only mentioning APIM's token validation misses half the real answer - a fully secured pipeline validates the external caller at the edge, APIM's JWT validation, and enforces least-privilege access for every internal hop afterward, RBAC on each Managed Identity. Mentioning only one of the two is the incomplete answer a panel interviewer is specifically listening for.
How this connects to Parts 1 and 2: in the Part 2 end-to-end example, the external partner's token gets validated once, at APIM, at the very start of the pipeline - but every single hop afterward, Logic App to Function App, Function App to Key Vault, Function App to SQL, Function App to Service Bus, is a separate authorization decision, made by RBAC, not by re-checking that same original token. This is why both topics genuinely need to be understood together, not treated as the same concept covered twice.
Putting the Whole Security Picture Together
Revisiting the Part 2 end-to-end pipeline, now with security layered on top of every hop, tells the complete story. An external partner calls APIM as the entry point, with TLS enforced for encryption in transit, and a subscription key plus OAuth validated at the gateway. APIM forwards to a Logic App, ideally over a private path if the Logic App is VNet-integrated. The Logic App calls a Function App for complex transformation, authenticating using Managed Identity rather than a stored key. The Function App needs a partner API key for one step, retrieved from Key Vault, referenced via the Function App's own Managed Identity. The Function App writes the result to Azure SQL, reached via a Private Endpoint, with SQL configured to reject all public internet traffic entirely, and an NSG on the Function App's subnet permitting this specific outbound path. The Function App publishes to a Service Bus topic for the next stage, authenticated via Managed Identity and Azure RBAC, with no connection string secret anywhere. Every step logs to Application Insights regardless - security doesn't remove the need for observability from Part 2, it adds to it.
This is the shape of answer, describing security as a layer across an already-understood pipeline rather than a separate topic, that demonstrates real architectural thinking in a panel interview.
Key Lessons
Managed Identity eliminates stored secrets for Azure-to-Azure authentication entirely - it doesn't help for non-Azure, third-party systems, which is exactly where Key Vault still matters.
Key Vault and Managed Identity work together - the Managed Identity is the credential that authenticates to Key Vault, which then holds whatever secrets genuinely can't be eliminated.
VNet Integration affects outbound traffic from a PaaS service; Private Endpoints affect how that service is reached - the two work together to keep an entire pipeline off the public internet.
Service Endpoints and Private Endpoints are not the same thing - a Service Endpoint optimizes a still-public path, a Private Endpoint gives the service an actual private IP with no public path required at all.
NSGs control network-level reachability, whether traffic can get there at all, while APIM's subscription keys and OAuth validation control authenticated access, who is allowed once traffic arrives - real architectures need both layers, not one instead of the other.
Encryption in transit and at rest are both already on by default for most Azure services - the interview-relevant knowledge is knowing that default exists, not assuming it needs manual setup.
RBAC is the authorization layer underneath every Managed Identity grant covered in this post - Managed Identity answers who is this, RBAC answers what are they allowed to do, and least-privilege role selection genuinely bounds the damage a compromised identity can do.
Token validation at APIM, the external edge, and RBAC, internal and resource-to-resource, are both authorization but operate at genuinely different layers of the same pipeline - a complete answer to how something is secured needs both, not just one.
What's Next
Future parts of this series will cover additional Azure integration topics based on continued interview prep needs - debugging and monitoring the secured pipeline built across this and earlier parts, or deeper API Management security patterns specifically.
Summary
Security and networking aren't a separate concern from the messaging and orchestration services covered in Parts 1 and 2 - they're a layer that sits directly on top of that same architecture. Managed Identity removes stored secrets between Azure services. Key Vault holds what genuinely can't be eliminated. VNet Integration and Private Endpoints keep traffic off the public internet entirely. NSGs enforce network-level reachability underneath all of it. Encryption in transit and at rest protect data whether it's moving or sitting still. Describing how these layer onto a specific, already-understood pipeline, rather than reciting them as abstract concepts, is what turns a security question into a demonstration of real architectural thinking in a panel interview.
More from TechStack Blog: Azure: https://www.techstackblog.com/category.html?cat=azure
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals
