Containers and managed application services reduce the amount of infrastructure an organization directly manages, but they do not remove responsibility for authentication, exposed endpoints, vulnerable images or overly privileged workloads. In SC-500, securing AKS, Azure Container Registry, Container Apps, Functions, Logic Apps, App Service and API Management requires an engineer to connect controls from build time to runtime and from the network path to the authenticated business operation.

Imagine a fictional customer-support platform. Developers build a container image, store it in Azure Container Registry (ACR), deploy a workload to Azure Kubernetes Service (AKS), and expose an approved HTTPS API. A background Function processes notifications, and a Logic App coordinates certain cases. The platform must prevent vulnerable images and unrestricted administrative access while allowing real customers to complete authorized support requests.

Map the software supply chain and runtime identities

Start with source code, package dependencies, build identity, image registry, deployment controller, runtime service account or workload identity, network exposure and downstream APIs. Every step can add an unwanted permission. A pipeline that can push arbitrary images to production may create as much risk as a compromised runtime, while an overly privileged pod can misuse cloud resources even when its image has no known vulnerability.

Use a release record that identifies the source revision, image digest, scanner result, environment and approved deployment. A tag such as latest is not an immutable artifact identity. For reproducible rollback and forensic review, retain the digest of the image that actually ran. Restrict who can push, delete or overwrite images and separate development from production registry access according to the environment’s needs.

Security reviews should test the actual workload identity. An API pod that needs to retrieve one Key Vault secret should not possess Azure subscription Owner rights. Where supported, use workload identity and bounded service principals with specific resource roles. A compromised container should encounter independent resource permission limits rather than inherit a broad administrator credential embedded in its environment variables.

Secure ACR images and deployment permissions

Registry security begins with image-push and image-pull permissions, vulnerability findings and pinning the exact build artifact. Azure Container Instances and Container Apps each need a trusted way to authenticate to the registry; a publicly reachable image URL does not prove its digest or provenance. Before promoting a release, check the identity used for image pulls, approved registry boundaries and scanner findings for the exact image version—not merely the deployment status returned by the control plane.

A vulnerability alert requires assessment of exploitability, exposure and mitigation, not an automatic claim that every affected workload has already been compromised. Some findings can be addressed by rebuilding with a patched base image; others may require network containment until a fix is available. Keep ownership and release history visible, and avoid suppressing critical findings merely to make a pipeline turn green.

Test that an unauthorized developer cannot push a production image, that a runtime identity can pull only approved images and that a deployment cannot silently replace an evaluated digest. Reconcile scanner output with the real running image because a cleaned registry entry does not mean every old pod has been updated.

Apply AKS workload, cluster and network controls

Kubernetes separates cluster control, node infrastructure, pod identity and application access. Configure supported authentication and RBAC for cluster administration, use namespaces and policies thoughtfully, restrict privileged containers and unnecessary capabilities, and limit access to sensitive volumes or environment secrets. A pod that runs as root or mounts the host filesystem can enlarge the damage caused by an application vulnerability.

Network policies and ingress controls can restrict pod-to-pod and external flows where supported by the chosen AKS configuration. The boundary matters: an NSG on a subnet, a Kubernetes network policy and an HTTP authorization rule solve different problems. Test the allowed service-to-service request and a denied cross-namespace request under the actual network plugin and policy engine. A policy definition that isn’t enforced by the deployed networking mode is not protection.

The Defender for Containers product guidance distinguishes agentless discovery and vulnerability assessment from runtime threat detections that can depend on a Defender sensor and supported Kubernetes audit telemetry. Enabling a protection plan is not evidence that every AKS workload is inventoried, its image has been assessed or the expected runtime alert path is operational. Check cluster onboarding, sensor health where required, scan coverage for the actual image and a supported benign detection test; mark unavailable telemetry as untested rather than inventing a successful alert.

Protect web apps, Functions and Logic Apps by purpose

App Service and Azure Functions can expose public endpoints or reach protected back-end services. Configure supported authentication and authorization, TLS, restrictions on inbound access and appropriate identity for downstream resources. A Function that reads from storage may need only a narrow data role, not the storage account key. Use separate environments and app settings according to sensitivity; avoid placing broad secrets in logs or unsecured deployment files.

A Logic App can automate workflows involving external systems. Its connector identity and permissions should reflect the business action’s sensitivity. A notification workflow and a privileged directory-change workflow should not share unrestricted credentials. Make retries and idempotency explicit for operations that alter data; repeating a message after a timeout can create duplicate tickets or payments even if the underlying API is securely authenticated.

