Merge pull request #221686 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: huypub

README.md

@@ -10,7 +10,7 @@ Contributing to open source is more than just providing updates, it's also about
 
 You've decided to contribute, that's great! To contribute to the documentation, you need a few tools.
 
-#### Github
+#### GitHub
 
 Contributing to the documentation requires a GitHub account. If you don't have an account, follow the instructions for [GitHub account setup](https://learn.microsoft.com/contribute/get-started-setup-github) from our contributor guide.
 

articles/active-directory/conditional-access/terms-of-use.md

@@ -385,6 +385,9 @@ A: On the Terms of use blade, select the number under **Accepted**. You can also
 **Q: How long is information stored?**<br />
 A: The user counts in the terms of use report and who accepted/declined are stored for the life of the terms of use. The Azure AD audit logs are stored for 30 days.
 
+**Q: Why do I see a different number of consents in the terms of use details overview versus the Azure AD audit logs?**<br />
+A: The terms of use details overview data is stored for the lifetime of that terms of use policy, while the Azure AD audit logs are stored for 30 days.
+
 **Q: Why do I see a different number of consents in the terms of use details overview versus the exported CSV report?**<br />
 A: The terms of use details overview reflects aggregated acceptances of the current version of the policy (updated once every day).  If expiration is enabled or a TOU agreement is updated (with re-acceptance required), the count on the details overview is reset since the acceptances are expired, thereby showing the count of the current version. All acceptance history is still captured in the CSV report.
 

articles/api-management/import-container-app-with-oas.md

@@ -85,7 +85,7 @@ The wildcard operation allows the same requests to the backend service as the op
     > [!NOTE]
     > Products are associations of one or more APIs. You can include many APIs and offer them to developers through the developer portal. Developers must first subscribe to a product to get access to the API. When they subscribe, they get a subscription key that is good for any API in that product. If you created the API Management instance, you're an administrator and subscribed to every product by default.
     >
-    > Each API Management instance comes with two sample products when createdgg:
+    > Each API Management instance comes with two sample products when created:
     > * **Starter**
     > * **Unlimited**
 

articles/communication-services/concepts/service-limits.md

@@ -86,7 +86,7 @@ Sending a high volume of messages has a set of limitations on the number of emai
 | **Name**         | Limit  |
 |--|--|
 |Number of recipients in Email|50 |
-|Attachment size - per message |10 MB |
+|Total email request size (including attachments) |10 MB |
 
 ### Action to take
 This sandbox setup is to help developers start building the application. You can gradually request to increase the sending volume once the application is ready to go live. Submit a support request to raise your desired sending limit if you require sending a volume of messages exceeding the rate limits.

articles/key-vault/general/rbac-migration.md

@@ -36,7 +36,7 @@ Azure RBAC has several Azure built-in roles that you can assign to users, groups
 Key Vault built-in roles for keys, certificates, and secrets access management:
 - Key Vault Administrator
 - Key Vault Reader
-- Key Vault Certificate Officer
+- Key Vault Certificates Officer
 - Key Vault Crypto Officer
 - Key Vault Crypto User
 - Key Vault Crypto Service Encryption User