4.3.2. Container Instances, Container Apps, Functions, and Logic Apps Security
💡 First Principle: These four serverless and lightweight-container services all shift infrastructure management to Microsoft, but each still needs the same access-control discipline covered throughout this guide — authentication choice, least-privilege permissions, and careful secrets handling — applied to its own specific configuration surface.
Security for Azure Container Instances and Azure Container Apps centers on network isolation (VNet integration where available) and identity — using managed identities (2.1.6) rather than embedded credentials for any downstream calls the container makes. Azure Functions security includes choosing between function keys (simple, but a shared secret) versus Microsoft Entra ID authentication for stronger, per-identity access control, plus network access restrictions limiting which networks can trigger HTTP-triggered functions. Azure Logic Apps security focuses heavily on connector permissions and secrets handling — a Logic App workflow often chains together many connectors, each with its own credential or managed identity, making least-privilege scoping per connector important rather than granting one broad identity across the whole workflow.
⚠️ Exam Trap: Securing Azure Functions or Logic Apps is not mainly a network-restriction exercise. Authentication choice (function keys versus Microsoft Entra ID/managed identity) and least-privilege connector permissions matter as much as network access controls — a scenario emphasizing "this function can be triggered by anyone who has the key" is an authentication-method problem, not a network configuration problem.
Reflection Question: Why might a Logic Apps workflow with ten connectors sharing one broadly-scoped managed identity represent worse practice than assigning each connector its own narrowly-scoped identity, even if the workflow "works" either way?
