Fundamental
Prepare and test your skills
Fundamental
Prepare and test your skills
How Managed Identities Remove Stored Credentials
Free sample question, answered and explained below. The AZ-900 Microsoft Azure Fundamentals Exam practice bank has 688 more like it. Try 10 free: instant score, no account.
An organization is modernizing its cloud infrastructure to align with the Zero Trust security model. The security team wants to ensure that cloud-hosted applications can authenticate to Azure services without storing access keys, connection strings, or static credentials in application source code or configuration files.
Which feature should the organization implement to provide secure, platform-managed identity authentication?
Explanations
Managed identities in Microsoft Entra ID
Managed identities in Microsoft Entra ID
What Managed Identities Are
Managed identities are a feature of Microsoft Entra ID that provide Azure services with an automatically managed identity in the cloud directory. They allow applications running in Azure to authenticate to resources that support Microsoft Entra authentication without needing developers to manage or store credentials.
How Managed Identities Meet the Requirements
- Eliminates hardcoded credentials: With managed identities, applications do not require connection strings or access keys stored in source code or configuration files.
- Aligns with Zero Trust: By leveraging Microsoft Entra ID authentication and Azure role-based access control (Azure RBAC), access is explicitly verified and granted according to the principle of least privilege.
- Automated lifecycle: Azure automatically manages the creation, rotation, and retirement of underlying identity credentials, significantly reducing operational overhead and the risk of credential leakage.
Key Advantages and Capabilities
- Credential protection: Eliminates the exposure of secrets in deployment scripts, code repositories, or configuration settings.
- Azure RBAC integration: Seamlessly assigns granular permissions to security principals, ensuring precise authorization boundaries.
- Seamless authentication: Enables secure connections to supported Azure resources such as Azure Storage, Azure Key Vault, and Azure Communication Services.
- Reduced management burden: Eliminates manual credential rotation tasks and associated potential service outages.
Why This Is Optimal
Managed identities represent the gold standard for service-to-service authentication in Azure within a Zero Trust architecture. Compared to static keys or connection strings, managed identities ensure that identity verification is strictly handled by the identity platform, fully mitigating credential theft vectors.
Shared access signatures (SAS)
Shared access signatures (SAS)
What Shared Access Signatures Are
Shared access signatures (SAS) are signed URI tokens that grant delegated, time-limited access to specific resource endpoints without exposing master access keys.
Why They Do Not Meet the Requirement
- Still relies on key distribution: While SAS tokens can restrict permissions and include expiration times, applications must still generate, distribute, and handle tokens or use master keys to sign them.
- Does not provide managed identity: SAS tokens do not grant a platform-managed identity in Microsoft Entra ID, meaning the platform does not automatically manage and rotate the client credential for the application.
- Potential credential sprawl: If mismanaged, long-lived SAS strings can still be leaked or exposed in code and configuration files.
Key Characteristics and Limitations
- Token-based delegation: Grants specific permissions (e.g., read, write) for a specified duration.
- Signed with access keys: Underlying validation relies on cryptographic signing using service access keys.
- Not an identity principal: Does not integrate natively with Azure RBAC role assignments for service authentication.
When This Option Would Be Appropriate
Shared access signatures are ideal for granting temporary, granular access to external clients or services that cannot authenticate directly through Microsoft Entra ID.
Access keys embedded in connection strings
Access keys embedded in connection strings
What Access Keys Are
Access keys are long-lived shared secrets generated by specific Azure services that grant full or administrative access to resource APIs when included in a connection string or request signature.
Why They Do Not Meet the Requirement
- Requires secret storage: Using access keys directly contradicts the requirement to avoid storing secrets, connection strings, or credentials in application code or local configurations.
- Violates Zero Trust principles: Access keys typically provide broad, account-wide permissions rather than granular, least-privilege role assignments.
- Increased risk of exposure: Hardcoded access keys are vulnerable to accidental leaks in source code repositories, CI/CD pipeline logs, and client binaries.
Key Characteristics and Limitations
- Shared secret model: Anyone in possession of the key has access to the underlying service.
- Manual rotation required: Rotating access keys requires coordinated application updates to prevent service downtime.
- Lacks individual identity tracking: Does not map actions to an individual security principal in Microsoft Entra ID.
When This Option Would Be Appropriate
Access keys may be used in legacy or development architectures running in trusted environments where native Microsoft Entra ID integration is unavailable.
Dynamic distribution lists
Dynamic distribution lists
What Dynamic Distribution Lists Are
Dynamic distribution lists are mail-enabled group objects used primarily in email services (such as Exchange Online) where group membership is calculated dynamically based on specific user attributes and filters.
Why They Do Not Meet the Requirement
- Not an authentication mechanism: Dynamic distribution lists are designed for message delivery and communication, not for authenticating application workloads to Azure services.
- Directory replication limitations: Dynamic distribution lists are not synchronized to Microsoft Entra ID as standard security groups and cannot be used for Azure RBAC or resource authorization.
- Irrelevant to credential management: They offer no functionality for eliminating connection strings or managing workload credentials.
Key Characteristics and Limitations
- Dynamic recipient filtering: Membership changes automatically based on recipient criteria (e.g., department or location).
- Messaging focus: Exclusively used for sending emails to collections of users.
- Incompatible with Azure access control: Cannot be assigned Azure roles or used in access control lists for cloud infrastructure.
When This Option Would Be Appropriate
Dynamic distribution lists are appropriate when an organization needs to send email communications to groups of users whose membership changes frequently based on directory attributes.
Try 10 interactive questions like this one, free
Answer them yourself and get your score the moment you finish. No account needed.
Full access includes
- 688 practice questions across all 3 exam domains
- Every answer explained: why it is right, and why the others are not
- Scout, an AI tutor that answers your follow-up questions
- Readiness tracking by domain, so you know when to book the exam
Related questions
Keep the momentum going with these hand-picked practice scenarios
FundamentalAZ-900 Microsoft Azure Fundamentals Exam
Zero Trust Least Privilege Access
Describe the concept of Zero Trust
FundamentalAZ-900 Microsoft Azure Fundamentals Exam
Microsoft Entra ID Protection
Describe the concept of Zero Trust
FundamentalAZ-900 Microsoft Azure Fundamentals Exam
Zero Trust Least Privilege Just-In-Time Access
Describe the concept of Zero Trust
FundamentalAZ-900 Microsoft Azure Fundamentals Exam
Microsoft Entra Conditional Access
Describe the concept of Zero Trust
FundamentalAZ-900 Microsoft Azure Fundamentals Exam
Azure Managed Disks
Describe the resources required for virtual machines
AdvancedAZ-104 Microsoft Azure Administrator Exam
Availability Zones High Availability
Deploy virtual machines to availability zones and availability sets
Last updated Validated