SC-500 notes: implement, verify, and troubleshoot

Trace the identity before changing its permissions

For a failed request, record the tenant, calling principal, target resource, operation, and scope. A user, service principal, and managed identity are different callers. An app registration describes an application; its service principal represents that application in a tenant. Delegated API access acts with a signed-in user, while application permissions support an app acting without that user. Review consent as well as permissions declared on the registration. Removing a secret from a repository does not revoke credentials already copied by another party.

System-assigned managed identities follow the lifecycle of their Azure resource. User-assigned identities can be attached to multiple supported resources and have an independent lifecycle. Reuse can simplify deployment but also increases the impact of excessive permissions. Give the actual runtime identity the minimum target data role; a deployment identity and an application identity need not share access.

Conditional Access is not a first-match firewall

All applicable enabled policies must be satisfied; an applicable block prevents access. Moving an MFA policy above a block policy does not override the block. Use report-only evaluation, sign-in logs, and a pilot group before broad rollout. Test emergency access separately and monitor its use. PIM eligibility alone does not remove an inherited permanent assignment. Review direct assignments, group membership, and parent scopes when privilege survives an activation window.

Further reading: Conditional Access evaluation.

Separate management, secret access, and network access

A deployment can manage a vault without being allowed to read secret values. In the RBAC permission model, Key Vault Contributor manages the resource; a data role such as Key Vault Secrets User permits the appropriate secret operation. Check the configured authorization model before assigning roles. Under the legacy access-policy model, a principal with vault write permissions can modify access policies and potentially grant itself data access. This is a reason to prefer RBAC and tightly control assignment authority.

Networking is a separate gate. An identity with a correct role can still fail if the vault hostname resolves to the wrong endpoint or the public firewall rejects its source. Diagnose the response and DNS path before granting broader privileges. Likewise, a working private endpoint does not authorize a caller to retrieve a secret.

Rotation and recovery require an application plan

Soft delete supports recovery during retention. Purge protection prevents early permanent removal during that period; it is not a substitute for credential rotation after exposure. Secret rotation must update the consuming system or its retrieval behavior. Test how the app refreshes cached secrets, whether it pins a version, and how failures are reported. App Configuration may hold a Key Vault reference; the secret value belongs in the vault, and the consuming identity still needs access.

Further reading: Key Vault access models.

Use the right enforcement layer

RBAC answers which caller can perform an operation at a scope. Azure Policy checks configuration against assigned requirements. A deny effect can reject a noncompliant change, but does not automatically repair every existing resource. For supported modify or deployIfNotExists policies, investigate the remediation task and the assignment identity's permissions. An exemption needs a defined scope, owner, reason, and review date; a green dashboard is not useful if broad exemptions hide the risk.

Resource locks govern management operations. A CanNotDelete lock on a storage account does not prevent an authorized client from deleting blobs through the data endpoint. Protect data with its own authorization, recovery, and retention controls. Review inherited locks before troubleshooting a failed deployment, and use change control rather than removing a lock without understanding its purpose.

Protect recovery as well as production

Backups are an attack target. Separate backup administration from authorization of destructive operations with Resource Guard and multiuser authorization where supported. Evaluate soft delete and vault immutability against recovery requirements. Locking immutability can be irreversible, so test retention and restore procedures before making that decision. An isolated practice subscription is the appropriate place to explore these settings. A backup job marked successful is not proof that the organization can restore within its recovery objective.

Further reading: Policy remediation, resource lock boundaries, and backup protection.

Match database controls to the risk

Encryption at rest, encrypted transport, authorization, auditing, and threat detection solve different problems. TDE protects stored database files; it does not prevent an already authorized account from querying a table. TLS protects the connection. Database permissions decide which statements a principal may execute. Audit records provide evidence, while Defender alerts identify potentially suspicious activity. Enabling one layer does not make the other layers unnecessary.

A SQL public firewall rule allowing every IPv4 address expands network reachability, but does not make database data anonymously readable. Do not describe a networking mistake as automatic authentication bypass. Prefer narrowly scoped connectivity and Entra authentication where the workload supports it. Check the database user and grants after proving that the client reaches the intended endpoint.

Build an audit trail that survives the incident

Before claiming that an investigation can reconstruct a destructive statement, verify that the required audit events were captured, the destination was reachable, and the time window was retained. Protect the destination against tampering and restrict access to sensitive query text. Turning auditing on today cannot recreate missing records from last week. Use a harmless test operation in a lab database to confirm delivery, time stamps, principal identity, and retrieval. SQL Database and Managed Instance have different network deployment models, so do not blindly transfer endpoint instructions between them.

Debug one layer at a time

Start with the destination hostname and the IP returned from the affected client. Next inspect the route and next hop, subnet and NIC rules, service firewall, TLS connection, and application authorization. A successful DNS lookup proves only name resolution; it does not prove an allowed flow. A 403 response is not sufficient evidence that an RBAC role is missing. Changing identity permissions cannot fix a public DNS answer when the service only permits a private path.

NSG rules use priorities and stateful flow handling. If both subnet and NIC NSGs apply, the flow must be allowed through both. ASGs simplify rule membership; they do not filter traffic independently. Use effective security rules and IP flow diagnostics for the relevant source, destination, protocol, and port. Check effective routes too: a permissive rule cannot compensate for an incorrect next hop.

