Back to Azure Developer Associate (AZ-204)

Implement Azure security

Implement user authentication, authorization, and secure Azure solutions using identity services and Key Vault.

Covers implementing user authentication and authorization using the Microsoft Identity platform and Microsoft Entra ID, creating and implementing shared access signatures, and implementing solutions that interact with Microsoft Graph. Also includes implementing secure Azure solutions by securing app configuration data with Azure App Configuration or Azure Key Vault, developing code that uses keys, secrets, and certificates stored in Key Vault, and implementing Managed Identities for Azure resources.
5 minutes 5 Questions

Implementing Azure security involves multiple layers of protection to safeguard applications, data, and infrastructure in the cloud environment. As an Azure Developer, understanding these security measures is essential for building robust solutions. **Identity and Access Management** Azure Active …

Concepts covered: Create and implement shared access signatures, Authenticate and authorize users using Microsoft Identity platform, Authenticate and authorize users and apps using Microsoft Entra ID, Implement solutions that interact with Microsoft Graph, Secure app configuration using Azure App Configuration or Key Vault, Develop code using keys, secrets, and certificates from Key Vault, Implement Managed Identities for Azure resources

Test mode:
Start practice test
AZ-204 - Implement Azure security Example Questions

Test your knowledge of Implement Azure security

Question 1

Your company operates a regulatory compliance application on Azure Kubernetes Service that manages document attestation workflows for government contract submissions. The application uses Azure Key Vault to store EdDSA (Ed25519) signing keys for creating digital signatures on compliance certificates before submission to federal oversight agencies. The development team has implemented document signing by instantiating a KeyClient during pod initialization, calling GetKey() to retrieve the signing key, and then using a third-party cryptographic library to extract the Ed25519 private key parameters from the JsonWebKey object into a custom SigningContext class that persists throughout the pod's lifecycle. This SigningContext holds the raw private key scalar value as a byte array in a private field, and the application invokes signing methods on this context object to generate Ed25519 signatures for each compliance certificate. Each pod processes approximately 280 document signatures per hour during regulatory reporting periods. During a FedRAMP compliance assessment, auditors discovered that when pods are terminated due to node maintenance or cluster scaling operations, Kubernetes captures termination state including memory contents that are forwarded to Azure Monitor Logs and retained for 180 days per the organization's incident investigation policy. These archived memory artifacts contain the extracted Ed25519 private key scalar values in plaintext within the SigningContext object allocations, persisting sensitive cryptographic material outside the Key Vault HSM environment for an extended retention period. The compliance framework mandates that all asymmetric signing operations must execute within the Key Vault cryptographic boundary to ensure private key material never exists in application process memory or any derived diagnostic artifacts. The business requires maintaining sub-90ms signature generation latency per compliance certificate to satisfy federal submission deadline requirements. The application generates 6,720 attestation signatures daily across all pods and contract workflows. What implementation approach should you adopt to satisfy the FedRAMP requirements while maintaining the signature generation latency target?

Correct Answer: Instantiate CryptographyClient with the key identifier URI and invoke SignData() to perform signing operations within Key Vault's cryptographic boundary

The correct approach is to instantiate CryptographyClient with the key identifier URI and invoke SignData() to perform signing operations within Key Vault's cryptographic boundary.

This is the proper solution because:

  1. Maintains Cryptographic Boundary: The CryptographyClient performs all cryptographic operations within Azure Key Vault's HSM environment. The private key material never leaves the Key Vault boundary and is never exposed to application memory, ensuring compliance with FedRAMP requirements that mandate cryptographic operations must execute within the Key Vault environment.

  2. Eliminates Memory Exposure: Since signing operations occur server-side within Key Vault, there are no private key values in pod memory that could be captured during termination or written to diagnostic logs. This completely eliminates the security vulnerability identified by auditors.

  3. Supports Ed25519 Operations: Azure Key Vault supports EdDSA signing algorithms including Ed25519 through the CryptographyClient API, making this approach technically viable for the regulatory compliance use case.

  4. Meets Performance Requirements: While Key Vault operations introduce network latency, the service is designed for production workloads. With proper optimization (connection pooling, async operations), the sub-90ms latency target is achievable for 6,720 daily signatures distributed across multiple pods.

  5. Azure SDK Best Practice: Using CryptographyClient is the Microsoft-recommended approach for cryptographic operations with Key Vault-stored keys, specifically designed to prevent key material exposure.

Why the other approaches fail:

Converting the JsonWebKey to PEM format and loading it into an X509Certificate2 object still extracts the private key into application memory, even if disposed immediately. The key material exists in process memory during signing operations, which means it can be captured in memory dumps, crash dumps, or diagnostic artifacts collected by Kubernetes and Azure Monitor. This violates the fundamental FedRAMP requirement.

