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.

• ✓

  Use OAuth 2.0 with Microsoft Entra ID to secure the Azure Functions.

  Why this is correct

  Using OAuth 2.0 with Microsoft Entra ID is correct because it provides robust user authentication and delegated authorization, allowing the mobile app to obtain access tokens that represent the signed-in user's identity. The Azure Functions can then validate these JWT tokens and use claims (such as object ID or roles) to implement fine-grained authorization. This approach supports multi-factor authentication, Conditional Access policies, and token expiry, which are essential for a modern mobile application and align with the principle of least privilege.

• ✗

  Restrict access to the Azure Functions by IP whitelisting.

  Why it's wrong here

  Restricting access to the Azure Functions by IP whitelisting is incorrect because it only filters traffic at the network layer based on source IP addresses, which does not uniquely authenticate an end user. Mobile users typically have dynamic or shared IP addresses, making this approach both impractical and easily bypassed if an attacker connects from an allowed network. IP whitelisting is a complementary security control, but it cannot replace identity-based authentication and authorization, so it fails to provide true defense-in-depth for user-facing APIs.

• ✓

  Configure Azure Cosmos DB with a private endpoint.

  Why this is correct

  Configuring Azure Cosmos DB with a private endpoint is correct because it places the database on a private IP address within your virtual network, fully eliminating exposure to the public internet. This leverages Azure Private Link, so all traffic to Cosmos DB stays on the Microsoft backbone and never traverses the internet, which drastically reduces the attack surface. It is a critical network-level control that complements identity-based authentication, helping prevent data exfiltration and satisfying a defense-in-depth architecture for a mobile back end.

• ✗

  Use function-level authorization keys for the Azure Functions.

  Why it's wrong here

  Function-level authorization keys (host or function keys) are incorrect for securing a mobile app because they are static, shared secrets that are not tied to an individual user. They are designed for service-to-service or low-trust scenarios where a simple API key suffices, and they offer no way to enforce per-user permissions, scopes, or revocation on a per-identity basis. When a mobile app user is authenticating, you need tokens that carry user claims (e.g., OAuth 2.0 access tokens), not a common key that could be extracted and reused from the client.

• ✗

  Enforce TLS 1.0 for all API calls.

  Why it's wrong here

  Enforcing TLS 1.0 for all API calls is incorrect because TLS 1.0 is deprecated and considered insecure due to known vulnerabilities such as POODLE and BEAST, and it fails modern compliance standards like PCI DSS. While TLS 1.2 or TLS 1.3 are required to provide confidentiality and integrity in transit, TLS itself only protects the transport channel; it does not authenticate the caller or authorize their access. Thus, enforcing TLS 1.0 does not contribute to user-level identity security and actually weakens the overall security posture.

Go deeper

Related to this question