This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Secure, monitor, and troubleshoot Azure solutions (20–25%)
   --> Implement secure Azure solutions
      --> Secure secrets by using Azure Key Vault, including rotation and retrieval

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Applications frequently need credentials, API keys, connection strings, passwords, certificates, and other sensitive values to communicate with external services. Storing these values directly in source code, configuration files, or deployment scripts creates unnecessary security risk.

Azure Key Vault provides a centralized service for securely storing and managing secrets, keys, and certificates. For the AI-200 exam, developers should understand how applications authenticate to Key Vault, retrieve secrets, implement least-privilege access, and support secret rotation without unnecessarily interrupting application operations.

A particularly important principle is:

Avoid secrets whenever Azure managed identities can provide passwordless authentication.

When a secret is unavoidable, store it in Key Vault and allow the application to retrieve it securely at runtime.

1. What Is Azure Key Vault?

Azure Key Vault is a managed service designed to protect and manage sensitive information used by applications and Azure services.

Key Vault can store three major types of security objects:

For AI applications, secrets might include:

• Third-party API keys
• Database passwords
• Service credentials
• Storage access credentials
• Application-specific secrets
• Credentials for systems that don’t support Microsoft Entra authentication

A secret should generally be treated as a value that the application needs to retrieve and use, whereas a key is often used by a cryptographic operation.

2. Why Applications Should Not Store Secrets Directly

Consider an application containing:

API_KEY = "abc123..."

Even if the value is stored in an environment variable rather than source code, it can still create security and operational problems.

Potential issues include:

• Accidental exposure through source control
• Exposure through configuration backups
• Difficulty rotating credentials
• Credentials being copied between environments
• Excessive access by developers or deployment systems
• Difficulty auditing access
• Credentials remaining valid longer than necessary

A better architecture is:

Application
    |
    | Microsoft Entra authentication
    v
Managed Identity
    |
    | authorized to read specific secret
    v
Azure Key Vault
    |
    v
Secret value

The application doesn’t need to know a Key Vault password or store another credential simply to authenticate to Key Vault.

Microsoft recommends using managed identities for applications and services accessing Key Vault because they eliminate the need to embed credentials in the application.

3. Authentication vs. Authorization

A common AI-200 exam distinction is the difference between authentication and authorization.

Authentication

Authentication answers:

Who are you?

For example, an Azure Function can authenticate to Azure using its managed identity.

Authorization

Authorization answers:

What are you allowed to do?

After the Function has authenticated, Azure must determine whether that identity is allowed to retrieve a particular Key Vault secret.

Therefore:

Managed Identity
       |
       | Authentication
       v
Microsoft Entra ID
       |
       | Authorization
       v
Azure Key Vault

Both concepts are necessary.

Simply giving an application a managed identity does not automatically give it access to secrets.

The identity must also have appropriate Key Vault data-plane permissions.

4. Managed Identities

A managed identity provides an Azure-managed identity that applications can use to authenticate to services that support Microsoft Entra authentication.

There are two primary types.

System-assigned managed identity

A system-assigned identity is tied to a specific Azure resource.

For example:

Azure Function App
       |
       +-- System-assigned managed identity

If the Function App is deleted, its system-assigned identity is also deleted.

User-assigned managed identity

A user-assigned identity is a separate Azure resource that can be assigned to multiple Azure resources.

For example:

User-assigned identity
       |
       +---- Function App A
       |
       +---- Function App B
       |
       +---- Container App

This can be useful when multiple applications need to use the same identity and permissions.

For many application scenarios, either type can provide passwordless authentication to Key Vault.

5. Azure RBAC for Key Vault

Azure Key Vault supports authorization through Azure role-based access control (RBAC), as well as the older access-policy model.

For new solutions, Azure RBAC is the preferred authorization model.

Key Vault separates management operations from operations involving the actual data stored in the vault.

Control plane

The control plane manages the Key Vault resource itself.

Examples include:

• Creating a vault
• Deleting a vault
• Configuring vault properties
• Managing certain resource-level settings

Data plane

The data plane operates on the contents of the vault.

Examples include:

• Reading secrets
• Creating secrets
• Updating secrets
• Deleting secrets
• Reading keys
• Performing cryptographic operations

This distinction is important because an identity that can manage a Key Vault resource does not necessarily need permission to read secret values.

