SC-100 Practice Question: Design security solutions for applications and data

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Configure the App Service to use a connection string with a storage account access key.

  Why it's wrong here

  Using a connection string that embeds a storage account access key in the App Service configuration means the key is stored in plaintext within the app settings or connection strings. This approach lacks the principle of least privilege because the key typically grants full access to the storage account, and if the connection string leaks (e.g., via source control or misconfigured deployment), an attacker can exfiltrate or modify all blobs. Access keys also cannot be scoped to a specific container or operation, and rotating them requires updating the application, causing downtime. This is fundamentally a credential-based authentication method, whereas the correct solution uses identity-based access with managed identities.

• ✓

  Configure private endpoints for the SQL Database and Storage account.

  Why this is correct

  Private endpoints for Azure SQL Database and Azure Storage assign each resource a private IP address from your virtual network, ensuring that all traffic to these PaaS services traverses the Microsoft backbone network and never the public internet. This provides strong network-level isolation because the service endpoint is only reachable from your VNet, and you can disable public access entirely, eliminating exposure to internet-based attacks. Private endpoints also support Azure Private Link, which integrates with network security groups, route tables, and on-premises connectivity via VPN or ExpressRoute. Unlike service endpoints, private endpoints give you granular control over which specific resource instances can be accessed, not just the service as a whole.

• ✓

  Configure the App Service to use a system-assigned managed identity.

  Why this is correct

  A system-assigned managed identity for the App Service creates an Azure AD identity that is automatically tied to the app's lifecycle—it is provisioned and deleted with the App Service, and no credentials are stored in code or configuration. This identity can be granted fine-grained roles, such as Storage Blob Data Contributor or SQL DB Contributor, so the App Service authenticates via Azure AD token requests, eliminating the need for access keys, SAS tokens, or connection string secrets. Managed identity also simplifies key rotation and credential management because Azure handles the underlying certificate automatically. This directly addresses the authentication portion of the secure solution, but it must be paired with network-level controls like private endpoints to fully secure the data plane.

• ✗

  Use shared access signatures (SAS) for the App Service to access the Storage account.

  Why it's wrong here

  Shared access signatures (SAS) are delegated access tokens that can be scoped to a specific storage service, container, or blob, but they still require the App Service to store and manage the SAS token, typically in a connection string or app setting. SAS tokens have expiration times and permissions, but managing them across many clients or long-lived applications is error-prone, and if a SAS token leaks, it can be used until it expires unless you have a revocation mechanism. More importantly, SAS does not support automatic rotation or Azure AD-based authentication, and it is not integrated with managed identity, making it a weaker alternative for a cloud-native security posture. For SQL Database, SAS is not even applicable—access keys or Azure AD authentication are the only options—so this choice fails to address the SQL side of the requirement.

• ✗

  Configure service endpoints for the SQL Database and Storage account.

  Why it's wrong here

  Service endpoints expose the Azure SQL Database and Storage account to your virtual network by routing traffic from the VNet to the service over the Microsoft backbone, but they do not assign a private IP to the resource. The service's public endpoint remains active, so the resource is still reachable from the internet if the firewall allows it, and service endpoints rely on route-based controls that are less granular than private endpoints. Service endpoints also do not support blocking exfiltration to other tenants because the service endpoint applies to the entire service, not to a specific resource instance—you cannot isolate a single storage account or SQL database behind a service endpoint. For a zero-trust design, private endpoints are the recommended approach because they provide true private IP connectivity and allow you to disable public access entirely.

Go deeper

Related to this question