SC-500 Storage, SQL and Network Security Labs

The largest domain on Microsoft SC-500 is Secure storage, databases, and networking, weighted at 25–30%. It is also an area where a security engineer can choose several individually correct controls and still build a weak system. A storage firewall can restrict a route without granting data permission. Azure SQL auditing can record activity without blocking it. A private endpoint can give an application a private path while the application’s identity remains overprivileged.

This article uses four small, realistic investigations to show how those controls fit together. It builds on the existing storage and database protection and Azure networking controls explanations. The aim is to reason from a specific security requirement to the relevant configuration and evidence, not to memorize a list of Azure portal screens.

Use a permitted Azure lab with synthetic data only. Some steps involve policy that can block access, and some networking services have running costs. Design test identities, a rollback path and appropriate resource isolation before making changes. If you cannot deploy a resource safely, reproduce the decision path from Microsoft documentation and record the expected test rather than pretending a change ran successfully.

The security engineer’s first diagram

Before changing anything, draw a request path. A workload receives a user request, obtains a token or other credential, resolves a service name, traverses a network path, reaches an Azure Storage or SQL endpoint, and performs a permitted action. Put each control at its actual location: user sign-in and workload identity, API authorization, subnet or network policy, firewall, PaaS network setting, data-plane permission, detection and logging.

Then mark the failure described by the scenario. Is the requirement “no internet route,” “only this team can read a container,” “detect malicious database access,” or “explain why connectivity fails”? Each maps to a different control. If a question mentions all of them, address the relevant layer in order. A single private endpoint should not receive credit for satisfying encryption, authorization, auditing and threat detection at once.

Lab one: protect a storage account without overprivileging the app

Imagine a support application that must read invoice PDFs from a particular blob container. Its developer gives the app a storage account key because it works quickly. That key is powerful: a leak can give an attacker broad account access and makes attribution or selective revocation harder. A stronger design commonly uses a managed identity and the narrowest appropriate Storage data-plane role, scoped to the relevant container or resource.

Start by listing the service identity, assigned role, container and required operations. Ask whether the application really needs write, delete or account-management permissions. Test the intended read operation under the application’s identity, then test an operation the application should not be able to perform. A successful Azure portal login by the developer does not prove the workload identity will work, and a resource-group Contributor role is not automatically the correct blob data-plane permission.

Move to network access. Azure Storage’s public endpoint can be protected using firewall rules, but a private endpoint gives a private IP path within an appropriate virtual network. If the client can reach storage over private networking, consider disabling public network access to remove unwanted internet exposure. Check private DNS resolution as well as the network configuration. A private endpoint with incorrect DNS may cause the client to keep using the public name/path and fail unexpectedly.

When supported by dependent clients, disallow Shared Key authorization and use Entra-backed permissions. This can break applications that still rely on account keys, so discover dependencies before enforcing. Note that a storage firewall restricting the public endpoint does not govern the private endpoint in exactly the same way. Network policy is necessary but separate from data authorization, and the client must still present an authorized identity.

Finally, consider Defender for Storage. It adds threat-protection signals for suspicious storage activity, which can aid an investigation. It is not a replacement for access policy or encryption, and enabling the plan does not retroactively prove there were no unauthorized reads. Record the storage account’s network exposure, key configuration, assigned roles, expected detections and a test result for an unauthorized identity.

Lab two: distinguish Azure SQL auditing from prevention

A fictional finance application uses Azure SQL Database. Its administrators want three things: deny access from untrusted networks, limit database permissions and maintain an audit trail for sensitive queries. Start by separating those into network, authorization and logging objectives. A database firewall or private endpoint can restrict reachability. Database users, roles and application identities determine what operations a reachable client may perform. Auditing provides evidence after a configured event occurs.

Configure an approved auditing destination and establish who can read or retain the logs. A useful validation is a harmless query from a test identity and confirmation that the expected event reaches the destination with meaningful context. Do not confuse the appearance of an “enabled” setting with evidence that the destination is receiving all required activity. Misconfigured retention, inaccessible storage, disabled connectors or unexpected filtering can leave an audit gap.

Compare encryption controls carefully. Transparent Data Encryption addresses data at rest; Always Encrypted can protect selected sensitive column values under a different key-handling model. Neither substitutes for least-privilege database permissions or a private network path. For a scenario requiring evidence of suspicious SQL activity, Defender for Databases and database auditing serve complementary detection and forensic purposes; the former generates threat signals while the latter captures configured activity records.

A practical exam problem might ask whether to enable auditing or Defender for Databases when the organization must investigate who changed a privileged table. Ask what detailed record is required. Another might describe an external actor attempting a known suspicious query; relevant threat detection may help, but the correct first defense includes appropriate network and permission controls. The best choice follows the requirement rather than the feature that sounds most security-focused.

