Add FAQ about MFA

[isra-fel]

PR Summary

Add an FAQ about how to recover from MFA failures.

PR Checklist

• Descriptive Title: This PR's title is a synopsis of the changes it proposes.
• Summary: This PR's summary describes the scope and intent of the change.
• Contributor's Guide: I have read the contributors guide.
• Style: This PR adheres to the style guide.

[isra-fel]

Versions TBD

[isra-fel]

Final error message TBD

[github-actions]

Expectations

Thanks for your submission! Here's a quick note to provide you with some context for what to expect from the docs team and the process now that you've submitted a PR. Even if you've contributed to this repo before, we strongly suggest reading this information; it might have changed since you last read it.

To see our process for reviewing PRs, please read our editor's checklist and process for managing pull requests in particular. Below is a brief, high-level summary of what to expect, but our contributor guide has expanded details.

The docs team begins to review your PR if you request them to or if your PR meets these conditions:

• It is not a draft PR.
• It does not have a WIP prefix in the title.
• It passes validation and build steps.
• It does not have any merge conflicts.
• You have checked every box in the PR Checklist, indicating you have completed all required steps and marked your PR as Ready to Merge.

You can always request a review at any stage in your authoring process, the docs team is here to help! You do not need to submit a fully polished and finished draft; the docs team can help you get content ready for merge.

While reviewing your PR, the docs team may make suggestions, write comments, and ask questions. When all requirements are satisfied, the docs team marks your PR as Approved and merges it. Once your PR is merged, it is included the next time the documentation is published. For this project, the documentation is published daily at 3 p.m. Pacific Standard Time (PST).

[mikefrobbins]

@isra-fel, I believe this type of customer assistance belongs in our troubleshooting article.

Also, could we make the H2 heading more generic while still including the specific error message in the text? I plan to use this approach in the Azure CLI version, as it's my understanding that they have a variety of error messages, and adopting a similar format will help align the Azure PowerShell documentation with the Azure CLI version.

I can make the suggested changes but wanted your feedback first.

[isra-fel]

Totally agree on putting this into the TSG. As for the exact error message my only concern/intention is if it's search engine friendly.
Please do recycle this draft and work on your version. Thanks!

[learn-build-service-prod]

Learn Build status updates of commit d44e154:

✅ Validation status: passed

File	Status	Preview URL	Details
docs-conceptual/azps-14.2.0/troubleshooting.md	✅Succeeded	View (azps-14.2.0)

For more details, please refer to the build report.