6. Least Privilege

Applications should receive only the permissions they actually require.

For example, suppose an application only needs to retrieve a secret.

It should not receive permissions to:

• Delete secrets
• Create secrets
• Manage keys
• Manage certificates
• Change Key Vault permissions

With Azure RBAC, the Key Vault Secrets User role provides access to read secret contents. The Key Vault Secrets Officer role provides much broader permissions to manage secrets.

Exam tip

If an application only needs to read secret values, think:

Key Vault Secrets User

If an application needs to manage secrets, a broader role such as:

Key Vault Secrets Officer

may be appropriate.

Don’t automatically choose a highly privileged role simply because it makes the application work.

7. Retrieving Secrets from Key Vault

Applications should normally retrieve secrets programmatically using the Azure SDK.

A common .NET pattern uses:

• SecretClient
• DefaultAzureCredential

Conceptually:

Application
   |
   +-- DefaultAzureCredential
   |
   +-- SecretClient
   |
   v
Azure Key Vault
   |
   v
Secret

For example, a .NET application might use:

var credential = new DefaultAzureCredential();
var client = new SecretClient(
    new Uri(keyVaultUrl),
    credential);
KeyVaultSecret secret =
    await client.GetSecretAsync("MySecret");
string value = secret.Value;

The important architectural point is that the application doesn’t contain a Key Vault password.

DefaultAzureCredential can use an appropriate Microsoft Entra credential depending on the environment. During local development, it can use developer credentials, while an Azure-hosted application can use its managed identity.

8. Secret Versions

Key Vault supports versioning for secrets.

Suppose an application has:

DatabasePassword

The secret might have:

DatabasePassword
 ├── Version 1
 ├── Version 2
 └── Version 3

When a new value is stored, Key Vault creates a new version rather than simply overwriting the existing version in place.

This is extremely useful for rotation.

Versionless retrieval

An application can retrieve the current version of a secret by requesting the secret without specifying a version.

Conceptually:

GetSecret("DatabasePassword")

This allows the application to receive the current version.

Version-specific retrieval

An application can also request a specific version.

Conceptually:

GetSecret("DatabasePassword", "specific-version")

This can be useful when an application intentionally needs a known version.

However, hard-coding a secret version can prevent the application from automatically receiving the newest rotated credential.

9. Secret Rotation

Secret rotation means periodically replacing an existing credential with a new credential.

For example:

Old password
     |
     | rotation
     v
New password

Regular rotation limits the amount of time a compromised credential remains useful.

Rotation is especially important for:

• Database passwords
• API keys
• Service credentials
• Application passwords
• Other long-lived secrets

Azure’s guidance emphasizes minimizing secrets and rotating credentials when they are required.

10. Secret Rotation vs. Key Rotation

Don’t confuse secret rotation with cryptographic key rotation.

Azure Key Vault provides specific automatic rotation capabilities for cryptographic keys.

For secrets, rotation commonly involves an automation process that:

1. Generates or obtains a new credential.
2. Updates the target service.
3. Stores the new credential as a new Key Vault secret version.
4. Causes applications to retrieve the updated value.
5. Eventually invalidates the old credential.

For example:

                +----------------------+
                | Credential Provider  |
                +----------+-----------+
                           |
                           v
                  Generate new secret
                           |
              +------------+------------+
              |                         |
              v                         v
       Target service             Azure Key Vault
       gets new password          stores new version
              |                         |
              +------------+------------+
                           |
                           v
                     Application
                     retrieves new
                        version

Key Vault’s automatic rotation capabilities vary by object type. For secrets, rotation commonly requires integration with the systems that use those credentials rather than simply turning on the same type of automatic key-rotation policy used for cryptographic keys.

11. Zero-Downtime Secret Rotation

A major concern with rotation is avoiding application outages.

Imagine:

Application ---> Database
                 password = OLD

If you immediately disable the old password before the application has started using the new password, requests can fail.

A safer approach is a coordinated rotation process.

Example

Suppose the database supports two valid credentials temporarily.

The rotation process can be:

Step 1 — Create new credential

Database:
    OLD credential
    NEW credential

Step 2 — Store new credential

Key Vault:
    DatabasePassword
       ├── Version 1 = OLD
       └── Version 2 = NEW

Step 3 — Application retrieves the new version

