SC-100 Practice Question: Design security solutions for applications and data
You need to design a secure solution for a web application that authenticates users via Microsoft Entra ID and calls a downstream API. Which TWO should you implement to secure the application? (Choose TWO.)
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use the OAuth 2.0 authorization code flow with PKCE.
Option A is correct because the OAuth 2.0 authorization code flow with PKCE is the recommended pattern for interactive web applications that sign users in through Microsoft Entra ID and then call a downstream API on the user's behalf; PKCE protects the authorization code exchange against interception, and the resulting access token is presented to the API. Option B is correct because confidential client applications still need credentials (client secrets or certificates), and Azure Key Vault provides centralized, access-controlled, audited storage for those secrets instead of leaving them in code or config. Option C is wrong because storing secrets in app configuration files exposes them to anyone with file or repository access and is not a secure secret-management practice. Option D is wrong for this scenario because the client credentials flow is a daemon/app-only flow with no user context, so it cannot authenticate interactive users. Option E is wrong because shared access signatures are an Azure Storage authorization mechanism, not an authentication protocol for a Microsoft Entra ID-protected web API.
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 the OAuth 2.0 authorization code flow with PKCE.
Why this is correct
The OAuth 2.0 authorization code flow with PKCE is the recommended authentication flow for web applications that need to authenticate users and obtain access tokens for downstream APIs. It provides proof of possession and mitigates interception attacks.
- ✓
Store application secrets in Azure Key Vault.
Why this is correct
Storing application secrets in Azure Key Vault is the correct choice because Key Vault is a dedicated cloud secret store with hardware security module (HSM) support. It provides central management of connection strings, API keys, and certificates with granular RBAC, managed identity integration, automatic key rotation, and full audit logging. Secrets never reside in source code or configuration files, which eliminates a common vector for credential leakage.
- ✗
Store application secrets in app configuration files.
Why it's wrong here
Storing application secrets in app configuration files is wrong because these files are typically plain text and are frequently committed to source control, embedded in build artifacts, or copied to backups. They lack access control, audit trails, and rotation capability, so anyone with read access to the repository or deployment package can extract the credentials. A single misconfigured web server directory listing can also expose the entire configuration.
- ✗
Use the OAuth 2.0 client credentials flow.
Why it's wrong here
The OAuth 2.0 client credentials flow is wrong for this scenario because it authenticates the client application itself (a service principal) with no end-user presence or consent. In a web application that needs to access resources on behalf of a signed-in user, the flow must carry user identity and consent, which is exactly what the authorization code flow with PKCE provides. Client credentials would make every request indistinguishable across users and could over-grant permissions to the application's service principal.
- ✗
Use shared access signatures (SAS) for API authentication.
Why it's wrong here
Using shared access signatures for API authentication is wrong because a SAS is a delegated URI that grants limited time-bound permissions to a specific Azure Storage account resource, such as a blob or queue. It is not a general-purpose authentication token for an arbitrary web API and cannot establish a caller's identity or authorization claims across different services. SAS tokens can leak through URLs in logs, and their revocation is impractical at a per-user level, making them unsuitable as an API credential.
Go deeper
Related to this question
About these practice questions
One of 605 original SC-100 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SC-100 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SC-100 exam.