Merge pull request #255205 from alexbuckgit/alexbuckgit/docutune-autopr-20231017-001735-7422712-ignore-build

[BULK] - DocuTune - Switch to site-relative links in active-directory folder prior to repo migration (part 30)

Author: American-Dipper

articles/active-directory/verifiable-credentials/how-to-opt-out.md

@@ -41,7 +41,7 @@ Opting out is a one-way operation. After you opt-out, your Microsoft Entra Verif
 
 When you complete opting out of the Microsoft Entra Verified ID service, the following actions take place:
 
-- The DID keys in Key Vault are [soft deleted](../../key-vault/general/soft-delete-overview.md).
+- The DID keys in Key Vault are [soft deleted](/azure/key-vault/general/soft-delete-overview).
 - The issuer object is deleted from our database.
 - The tenant identifier is deleted from our database.
 - All of the verifiable credentials contracts are deleted from our database.

articles/active-directory/verifiable-credentials/how-to-use-quickstart-idtoken.md

@@ -208,7 +208,7 @@ To match the display and rules definitions, you should make your application's o
 },
 ```
 
-**For Azure Active Directory B2C**: Configuring other claims in your ID token depends on whether your B2C policy is a *user flow* or a *custom policy*. For information about user flows, see [Set up a sign-up and sign-in flow in Azure Active Directory B2C](../../active-directory-b2c/add-sign-up-and-sign-in-policy.md?pivots=b2c-user-flow). For information about custom policy, see [Provide optional claims to your app](../../active-directory-b2c/configure-tokens.md?pivots=b2c-custom-policy#provide-optional-claims-to-your-app).  
+**For Azure Active Directory B2C**: Configuring other claims in your ID token depends on whether your B2C policy is a *user flow* or a *custom policy*. For information about user flows, see [Set up a sign-up and sign-in flow in Azure Active Directory B2C](/azure/active-directory-b2c/add-sign-up-and-sign-in-policy?pivots=b2c-user-flow). For information about custom policy, see [Provide optional claims to your app](/azure/active-directory-b2c/configure-tokens?pivots=b2c-custom-policy#provide-optional-claims-to-your-app).  
 
 For other identity providers, see the relevant documentation.
 

articles/active-directory/verifiable-credentials/plan-issuance-solution.md

@@ -176,7 +176,7 @@ The following provides areas to consider when planning for performance:
 * To limit latency, deploy your issuance frontend website and key vault in the region listed above.
 
 Model based on throughput:
-* The Issuer service is subject to [Azure Key Vault service limits](../../key-vault/general/service-limits.md). 
+* The Issuer service is subject to [Azure Key Vault service limits](/azure/key-vault/general/service-limits). 
 
 *  For Azure Key Vault, there are three signing operations involved in each a VC issuance:
 
@@ -186,7 +186,7 @@ Model based on throughput:
 
       * One for the contract download
 
-* You can't control throttling; however, we recommend you read [Azure Key Vault throttling guidance](../../key-vault/general/overview-throttling.md). 
+* You can't control throttling; however, we recommend you read [Azure Key Vault throttling guidance](/azure/key-vault/general/overview-throttling). 
 
 * If you're planning a large rollout and onboarding of VCs, consider batching VC creation to ensure you don't exceed limits.
 
@@ -216,7 +216,7 @@ For scalability, consider implementing metrics for the following items:
 
 * Monitor Azure Key Vault using the following link:
 
-   * [Azure Key Vault monitoring and alerting](../../key-vault/general/alert.md)
+   * [Azure Key Vault monitoring and alerting](/azure/key-vault/general/alert)
 
 * Monitor the components used for your business logic layer. 
 
@@ -226,7 +226,7 @@ To plan for reliability, we recommend:
 
 * After you define your availability and redundancy goals, use the following guides to understand how to achieve your goals:
 
-   * [Azure Key Vault availability and redundancy - Azure Key Vault](../../key-vault/general/disaster-recovery-guidance.md)
+   * [Azure Key Vault availability and redundancy - Azure Key Vault](/azure/key-vault/general/disaster-recovery-guidance)
 
 * For frontend and business layer, your solution can manifest in an unlimited number of ways. As with any solution, for the dependencies you identify, ensure that the dependencies are resilient and monitored. 
 
@@ -272,7 +272,7 @@ As part of your design considerations focused on security, we recommend the foll
 
 For security logging and monitoring, we recommend the following items:
 
-* Enable logging and alerting of Azure Key Vault. Track credential issuance operations, key extraction attempts and permission changes. Monitor and send alert for configuration changes. More information can be found at [How to enable Key Vault logging](../../key-vault/general/howto-logging.md). 
+* Enable logging and alerting of Azure Key Vault to track credential issuance operations, key extraction attempts, permission changes, and to monitor and send alert for configuration changes. More information can be found at [How to enable Key Vault logging](/azure/key-vault/general/howto-logging). 
 
 * Archive logs in a security information and event management (SIEM) systems, such as [Microsoft Sentinel](https://azure.microsoft.com/services/azure-sentinel) for long-term retention.
 
@@ -292,7 +292,7 @@ For guidance on managing your Azure environment, we recommend you review the [Mi
 
 When you complete your POC, gather all the information and documentation generated, and consider tearing down the issuer configuration. 
 
-For more information on Key Vault implementation and operation, see [Best practices to use Key Vault](../../key-vault/general/best-practices.md). For more information on Securing Azure environments with Active Directory, see [Securing Azure environments with Microsoft Entra ID](https://aka.ms/AzureADSecuredAzure). 
+For more information on Key Vault implementation and operation, refer to [Best practices to use Key Vault](/azure/key-vault/general/best-practices). For more information on Securing Azure environments with Active Directory, refer to [Securing Azure environments with Microsoft Entra ID](https://aka.ms/AzureADSecuredAzure). 
 
 ## Next steps
 

articles/active-directory/verifiable-credentials/plan-verification-solution.md

@@ -27,7 +27,7 @@ This content covers the technical aspects of planning for a verifiable credentia
 
 Supporting technologies that aren't specific to verification solutions are out of scope. For example, websites are used in a verifiable credential verification solution but planning a website deployment isn't covered in detail.
 
-As you plan your verification solution, you must consider what business capability is being added or modified. You must also consider what IT capabilities can be reused, and what capabilities must be added to create the solution. Also consider what training is needed for the people involved in the business process and the people that support the end users and staff of the solution. These articles aren't covered in this content. We recommend reviewing the [Microsoft Azure Well-Architected Framework](/azure/architecture/framework/) for information covering these articles.
+As you plan your verification solution, you must consider what business capability is being added or modified. You must also consider what IT capabilities can be reused, and what capabilities must be added to create the solution. Also consider what training is needed for the people involved in the business process and the people that support the end users and staff of the solution. These articles aren't covered in this content. We recommend reviewing the [Microsoft Azure Well-Architected Framework](/azure/well-architected/) for information covering these articles.
 
 ## Components of the solution
 
@@ -271,19 +271,19 @@ The following items provide areas to consider when planning for performance:
 
 * Model based on throughput:
 
-   * VC verification capacity is subject to [Azure Key Vault service limits](../../key-vault/general/service-limits.md). 
+   * VC verification capacity is subject to [Azure Key Vault service limits](/azure/key-vault/general/service-limits). 
 
    * Each verification of a VC requires one Key Vault signature operation.
 
-   * You can't control throttling; however, we recommend you read [Azure Key Vault throttling guidance](../../key-vault/general/overview-throttling.md) so that you understand how throttling might impact performance. 
+   * You can't control throttling; however, we recommend you read [Azure Key Vault throttling guidance](/azure/key-vault/general/overview-throttling) so that you understand how throttling might impact performance. 
 
 ## Plan for reliability
 
 To best plan for high availability and disaster recovery, we suggest the following items:
 
 * Microsoft Entra Verified ID service is deployed in the West Europe, North Europe, West US 2, and West Central US, Australia and Japan Azure regions. Consider deploying your supporting web servers and supporting applications in one of those regions, specifically in the ones from which you expect most of your validation traffic to originate. 
 
-* Review and incorporate best practices from [Azure Key Vault availability and redundancy](../../key-vault/general/disaster-recovery-guidance.md) as you design for your availability and redundancy goals.
+* Review and incorporate best practices from [Azure Key Vault availability and redundancy](/azure/key-vault/general/disaster-recovery-guidance) as you design for your availability and redundancy goals.
 
 ## Plan for security
 
@@ -295,7 +295,7 @@ As you're designing for security, consider the following:
 
 * Only the Microsoft Entra Verified ID service and the website service principals should have permissions to use Key Vault to sign messages with the private key. 
 
-* Don't assign any human identity administrative permissions to the Key Vault. For more information on Key Vault best practices, see [Azure Security Baseline for Key Vault](../../key-vault/general/security-baseline.md).
+* Don't assign any human identity administrative permissions to the Key Vault. For more information on Key Vault best practices, see [Azure Security Baseline for Key Vault](/security/benchmark/azure/baselines/key-vault-security-baseline).
 
 * Review [Securing Azure environments with Microsoft Entra ID](https://azure.microsoft.com/resources/securing-azure-environments-with-azure-active-directory/) for best practices for managing the supporting services for your solution. 
 
@@ -323,11 +323,11 @@ As part of your operational planning, consider monitoring the following:
 
    * Monitor underlying dependencies used by the verification solution. 
 
-   * Follow [Azure Key Vault monitoring and alerting](../../key-vault/general/alert.md).
+   * Follow [Azure Key Vault monitoring and alerting](/azure/key-vault/general/alert).
 
 * **For security**:
 
-   * Enable logging for Key Vault to track signing operations, and to monitor and alert on configuration changes. See [How to enable Key Vault logging](../../key-vault/general/howto-logging.md) for more information.
+   * Enable logging for Key Vault to track signing operations, and to monitor and alert on configuration changes. Refer to [How to enable Key Vault logging](/azure/key-vault/general/howto-logging) for more information.
 
    * Archive logs in a security information and event management (SIEM) systems, such as [Microsoft Sentinel](https://azure.microsoft.com/services/azure-sentinel/) for long-term retention.