New application instances begin using the new credential.

Step 4 — Verify

Confirm that applications are successfully authenticating.

Step 5 — Revoke old credential

Only after applications have migrated should the old credential be invalidated.

This approach reduces the risk of downtime.

12. Event-Driven Secret Rotation

Polling Key Vault continuously to determine whether a secret needs to be updated is generally inefficient.

Azure Key Vault can integrate with Azure Event Grid to publish events associated with secret lifecycle changes.

Events include notifications related to:

• A new secret version
• A secret approaching expiration
• A secret expiring

For example:

Azure Key Vault
      |
      | SecretNearExpiry
      v
 Azure Event Grid
      |
      v
 Azure Function
      |
      +--> Generate new credential
      |
      +--> Update target service
      |
      +--> Store new Key Vault version

This event-driven pattern can automate credential rotation workflows.

13. Secret Expiration

Secrets can have expiration information.

An application should not assume that a secret remains valid indefinitely.

Key Vault can produce lifecycle-related events such as:

• SecretNearExpiry
• SecretExpired
• SecretNewVersionCreated

These events can be used to trigger monitoring, notification, or automated rotation processes.

Important exam concept

A near-expiry event is not the same thing as automatic secret rotation.

The event can notify or trigger another component, such as an Azure Function, which then performs the appropriate rotation workflow.

14. Retrieving Secrets Efficiently

Applications shouldn’t necessarily call Key Vault every time they need a secret.

For example, consider an API receiving 10,000 requests per minute.

Doing this for every request:

Request
   |
   v
Key Vault
   |
   v
Secret

can create unnecessary network calls and dependency on Key Vault availability.

A better pattern is to retrieve the secret and cache it for an appropriate period.

Application
    |
    +-- Local/in-memory cache
            |
            +-- Secret available?
            |       |
            |      YES ---> use cached value
            |
            +-- NO ---> retrieve from Key Vault

The cache lifetime should be balanced against security requirements and rotation frequency.

A very long cache lifetime could cause the application to continue using an old credential after rotation.

Microsoft’s AI-200 training specifically emphasizes caching patterns that reduce Key Vault API calls while maintaining credential freshness.

15. Handling Rotation with Caching

Suppose:

10:00 AM -> Application retrieves Version 1
10:15 AM -> Secret is rotated to Version 2

If the application caches Version 1 for several hours, it may continue using the old credential.

Therefore, applications should have a strategy for detecting or recovering from credential changes.

Possible approaches include:

Short-lived cache

Refresh the secret periodically.

Event-driven refresh

Use an event such as SecretNewVersionCreated to initiate a refresh.

Retry and refresh

If authentication fails because a credential may have changed:

1. Refresh the secret from Key Vault.
2. Retry the operation.
3. Avoid repeatedly retrying a permanently invalid credential.

The appropriate strategy depends on the application’s requirements.

16. Key Vault Networking

Security isn’t limited to identity and permissions.

Key Vault access can also be restricted through network controls.

Depending on the architecture, you may use mechanisms such as:

• Public network access restrictions
• Firewall rules
• Virtual network integration
• Private endpoints

The goal is to reduce unnecessary network exposure while ensuring authorized applications can reach the vault.

A secure architecture can therefore involve multiple layers:

Application
     |
     | Managed Identity
     v
Microsoft Entra ID
     |
     | Authorization
     v
Azure Key Vault
     |
     | Network controls
     v
Secret

17. Monitoring Key Vault Access

Key Vault operations can be logged.

Examples include operations such as:

• Secret get
• Secret update
• Secret delete
• Secret list
• Secret version listing

These logs can help organizations determine:

• Who accessed a secret
• When it was accessed
• What operation was performed
• Whether suspicious access patterns occurred

Key Vault diagnostic logging can capture secret-related operations, including SecretGet and SecretUpdate.

For security-sensitive applications, logging and monitoring should be part of the overall secret-management strategy.

18. Common Design Pattern

A strong AI application architecture might look like this:

                         +----------------------+
                         |    Azure Key Vault   |
                         |                      |
                         | API credentials      |
                         | DB credentials       |
                         | Other secrets        |
                         +----------+-----------+
                                    ^
                                    |
                              Microsoft Entra ID
                                    ^
                                    |
                           Managed Identity
                                    ^
                                    |
