diff --git a/docs/2.0/docs/accountfactory/architecture/index.md b/docs/2.0/docs/accountfactory/architecture/index.md
index 240d9a76e..37ddb2ed9 100644
--- a/docs/2.0/docs/accountfactory/architecture/index.md
+++ b/docs/2.0/docs/accountfactory/architecture/index.md
@@ -2,21 +2,21 @@
## Overview
-Account Factory builds upon Gruntwork's [AWS Control Tower Multi Account Factory](/reference/modules/terraform-aws-control-tower/control-tower-multi-account-factory/) and Pipelines to provide automated account creation, baselining, and managed IAM policies.
+Account Factory uses Gruntwork's [AWS Control Tower Multi Account Factory](/reference/modules/terraform-aws-control-tower/control-tower-multi-account-factory/) and Pipelines to automate account creation, baselining, and IAM policy management.
-In your `infrastructure-live-root` repository, the `_new-account-requests` directory acts as input for the Gruntwork Control Tower Module. This module runs within your management account and uses AWS Control Tower to provision new accounts and manage existing ones.
+In your `infrastructure-live-root` repository, the `_new-account-requests` directory acts as input for the Gruntwork Control Tower Module. The module, functioning within your management account, employs AWS Control Tower to efficiently provision new accounts and manage existing ones.
Pipelines tracks each provisioned account as a new base directory containing Terragrunt units in your `infrastructure-live-root` repository.
-## Account Vending
+## Account vending
-Account Vending starts when the Account Factory Workflow generates a Pull Request against `infrastructure-live-root`, adding a file to the `_new-account-requests` directory. Pipelines detects these new account requests and runs terragrunt plan/apply commands on the `control-tower-multi-account-factory` unit in the management account.
+Account vending begins when the Account Factory Workflow creates a pull request in `infrastructure-live-root`, adding a file to the `_new-account-requests` directory. Pipelines detects these new account requests and runs terragrunt plan/apply commands on the `control-tower-multi-account-factory` unit in the management account.
-After creating the account(s), Pipelines provisions resources, including IaC-controlled OIDC authenticated roles, which Pipelines can later use to deploy infrastructure changes within the account, and IAM policies that define the scope of changes Pipelines can deploy.
+After creating the account(s), Pipelines provisions resources such as IaC-controlled OIDC-authenticated roles. These roles, combined with IAM policies that define the scope of permissible changes, allow Pipelines to deploy infrastructure updates within the account.
-After adding this infrastructure to the repository, Pipelines deploys the resources into the AWS account and runs account baselines in the logs, security, and shared accounts to complete the provisioning process.
+Once this infrastructure is added to the repository, Pipelines deploys the resources into the AWS account and runs account baselines in the logs, security, and shared accounts to complete the provisioning process.
```mermaid
sequenceDiagram
@@ -28,12 +28,14 @@ sequenceDiagram
Infra Live Repository ->> Pipelines: Trigger Account Added
Pipelines ->> Core Accounts: Execute terragrunt to baseline account
```
-## IAM Roles
+## IAM roles
-Each new account includes IAM policies that define the scope of changes Pipelines can make within AWS. Pipelines automatically assumes the appropriate roles for each account when changes are detected. Read about the [roles in full here](/2.0/docs/pipelines/architecture/security-controls#roles-provisioned-by-devops-foundations).
+Newly created accounts include IAM policies that define the scope of changes Pipelines is authorized to perform within AWS. Pipelines automatically assumes the necessary roles for each account when it detects changes. Detailed information about the provisioned roles can be found [here](/2.0/docs/pipelines/architecture/security-controls#roles-provisioned-by-devops-foundations).
-## Delegated Repositories
+## Delegated repositories
-Delegated repositories expand the architecture of your infrastructure estate management and provide additional access control for your infrastructure. When vending delegated repositories, Pipelines continues tracking new account security baselines in your `infrastructure-live-root` repository, while other infrastructure is tracked in a new repository specific to the account(s). Pipelines inherits new IAM roles from your `infrastructure-live-access-control` repository when deploying infrastructure in delegated repositories. This setup allows the central platform team to control what changes individual teams can make via Pipelines in the delegated repository.
+Delegated repositories enhance the architecture of infrastructure management by introducing additional layers of access control. When delegated repositories are created, Pipelines continues to manage new account security baselines within the `infrastructure-live-root` repository, while other infrastructure resources are managed in a new repository specific to the delegated account(s).
+
+Pipelines uses IAM roles from the `infrastructure-live-access-control` repository to deploy infrastructure in these delegated repositories. This setup enables the central platform team to define and restrict the scope of changes individual teams can make via Pipelines in delegated repositories.
diff --git a/docs/2.0/docs/accountfactory/concepts/delegated-repositories.md b/docs/2.0/docs/accountfactory/concepts/delegated-repositories.md
index 4cbd6f47e..47b4fcfdd 100644
--- a/docs/2.0/docs/accountfactory/concepts/delegated-repositories.md
+++ b/docs/2.0/docs/accountfactory/concepts/delegated-repositories.md
@@ -1,21 +1,31 @@
# Delegated Repositories
-:::note
-Account Factory created Delegated Repositories are only available to DevOps Foundations Enterprise customers.
+:::note
+
+Account Factory-created Delegated Repositories are only available to DevOps Foundations Enterprise customers.
+
:::
-As enterprises scale their usage of IaC across more teams there often arises a need to enforce least-privilege access control to both IaC source code and the CI/CD of that code. Gruntwork's recommendation is to leverage multiple source code repositories to create hard-boundaries that enforce least-privilege access control. The pattern we recommend consists of three parts:
+As enterprises scale their usage of IaC across multiple teams, the need to enforce least-privilege access control to both IaC source code and its CI/CD processes becomes increasingly important. Gruntwork recommends leveraging multiple source code repositories to establish clear boundaries that enforce least-privilege access control.
+
+This approach involves a structured pattern that includes:
+
+- **Centralized `infrastructure-live-root` repository**
+ Governed by the core platform team, this repository contains IaC for essential security and shared infrastructure. Examples include account creation, central logging/auditing, and networking controls (e.g., GuardDuty, SecurityHub, Macie, Transit Gateway).
+
+- **Team-specific delegated repositories**
+ Named using a convention such as `infrastructure-live-$TEAM_NAME`, these repositories enable individual teams to manage their own IaC. The core platform team creates delegated repositories through the Account Factory. The `infrastructure-live-access-control` system controls access to these repositories, granting teams permissions specific to their infrastructure responsibilities.
+
+By adopting this pattern, core platform teams can:
+
+- Centrally manage compliance and security infrastructure.
+- Define and enforce which teams are authorized to deploy specific types of infrastructure, ensuring alignment with architecture board-approved plans.
+- Oversee shared and per-team infrastructure tags for consistency and governance.
+- Enforce least-privilege access policies, restricting teams to access only the IaC and deployment capabilities necessary for their responsibilities.
-1. A single `infrastructure-live-root` repository, ideally governed by the core platform team. This repository includes IaC for security and shared infrastructure including core-account creation, central logging/auditing and networking controls (e.g. GuardDuty, SecurityHub, Macie, Transit Gateway etc.).
-1. Many _delegated_ repositories, often named using the pattern `infrastructure-live-$TEAM_NAME`, where individual teams can manage their own IaC. These repositories are created by the core platform team using the Account Factory and, via `infrastructure-live-access-control`, are granted limited permissions to manage their own infrastructure.
-Using this pattern core platform teams have the ability to:
-* Centrally manage core compliance and security infrastructure
-* Centrally manage which teams have permission to deploy different types of infrastructure, allowing their team to enforce compliance with architecture-board approved plans
-* Centrally manage tags for shared and per-team infrastructure
-* Enforce least-privilege access to IaC, restricting teams to have access only to IaC and deployment capability / role assumptions for resources that they are responsible for.
+## Delegated repository creation
-## Delegated Repository Creation
-Delegated repositories are optionally created by [Account Factory](/2.0/docs/accountfactory/concepts) during account creation. A delegated account vend follows the following (automated) workflow:
+Delegated repositories can be optionally created by the [Account Factory](/2.0/docs/accountfactory/concepts) as part of the account provisioning process. The workflow for vending a delegated account follows these automated steps:
```mermaid
sequenceDiagram
diff --git a/docs/2.0/docs/accountfactory/concepts/index.md b/docs/2.0/docs/accountfactory/concepts/index.md
index 896733f22..b91cada50 100644
--- a/docs/2.0/docs/accountfactory/concepts/index.md
+++ b/docs/2.0/docs/accountfactory/concepts/index.md
@@ -1,28 +1,29 @@
# Gruntwork Account Factory
-Gruntwork Account Factory allows you to vend new AWS accounts with best practice account baselines.
+Gruntwork Account Factory lets you create new AWS accounts with best-practice baselines.
-For enterprise customers, new accounts can be created with their own delegated Infrastructure as Code repositories automatically when vending accounts. This allows a central platform team to automate the process by which new AWS accounts are created, and delegation of select infrastructure management to particular teams.
+Enterprise customers can create dedicated Infrastructure as Code repositories for new accounts during the vending process. As a result, central platform teams can automate AWS account creation and delegate infrastructure management to individual teams for scalability and autonomy.
-This allows developer teams to self-service deploy their own infrastructure within the bounds of IAM roles controlled in a dedicated access control repository, allowing for a combination of least privilege access to AWS resources and self-service infrastructure deployment.
+This approach empowers developer teams to self-service deploy infrastructure within the confines of IAM roles managed in a centralized access control repository. This approach ensures least-privilege access to AWS resources while enabling flexible, self-service infrastructure deployment.
-Gruntwork Account Factory is built on top of Gruntwork Pipelines. New account requests are tracked in git as IaC, triggering Terragrunt plans and applies to provision and baseline the new account. This allows the provisioning of new AWS accounts to be proposed and reviewed in the same way as any other infrastructure change, via pull requests.
+Gruntwork Account Factory is built on Gruntwork Pipelines, ensuring reliable and automated account provisioning. Account creation requests are tracked in Git as Infrastructure as Code (IaC), triggering Terragrunt plans and applies to set up and baseline the accounts. By following this approach, account provisioning follows the same review and collaboration steps as other infrastructure changes, using pull requests for validation
## Account baselines
-When provisioning new accounts, Gruntwork Account Factory doesn't just provision new AWS accounts, but also provisions a set of customizable baseline resources within those AWS accounts that make them ready to use for production workloads immediately.
+Gruntwork Account Factory does more than create AWS accounts—it also provisions a set of customizable baseline resources to prepare accounts for immediate use in production workloads.
-These baselines include things like:
+These baselines include:
+
+1. Security configurations for services such as [GuardDuty](https://aws.amazon.com/guardduty/), [SecurityHub](https://aws.amazon.com/security-hub/), and [Macie](https://aws.amazon.com/macie/), following best practices.
+2. Networking configurations aligned with best practices for [AWS VPCs](https://aws.amazon.com/vpc/).
+3. IAM roles designed for least privilege access, enabling CI/CD pipelines to manage AWS resources using [GitHub OIDC](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).
-1. Best practice security settings for services like [GuardDuty](https://aws.amazon.com/guardduty/), [SecurityHub](https://aws.amazon.com/security-hub/) and [Macie](https://aws.amazon.com/macie/).
-2. Best practice networking configurations for [AWS VPCs](https://aws.amazon.com/vpc/).
-3. Best practice IAM roles for least privilege access to manage AWS resources in CI/CD via [GitHub OIDC](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).
## White glove support
-Enterprise customers can expect white glove support in customizing their account baselines and vending process to meet their specific requirements. This includes:
+Enterprise customers benefit from tailored white glove support to customize account baselines and the vending process according to their needs. This support includes:
-1. Customizing the security configurations of the account baseline, and support in validating CIS compliance on day one.
-2. Customizing the networking configurations of the account baseline, and support for [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) configurations, including setup of network inspection appliances, like [AWS Network Firewall](https://aws.amazon.com/network-firewall/).
-3. Customizing the access control for delegated infrastructure management repositories, automatically granting particular teams access to manage their Infrastructure as Code for newly vended accounts.
+1. Adjusting security configurations within the account baseline and ensuring compliance with frameworks like CIS from the outset.
+2. Modifying networking configurations in the account baseline, including support for [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) setups and integration of network inspection appliances like [AWS Network Firewall](https://aws.amazon.com/network-firewall/).
+3. Customizing access control for delegated infrastructure management repositories, automatically assigning specific teams the necessary permissions to manage IaC for newly created accounts.
diff --git a/docs/2.0/docs/accountfactory/guides/collaborators.md b/docs/2.0/docs/accountfactory/guides/collaborators.md
index 0ec9b23d0..f673cd1a2 100644
--- a/docs/2.0/docs/accountfactory/guides/collaborators.md
+++ b/docs/2.0/docs/accountfactory/guides/collaborators.md
@@ -6,41 +6,41 @@ Delegated Repositories are only available to DevOps Foundations Enterprise custo
## Introduction
-When vending new delegated repositories you can configure a list of GitHub collaborators and permissions that will be added to the new repository.
+When creating new delegated repositories, you can configure a list of GitHub collaborators and their permissions to be added to the repository.
## Understanding collaborator settings
-GitHub collaborators can be defined in [account-factory configuration](/2.0/reference/accountfactory/configurations#github-collaborators).
+GitHub collaborators are defined in the [account-factory configuration](/2.0/reference/accountfactory/configurations#github-collaborators).
-Each object in the sequence is a pair of **Team Name** and **Permission**.
+Each collaborator entry consists of a **Team Name** and a **Permission**.
-#### Team Name
+#### Team name
-Teams must exist within your GitHub Organization where Account Factory is running.
+Teams must exist within the GitHub organization where Account Factory is running.
-To find a Team Name navigate to your Organization, and select the Teams tab. The Team Name is the unique identifier for each team.
+To locate a Team Name, navigate to your GitHub organization and select the "Teams" tab. The Team Name is the unique identifier for each team.
-In the above screenshot the Team Name is `platform-team`.
+In the example above, the Team Name is `platform-team`.
#### Permission
-Permissions directly map to the GitHub Teams API
+Permissions correspond to the GitHub Teams API.
-The options are `pull`, `triage`, `push`, `maintain`, `admin`, or a custom repository role name, if the your organization has defined any.
+Available options include `pull`, `triage`, `push`, `maintain`, `admin`, or a custom repository role name if defined by your organization.
## Adding collaborators
-To add a team to new delegated repositories add a new item to the collaborators block in your account factory configuration.
+To add a team to new delegated repositories, include a new entry in the `collaborators` block of your Account Factory configuration.
-All collaborators in each account type will be added to new repositories of that type when the repository is created. If you want to add a team to vended repositories of different types you will need to add them in multiple places.
+Collaborators for each account type are automatically added to the corresponding repositories when they are created. To give a team access to multiple repository types, add them to the configuration for each type.
-A common scenario is to create a team for administration that is granted access everywhere, and individual teams for each delegated repository.
+A common practice is to create an administrative team with access to all repositories, along with separate teams for each delegated repository.
-For example you might have the existing team `platform-admins`, and two account types `foo` and `bar`. For each account type you would then create a development team that should be granted push access to the repository `foo-devs` and `bar-devs`.
+For example, consider an organization with an administrative team called `platform-admins` and two account types, `foo` and `bar`. For each account type, you might create development teams with push access to their respective repositories, such as `foo-devs` and `bar-devs`.
-Your Account Factory configuration would look something like:
+The Account Factory configuration would look like this:
```yml title="./.gruntwork/config.yml"
@@ -62,6 +62,6 @@ pipelines:
## Updating existing repositories
-To update existing repositories you will need to manually make changes to the repository settings.
+To update existing repositories, you must manually modify the repository settings.
-See the documentation on GitHub for more information.
\ No newline at end of file
+Refer to the GitHub documentation for detailed instructions.
diff --git a/docs/2.0/docs/accountfactory/guides/delegated-repositories.md b/docs/2.0/docs/accountfactory/guides/delegated-repositories.md
index f9d9ae578..df437a772 100644
--- a/docs/2.0/docs/accountfactory/guides/delegated-repositories.md
+++ b/docs/2.0/docs/accountfactory/guides/delegated-repositories.md
@@ -7,54 +7,56 @@ Vending Delegated Repositories by Account Factory is only available to DevOps Fo
## Introduction
-When using Account Factory to request new account(s) you can chose to Delegate Management of the new accounts(s). This means that a new GitHub repository will be created for the account(s) allowing developer teams to provision their own infrastructure within their accounts.
+When using Account Factory to request new accounts, you can choose to delegate management of the new accounts. Delegating management automatically generates a dedicated GitHub repository for each account, empowering developer teams to manage their infrastructure independently.
-Specific permissions for IaC changes are controlled via IAM roles in your `infrastructure-live-access-control` repository, allowing your infrastructure team to act as a central authority for permissions.
+Specific permissions for IaC changes are managed via IAM roles in your `infrastructure-live-access-control` repository, enabling your infrastructure team to act as a central authority for permissions.
-### Step 1 - Update Account Factory Settings
-Account Factory options are located in `.gruntwork/config.yml`. See a full description of all account factory options in the [configuration reference](/2.0/reference/accountfactory/configurations).
+### Step 1 - Update Account Factory settings
-The following options are particularly relevant for delegated repositories and you may want to update them before creating the new account(s):
+Account Factory options are defined in the `.gruntwork/config.yml` file. For a full description of all available options, refer to the [configuration reference](/2.0/reference/accountfactory/configurations).
-#### Catalog Repositories
+The following options are especially relevant for delegated repositories and should be reviewed or updated before creating new accounts:
-Catalog Repositories are what your developer teams will use when running `terragrunt catalog` within their delegated repository. This defaults to your `infrastructure-catalog` repository but you can customize this list and the values will be vended into the newly created repository.
+#### Catalog repositories
+
+Catalog repositories are used by developer teams when running `terragrunt catalog` in their delegated repositories. By default, this points to your `infrastructure-catalog` repository, but you can customize the list. These values will be included in the newly created repositories.
[catalog-repositories](/2.0/reference/accountfactory/configurations#catalog-repositories)
-#### GitHub Collaborators
+#### GitHub collaborators
-GitHub Collaborators is a list of teams to automatically grant access to the new repository. This is optional to use as you can also manually set up access controls, but we do recommend configuring some teams and permissions to smooth out the vending process.
+GitHub collaborators define the list of teams granted automatic access to the new repository. This is optional, but we recommend configuring teams and permissions to streamline the account vending process.
[github-collaborators](/2.0/reference/accountfactory/configurations#github-collaborators)
-### Step 2 - Requesting the Account
-In a web browser open the file `.github/workflows/account-factory-inputs.html` from your `infrastructure-live-root` repository. This webpage is used to craft the initial account request payload that we will pass to the account factory workflow.
+### Step 2 - Requesting the account
+
+Open the `.github/workflows/account-factory-inputs.html` file in a web browser from your `infrastructure-live-root` repository. This page is used to generate the initial account request payload for the account factory workflow.
-The account name field will be used as the suffix for the GitHub name of the new repository.
+The account name field will be used as the suffix for the GitHub repository name.
-In the above example a new repository named `infra-live-new-account` will be created. It is important to use a unique name here that will not create a conflict with an existing repository in your GitHub Organization.
+In the above example, a new repository named `infra-live-new-account` will be created. Ensure the account name is unique to avoid conflicts with existing repositories in your GitHub organization.
-Fill out the form, and check the box "Delegate Management of Account(s)?"
+Fill out the form and check the "Delegate Management of Account(s)?" option.
-Press Generate and copy the resulting JSON. This is the payload we will pass into the Account Factory workflow.
+Click "Generate" and copy the resulting JSON payload. This payload will be passed to the Account Factory workflow.
-### Step 3 - Run the Account Factory Workflow
+### Step 3 - Run the Account Factory workflow
-Navigate to the Actions tab in your `infrastructure-live-root` repository and select the Account Factory workflow in the left hand pane.
+Go to the Actions tab in your `infrastructure-live-root` repository and select the Account Factory workflow from the left-hand pane.
-Select Run Workflow on the right, and paste the JSON payload into the input. Run the workflow.
+Click "Run Workflow," paste the JSON payload into the input field, and execute the workflow.
@@ -62,11 +64,11 @@ Select Run Workflow on the right, and paste the JSON payload into the input. Run
### Step 4 - Merge the Request PR
-The result of the Account Factory Workflow run will be a new Pull Request, adding a new YAML file in the `_new-account-requests` directory.
+The Account Factory workflow will generate a new Pull Request, adding a YAML file to the `_new-account-requests` directory.
-If everything looks as expected you can merge the pull request. Once the commit is on your main branch Pipelines will begin running a `terragrunt apply` that will create the new account in AWS.
+Review the Pull Request to ensure everything looks correct, then merge it. Once merged into the main branch, Pipelines will automatically run a `terragrunt apply` to create the new account in AWS.
-You can view the workflow run on the main branch. Provisioning the account(s) can take around 10 minutes to complete. Once the account has been created another Pull Request will be created in the `infrastructure-live-root` repository to baseline the new account.
+Provisioning typically takes around 10 minutes, but it may vary. Once complete, a new Pull Request will be created in the `infrastructure-live-root` repository to baseline the account.
@@ -74,61 +76,55 @@ You can view the workflow run on the main branch. Provisioning the account(s) ca
### Step 5 - Merge the Baseline PR
-The new Baseline PR contains required infrastructure for your delegated repository to plan and apply infrastructure changes in AWS, as well as account baselines and account specific infrastructure such as a VPC if configured.
-
-Inspect the baseline PR and merge it into your main branch to continue creating the account.
+The Baseline PR includes essential infrastructure for the delegated repository to manage infrastructure changes in AWS, along with account-specific infrastructure like VPCs if configured.
-This will kick off the following steps:
+Inspect the Baseline PR and merge it into the main branch. This triggers:
-- Terragrunt will run the core (security, logs, shared) account baselines for the new account(s)
-- Terragrunt will apply baselines for your new account(s) and create the new requested infrastructure.
-- Pipelines will create a new repository for your new account(s). As part of this step pipelines will also:
- - Set collaborators in the new repository from your configuration
- - Enable branch protection in the new repository. This step can fail if you are on a free (non paid) GitHub plan.
+- Terragrunt to apply core baselines (in the security, logs, and shared accounts) for the new account(s).
+- Baseline application for the new account(s), creating the requested infrastructure.
+- Pipelines to create the new repository for the account(s), including:
+ - Configuring collaborators from your settings.
+ - Enabling branch protection (may fail on free GitHub plans).
+ - Creating a Pull Request in the new repository with base IaC and Pipelines workflows.
+ - Creating a Pull Request in the `infrastructure-live-access-control` repository for IAM roles.
-- Pipelines will create a pull request in this new repository with the base IaC and Pipelines workflows for your new account(s).
-
-- Pipelines will create a pull request against your `infrastructure-live-access-control` repository containing IAM roles for your new repository.
-
-On completion the workflow run will show the following summary, linking to both of the new Pull Requests.
+Upon completion, the workflow run will display a summary linking to the new Pull Requests.
-Until the Access Control Pull Request has been merged, the workflows in your new repository will not be able to make infrastructure changes, so it is important to merge this pull request first.
+Merge the Access Control PR before running workflows in the new repository.
### Step 6 - Merge the Access Control PR
-Follow the link to the Access Control Pull Request and review the infrastructure changes in the PR. There are two new roles, `delegated-pipelines-apply-role` and `delegated-pipelines-plan-role` that grant permissions specifically for the new repository.
-
-These base roles contain the minimum permissions required to merge and apply the bootstrap PR in your new repository.
+Review the Access Control Pull Request, which adds two new roles: `delegated-pipelines-apply-role` and `delegated-pipelines-plan-role`. These roles grant the minimum permissions required to bootstrap the new repository.
-You can add additional permissions by adding to the [iam_policy](/reference/modules/terraform-aws-security/github-actions-iam-role/#iam_policy) block in each role.
+To add additional permissions, modify the [iam_policy](/reference/modules/terraform-aws-security/github-actions-iam-role/#iam_policy) block in each role.
-Managing these roles via the `infrastructure-live-access-control` repository allows your platform team to maintain full control over the specific change types that can occur in the delegated repository.
+Managing these roles through the `infrastructure-live-access-control` repository ensures your platform team retains control over changes in the delegated repository.
-Merge the PR and allow Pipelines to apply the terragrunt changes to create the roles in AWS.
+Merge the PR and allow Pipelines to apply the Terragrunt changes, creating the roles in AWS.
-### Step 7 - Merge the Delegated Repository Bootstrap PR
+### Step 7 - Merge the delegated repository Bootstrap PR
Once the Access Control PR has been merged and applied, navigate to the delegated repository and review the Bootstrap PR.
-This PR contains the necessary GitHub workflow files for Pipelines to run, as well as terragrunt configuration ready to start deploying new infrastructure.
+This PR contains the necessary GitHub workflow files for Pipelines and Terragrunt configurations to deploy new infrastructure.
-Merge this pull request and your delegated repository is read to use.
+Merge the PR, and the delegated repository will be ready for use.
### Step 8 - Start adding new infrastructure
-To summarize, at this point you will have:
-- Provisioned a new AWS account(s)
-- Applied baselines for the new account(s)
-- Created a new repository to manage infrastructure changes in this account(s)
-- Configured new IAM roles to manage permissions in the delegated repository
-- Bootstrapped the repository ready to add new infrastructure
+At this point, you will have:
+- Provisioned a new AWS account(s).
+- Applied baselines for the new account(s).
+- Created a new repository for managing infrastructure changes in the account(s).
+- Configured new IAM roles for permissions in the delegated repository.
+- Bootstrapped the repository for adding infrastructure.
-You can now start adding new infrastructure to the delegated repository.
+You can now begin adding new infrastructure to the delegated repository.
diff --git a/docs/2.0/docs/accountfactory/guides/iam-roles.md b/docs/2.0/docs/accountfactory/guides/iam-roles.md
index 562bc72dc..76e2bf39b 100644
--- a/docs/2.0/docs/accountfactory/guides/iam-roles.md
+++ b/docs/2.0/docs/accountfactory/guides/iam-roles.md
@@ -8,30 +8,30 @@ Delegated Repositories are only available to DevOps Foundations Enterprise custo
## Introduction
-When delegated repositories are vended from Account Factory they will be granted a minimal set of permissions in AWS to manage infrastructure. These permissions are controlled by IAM policies, tracked as IaC in your `infrastructure-live-access-control` repository. As part of the account provisioning process a pull request will be opened in the access control repository to add these policies.
+When delegated repositories are created using Account Factory, they are granted a minimal set of AWS permissions for managing infrastructure. These permissions are controlled through IAM policies, which are tracked as Infrastructure as Code (IaC) in your `infrastructure-live-access-control` repository. As part of account provisioning, a pull request is automatically created in the access control repository to add the necessary IAM policies.
-## Adding Permissions
+## Adding permissions
-You can add permissions to a role when the repository is created by modifying the Access Control Pull Request before it is merged, or by updating the policies in later updates.
+To grant additional permissions, modify the Access Control pull request during repository creation or update the policies in future changes.
-### Customizing a Specific Repository
+### Customizing a specific repository
+
+Each repository includes two sets of IAM policies in your `infrastructure-live-access-control` repository: one for `terragrunt plan` (read-only) and another for `terragrunt apply`.
-Each repository will have two sets of policies in your `infrastructure-live-access-control`, one used for `terragrunt plan` that should be read only, and another for `terragrunt apply`.
-
-To locate these policies, navigate to your `infrastructure-live-access-control` repository. The two terragrunt units for a given repository will be located in the following locations:
+To locate these policies, go to your `infrastructure-live-access-control` repository. The two Terragrunt units for a specific repository are located at the following paths:
- Plan role: `/_global/delegated-pipelines-plan-role/terragrunt.hcl`
- Apply role: `/_global/delegated-pipelines-apply-role/terragrunt.hcl`
-At the end of each terragrunt file you will find the following block
+At the end of each Terragrunt file, you will find the following block:
```hcl
iam_policy = {
}
```
-You can add additional policies granting permissions to this repository here. For example, to add read only ec2 permissions to the `plan` role you would add the following:
+You can add additional policies to grant permissions to the repository in this section. For example, to provide read-only EC2 permissions to the `plan` role, add the following:
```hcl
iam_policy = {
@@ -60,10 +60,10 @@ iam_policy = {
See the full description of the `iam_policy` input [in the library reference](/reference/modules/terraform-aws-security/github-actions-iam-role/#iam_policy).
-### Customizing All Delegated Repositories
-
-To add IAM roles to all delegated repositories you can modify the base roles in `_envcommon/landingzone/delegated-pipelines-plan-role.hcl` and `_envcommon/landingzone/delegated-pipelines-apply-role.hcl`.
+### Customizing all delegated repositories
+
+To add IAM roles to all delegated repositories, modify the base roles located in `_envcommon/landingzone/delegated-pipelines-plan-role.hcl` and `_envcommon/landingzone/delegated-pipelines-apply-role.hcl`.
-These HCL files also contain a `iam_policy` block which is already populated with the necessary policies for terragrunt to store state and perform bare-bones plans and applies.
+These HCL files include an `iam_policy` block, which is pre-populated with the necessary policies for Terragrunt to store state and perform basic plans and applies.
-You can expand this block by adding new policy descriptions, and they will be granted to all delegated repositories.
+You can extend this block by adding new policy descriptions, which will then apply to all delegated repositories.
diff --git a/docs/2.0/docs/accountfactory/guides/vend-aws-account.md b/docs/2.0/docs/accountfactory/guides/vend-aws-account.md
index fff924e26..61f2d0bc7 100644
--- a/docs/2.0/docs/accountfactory/guides/vend-aws-account.md
+++ b/docs/2.0/docs/accountfactory/guides/vend-aws-account.md
@@ -2,48 +2,49 @@
## Introduction
-The Account Factory Workflow in your `infrastructure-live-root` repository can be used to vend new AWS accounts. It takes a single input consisting of a JSON payload that you can generate from the `account-factory-inputs.html` web page.
+The Account Factory Workflow in your `infrastructure-live-root` repository can be used to create new AWS accounts. It requires a single input—a JSON payload—generated from the `account-factory-inputs.html` web page.
-We use a JSON payload to support more vending options, as GitHub Workflows are limited to only 10 inputs.
+The JSON payload approach provides greater flexibility for account vending, overcoming the GitHub workflow restriction of a 10-input maximum.
:::note
-This guide pertains only to non-delegated repositories. Enterprise customers are also able to [use Account Factory to create new Delegated Repositories](/2.0/docs/accountfactory/guides/delegated-repositories).
+
+This guide focuses on non-delegated repositories. Enterprise customers can also [use Account Factory to create new Delegated Repositories](/2.0/docs/accountfactory/guides/delegated-repositories).
+
:::
+
### Step 1 - Download the file
-Navigate to your `infrastructure-live-root` repository and download the inputs web page located at `.github/workflows/account-factory-inputs.html` to your local machine.
+Locate the inputs web page in your `infrastructure-live-root` repository at `.github/workflows/account-factory-inputs.html` and download it to your local machine.
### Step 2 - Populate the values
-Open `account-factory-inputs.html` in a web browser and populate the input options.
-
-At the end of the page click "Generate", and copy the JSON output into your clipboard.
+Open the downloaded `account-factory-inputs.html` file in a web browser and populate the input fields as required.
-### Step 3 - Run the Account Factory Workflow
+Once all values are filled, click "Generate" and copy the resulting JSON output to your clipboard.
-In GitHub, navigate to the Actions tab of your `infrastructure-live-root` repository and select `Account factory` on the left hand pane.
+### Step 3 - Run the Account Factory workflow
-Select "Run workflow" on the right and paste in the generated JSON payload into the dropdown.
+Access the Actions tab in your `infrastructure-live-root` repository on GitHub and select `Account factory` from the left-hand pane.
-Click the green "Run workflow" button in the dropdown and your workflow will begin running.
+Click "Run workflow" on the right, paste the generated JSON payload into the dropdown, and click the green "Run workflow" button to initiate the workflow.
-### Step 4 - Merge the Account Request PR
+### Step 4 - Merge the account request PR
-Once the workflow has completed a new Pull Request will be opened in your `infrastructure-live-root` repository adding an account request to the `_new-account-requests` directory.
+After the workflow is complete, a new Pull Request will be created in the `infrastructure-live-root` repository. This PR will add an account request to the `_new-account-requests` directory.
-Review and merge the pull request to being creating the account.
+Review and merge the Pull Request to begin the account creation process.
-When the account request PR has been merged into your main branch, Pipelines will begin creating the new account in AWS. This can take some time (generally 10 to 15 minutes though it can be up to 45).
+Once the account request PR merges into the main branch, Pipelines will initiate the account creation in AWS. This process typically takes 10 to 15 minutes but may extend to 45 minutes.
-- The SSO user created in the new account will be able to sign in using your organization’s [Access Portal Url](https://docs.aws.amazon.com/signin/latest/userguide/sign-in-urls-defined.html#access-portal-url). If the user is being invited into AWS IAM Identity Center (Successor to SSO) for this first time, they will receive an email with instructions on how to log in. Otherwise, the Portal Url can be provided by your organization’s administrator.
+- The SSO user created for the new account will use your organization's [Access Portal URL](https://docs.aws.amazon.com/signin/latest/userguide/sign-in-urls-defined.html#access-portal-url) to log in. New users invited to AWS IAM Identity Center (formerly AWS SSO) will receive an email with login instructions. Existing users can access the Portal URL through the organization's administrator.
-- The root user of the new account will receive an email and can login by following the “Forgot Password” flow in the [AWS Console’s Sign in page](https://console.aws.amazon.com/) to set a password and subsequently log in.
+- The root user of the new account will receive an email and can log in by following the "Forgot Password" process on the [AWS Console's Sign-in page](https://console.aws.amazon.com/).
-Once the account has been successfully created, Pipelines will open another Pull Request to baseline the new account.
+When the account is successfully created, Pipelines will open another Pull Request to baseline the account.
### Step 5 - Merge the Account Baseline PR
-Review and merge the Account Baseline Pull Request. This Pull Request contains required infrastructure for your delegated repository to plan and apply infrastructure changes in AWS, as well as account baselines and account specific infrastructure such as a VPC if configured.
+Review and merge the Account Baseline Pull Request. This PR contains essential infrastructure for enabling your delegated repository to plan and apply infrastructure changes in AWS. It also includes account baselines and configured account-specific infrastructure, such as a VPC.
-The new account's IaC is tracked in your `infrastructure-live-root` as a new directory. Once the Account Baseline PR has been merged to your main branch, and Pipelines has applied the changes, you are ready to start adding new infrastructure to your new account by adding Terragrunt units to this directory.
+The new account's Infrastructure as Code (IaC) is tracked in `infrastructure-live-root` as a newly created directory. Once the Account Baseline PR merges into the main branch and Pipelines applies the changes, you can add infrastructure to the new account by creating Terragrunt units in the directory.
diff --git a/docs/2.0/docs/accountfactory/installation/index.md b/docs/2.0/docs/accountfactory/installation/index.md
index ce8564b59..11a240e3b 100644
--- a/docs/2.0/docs/accountfactory/installation/index.md
+++ b/docs/2.0/docs/accountfactory/installation/index.md
@@ -2,20 +2,23 @@
## Overview
-Account Factory is automatically added to [new Pipelines root repositories](/2.0/docs/pipelines/installation/addingnewrepo) as part of the bootstrapping process.
+Account Factory is automatically integrated into [new Pipelines root repositories](/2.0/docs/pipelines/installation/addingnewrepo) during the bootstrapping process.
-Out of the box Account Factory has the following components:
-
-- 📋 An HTML form for generating workflow inputs: `.github/workflows/account-factory-inputs.html`
+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`
-- 🗃️ A root directory tracking account requests: `_new-account-requests`
+For detailed instructions on using these components, refer to the [Vending a New AWS Account Guide](/2.0/docs/accountfactory/guides/vend-aws-account).
-- ⚙️ A yaml file tracking account names and IDs: `accounts.yml`
+## Configuring account factory
-You can read more about how to use these components in the [Vending a New AWS Account Guide](/2.0/docs/accountfactory/guides/vend-aws-account).
+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.
-## Configuring Account Factory
+
-Account Factory is ready to start vending new accounts without modifying any options. If needed, you can find a [full reference of every configuration option here](/2.0/reference/accountfactory/configurations) allowing you to customize the values and templates used when generating new IaC for new accounts.
diff --git a/docs/2.0/docs/accountfactory/tutorials/modify-account.md b/docs/2.0/docs/accountfactory/tutorials/modify-account.md
index 4a11239ac..6cccf2a61 100644
--- a/docs/2.0/docs/accountfactory/tutorials/modify-account.md
+++ b/docs/2.0/docs/accountfactory/tutorials/modify-account.md
@@ -1,25 +1,24 @@
-
-
# Modifying an AWS Account
-Over time you will need to run various operations on your AWS accounts such as requesting new accounts, creating new accounts, renaming accounts, etc. With the Gruntwork Account Factory, some AWS account management operations should only be done using IaC, some can only be done using ClickOps, and some can be done using either.
+Managing AWS accounts involves tasks such as requesting new accounts, creating accounts, or renaming them. The Gruntwork Account Factory specifies which account management tasks must be performed exclusively through Infrastructure as Code (IaC), which are restricted to ClickOps in the AWS Console, and which support both methods.
+
+This page outlines the appropriate mode (IaC or ClickOps) for various AWS account operations. When both options are available, we strongly recommended IaC for consistency, auditability, and reduced manual error.
-In this page, we review which mode (IaC or ClickOps) to use for each AWS account operation. _When operations may be performed using either mode, we strongly recommend using IaC._
## Prerequisites
-This page applies to users who are:
-- Actively running Gruntwork Account Factory
-- Have access to an AWS user or IAM Role with administrative permissions to AWS Control Tower
+This page is intended for users who are:
+- Are actively running Gruntwork Account Factory
+- Have access to an AWS user or IAM role with administrative permissions for AWS Control Tower
## When to use IaC vs. ClickOps
-Below you'll find a table with common AWS account operations and the Gruntwork recommendation for if the operation should be done using IaC or in the AWS Console. When both options are available, using IaC is strongly recommended. You can explore more documentation for each operation by clicking on the operation name in the table.
+The table below lists common AWS account operations and provides guidance on whether to perform them using IaC or the AWS Console. Again, when both methods are supported, we strongly recommend IaC. For detailed information on each operation, click the operation name in the table.
-- ✅ means that the operation should or can only be done using the given mode.
-- ❌ means that the operation should not or cannot be done using the given mode.
+- ✅ means that the operation is allowed or only possible in the specified mode.
+- ❌ means the operation is not allowed or possible in the specified mode.
-| Management Operation | Terraform (IaC) | AWS Console (ClickOps) |
+| Management operation | Terraform (IaC) | AWS Console (ClickOps) |
|-------------------------------------------------------------------------------------------------------------------------------| ---------------- | ---------------------- |
| [Create a new Organization Unit](https://docs.aws.amazon.com/controltower/latest/userguide/create-new-ou.html) (OU) | ❌ | ✅ |
| [Request a new account](/2.0/docs/accountfactory/guides/vend-aws-account) | ✅ | ❌ |
@@ -33,13 +32,21 @@ Below you'll find a table with common AWS account operations and the Gruntwork r
| Granting additional users access to accounts in AWS IAM Identity Center | ✅ (recommended) | ✅ (discouraged) |
-### Updating the Account via the new AWS account request file
+### Updating the account through the new AWS account request file
-You may update some attributes of an AWS Account by modifying the account request file in `_new_account_requests`. See below for steps to update each attribute.
+You can update specific attributes of an AWS account by modifying the corresponding account request file in the `_new_account_requests` directory. Follow the steps below to update specific attributes:
-Start by creating a new branch that will contain your changes.
+#### Steps to update
-1. Update the name of the OU by modifying the `organizational_unit_name` key
-1. Updating the account admin user by modifying the `sso_user_first_name`, `sso_user_last_name`, and `sso_user_email` keys to the new users first name, last name, and email.
+1. Create a new branch to contain your changes.
+2. Update the desired attributes:
+ - To change the Organizational Unit (OU) name, modify the value of the `organizational_unit_name` key.
+ - To update the account admin user, adjust the `sso_user_first_name`, `sso_user_last_name`, and `sso_user_email` keys with the new user's first name, last name, and email.
+
+#### Applying the updates
-After you have made your modifications, push your branch and create a pull request. Gruntwork Pipelines will detect the account changes and run a `plan` operation. Review the output of the `plan` to confirm the output is as expected. Once confirmed, merge the PR to apply the changes.
+After completing your modifications:
+1. Push the branch with your changes and open a pull request.
+2. Gruntwork Pipelines automatically detects updates and executes a `plan` operation.
+3. Review the `plan` output to confirm the changes are accurate and align with expectations.
+4. Once validated, merge the pull request to apply the updates.
diff --git a/docs/2.0/docs/accountfactory/tutorials/remove-account.md b/docs/2.0/docs/accountfactory/tutorials/remove-account.md
index 3c370787d..4faed2f06 100644
--- a/docs/2.0/docs/accountfactory/tutorials/remove-account.md
+++ b/docs/2.0/docs/accountfactory/tutorials/remove-account.md
@@ -1,40 +1,41 @@
-
-
# Removing an AWS Account
## Prerequisites
-This page applies to users who are:
-- Actively running Gruntwork Account Factory
+This page is intended for users who:
+- Are actively running Gruntwork Account Factory
- Have access to an AWS user or IAM Role with administrative permissions to AWS Control Tower
## Procedure
-We recommend following a two step procedure to close AWS Accounts managed by Devops Foundations:
+We recommend a two-step process to close AWS accounts managed by DevOps Foundations:
1. [Cleanup Infrastructure Code](#1-cleanup-infrastructure-code) and modify OpenTofu/Terraform state for the Control Tower module.
1. [Close Account with Clickops](#2-close-the-accounts-in-aws-organizations)
-We are recommending that accounts be closed with ClickOps instead of using Gruntwork Pipelines. Removing the account via pipelines by deleting the account request file can and often does work, however the underlying AWS Service Catalog that we use to interact with Control Tower and deprovision the account is not (https://github.com/hashicorp/terraform-provider-aws/issues/31705) and often returns spurious errors that can require multiple retries to complete successfully. The procedure here is fundamentally about working around that unreliability.
+We recommend using ClickOps to close accounts instead of Gruntwork Pipelines. Removing the account through Pipelines by deleting the account request file often fails due to the unreliable AWS Service Catalog used with Control Tower (see [issue](https://github.com/hashicorp/terraform-provider-aws/issues/31705)), which frequently requires multiple retries. This procedure addresses those reliability issues.
-### 1. Cleanup Infrastructure Code
-All the code changes recommended here should be committed for each repository, **at the end**, to Git with a **[skip ci]** in the commit message to avoid triggering Gruntwork Pipelines CI processes.
+### 1. Clean up infrastructure code
+After making all necessary code changes, commit them to Git with **[skip ci]** in the message to avoid triggering Gruntwork Pipelines CI workflows.
-#### Root/Central Infrastructure Repository
-1. Obtain AWS CLI credentials for the your *management* account.
-1. Checkout a new branch in your central/root infrastructure repository
-1. Navigate to the `_new-account-requests` folder in the repository
-1. Delete the account request file corresponding to each account slated for removal
+#### Root/Central infrastructure repository
+
+1. Obtain AWS CLI credentials for your *management* account
+2. Create a new branch in your central/root infrastructure repository
+3. Navigate to the `_new-account-requests` folder in the repository
+4. Delete the account request file for each account to be removed
:::danger
- Make sure you are deleting the correct account request file and do not attempt to delete more than 5 accounts at once because [Control Tower has concurrent operations limit of 5](https://github.com/gruntwork-io/terraform-aws-control-tower/tree/main/modules/landingzone/control-tower-account-factory#resourceinuseexception).
+
+ Make sure you delete the correct account request file and do not attempt to delete more than five accounts at once, as [Control Tower has concurrent operations limit of 5](https://github.com/gruntwork-io/terraform-aws-control-tower/tree/main/modules/landingzone/control-tower-account-factory#resourceinuseexception).
+
:::
-1. Locate and modify the `accounts.yml` file in the repository, removing any data associated with the accounts to be removed.
-1. Remove the targeted account(s) from being controlled by the *management* account's Control Tower module by running the following commands:
+5. Edit the `accounts.yml` file in the repository to remove data for the accounts being deleted
+6. Remove the targeted account(s) from the Control Tower module in the *management* account by running these commands:
```bash
cd management/_global/control-tower-multi-account-factory/ # Navigate to the Control Tower module directory
@@ -43,54 +44,57 @@ All the code changes recommended here should be committed for each repository, *
terragrunt plan # Verify no accounts are set for destruction but outputs are updated
terragrunt apply # Apply the changes.
```
-1. (Optional) Remove AWS Transit Gateway(TGW) attachments. If an account being removed uses AWS TGW, you will need to remove the attachments by running the following commands sequentially:
+7. (Optional) Remove AWS Transit Gateway (TGW) attachments if the account uses AWS TGW by running:
```bash
cd /_global/transit_gateway_attachments/
terragrunt plan
terragrunt apply
```
+This is a plan/apply operation because the TGW module reads the `accounts.yml` file to determine which accounts are attached to the TGW.
+8. Delete the folders for the targeted accounts from the repository
+9. Commit the changes to your branch, including `[skip ci]` in the commit message
+10. Open a Pull Request and verify that `Pipelines Plan` is absent
+11. Approve and **squash-merge** the Pull Request (if multiple commits exist), again including [skip ci] in the commit message. This step will prevent Gruntwork Pipelines from initiating any destruction processes
- This is a plan/apply operation because the TGW module reads the `accounts.yml` file to determine which accounts are attached to the TGW.
+##### Delegated infrastructure repository (Enterprise-only)
-1. Delete the folders for the targeted accounts from the repository.
-1. Commit all changes to your branch, ensuring to include `[skip ci]` in the commit message.
-1. Open a Pull Request and observe that `Pipelines Plan` is absent.
-1. Approve and **squash-merge**(if you have multiple commits) the Pull Request, again ensuring to include `[skip ci]` in the commit message to prevent Gruntwork Pipelines from initiating any destruction processes.
+For accounts created in a separate delegated infrastructure repository:
-##### Delegated Infrastructure Repository (Enterprise-only)
+1. If all accounts in a delegated repository are closed, delete the entire repository. Otherwise, delete only the folders for the closed accounts
+2. Create and merge a Pull Request with [skip ci] in the commit message
+3. If delegated repositories were removed, **and** you have a setup that includes an `infrastructure-pipelines` repository; update the `infrastructure-pipelines` repository by removing references to the deleted repositories in the `.gruntwork/config` file via a Pull Request
-If targeted accounts were created as part of a separate delegated infrastructure-live repository and;
+##### Access control infrastructure repository (Enterprise-only)
+
+If an `infrastructure-access-control` repository is part of your setup:
-1. If all the accounts in a delegated repository have been closed; delete the entire repository else delete the accounts folders for only the closed accounts and repeat the CI steps of creating a PR and merging it with `[skip ci]` in the commit message.
-2. If delegated repositories were removed above **and** you have a setup that includes an `infrastructure-pipelines` repository; complete the cleanup process by removing the deleted repository references from the Gruntwork Pipelines configuration in `.gruntwork/config` file located in the `infrastructure-pipelines` repository via a Pull Request and merge it into the designated *main* branch.
+1. Remove the deleted account references from the accounts.yml file
+2. Delete the folders for the removed accounts from the repository
+3. Create and merge a Pull Request with [skip ci] in the commit message
-##### Access Control Infrastructure Repository (Enterprise-only)
+##### (Optional) Destroy resources in account before closing
-If your setup includes an `infrastructure-access-control` repository;
+If necessary, destroy resources provisioned in the account before closing it.
-1. Remove the deleted account references from the `accounts.yml` file in the access control repository.
-2. Remove the folders for the deleted accounts from the repository.
-3. Repeat the CI steps of creating a PR and merging it with `[skip ci]` in the commit message.
+You may need to delete resources if you encounter issues with coordination between different accounts where resources remain present in the account to be closed that are referenced in other accounts.
-##### (Optional) Destroy resources in Account before closing
+1. Create a new branch in the infrastructure repository
+2. Remove the folders containing the resources to be destroyed
+3. Commit changes and create a Pull Request, which will trigger Gruntwork Pipelines to destroy the resources upon merging
-You may choose or need to destroy some or all of your provisioned resources before closing an account. e.g You may need to delete resources if you encounter issues with coordination between different accounts where resources remain present in the account to be closed that are referenced in other accounts.
+:::danger
+
+ Make sure you delete the correct resources and back up any data needed for future use.
-1. Checkout a new branch in the infrastructure repository
-1. Remove the folder(s) containing the resources you want to destroy
-1. Commit your changes and create a Pull Request which will trigger Gruntwork Pipelines to destroy the resource once the Pull Request is merged.
-
- :::danger
- Make sure you are deleting the correct resources in the right account and that you have a backup of any data you may need in the future.
-
- It is not recommended that you delete the AWS IAM OIDC provider or the AWS IAM roles used by Pipelines within the AWS account before closing the account. This ensures that you can continue to use Pipelines to manage resources within it (including destroying resources) prior to its full closure.
- :::
+ Do not delete the AWS IAM OIDC provider or IAM roles used by Pipelines in the account to ensure Pipelines can manage resources, including destroying them, before the account is fully closed.
+
+ ::
### 2. Close the account(s) in AWS Organizations
-Using the AWS Console's Organizations interface for closing an account and destroying all of its resources is preferred due to current [flakiness](https://github.com/hashicorp/terraform-provider-aws/issues/31705) of the AWS Service Catalog when performing deletes via OpenTofu/Terraform providers. AWS Organizations will permanently [close an account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html) after 90 days.
+Use the AWS Console's Organizations interface to close accounts and destroy all resources, as it is more reliable than using OpenTofu/Terraform providers due to [AWS Service Catalog issues](https://github.com/hashicorp/terraform-provider-aws/issues/31705). AWS Organizations will permanently [close an account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html) after 90 days.
-1. Authenticate to your Management Account's AWS console with the necessary permissions to close accounts.
-2. Visit the [AWS Organizations page](https://console.aws.amazon.com/organizations).
-3. For each account targeted for deletion, select the "close" option.
+1. Log in to your management account's AWS Console with permissions to close accounts
+2. Visit the AWS Organizations page [AWS Organizations page](https://console.aws.amazon.com/organizations)
+3. For each account targeted for deletion, select the "close" option
diff --git a/docs/2.0/docs/pipelines/configuration/driftdetection.md b/docs/2.0/docs/pipelines/configuration/driftdetection.md
index 9bf91242c..388996f11 100644
--- a/docs/2.0/docs/pipelines/configuration/driftdetection.md
+++ b/docs/2.0/docs/pipelines/configuration/driftdetection.md
@@ -1,6 +1,6 @@
-
# Setting up Pipelines Drift Detection
If you're a Pipelines Enterprise customer and you installed Pipelines using our infrastructure-live-root repository template then Drift Detection is already installed and available as a GitHub workflow in your repository.
If you installed Pipelines in a manner other than from the template and you're an enterprise customer and you want to add Drift Detection, see the [Installing Drift Detection Guide](/2.0/docs/pipelines/guides/installing-drift-detection.md).
+
diff --git a/docs/2.0/docs/pipelines/configuration/settings.md b/docs/2.0/docs/pipelines/configuration/settings.md
index 0a1db0a64..c29cd2cae 100644
--- a/docs/2.0/docs/pipelines/configuration/settings.md
+++ b/docs/2.0/docs/pipelines/configuration/settings.md
@@ -9,4 +9,4 @@ import PipelinesConfig from '/docs/2.0/reference/pipelines/language_auth_partial
## Terraform & OpenTofu
-You can customize whether to invoke Terraform or OpenTofu in your Pipeline via the [tf-binary](/2.0/reference/pipelines/configurations#tf-binary) configuration. The version of the `tf-binary` and Terragrunt are configured via [mise.toml](/2.0/reference/pipelines/configurations#example-mise-configuration) inside your repository
\ No newline at end of file
+You can customize whether to invoke Terraform or OpenTofu in your Pipeline via the [tf-binary](/2.0/reference/pipelines/configurations#tf-binary) configuration. The version of the `tf-binary` and Terragrunt are configured via [mise.toml](/2.0/reference/pipelines/configurations#example-mise-configuration) inside your repository