Corrected Hash Links

This PR corrects many broken hash links

_docs-sources/guides/build-it-yourself/6-achieve-compliance/2-production-grade-design/1-identity-and-access-management.md

@@ -83,7 +83,7 @@ This code creates an IAM user called `support`, adds them to a new group called
 2. The policy is attached to an IAM group, not directly to the IAM user (recommendation 1.15).
 
 3. Recommendation 1.17 specifically requires that the Support policy be used. You should attach it to a group, as
-    shown here.
+   shown here.
 
 ## Do not use full administrator privileges
 
@@ -275,7 +275,7 @@ aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>
 ```
 
 To automate this process you might decide to implement a Lambda function that runs on a regular schedule and removes
-all expired SSL/TLS certificates. Check out the [Apply the baseline to the root account](#apply_account_baseline_root), [Apply the to the logs account](#apply_account_baseline_logs) and [Apply the to the security account](#apply_account_baseline_security) section of the deployment walkthrough
+all expired SSL/TLS certificates. Check out the [Apply the baseline to the root account](../3-deployment-walkthrough/8-deploy-landing-zone-solution/0-apply-account-baseline-root-to-root-account.md#apply-the-account-baseline-root-baseline-to-the-root-account), [Apply the to the logs account](../3-deployment-walkthrough/8-deploy-landing-zone-solution/1-apply-account-baseline-app-to-logs-account.md) and [Apply the to the security account](../3-deployment-walkthrough/8-deploy-landing-zone-solution/2-apply-account-baseline-security-to-security-account.md) section of the deployment walkthrough
 to see how this module is used from the Landing Zone account baselines and is deployed in each of your AWS accounts.
 
 ## IAM Access Analyzer
@@ -285,7 +285,7 @@ AWS Account or Organization.
 
 To achieve this compliance requirement, enable the IAM Access Analyzer service for every AWS region you have enabled in
 every one of your AWS accounts. Alternatively, you could make use of the [`iam-access-analyzer-multi-region`](https://github.com/gruntwork-io/terraform-aws-security/tree/master/modules/iam-access-analyzer-multi-region) module
-available in the Gruntwork Service Catalog, or if you’re following this guide, refer to [Apply the baseline to the root account](#apply_account_baseline_root), [Apply the to the logs account](#apply_account_baseline_logs) and [Apply the to the security account](#apply_account_baseline_security) sections of the
+available in the Gruntwork Service Catalog, or if you’re following this guide, refer to [Apply the baseline to the root account](../3-deployment-walkthrough/8-deploy-landing-zone-solution/0-apply-account-baseline-root-to-root-account.md#apply-the-account-baseline-root-baseline-to-the-root-account), [Apply the to the logs account](../3-deployment-walkthrough/8-deploy-landing-zone-solution/1-apply-account-baseline-app-to-logs-account.md) and [Apply the to the security account](../3-deployment-walkthrough/8-deploy-landing-zone-solution/2-apply-account-baseline-security-to-security-account.md) sections of the
 deployment walkthrough to see how this module is used from the Landing Zone account baselines and is deployed in each of your AWS accounts.
 
 Once enabled, it will scan only within the boundaries of the AWS Account or Organization it has access to. Only specific

_docs-sources/guides/build-it-yourself/6-achieve-compliance/3-deployment-walkthrough/8-deploy-landing-zone-solution/0-apply-account-baseline-root-to-root-account.md

@@ -291,29 +291,29 @@ The example code above does the following:
 1. **Create 6 child AWS accounts**. These accounts are described in more detail in the [How to configure a production-grade AWS account structure using Gruntwork AWS Landing Zone child accounts section](https://www.gruntwork.io/guides/foundations/how-to-configure-production-grade-aws-account-structure/#child_accounts).
 
 2. **Associate an email address with each of the child accounts**. This will be the email address for the root user of
-    each account and AWS requires that the root user’s email address is _globally_ unique, so it cannot be the email
-    address you used for the root account or any of the other child accounts. You’ll have to either create multiple email
-    accounts in your company’s email system, or, if your company uses Gmail (perhaps as part of G Suite), you can take
-    advantage of the fact that [Gmail
-    ignores everything after a plus sign in an email address](https://gmail.googleblog.com/2008/03/2-hidden-ways-to-get-more-from-your.html), so that while AWS will see
-    `root-accounts+security@acme.com`, `root-accounts+shared@acme.com`, and
-    `root-accounts+dev@acme.com` as three unique email addresses, Gmail will see them all as the same email
-    address, `root-accounts@acme.com`.
+   each account and AWS requires that the root user’s email address is _globally_ unique, so it cannot be the email
+   address you used for the root account or any of the other child accounts. You’ll have to either create multiple email
+   accounts in your company’s email system, or, if your company uses Gmail (perhaps as part of G Suite), you can take
+   advantage of the fact that [Gmail
+   ignores everything after a plus sign in an email address](https://gmail.googleblog.com/2008/03/2-hidden-ways-to-get-more-from-your.html), so that while AWS will see
+   `root-accounts+security@acme.com`, `root-accounts+shared@acme.com`, and
+   `root-accounts+dev@acme.com` as three unique email addresses, Gmail will see them all as the same email
+   address, `root-accounts@acme.com`.
 
 3. **Mark one of the child accounts as a logs account**. We set `is_logs_account = true` on one of the child accounts
-    to indicate it is the logs account where we will aggregate AWS Config, CloudTrail, IAM Access Analyzer, Security Hub and Amazon Macie data from all the other accounts.
-    The `account-baseline-root` module will automatically create an S3 bucket for AWS Config and an S3 bucket and KMS CMK
-    = for CloudTrail in this account and configure the root account to send all the AWS Config and CloudTrail data to these
-    S3 buckets. Later on, you’ll configure all the other accounts to send their data to these S3 buckets too.
+   to indicate it is the logs account where we will aggregate AWS Config, CloudTrail, IAM Access Analyzer, Security Hub and Amazon Macie data from all the other accounts.
+   The `account-baseline-root` module will automatically create an S3 bucket for AWS Config and an S3 bucket and KMS CMK
+   = for CloudTrail in this account and configure the root account to send all the AWS Config and CloudTrail data to these
+   S3 buckets. Later on, you’ll configure all the other accounts to send their data to these S3 buckets too.
 
 4. **Create IAM groups**. By default, `account-baseline-root` will **not** create a `full-access` IAM group as CIS requirement 1.16 guides. It will create a `support` and a `billing` IAM group (for the support and finance teams).
 
 5. **Create IAM users**. For this example, we create `alice` and `bob`, adding `alice` to the `full-access`
-    IAM group and `bob` to the `billing` IAM group. _Note_: your own IAM user (the one you created manually) should be
-    in the `users` list; we’ll use the `import` command to put this user under Terraform management shortly.
+   IAM group and `bob` to the `billing` IAM group. _Note_: your own IAM user (the one you created manually) should be
+   in the `users` list; we’ll use the `import` command to put this user under Terraform management shortly.
 
 6. **Generate a password for each user**. We encrypt this password with that user’s PGP key from Keybase (we’ll come
-    back to how to handle the passwords shortly).
+   back to how to handle the passwords shortly).
 
 Pull in the [backend](https://www.terraform.io/docs/backends/) settings from a root `terragrunt.hcl` file that you
 `include` in each child `terragrunt.hcl`:
@@ -581,6 +581,6 @@ Use this process to reset the password for the root user of each child account y
 
 ## Lock down the root user in the child accounts
 
-Once you’re able to access the root user of each child account, you should follow the steps in [Lock down the root user](#lock_down_root_user)
+Once you’re able to access the root user of each child account, you should follow the steps in [Lock down the root user](../4-lock-down-the-root-user.md)
 for each of those child accounts—including enabling MFA and deleting the root user’s access keys—and (almost) never use
 those root users again.

_docs-sources/guides/build-it-yourself/6-achieve-compliance/3-deployment-walkthrough/8-deploy-landing-zone-solution/3-apply-account-baseline-app-to-other-child-accounts.md

@@ -1,6 +1,7 @@
 ---
 sidebar_label: Apply the account-baseline-app to the other child accounts
 ---
+
 # Apply the `account-baseline-app` to the other child accounts
 
 Now that your **security** account is fully configured, you need to apply the security baseline to the remaining child
@@ -206,15 +207,15 @@ The code above does the following:
 2. **Enable AWS Config**. We’ve configured AWS Config to use the S3 bucket in the logs account.
 
 3. **Configure the dev IAM role**. We create a `dev` IAM role in this account, which will get read and write access to
-    the services specified in `dev_permitted_services`.
+   the services specified in `dev_permitted_services`.
 
 4. **Configure the Auto Deploy IAM role**. We also create an `auto-deploy` IAM role that can be assumed by a CI server
-    in the `shared-services` account to do deployments. This role will have the permissions specified in
-    `auto_deploy_permissions`.
+   in the `shared-services` account to do deployments. This role will have the permissions specified in
+   `auto_deploy_permissions`.
 
 5. **Configure cross-account IAM roles**. We then specify which other accounts are allowed to assume the IAM roles in
-    this account. For the most part, we grant all permissions to the security account, so that by assigning users to IAM
-    groups in that account, you’ll be able to access IAM roles in all the other child accounts.
+   this account. For the most part, we grant all permissions to the security account, so that by assigning users to IAM
+   groups in that account, you’ll be able to access IAM roles in all the other child accounts.
 
 Configure your Terraform backend:
 
@@ -272,24 +273,24 @@ On some operating systems, such as MacOS, you may also need to increase your ope
 **Next, try authenticating as an IAM user to the child accounts:**
 
 1. Use your IAM user’s user name and password (decrypted using keybase) to log into the web console of the security
-    account (remember to use the IAM user sign-in URL for the security account).
+   account (remember to use the IAM user sign-in URL for the security account).
 
-2. Follow the steps in [Lock down the root account IAM users](#lock_down_iam_users) to lock down your IAM user in the security account. This includes
-    configuring an MFA device for your IAM user.
+2. Follow the steps in [Lock down the root account IAM users](../6-lock-down-the-root-account-iam-users.md) to lock down your IAM user in the security account. This includes
+   configuring an MFA device for your IAM user.
 
 3. After configuring an MFA device, log out, and then log back into the security account again, this time providing your
-    MFA token. If you don’t do this, attempting to assume IAM roles in other accounts won’t work, as those roles require
-    an MFA token to be present.
+   MFA token. If you don’t do this, attempting to assume IAM roles in other accounts won’t work, as those roles require
+   an MFA token to be present.
 
 4. Try to [switch to a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) in
-    one of the other child accounts using the AWS Web Console. For example, authenticate as one of the IAM users in the
-    security account, and then assume the `allow-full-access-from-other-accounts` role in the dev account (you can find
-    the default list of IAM roles created in each account
-    [here](https://github.com/gruntwork-io/module-security/tree/master/modules/cross-account-iam-roles#resources-created)).
+   one of the other child accounts using the AWS Web Console. For example, authenticate as one of the IAM users in the
+   security account, and then assume the `allow-full-access-from-other-accounts` role in the dev account (you can find
+   the default list of IAM roles created in each account
+   [here](https://github.com/gruntwork-io/module-security/tree/master/modules/cross-account-iam-roles#resources-created)).
 
 5. Alternatively, you can use the `aws-vault login xxx` command to login to the AWS Web Console for any profile `xxx`
-    that you’ve configured in `aws-vault`. For example, `aws-vault login logs-from-root` will open up your web browser
-    and log you into the `logs` account using the `OrganizationAccountAccessRole` IAM Role.
+   that you’ve configured in `aws-vault`. For example, `aws-vault login logs-from-root` will open up your web browser
+   and log you into the `logs` account using the `OrganizationAccountAccessRole` IAM Role.
 
 ## Configure AWS Security Hub in the root account
 

_docs-sources/guides/reference-architecture/02-authenticate/02-setting-up-initial-access.md

@@ -24,7 +24,7 @@ organization, AWS does _not_ allow you to set those passwords. So, to get the pa
 1. Click "Forgot your password" to reset the password.
 1. Check the email address associated with the root user account for a link you can use to create a new password.
 
-Please note that the root user account can do just about *anything* in your AWS account, bypassing almost all security
+Please note that the root user account can do just about _anything_ in your AWS account, bypassing almost all security
 restrictions you put in place, so you need to take extra care with protecting this account. We **very strongly**
 recommend that when you reset the password for each account, you:
 
@@ -60,7 +60,7 @@ Once you have access with the IAM user, be sure to do the following to finish co
 
 1. **Enable MFA**. [Follow these instructions to enable
    MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable.html) for your IAM user. It takes
-less than a minute and_dramatically_ improves your security posture. Moreover, MFA is **required** by the Reference
+   less than a minute and*dramatically* improves your security posture. Moreover, MFA is **required** by the Reference
    Architecture, and you won't be able to access any other accounts without it!
 
 1. **Logout and log back in**. After enabling MFA, you need to log out and then log back in, thereby forcing AWS to
@@ -133,7 +133,7 @@ A few notes about the code above:
 
 To deploy this new code and create the new IAM users, you will need to:
 
-1. **Authenticate**. [Authenticate to AWS via the CLI](#authenticate-to-aws-via-the-cli).
+1. **Authenticate**. [Authenticate to AWS via the CLI](04-authenticate-to-aws-via-the-cli.md).
 
 1. **Apply your changes**. Run `terragrunt apply`.
 

_docs-sources/guides/reference-architecture/02-authenticate/06-authenticate-to-the-vpn-server.md

@@ -33,7 +33,7 @@ that has access to the SQS queues in those accounts.
 
 To be able to assume an IAM role, your IAM user needs to be part of an IAM group with the proper permissions, such as
 `_account.xxx-full-access` or `_account.xxx-openvpn-users`, where `xxx` is the name of the account you want to access
-(`stage`, `prod`, etc). See [Configure other IAM users](#configure-other-iam-users) for instructions on adding users to
+(`stage`, `prod`, etc). See [Configure other IAM users](02-setting-up-initial-access.md#configure-other-iam-users) for instructions on adding users to
 IAM groups.
 
 ## Use openvpn-admin to generate a configuration file
@@ -43,7 +43,7 @@ to authenticate. To generate this configuration file, do the following:
 
 1. Install the latest [openvpn-admin binary](https://github.com/gruntwork-io/terraform-aws-openvpn/releases) for your OS.
 
-1. [Authenticate to AWS via the CLI](#authenticate-to-aws-via-the-cli). You will need to assume an IAM role in the AWS
+1. [Authenticate to AWS via the CLI](04-authenticate-to-aws-via-the-cli.md). You will need to assume an IAM role in the AWS
    account with the OpenVPN server you're trying to connect to. This IAM role must have access to the SQS queues used
    by OpenVPN server. Typically, the `allow-full-access-from-other-accounts` or
    `openvpn-server-allow-certificate-requests-for-external-accounts` IAM role is what you want.

_docs-sources/guides/reference-architecture/07-undeploy/09-useful-tips.md

@@ -1,23 +1,24 @@
 # Useful tips
 
 - **Destroy resources in groups instead of all at once.**
-  - There are [known instabilities](#known-errors) with destroying many modules at once. In addition, Terragrunt is
-      designed to process the modules in a graph, and will not continue on if there is an error. This means that you
-      could run into situations where Terragrunt has destroyed a module, but returns an error due to Terraform bugs that
-      prevent you from cleanly calling destroy twice.
+
+  - There are [known instabilities](10-known-errors.md) with destroying many modules at once. In addition, Terragrunt is
+    designed to process the modules in a graph, and will not continue on if there is an error. This means that you
+    could run into situations where Terragrunt has destroyed a module, but returns an error due to Terraform bugs that
+    prevent you from cleanly calling destroy twice.
   - To address these instabilities, it is recommended to destroy the resources in groups. For example, you can start
-      by destroying all the services first (e.g., `stage/REGION/stage/services`), then the data stores (e.g.,
-      `stage/REGION/stage/data-stores`), and finally the networking resources (e.g., `stage/REGION/stage/networking`).
+    by destroying all the services first (e.g., `stage/REGION/stage/services`), then the data stores (e.g.,
+    `stage/REGION/stage/data-stores`), and finally the networking resources (e.g., `stage/REGION/stage/networking`).
   - When identifying groups to destroy, use [terragrunt
-      graph-dependencies](https://terragrunt.gruntwork.io/docs/reference/cli-options/#graph-dependencies) to view the
-      dependency graph so that you destroy the modules in the right order.
+    graph-dependencies](https://terragrunt.gruntwork.io/docs/reference/cli-options/#graph-dependencies) to view the
+    dependency graph so that you destroy the modules in the right order.
 
 - **Empty + Delete S3 buckets using the web console (when destroying whole environments).**
-  - As mentioned in [Pre-requisite: force_destroy on S3 buckets](#pre-requisite-force_destroy-on-s3-buckets), it is
-      recommended to set `force_destroy = true` prior to running destroy so that terraform can destroy the S3 buckets.
-      However, this can be cumbersome if you are destroying whole environments, as it can be difficult to flip the bit in
-      every single module.
+  - As mentioned in [Pre-requisite: force_destroy on S3 buckets](03-pre-requisite-force-destroy-on-s3-buckets.md), it is
+    recommended to set `force_destroy = true` prior to running destroy so that terraform can destroy the S3 buckets.
+    However, this can be cumbersome if you are destroying whole environments, as it can be difficult to flip the bit in
+    every single module.
   - Instead, oftentimes it is faster and more convenient to first empty and then delete the buckets using the AWS web console prior to
-      invoking `destroy` with `terragrunt`.
+    invoking `destroy` with `terragrunt`.
   - **IMPORTANT**: You should only do this if you are intending on destroying an entire environment. Otherwise, it is
-      too easy to accidentally delete the wrong S3 bucket.
+    too easy to accidentally delete the wrong S3 bucket.

_docs-sources/guides/stay-up-to-date/terraform/5-how-to-update-to-aws-provider-v3/2-deployment-walkthrough.md

@@ -154,7 +154,7 @@ updates).
 If you purchased the Gruntwork Reference Architecture, you will have a copy of the `infrastructure-live` and
 `infrastructure-modules` repositories that contain the infrastructure code for deploying the Reference Architecture. You
 will need to update the relevant code in `infrastructure-modules` to use a compatible version of the
-Gruntwork Infrastructure as Code Library, as per [the compatibility table](#compatibility-table) above.
+Gruntwork Infrastructure as Code Library, as per [the compatibility table](#version-compatibility-table) above.
 
 To help guide you through the upgrade process, we have updated the Acme Reference Architecture examples to support AWS
 provider v3. You can refer to the following release notes for detailed information and code patches that you can apply