+----------------+          +-------+-------+
| Azure Function |          | Container App |
+----------------+          +---------------+
          \                         /
           \                       /
            +---------------------+
                  AI solution

The application:

1. Uses a managed identity.
2. Authenticates through Microsoft Entra ID.
3. Receives authorization through Azure RBAC.
4. Retrieves only the secrets it needs.
5. Caches values appropriately.
6. Handles secret rotation.
7. Avoids exposing secret values in logs.

19. Common Mistakes to Avoid

Mistake 1: Storing secrets in source code

Avoid:

string apiKey = "secret-value";

Use Key Vault instead.

Mistake 2: Using a client secret just to access Key Vault

If the workload supports managed identity, use it rather than creating another credential that must itself be protected.

Mistake 3: Giving applications excessive permissions

If an application only needs to read secrets, don’t give it administrative access to the vault.

Mistake 4: Confusing control-plane and data-plane permissions

Being able to manage the Key Vault resource does not necessarily mean an identity can retrieve secret values.

Mistake 5: Hard-coding secret versions

This can prevent applications from automatically seeing a newly rotated version.

Mistake 6: Rotating credentials without updating dependent services

Changing the value in Key Vault alone doesn’t necessarily change the credential accepted by the target system.

Mistake 7: Immediately revoking the old credential

Doing so can cause downtime if applications have not migrated.

Mistake 8: Logging secret values

Never write secret values to:

• Application logs
• Console output
• Error messages
• Telemetry
• Exceptions
• Debug traces

Mistake 9: Excessive Key Vault calls

Retrieve and cache secrets appropriately rather than unnecessarily querying Key Vault for every operation.

Mistake 10: Assuming Event Grid performs the entire rotation

Event Grid provides event delivery. Your automation or application must perform the appropriate response.

20. AI-200 Exam Takeaways

For the exam, remember these relationships:

The most important mental model is:

Authenticate with managed identity → authorize with least-privilege Key Vault permissions → retrieve secrets securely → cache appropriately → rotate safely → monitor access.

Practice Exam Questions

Question 1

An Azure Function needs to retrieve the value of a database password stored in Azure Key Vault. The Function App has a system-assigned managed identity. The application must not store any credentials for accessing Key Vault.

What should you configure?

A. Assign the Key Vault Secrets User role to the Function App’s managed identity.

B. Store a Key Vault administrator password in the Function App settings.

C. Assign the Owner role to the Function App’s managed identity.

D. Create a client secret for the Function App and store it in Azure App Configuration.

Answer: A

Explanation:
The Function’s managed identity can authenticate to Azure without storing credentials. The Key Vault Secrets User role allows the identity to read secret contents. Owner is unnecessarily privileged, and storing another credential defeats the purpose of managed identity.

Question 2

An organization wants to rotate a database password stored in Azure Key Vault. The application must continue operating while the password is changed.

Which approach provides the best zero-downtime strategy?

A. Delete the existing secret before creating the new password.

B. Disable the application’s managed identity during rotation.

C. Replace the Key Vault with Azure App Configuration.

D. Create the new credential, update the target database, store the new secret version, allow applications to transition, and revoke the old credential afterward.

Answer: D

Explanation:
A coordinated rotation allows both the old and new credentials to coexist temporarily. The new credential is deployed and verified before the old credential is revoked. This reduces the likelihood of authentication failures during rotation.

Question 3

An application currently retrieves a Key Vault secret by explicitly specifying Version 4. Version 5 has now been created as part of a credential rotation. The application continues using Version 4.

What is the most likely reason?

A. Key Vault cannot contain multiple versions of a secret.

B. Azure RBAC prevents version changes.

C. The application explicitly requested Version 4 instead of retrieving the current version.

D. Managed identities can only access the first version of a secret.

Answer: C

Explanation:
A version-specific request intentionally retrieves that particular version. If an application needs to follow the current secret version, it should retrieve the secret without hard-coding a specific version.

Question 4

A company wants to automatically detect when an Azure Key Vault secret is approaching expiration and start a rotation workflow.

Which service is most appropriate for detecting and routing the lifecycle event?

A. Azure Load Balancer

B. Azure DNS

C. Azure Storage Queue

D. Azure Event Grid

Answer: D

