A deployment pipeline passes its build checks and publishes an image to Azure Container Registry. The production cluster pulls the image, the application becomes healthy, and an operations dashboard reports green. Two weeks later, a vulnerability report shows that an earlier image layer contains a known issue, while a compromised pod could reach an internal service through a network path that was never intended. Successful deployment and service health say very little about the protection of the software supply chain or runtime. The Microsoft SC-500 exam treats Kubernetes, registries and Defender for Containers as parts of an end-to-end compute security responsibility.
VM and container security requires reliable baselines for approved images, registry access, runtime identity and monitoring. Follow one container from its build artifact through the registry, AKS admission, network access, threat monitoring and remediation. At each transition, ask who may introduce code, which credentials a pod receives, which services it can reach and how operators verify that a running workload still matches its approved image and policy.
Inventory where images enter the environment
An application image is assembled from a base, language dependencies, build scripts and application code. Each layer can introduce vulnerabilities or unauthorized content. Security engineers should identify which registries and namespaces are approved, who may push or overwrite tags, what constitutes a trusted build and whether production deploys by mutable tag or immutable image digest. A green CI job does not prove that the image deployed in production matches the artifact reviewed during the build. Prefer provenance that can be reconciled with an exact deployed digest.
In a release exercise, deploy the expected image and record its digest and workload owner. Then attempt a release with a tag unexpectedly pointing to a different digest. The system should detect the drift or prevent the change according to policy. Scanning is an important input, but a report produced before a new vulnerability was disclosed can become stale. Regularly reassess the images that actually run, not only those most recently uploaded, and document who accepts or fixes a finding that cannot be addressed immediately.
Use registry access as an independent security boundary
Azure Container Registry permissions should follow distinct jobs: build agents can push to approved repositories, deployment identities can pull what they need, and routine application workloads should not inherit registry administration privileges. Network restrictions and private access can further reduce unwanted exposure but do not replace identity-based authorization. Avoid embedding registry secrets in pipeline YAML or copying the same high-privilege credential between clusters. Establish rotation and revocation procedures for any secret-based integration that cannot use a safer identity pattern.
An environment with dev, staging and production subscriptions may require different registry reachability and image promotion rules. Define when a digest becomes deployable to production and who can override a failed security gate. Use an explicit break-glass path rather than a permanent Owner assignment held by the deployment robot. The identity distinction in Entra ID and PIM also applies to engineers who can alter registry configuration or assign permissions to a powerful automation principal.
Scope Kubernetes authorization separately from Azure roles
Azure RBAC and Kubernetes authorization can interact through supported integration, but their resource scopes and enforcement layers should not be collapsed into one mental model. A person who can edit an Azure resource definition does not necessarily need permission to enumerate all secrets in a Kubernetes namespace. A CI service that deploys a named workload should not have broad permission to change cluster-wide admission or security policy. Map administrator, workload-deployer, namespace-owner and incident-responder duties before assigning roles.
In a cluster review, test a team member’s permissions against a normal rollout and a deliberately forbidden command such as reading a secret from another team’s namespace. Check the effective permissions through the Kubernetes API as well as the Azure side. Restrict service-account tokens and avoid unnecessarily mounting sensitive credentials in pods. Apply Kubernetes RBAC design to namespace scoping and escalation paths; the SC-500 security engineer must then connect those controls to Azure’s surrounding infrastructure.
Prefer workload identity over distributed service secrets
An AKS workload often needs Azure Storage, Key Vault or a service API. With a supported workload identity design, the application can obtain scoped credentials without placing a broadly reusable cloud secret in its environment variables or repository. The relationship between the Kubernetes service account, federated credential, Entra application or managed identity, token audience and target resource permission must be configured correctly. A token exchange succeeding does not itself prove that the application is authorized to read an unrelated secret.
Suppose one pod writes processed invoices to storage. Give it the appropriate data-plane role for only the intended container or account scope, and deny a sibling pod that tries to use the same permission. If multiple workloads share one high-power managed identity, the blast radius can defeat the value of separate namespaces. Key Vault security requires testing both the caller’s identity and the vault’s authorization and network rules; network reachability alone must not grant a pod permission to retrieve another workload’s secrets.
Segment pod-to-pod and egress traffic deliberately
Clusters often begin with permissive network connectivity because early developers need working service discovery. Production policy should instead reflect service-to-service dependencies and deny paths that are not required. Apply supported AKS networking and network policy controls appropriate to the chosen CNI and deployment architecture; different networking models can have different policy capabilities. Validate DNS and platform dependencies as part of restrictions, rather than assuming that denying all egress is operationally safe without a dependency inventory.
For a payment API, draw an allowed path from ingress through the application to its backing store and an explicitly denied path from an unrelated namespace. Test both from inside actual pods. Network isolation does not replace service authentication: a compromised pod inside the permitted namespace may still attempt unauthorized operations. Network Manager and private access describes broader network boundaries, which complement rather than substitute for Kubernetes workload-level restrictions.
Understand Defender for Containers signals and blind spots
Microsoft Defender for Containers supports posture and protection capabilities such as vulnerability assessment and threat detections for supported registries and clusters, with coverage depending on plan, environment and feature status. An agentless image finding may identify a problem in an image’s dependency layer, while runtime signals can indicate suspicious execution. Neither proves an attacker exploited a vulnerability. Security engineers should connect the registry digest, running workload, relevant package, network exposure and business criticality before deciding how urgently to act.
Suppose a scanner reports a critical issue in a library embedded in an image that appears unused by the application. Validate the version, actual reachable code path and threat exposure rather than dismissing or blindly escalating solely by severity. If the cluster is publicly reachable or the workload runs with broad cloud privileges, the same issue can deserve more urgent treatment. Defender CSPM attack-path analysis helps connect registry and compute weaknesses to network and identity relationships that change real exploitability.
Secure policy admission, node posture and the workload lifecycle
Pod security controls, trusted images, resource limits, read-only file systems when appropriate, non-root execution and managed node patching all reduce the impact of compromise. Apply those as tested baselines rather than a checklist that breaks ordinary application needs without a migration path. Review admission configuration and policy exclusions: a namespace or service account permanently excluded for convenience becomes an attractive attack entry point. Keep policy definitions versioned, and ensure that bypasses have accountable owners and expiry dates.
Node security also matters. An application can be correctly configured while the underlying node pool is outdated or the cluster management plane exposes unnecessary privileges. Verify node upgrade practices, credential rotation and the separation between infrastructure administrators and application operators. For containers outside AKS, such as Azure Container Apps or Container Instances, apply the controls actually supported by that platform rather than assuming every Kubernetes policy exists there. The exam expects reasoning across execution environments, not copying the same configuration command to each product.
Teams should also decide how they will retire vulnerable artifacts. Blocking new deployment is only a first step if a controller is still running the old digest on several nodes or a disaster-recovery environment restores the same image after an outage. Inventory deployment histories and registries so the response team can find live consumers of the affected artifact, and coordinate a staged replacement with service owners. Record the corrected digest, rollout status, vulnerability reassessment and permissions after release. Avoid deleting every old image immediately if forensic or rollback evidence must be preserved under an approved retention policy. The goal is to end exposure while keeping the change explainable, not simply to make the scanner dashboard show fewer rows.
Respond to a vulnerable or compromised image without losing control
When a runtime alert coincides with a vulnerable deployed image, preserve the image digest, deployment manifest, evidence, relevant process or network signals, and the identities involved. Determine whether the right immediate action is blocking further deployment, revoking a workload credential, restricting egress, replacing the workload or isolating a namespace. A rollback to a prior image is not safe if that earlier digest contains the same vulnerable component. Likewise, deleting a pod alone is not remediation if the controller promptly starts the same image again.
Release the repaired image in stages and verify that authorized traffic still works while the previously exploitable path is blocked. Retain the image digest, changed dependency, identity assignment, network decision and runtime telemetry as review evidence. A fresh deployment is not itself remediation: the earlier weakness may return through an unchanged controller, a copied secret or a permissive namespace.