For every managed app, test the actual public entry point, identity boundary, disabled authentication case and failure of a dependent private resource. A healthy deployment page doesn’t prove that the API rejects unauthenticated requests or that its backend has been isolated.

Use WAF and API Management at their actual boundaries

A web application firewall (WAF) can inspect supported HTTP/S traffic for web-application attacks. API Management can provide gateway-level identity and policy enforcement, quotas, transformations and backend routing for supported APIs. Neither control is a database permission system, nor does a WAF validate a user’s entitlement to modify an account. The backend must remain responsible for object-level authorization and business invariants.

Place the controls where the request actually travels. If a mobile client can call a raw backend IP or URL that bypasses API Management, a gateway policy alone cannot guarantee enforcement. Test that direct access is blocked or independently secured. Record the client identity, token audience, gateway decision, downstream principal and final action result for a request that changes state.

Microsoft’s API Management GenAI gateway capabilities include supported token quotas, rate limits, observability and routing for eligible AI endpoints. Integration of an AI gateway directly into Microsoft Foundry is preview, and its supported capabilities depend on the configured deployment and policies. A token quota can limit consumption but cannot determine whether a particular user is allowed to modify a payment record; the backend must enforce that business authorization. Test the chosen gateway policy, direct-backend bypass route and identity used for the final write before claiming the model or an MCP tool is safely governed.

Restrict API side effects and secrets

A secure API should distinguish reads, proposals and confirmed writes. A model or UI may suggest a support ticket update, but a trusted service should validate the caller, request schema, target object’s ownership, version precondition and any required approval. An HTTP 200 from a model endpoint or gateway is not evidence that a database mutation was committed or authorized.

For sensitive operations, use idempotency keys or a transaction ledger so retries cannot accidentally repeat an irreversible action. Distinguish a timeout before a request reaches the service from a timeout after a write committed. If the transaction status is unknown, query the authoritative system of record instead of blindly sending another write.

Use managed identities and Key Vault where supported to keep credentials outside source code. Narrow runtime access to each downstream resource and review whether a compromised tool can call unintended APIs. A prompt saying “never read confidential data” cannot undo an overly broad storage or SQL role.

Test runtime detections and remediation boundaries

Create a synthetic vulnerable image and an appropriately restricted test environment. Verify the chosen registry/image assessment identifies the expected issue, then deploy a patched image by immutable digest and confirm the running workload changed. If using Defender for Containers, verify sensor health and that any alert type claimed by the runbook is supported in the current plan and cluster configuration. Do not fabricate detections when live cluster instrumentation is unavailable.

Inject a harmless denied tool call, a wrong-tenant API request and an attempt to bypass the gateway. Confirm that the service refuses the prohibited action before it reaches the business data store. Add a temporary dependency outage and watch that automatic retries remain bounded. For an AKS policy change, test whether a necessary workload path still succeeds; a “fix” that removes cluster DNS or a critical health endpoint can create an avoidable outage.

An operational response plan should preserve an artifact rollback target, role-assignment record, affected namespaces or apps and owner decisions. A blanket “disable all services” instruction rarely meets real recovery needs. Contain the exploitable path, retain evidence and restore only verified safe functionality.

Prepare an SC-500 compute protection release gate

For the fictional support system, build a table across ACR, AKS, App Service, Functions, Logic Apps and API Management. Each row should name owner, permitted operation, actual workload identity, network entry point, relevant Defender coverage, negative security test and recovery path. Perform a successful user request and an unauthorized one, then inspect where the denial occurred. The security boundary is complete only when the backend cannot be reached through an ungoverned alternative route.

Protecting an application workload requires coordination across its container or app-hosting layer, ingress, API authentication and the services it can reach. The SC-100 AI workload architecture clarifies system-level responsibilities; an SC-500 engineer must verify deployment-specific controls. In a hypothetical AKS service exposing a payment API, scan the approved image, restrict the workload identity, inspect egress, check object-level authorization at the backend and capture a forbidden-access trace. Compare an App Service deployment where managed identity and private connectivity create different risks. If independent SC-500 compute and API practice scenarios describe a gateway rule passing while the same user can modify another customer’s payment directly, the real defect is missing backend authorization or gateway bypass—not the absence of another security-product checkbox. Confirm the proposed fix with both allowed and denied requests.

Container and application platform protection is a chain of independently verifiable controls. Image scanning cannot compensate for a privileged runtime; an API gateway cannot compensate for missing object authorization; a Defender alert cannot substitute for fixing a dangerous configuration. Defending the chain means identifying its weakest effective boundary and testing it after each meaningful change.