Explanation:
Azure Key Vault integrates with Event Grid and can emit events associated with secret lifecycle changes, including near-expiry and expiration events. Event Grid can route those events to handlers such as Azure Functions.

Question 5

An application only needs to read the value of a secret from a Key Vault that uses the Azure RBAC permission model.

Which built-in role is the most appropriate?

A. Key Vault Secrets User

B. Owner

C. Key Vault Contributor

D. Key Vault Secrets Officer

Answer: A

Explanation:
Key Vault Secrets User provides read access to secret contents. Secrets Officer is intended for managing secrets and therefore grants broader permissions than the application requires.

Question 6

An AI application makes thousands of requests per minute. Each request currently retrieves the same API key from Azure Key Vault. The API key changes infrequently.

What should the developer consider to reduce unnecessary Key Vault calls?

A. Grant the application Owner permissions.

B. Copy the API key into source code.

C. Cache the secret for an appropriate period while implementing a strategy to refresh it when necessary.

D. Disable Key Vault logging.

Answer: C

Explanation:
Caching can substantially reduce unnecessary Key Vault calls. However, the cache lifetime must be selected carefully because an excessively long cache can cause the application to continue using an old secret after rotation.

Question 7

An administrator grants an application’s managed identity the Azure Key Vault Contributor role. The application still cannot retrieve a secret’s value.

What best explains this behavior?

A. Managed identities cannot access Key Vault.

B. Key Vault Contributor is a control-plane management role and does not provide access to secret contents.

C. Key Vault requires a storage account before secrets can be retrieved.

D. The application must use a user-assigned managed identity.

Answer: B

Explanation:
Key Vault separates management of the vault from access to data stored within it. Key Vault Contributor allows management of the Key Vault resource but does not grant access to secret contents. A suitable data-plane role, such as Key Vault Secrets User, is required.

Question 8

A security team wants applications to authenticate to Azure Key Vault without storing usernames, passwords, client secrets, or certificates in application configuration.

Which solution should the developer use?

A. Store a service principal secret in Azure App Configuration.

B. Embed an administrator credential in the application.

C. Use a shared Key Vault access password.

D. Use an Azure managed identity with Microsoft Entra authentication.

Answer: D

Explanation:
Managed identities provide Azure-managed identities that applications can use to authenticate to supported Azure services without embedding credentials in application code or configuration.

Question 9

A developer implements an automated secret-rotation process. The process receives a SecretNearExpiry event from Azure Event Grid.

What should the developer understand about this event?

A. The event itself automatically replaces the secret in every dependent system.

B. The event means the secret has already expired.

C. The event can trigger automation that performs the required rotation workflow.

D. The event permanently disables the existing secret.

Answer: C

Explanation:
Event Grid provides event delivery. A receiving service, such as Azure Functions, can respond by performing the rotation workflow. A near-expiry event does not itself rotate credentials in every system.

Question 10

A developer needs to secure an AI application’s API credential stored in Azure Key Vault. The developer wants to follow least-privilege principles.

Which design is best?

A. Give the application’s managed identity Owner access to the subscription.

B. Store the API key in the application’s source code and restrict repository access.

C. Give the application’s managed identity Key Vault Secrets Officer permissions even though it only reads the secret.

D. Give the application’s managed identity only the Key Vault data-plane permissions required to retrieve the secret.

Answer: D

Explanation:
Least privilege means granting only the permissions necessary for the workload. If the application only needs to retrieve a secret, it should receive a read-oriented Key Vault role rather than Owner or a broader secret-management role.

Final Study Summary

For “Secure secrets by using Azure Key Vault, including rotation and retrieval,” focus especially on these exam relationships:

Managed Identity → Microsoft Entra authentication → Azure RBAC authorization → Key Vault secret retrieval → versioning → caching → rotation → Event Grid notifications.

A particularly important exam distinction is that storing a new secret version does not automatically mean every application has switched to the new credential. Applications and the systems they connect to must be designed to recognize and safely adopt rotated credentials.

Likewise, Event Grid can notify or trigger a rotation workflow, but it isn’t itself the complete rotation mechanism. A Function, automation process, or other handler may need to update the target resource and Key Vault.

Finally, favor managed identities and least-privilege Azure RBAC over embedded credentials and excessive permissions. These patterns reduce secret exposure and make AI workloads easier to operate securely.

Go to the AI-200 Exam Prep Hub main page