Centralized inspection needs a proven route

Putting Azure Firewall in a hub does not force every spoke flow through it. Validate routes, forwarding, peering, and the return path. Private endpoint traffic has its own routing and network-policy considerations; do not assume a generic default route inspects every such flow. WAF focuses on HTTP application attacks. Azure Firewall supports network and application filtering across a wider traffic boundary. API Management validates and governs API calls. These controls can complement each other.

For VPN and Entra Private Access, identify whether the requirement is network connectivity or identity-aware access to selected applications. Validate the supported client, connector, authentication, and routing design instead of assuming the products are interchangeable.

Reachability, elevation, and operating-system protection

Bastion provides a managed connection path; PIM controls eligible administrative roles; JIT limits network access windows. These are three different layers. A VM may have a private address and still use JIT, provided an authorized client has a private route to it. Conversely, a successful JIT request does not establish VPN connectivity, authenticate to the operating system, or grant a local administrator role.

Trusted launch features address the boot chain and integrity of supported VMs. Disk encryption protects stored data. Neither replaces patching, endpoint protection, or privileged-access review. Machine Configuration helps assess and, where configured and supported, remediate OS settings. Investigate whether a finding indicates assessment-only behavior, failed remediation, or a workload that legitimately needs a documented exception.

Verify coverage on each kind of machine

Azure Arc connects supported non-Azure servers to Azure management. It does not automatically enable every paid Defender feature. Check the selected plan, onboarding status, endpoint integration, and vulnerability assessment freshness. Agentless machine scanning uses supported cloud infrastructure in Azure, AWS, and GCP; an arbitrary on-premises machine does not gain this disk-scanning capability merely by installing Arc. Snapshot-based findings also do not replace runtime EDR. In a lab inventory, record the expected protection method for each machine rather than counting only successful Arc registrations.

Further reading: JIT network access and agentless scan coverage.

Secure deployment and runtime independently

For AKS, separate API-server access, Kubernetes authorization, workload identity, image retrieval, and pod-to-pod traffic. Restricting the API server does not decide which application can query a database. A clean image scan does not prove that a running container is uncompromised. Review runtime detections alongside registry permissions, image provenance, and the privileges a pod actually receives.

For App Service and Functions, distinguish inbound private access from outbound virtual network integration. Outbound integration is not proof that anonymous internet callers cannot invoke the app. Configure authentication and authorization, verify the supported hosting plan's networking features, and test the public and private endpoints separately. If a front-end gateway is mandatory, validate that direct access to the backend cannot bypass it.

Logic Apps and container platforms also need protection for connection credentials, workload identities, and network paths. Keep secrets out of deployment templates and pipeline output. Review a workflow's run history for sensitive data exposure before assuming that only the original data store matters. In a test environment, intentionally send an unauthorized request and verify a denial at the expected boundary. A screenshot of an enabled feature is weaker evidence than a reproducible allowed-and-denied test.

Follow the telemetry from source to incident

Installing a Content Hub solution supplies content; it does not automatically configure every connector or enable every analytics rule. Trace a known test event through the source, collector or connector, data collection rule, destination table, query, and detection. For Windows events, verify the source audit policy as well as the collection filter. For CEF, validate the device format and forwarding path. A missing event may have been filtered before ingestion rather than lost by the SIEM.

Check retention per table and data store against investigation requirements and cost. Increasing retention cannot restore data already expired. New retention settings also cannot recreate events that were never collected. Validate time zones, ingestion delay, table schema, and workspace selection before interpreting an empty query as an absence of suspicious activity.

Separate human roles from automation identities

Sentinel Reader can inspect data; Responder can manage incidents; Contributor can manage Sentinel configuration. Running or editing a Logic Apps playbook involves additional permissions. The Sentinel service needs permission to run a playbook from its resource group, and the playbook's connections need permissions for downstream actions. A human analyst's broad role does not automatically transfer to either identity. Test with a harmless action before enabling host isolation or account changes.

Further reading: Sentinel roles and playbook execution permissions.

Validate access and evidence behind an answer

Access to Security Copilot is not an automatic grant to every connected security product. For a failed plugin request, check the workspace role, enabled plugin, selected tenant or workspace, and the user's underlying product permissions. Microsoft plugins can use on-behalf-of authentication. Grant the minimum required access at the source rather than giving organization-wide administrator rights to resolve a single failed query.

Plugins and agents provide integrations and workflows; enabling them does not guarantee correct output. Require an analyst to verify the referenced evidence, time range, and affected asset before acting on a recommendation. If a summary claims there were no incidents, check whether the underlying query actually succeeded and whether the queried data was retained. Missing context, denied access, and a genuinely empty result are different outcomes.

Review custom plugin provenance, permissions, and the data it may send to an external service. Test with synthetic investigation data first. Track the owner of each enabled agent and define what it can do automatically, what requires review, and how failures are investigated. This keeps the learning exercise focused on operational controls rather than assuming that adding AI removes the need for logging and human judgment.

Further reading: Security Copilot plugin access.