Applications need controls from image to public request
The application-platform section of SC-500 spans Azure Kubernetes Service, container registries, Container Instances, Container Apps, Azure Functions, Logic Apps, App Service, Web Application Firewall and Azure API Management. Microsoft Defender for Containers is also part of the scope. These technologies expose different operational surfaces: some run container workloads, some host code or integrations as managed services, and others control incoming application requests. The security engineer must match safeguards to each surface instead of applying a single “enable firewall” rule to everything.
Consider a fictional ordering platform. Its core API runs on a managed container service, event processing uses Functions, a workflow uses Logic Apps, and the public storefront reaches a backend through an approved API path. The business needs strong identities, restricted service connections, protected deployment artifacts and detection of risky behavior. A network rule around one hosting service does not automatically defend the container image, its dependencies or the identity that reaches confidential data.
This topic belongs to Microsoft SC-500 secure compute. Its implementation scope is different from a general Kubernetes certification: the engineer needs to know which Azure platform features govern exposure, which workload-protection controls are available, and how to validate that a deployed service matches the expected posture.
Container supply chain and runtime protection
A container image packages application code and dependencies. Security begins before it runs: trusted sources, vulnerability review, registry access and controlled deployment are essential. An image might have no publicly exposed port and still contain an outdated vulnerable library. Conversely, a current image can be deployed with excessively privileged container configuration or an unsafe network route. Both the artifact and its runtime environment require scrutiny.
Microsoft Defender for Containers supports posture assessment and threat detection for supported container environments. Microsoft’s Defender for Containers differentiates security posture, vulnerabilities and runtime observations. Feature scope varies by supported cluster, component and plan; do not assume enabling a plan proves each application pod received identical coverage. A vulnerability finding is also not the same as evidence that an attack occurred.
An effective operating process traces a finding back to its image, workload and environment, identifies the appropriate maintainer and retests after remediation. A base-image update should not be applied blindly if it changes application behavior. The change needs an approved test and a known rollback. The useful goal is reliable deployment of a supported artifact with visible security status, not an impressively large list of scanner alerts.
AKS security includes workload and control-plane choices
Azure Kubernetes Service provides a managed orchestration environment, but organizations remain responsible for many workload, identity, networking and policy decisions. An AKS cluster can contain services with different levels of sensitivity. Separating namespaces, limiting service account permissions, controlling pod privileges and enforcing appropriate network paths all matter. A cluster-level administrative role does not need to be the routine identity for every application deployment.
Access to the Kubernetes API and access from a running pod to a data service are distinct questions. An operator may have permission to update a deployment without being allowed to read business secrets. A pod may use a supported workload identity to reach a service while another namespace is blocked. The security engineer must know which control applies to a user, control plane, runtime process or network connection.
For a fictional AKS service, document who can change its manifests, which container image can be pulled, what network connections are required and where its secret dependencies reside. Testing should include appropriate denied cases, but a paper design should not be described as a configured cluster. Microsoft documentation and service versions can alter detailed security feature support.
Registries, Container Apps, and Container Instances
Azure Container Registry holds images that other services retrieve for deployment. Registry access should be scoped to identities and tasks; a build system pushing images needs different privileges from a runtime that only pulls approved artifacts. Image versioning, signing or verification practices and repository separation can support supply-chain trust, depending on supported features and workflow. A registry’s network access settings also deserve review rather than assuming authentication alone covers every exposure.
Azure Container Apps and Azure Container Instances offer different managed container execution experiences from full AKS administration. Their host platform reduces some infrastructure burden, but the organization still selects identities, container settings, network access, secret handling and service dependencies. Do not transplant AKS-only instructions directly into another Azure container product as if the management surface were identical.
The practical SC-500 question is what boundary can be configured for the selected hosting service. A serverless container workload might need an identity for a protected queue and must not expose internal endpoints publicly. If the chosen platform cannot satisfy a specific isolation requirement, architecture selection itself becomes part of the security decision.
Functions, Logic Apps, and App Service have distinct exposure paths
Azure Functions executes code in response to triggers, and authentication and networking choices depend on the function app and hosting plan. A scheduled function may need no public inbound business endpoint at all. A function that receives HTTP requests should use appropriate authentication and upstream controls. A valid function key or other application-level mechanism is not a substitute for authorization when sensitive customer operations are involved.
Logic Apps coordinate workflows through connections and managed actions. A workflow connector might have access to a mailbox, storage account or business record system; that permission can become more significant than the workflow’s own public endpoint. Review connection identities and permitted actions. Avoid assuming a low-code workflow is harmless because its diagram contains no traditional server processes.
Azure App Service supplies managed hosting, but the application team still owns input validation, backend authorization and a protected release process. Hosted code should use a narrowly scoped workload identity for the specific backend operations it performs rather than distribute shared credentials across deployment settings. A managed hosting platform does not automatically prevent overbroad data access.
WAF and API Management enforce different request boundaries
A web application firewall can inspect supported HTTP traffic and apply protections against common web attack patterns at the configured edge or gateway. It should be tuned to actual application behavior so that useful requests are not routinely blocked and the deployment path is covered. A WAF cannot decide which authenticated customer is allowed to update a particular database row unless the application and its supporting systems implement that business rule.
API Management can provide a gateway and policy surface for supported backend APIs. Common concerns include client authentication, routing, service protection and usage policies. If traffic can bypass the gateway and reach the backend directly, the assumed enforcement boundary may be incomplete. A gateway policy is also not proof that a downstream identity has only necessary data privileges. The layers should agree about caller identity and intended permission.
Consider an API that takes orders. The WAF addresses applicable web-request risk, API Management enforces configured gateway policy, the application validates each order, and storage or SQL permissions govern data operations. A useful design test traces one request across all four layers. If the API returns an authorization denial, first determine which boundary denied it rather than disabling all web protections to “fix” the response.
Review one application end to end
A defensible app-platform review covers the artifact, deployment identity, hosting configuration, inbound network route, connected services, runtime monitoring and recovery plan. The workload owner should explain what changes when a new image or function version is released, whether permissions expand, and where evidence of failure appears. Vulnerability reports, platform diagnostics and security alerts can complement one another but cannot be treated as identical measurements.
Compare an AKS deployment with an App Service or Container Apps implementation. Both may serve an HTTPS endpoint, yet the operator has different configuration responsibility in each. Select controls supported by the specific platform instead of writing one generic checklist that could fit anything. The surrounding Azure network security decisions and Defender for Cloud posture still affect the app, but this article focuses on securing its deployment and request-facing services.
For SC-500, the useful test is whether an engineer can name the asset being protected, identify the correct control plane and explain how to verify a configuration without claiming an unexecuted lab succeeded. That level of specificity is a better measure of knowledge than a long catalog of service names.
For an AKS example, compare a deployment identity that can create Kubernetes resources with a workload identity that only reads its own Key Vault secret. The first operates against the cluster management plane, while the second authenticates from the running application to an external data service. Giving the pod the deployer’s broad privileges would collapse an important boundary. The engineer can review Kubernetes role assignments, service account relationships, Azure role scope and intended egress to demonstrate that compromise of one container would not automatically grant administrative access to every cluster or subscription resource.
Application edge controls need testing against legitimate business actions as well as malicious inputs. A WAF rule might reject malformed requests, while an API Management policy requires an approved token and the backend enforces customer-level authorization. A 403 response alone does not tell the operator which layer rejected the request. A safe change review records the exact endpoint, test identity, expected gateway behavior and application diagnostic evidence. This prevents developers from disabling effective edge protection to fix a backend role or token problem.