gruntwork-io · yhakbar · Oct 7, 2025 · Sep 19, 2025 · Sep 22, 2025 · Sep 25, 2025
diff --git a/custom-dictionary.txt b/custom-dictionary.txt
@@ -62,3 +62,7 @@ hcledit
 self-hosting
 infrachanges
 Entra
+GLMU
+myprodsa
+azuread
+mysa
diff --git a/docs/2.0/docs/accountfactory/architecture/security-controls.md b/docs/2.0/docs/accountfactory/architecture/security-controls.md
@@ -79,7 +79,7 @@ Requires the following tokens be created:
 - `INFRA_ROOT_WRITE_TOKEN`: Fine-grained PAT with read/write access to infrastructure repositories
 - `ORG_REPO_ADMIN_TOKEN`: Fine-grained PAT with admin access for repository management
 
-See [Setup via Machine Users](/2.0/docs/pipelines/installation/viamachineusers.md) for more details.
+See [Setup via Machine Users](/2.0/docs/pipelines/installation/viamachineusers) for more details.
 
 </TabItem>
 <TabItem value="gitlab" label="GitLab">

diff --git a/...s/pipelines/installation/addingnewrepo.md → ...ountfactory/installation/addingnewrepo.md b/...s/pipelines/installation/addingnewrepo.md → ...ountfactory/installation/addingnewrepo.md
@@ -1,6 +1,6 @@
-# Initial Setup
+# Adding Account Factory to a new repository
 
-To configure Gruntwork Pipelines in a new GitHub repository, complete the following steps:
+To configure Gruntwork Account Factory in a new GitHub repository, the following steps are required (and will be explained in detail below):
 
 1. Create your `infrastructure-live-root` repository using Gruntwork's GitHub template.
 2. Configure the Gruntwork.io GitHub App to authorize your `infrastructure-live-root` repository, or ensure that the appropriate machine user tokens are set up as repository or organization secrets.
