AZ-204 Implement Azure security Practice Question
Which FOUR of the following are true regarding Microsoft Entra ID authentication for Azure Storage?
⚠ Common exam trap
Candidates may mistakenly think that enabling Microsoft Entra ID authentication automatically disables Shared Key authorization, but in fact Shared Key access remains enabled by default unless explicitly disabled via the 'AllowSharedKeyAccess' property.
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
✓
RBAC roles can be used to grant permissions to a user or service principal.
Option B is correct because Azure Storage supports Azure RBAC roles such as Storage Blob Data Reader, Storage Blob Data Contributor, and Storage Blob Data Owner, which can be assigned to users, groups, service principals, or managed identities to grant data-plane permissions. Option C is correct because enabling Microsoft Entra ID authentication does not disable Shared Key authorization; unless the storage account is explicitly configured to disallow Shared Key access (for example, by setting AllowSharedKeyAccess to false), Shared Key remains enabled by default. Option D is correct because managed identities for Azure resources let applications authenticate to Azure Storage without storing credentials in code or configuration, since the identity is managed by the Microsoft Entra ID and Azure platform. Option E is correct because Microsoft Entra ID authentication to Azure Storage uses OAuth 2.0 access tokens issued by Microsoft Entra ID, which are presented to the storage service to authorize data-plane requests. Option A is not correct because SAS tokens are still supported alongside Microsoft Entra ID authentication; SAS is a separate authorization mechanism, and user delegation SAS can even be secured with Microsoft Entra ID credentials.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
SAS tokens are not supported when using Microsoft Entra ID authentication.
Why it's wrong here
SAS tokens remain fully usable alongside Microsoft Entra ID; the two are independent authorisation mechanisms, so this claim is false. It tempts candidates because Entra ID is often contrasted with shared-key access, but SAS delegation is orthogonal to OAuth 2.0 token authentication and does not conflict with it.
- ✓
RBAC roles can be used to grant permissions to a user or service principal.
Why this is correct
Azure RBAC roles assign storage data-plane permissions to a user or service principal through Microsoft Entra ID, satisfying the stem's requirement that Entra ID authentication governs access. Role assignments scope to subscription, resource group, storage account, or container, letting the same identity receive least-privilege access without sharing account keys.
- ✓
When Microsoft Entra ID authentication is enabled, Shared Key authorization is still allowed by default.
Why this is correct
Shared Key authorisation remains enabled unless you explicitly disable it with `AllowSharedKeyAccess = false`; enabling Microsoft Entra ID does not remove it. This satisfies the stem's requirement that the statement be true: both schemes coexist by default, so Entra ID alone never forces Shared Key off.
- ✓
Managed identities can authenticate to Azure Storage without storing credentials.
Why this is correct
Managed identities give the App Service or VM an identity in Microsoft Entra ID, so the platform requests and rotates the OAuth token internally. No connection string, account key or secret is stored in code or configuration, satisfying the credential-free authentication requirement.
- ✓
The authentication process uses OAuth 2.0 access tokens.
Why this is correct
Microsoft Entra ID authorisation for Blob, Queue, Table and File endpoints issues OAuth 2.0 bearer tokens scoped to the storage resource. Clients present that token in the Authorization header, and Storage validates it, rather than verifying a shared account key signature.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
One of 883 original AZ-204 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 AZ-204 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 AZ-204 exam.