Storing extracted key parameters in Azure Cache for Redis creates an even larger security vulnerability by persisting private key material outside the HSM boundary in a shared cache service. This exponentially increases the attack surface and retention risk, directly contradicting the compliance mandate. Additionally, the 60-second expiration doesn't prevent the initial extraction and storage violation.

Using the MemoryProtection API to encrypt the byte array in process memory still requires extracting and holding the private key material in the application's memory space. While encryption adds a layer of protection, the key material has still left the Key Vault HSM boundary and exists in application memory (albeit encrypted). This approach doesn't satisfy the requirement that signing operations must execute within the Key Vault cryptographic boundary, and the encrypted material could still be captured in memory dumps and retained in Azure Monitor Logs.

Question 2

Your company is developing a microservices application on Azure that consists of an Azure Function App that needs to retrieve secrets from Azure Key Vault. The security team has mandated that no credentials should be stored in application code or configuration files. The development team has enabled a system-assigned managed identity on the Function App. However, when the application attempts to access Key Vault secrets, it receives an authorization error. What is the most appropriate action to resolve this issue while maintaining the security requirements?

Correct Answer: Configure an access policy in Azure Key Vault that grants the Function App's managed identity permission to retrieve secrets from the vault

The correct solution is to configure an access policy in Azure Key Vault that grants the Function App's managed identity permission to retrieve secrets from the vault.

Here's why this is the best approach:

The scenario describes a properly configured system-assigned managed identity on the Function App, which eliminates the need for storing credentials. The authorization error occurs because while the managed identity exists, it hasn't been granted the necessary permissions to access the Key Vault secrets.

Azure Key Vault uses access policies (in the classic model) or Azure RBAC to control access to secrets. The Function App only needs to retrieve secrets, so granting specific permissions to GET secrets follows the principle of least privilege - a fundamental security best practice. This approach:

  1. Maintains the security requirement of no stored credentials
  2. Uses the existing system-assigned managed identity
  3. Grants only the minimum necessary permissions (secret retrieval)
  4. Directly addresses the authorization error

Why the other options are not optimal:

The second option grants permissions for ALL secret operations including deletion and purging, which violates the principle of least privilege. The Function App only needs to read secrets, not delete or purge them, making this excessive and potentially dangerous.

The third option assigns the Key Vault Administrator role at the subscription scope, which is far too broad. This would grant comprehensive access to all Key Vault operations across all Key Vaults in the subscription, creating unnecessary security risks and violating least privilege principles.

The fourth option suggests creating a user-assigned managed identity when a system-assigned identity already exists and is sufficient for the task. Additionally, it mentions granting permissions for 'all key operations' when the requirement is specifically for secrets (not keys), and again violates the principle of least privilege by granting more permissions than necessary.

Question 3

Which Azure identity feature provides automatic credential lifecycle management that is bound to a single Azure resource instance and gets removed when that resource is deleted?

Correct Answer: System-assigned managed identity

The correct answer is System-assigned managed identity.

A system-assigned managed identity is specifically designed to have its lifecycle tightly bound to a single Azure resource instance. When you enable a system-assigned managed identity on an Azure resource (such as a VM, App Service, or Function App), Azure automatically creates an identity in Azure AD that is tied exclusively to that resource. The key characteristics that make this the correct answer are:

  1. Automatic credential management - Azure handles all credential lifecycle operations without any manual intervention
  2. Bound to a single resource - The identity cannot be shared across multiple resources
  3. Automatic deletion - When the Azure resource is deleted, the managed identity is automatically removed from Azure AD
  4. No manual cleanup required - This prevents orphaned identities in your Azure AD tenant

Why the other options are incorrect:

User-assigned managed identity with automatic resource binding is not correct because user-assigned managed identities are independent resources that exist separately from the resources they're assigned to. They can be associated with multiple Azure resources and persist even after those resources are deleted. You must explicitly delete a user-assigned managed identity, and it does not get automatically removed when a resource using it is deleted.

Service principal with system-generated client certificate rotation is not correct because service principals are not bound to specific Azure resource instances. While Azure can help with certificate rotation in some scenarios, service principals exist independently in Azure AD and are not automatically deleted when any particular resource is removed. They require manual lifecycle management.

Azure AD application registration with resource-scoped credentials is not correct because application registrations are standalone objects in Azure AD that are not tied to the lifecycle of any specific Azure resource. They persist independently and must be manually managed and deleted. There is no automatic cleanup when resources are deleted.

More Implement Azure security questions
382 questions (total)
Start 100 question test