@@ -23,7 +23,7 @@ Navigate to the template repository and select **Use this template** -> **Create
 
 Use the Gruntwork.io GitHub App to [add the repository as an Infra Root repository](/2.0/docs/pipelines/installation/viagithubapp#configuration).
 
-If using the [machine user model](/2.0/docs/pipelines/installation/viamachineusers.md), ensure the `INFRA_ROOT_WRITE_TOKEN` (and `ORG_REPO_ADMIN_TOKEN` for enterprise customers) is added to the repository as a secret or configured as an organization secret.
+If using the [machine user model](/2.0/docs/pipelines/installation/viamachineusers), ensure the `INFRA_ROOT_WRITE_TOKEN` (and `ORG_REPO_ADMIN_TOKEN` for enterprise customers) is added to the repository as a secret or configured as an organization secret.
 
 ## Updating the Bootstrap Workflow
 
@@ -47,5 +47,5 @@ Each of your repositories will contain a Bootstrap Pull Request. Follow the inst
 
 :::info
 
-The bootstrapping pull requests include pre-configured files, such as a `mise.toml` file that specifies versions of OpenTofu and Terragrunt. Ensure you review and update these configurations to align with your organization's requirements.
+The bootstrapping pull requests include pre-configured files, such as a `.mise.toml` file that specifies versions of OpenTofu and Terragrunt. Ensure you review and update these configurations to align with your organization's requirements.
 :::
diff --git a/docs/2.0/docs/accountfactory/installation/index.md b/docs/2.0/docs/accountfactory/installation/index.md
@@ -2,23 +2,20 @@
 
 ## Overview
 
-Account Factory is automatically integrated into [new Pipelines root repositories](/2.0/docs/pipelines/installation/addingnewrepo) during the bootstrapping process.
+Account Factory is automatically integrated into [new Pipelines root repositories](/2.0/docs/accountfactory/installation/addingnewrepo) during the bootstrapping process.
 
 By default, Account Factory includes the following components:
 
 - 📋 An HTML form for generating workflow inputs: `.github/workflows/account-factory-inputs.html`
-  
+
 - 🏭 A workflow for generating new requests: `.github/workflows/account-factory.yml`
-  
+
 - 🗃️ A root directory for tracking account requests: `_new-account-requests`
-  
+
 - ⚙️ A YAML file for tracking account names and IDs: `accounts.yml`
 
 For detailed instructions on using these components, refer to the [Vending a New AWS Account Guide](/2.0/docs/accountfactory/guides/vend-aws-account).
 
 ## Configuring account factory
 
 Account Factory is fully operational for vending new accounts without requiring any configuration changes. However, a [comprehensive reference for all configuration options is available here](/2.0/reference/accountfactory/configurations), allowing you to customize values and templates for generating Infrastructure as Code (IaC) for new accounts.
-
-
-
diff --git a/...tallation/prerequisites/awslandingzone.md → ...ntfactory/prerequisites/awslandingzone.md b/...tallation/prerequisites/awslandingzone.md → ...ntfactory/prerequisites/awslandingzone.md
@@ -1,11 +1,10 @@
 import CustomizableValue from '/src/components/CustomizableValue';
 
-
 # Landing Zone
 
 ## Overview
 
-The Landing Zone component establishes an initial best-practice AWS multi-account setup.
+The Landing Zone component establishes an initial best-practice AWS multi-account setup for use with Gruntwork Account Factory.
 
 ## Extending AWS Control Tower
 
@@ -242,16 +241,15 @@ Complete the following steps to prepare for Gruntwork Account Factory:
 
       3. Switch to the `Users` tab, select your management user from the list and click **Next**
 
-      4.  Select `AWSAdministratorAccess` from the list of Permission Sets, then click **Next**
+      4. Select `AWSAdministratorAccess` from the list of Permission Sets, then click **Next**
 
-      5.  Click `Submit` to finish assigning access to your user
+      5. Click `Submit` to finish assigning access to your user
 
 ## Next steps
 
 Now that Control Tower is configured, consider these next steps:
+
 - [Set up IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-choose-identity-source.html) for access control.
 - [Apply required controls or SCPs](https://docs.aws.amazon.com/controltower/latest/userguide/controls.html).
 - [Install Gruntwork Pipelines](/2.0/docs/pipelines/installation/viagithubapp).
 - [Set up Gruntwork Account Factory](/2.0/docs/accountfactory/installation).
-
-
diff --git a/docs/2.0/docs/overview/getting-started/index.md b/docs/2.0/docs/overview/getting-started/index.md
@@ -7,7 +7,7 @@ Create your Gruntwork account and invite your team members to access Gruntwork r
 
 <PersistentCheckbox id="install-df-1" label="Gruntwork Account Ready" />
 
-### Step 2: [Set up a Landing Zone](/2.0/docs/pipelines/installation/prerequisites/awslandingzone)
+### Step 2: [Set up a Landing Zone](/2.0/docs/accountfactory/prerequisites/awslandingzone)
 
 Follow Gruntwork's AWS Landing Zone walkthrough to implement a best-practice multi-account setup, ready for use with DevOps Foundations.
 

diff --git a/docs/2.0/docs/pipelines/architecture/execution-flow.md b/docs/2.0/docs/pipelines/architecture/execution-flow.md
@@ -10,6 +10,6 @@ The orchestrator analyzes each infrastructure change in a pull request or git co
 
 ## Executor
 
-The executor receives as inputs a pipeline action (e.g. `terragrunt plan`) and a specific unit of infrastructure that has been changed (e.g. `/path/to/changed-unit/terragrunt.hcl`) and executes the specified action on the specified unit. 
+The executor receives as inputs a pipeline action (e.g. `terragrunt plan`) and a specific unit of infrastructure that has been changed (e.g. `/path/to/changed-unit/terragrunt.hcl`) and executes the specified action on the specified unit.
 
 For example, when responding to a `ModuleUpdated` event for `/some/unit/terragrunt.hcl`, the executor might execute a `terragrunt apply` on `/some/unit/terragrunt.hcl`. Or when responding to `AccountsAdded` events on merge, the executor may create a follow-up pull request in the `infrastructure-live-root` repository to include additional IaC code for baselining the newly added accounts.
diff --git a/docs/2.0/docs/pipelines/architecture/index.md b/docs/2.0/docs/pipelines/architecture/index.md
@@ -8,7 +8,7 @@ Outside of the main binary, Pipelines has several other components that work tog
 
 By design, customers run the binary as part of their CI/CD pipelines (e.g. GitHub Actions, GitLab CI, etc.). As such, Gruntwork provides out-of-the-box CI/CD configurations for supported platforms when customers sign up for Gruntwork Pipelines.
 
-We likewise provide CI/CD configurations for [Gruntwork Account Factory](https://docs.gruntwork.io/account-factory/overview). 
+We likewise provide CI/CD configurations for [Gruntwork Account Factory](https://docs.gruntwork.io/account-factory/overview).
 
 When using Gruntwork Pipelines without Gruntwork Account Factory, customers are responsible for configuring their repositories to use the appropriate CI/CD configuration for that platform (see [Adding Pipelines to an Existing Repository](/2.0/docs/pipelines/installation/addingexistingrepo) for more information). This code is typically fairly minimal, and the majority of the work is done by reusable workflows made available by Gruntwork, and the binary itself.
 

diff --git a/docs/2.0/docs/pipelines/architecture/security-controls.md b/docs/2.0/docs/pipelines/architecture/security-controls.md
@@ -47,7 +47,7 @@ Requires that the following tokens are created:
 - `INFRA_ROOT_WRITE_TOKEN`: Fine-grained PAT with read/write access to infrastructure repositories
 - `ORG_REPO_ADMIN_TOKEN`: Fine-grained PAT with admin access for repository management
 
-See [Setup via Machine Users](/2.0/docs/pipelines/installation/viamachineusers.md) for more details.
+See [Setup via Machine Users](/2.0/docs/pipelines/installation/viamachineusers) for more details.
 
 </TabItem>
 <TabItem value="gitlab" label="GitLab">

diff --git a/docs/2.0/docs/pipelines/concepts/cloud-auth/index.md b/docs/2.0/docs/pipelines/concepts/cloud-auth/index.md
@@ -17,9 +17,9 @@ Cloud authentication in Pipelines is built on the principle of least privilege a
 
 Currently, Pipelines supports authentication to the following cloud providers:
 
-- [AWS](./aws.mdx) - AWS authentication using OIDC
-- [Azure](./azure.md) - Azure authentication using OIDC
-- [Custom](./custom.md) - Custom authentication you can implement yourself
+- [AWS](/2.0/docs/pipelines/concepts/cloud-auth/aws) - AWS authentication using OIDC
+- [Azure](/2.0/docs/pipelines/concepts/cloud-auth/azure) - Azure authentication using OIDC
+- [Custom](/2.0/docs/pipelines/concepts/cloud-auth/custom) - Custom authentication you can implement yourself
 
 ## Security Best Practices
 

diff --git a/docs/2.0/docs/pipelines/configuration/driftdetection.md b/docs/2.0/docs/pipelines/configuration/driftdetection.md
@@ -2,4 +2,4 @@
 
 If you are a Pipelines Enterprise customer using GitHub or GitLab and used the infrastructure-live-root repository template to install Pipelines, Drift Detection is already included and available as a workflow in your repository.
 
-For installations not based on the template, follow the [Installing Drift Detection Guide](/2.0/docs/pipelines/guides/installing-drift-detection.md) to enable Drift Detection.
+For standalone installations that did not use the `infrastructure-live-root` repository template, follow the [Installing Drift Detection Guide](/2.0/docs/pipelines/guides/installing-drift-detection.md) to enable Drift Detection.
diff --git a/docs/2.0/docs/pipelines/configuration/settings.md b/docs/2.0/docs/pipelines/configuration/settings.md
@@ -1,11 +1,9 @@
 # Pipelines Configuration
 
-[Full Pipelines Configuration Reference](/docs/2.0/reference/pipelines/configurations.md)
-
 import PipelinesConfig from '/docs/2.0/reference/pipelines/language_auth_partial.mdx'
 
 <PipelinesConfig />
 
-## Terraform & OpenTofu
+## OpenTofu & Terraform
 
-You can specify whether to invoke Terraform or OpenTofu in your Pipeline by configuring the [tf-binary](/2.0/reference/pipelines/configurations#tf-binary) setting. Define the versions of `tf-binary` and Terragrunt in the [mise.toml](/2.0/reference/pipelines/configurations#example-mise-configuration) file within your repository.
+You can specify whether to invoke OpenTofu or Terraform with Pipelines by configuring the [tf-binary](/2.0/reference/pipelines/configurations#tf-binary) setting. Define the versions of Terragrunt and OpenTofu/Terraform used by Pipelines in the [mise.toml](/2.0/reference/pipelines/configurations#example-mise-configuration) file within your repository.
diff --git a/docs/2.0/docs/pipelines/guides/setup-delegated-repo.mdx b/docs/2.0/docs/pipelines/guides/setup-delegated-repo.mdx
@@ -19,7 +19,7 @@ Delegating infrastructure management might be necessary for reasons such as:
 
   For example, a repository with application code may need to build and push a container image to AWS ECR before deploying it to a Kubernetes cluster.
 
-The following guide assumes you have completed the [Pipelines Setup & Installation](/2.0/docs/pipelines/installation/prerequisites/awslandingzone.md).
+The following guide assumes you have completed the [Pipelines Setup & Installation](/2.0/docs/accountfactory/prerequisites/awslandingzone).
 
 ## Step 1 - Verify the delegated account setup
Original file line number	Diff line number	Diff line change
Expand Up		@@ -2,4 +2,4 @@

		If you are a Pipelines Enterprise customer using GitHub or GitLab and used the infrastructure-live-root repository template to install Pipelines, Drift Detection is already included and available as a workflow in your repository.

		For installations not based on the template, follow the [Installing Drift Detection Guide](/2.0/docs/pipelines/guides/installing-drift-detection.md) to enable Drift Detection.
		For standalone installations that did not use the `infrastructure-live-root` repository template, follow the [Installing Drift Detection Guide](/2.0/docs/pipelines/guides/installing-drift-detection.md) to enable Drift Detection.