Lab three: evaluate Virtual Network Manager before an NSG

Now consider an Azure estate with dozens of virtual networks. The central security team must deny a risky inbound management port across a network group while application teams manage local NSGs. Azure Virtual Network Manager security admin rules support this central approach. They are evaluated before NSGs and can use three important actions: Allow, Always Allow and Deny.

The distinction is deliberate. A central Allow rule permits the traffic to continue to NSG evaluation, where a local rule can still deny it. A central Always Allow rule allows matching traffic without further NSG evaluation. A central Deny rule stops the flow regardless of a later local NSG Allow. The security engineer must understand the priority order and the action semantics, not just the presence of an “allow” line somewhere in the configuration.

Practice with a harmless diagram. A central security admin rule denies TCP traffic to a designated management port from an untrusted source. A local application team’s NSG includes a more permissive rule. Determine whether the flow is allowed. Then change the central action to Allow and ask how the NSG can alter the outcome. Test another case with Always Allow and consider why that option should be used cautiously when local teams need autonomy to restrict their own workloads.

Azure security admin rules have scope and service exceptions; certain managed network environments and network-intent-policy resources are not governed in the same way. Do not assert that a configuration always reaches every private endpoint or specialized subnet. For a real deployment, confirm the chosen network group, region, deployment state, effective policy and service-specific exclusions. Centralized rules can be eventually consistent, so allow for propagation when reviewing a just-changed configuration.

For NSGs, remember that lower numerical priority values are evaluated before higher ones within the relevant rule set. Application security groups can make source/destination groupings more manageable without creating a new independent service firewall. Using those constructs appropriately can reduce maintenance while preserving narrow access between application tiers.

Lab four: troubleshoot Private Link, DNS and effective rules

Suppose a web application cannot reach an Azure SQL or Storage service after a private endpoint is added. A common mistake is to blame the identity or resource firewall immediately. First test name resolution from the application network. Does the service hostname resolve to the intended private IP? If it still resolves publicly, examine the private DNS zone and network linking. If DNS is correct, investigate the relevant network route and policy layers, then check resource authorization.

Private Link brings selected platform resource access onto a private path, but it does not mean that a compromised workload can access only approved data. The platform service still evaluates the request’s credentials and authorization. Network isolation and identity controls should be designed together. A private connection may also break an external integration that depended on a public endpoint; discover such clients and plan a supported alternative before disabling public access.

Azure Network Watcher diagnostics can help inspect effective security rules and connectivity. Use them to ask a specific question about the source, destination, protocol and port. A network diagnostic showing an allowed path narrows the problem; a subsequent 403 may point toward service authorization or a resource-specific firewall rather than NSG evaluation. Conversely, an authorization change cannot make a denied network packet pass through a central security admin rule.

Keep a small troubleshooting record: actual DNS answer, intended private endpoint, effective central and local rules, resource network setting, workload identity and service response. Compare those in an order that follows the request path. This method makes a complex configuration failure much less mysterious and aligns with the exam’s expectation that candidates implement controls and diagnose their consequences.

A full scenario that combines all four labs

A company runs a containerized finance application that reads invoices from Azure Storage and writes metadata to Azure SQL. Security engineers have restricted both services using private endpoints. During a deployment, the app begins returning errors, while Defender raises an alert about suspicious storage activity. Several changes have occurred: a new managed identity, a central network admin rule and a storage-account key restriction.

The engineer should not immediately roll back every control. First isolate the failure path. Check whether the app is using the expected managed identity and whether it has appropriate data-plane roles. Verify that DNS resolves the private service addresses. Determine whether a Virtual Network Manager rule or local NSG is stopping traffic. Inspect whether the app still relies on a Shared Key that has been deliberately disabled. Distinguish the current connectivity failure from the separate Defender alert, which needs its own investigation.

If a storage operation succeeds under the new identity, validate the next stage against SQL permissions. If the app can connect but cannot perform a required database operation, verify the database user and role rather than opening the network to the internet. Audit should help establish which activity occurred, and the incident review should identify whether the storage alert represents actual malicious behavior or a benign change pattern.

That separation gives an engineer a defensible action plan. Each fix has an intended effect, an owner and a way to test it. A secure solution must protect data while maintaining authorized business behavior; otherwise, an overly broad emergency exception can erase the very protection the team was trying to create.

The most transferable SC-500 skill is tracing the control chain. Ask what must be authorized, what network path must be allowed, what configuration prevents unsafe resource behavior and what evidence demonstrates both success and failure. Storage, database and networking security becomes manageable when each layer is understood on its own and then tested as one connected system.