Update setup-delegated-repo.mdx

docs/2.0/docs/pipelines/guides/setup-delegated-repo.mdx

@@ -10,50 +10,52 @@ If you are an Enterprise customer, Account Factory will automatically provision
 
 ## Introduction
 
-Infrastructure management delegation is a first-class concept in DevOps Foundations. To learn more about delegated repositories, click [here](/2.0/docs/accountfactory/architecture/#delegated-repositories).
+Infrastructure management delegation is a key feature in DevOps Foundations. To learn more about delegated repositories, click [here](/2.0/docs/accountfactory/architecture/#delegated-repositories).
 
-Reasons you might want to delegate management of infrastructure includes:
+Delegating infrastructure management might be necessary for reasons such as:
 
-- A different team is autonomously working on parts of infrastructure relevant to a specific account.
-- A GitHub Actions workflow in a repository needs to be able to make limited changes to infrastructure in a specific account.
+- Allowing a separate team to independently manage infrastructure relevant to a specific account.
+- Enabling a GitHub Actions workflow in a repository to make restricted changes to infrastructure in a specific account.
 
-  e.g. A repository has application code relevant to a container image that needs to be built and pushed to AWS ECR before it can be used in a Kubernetes cluster via a new deployment.
+  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 that you have already gone through [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/pipelines/installation/prerequisites/awslandingzone.md).
 
-## Step 1 - Ensure the delegated account is set up
+## Step 1 - Verify the delegated account setup
 
-Ensure that the account you want to delegate management for is set up. This includes the following:
+Ensure the target account is prepared for delegation with the following:
 
 1. The account is created in AWS.
-2. An OIDC provider is set up in the account.
-3. The account has the following roles provisioned:
-  - `infrastructure-live-access-control-plan`
-  - `infrastructure-live-access-control-apply`
+2. An OIDC provider is configured in the account.
+3. The account includes the following roles:
+   - `infrastructure-live-access-control-plan`
+   - `infrastructure-live-access-control-apply`
 
-If the account was provisioned normally using Account Factory, these roles should already be set up.
+These roles should already exist if the account was provisioned through Account Factory.
 
-If you want more information about exactly how this works, read [GitHub OIDC docs](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).
+For more details, refer to [GitHub OIDC documentation](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).
 
-## Step 2 - Ensure that the `infrastructure-live-access-control` repository is provisioned.
+## Step 2 - Confirm the `infrastructure-live-access-control` repository setup
 
-The [infrastructure-live-access-control](/2.0/docs/pipelines/architecture/security-controls.md#infrastructure-access-control) repository is an optionally provisioned part of DevOps Foundations, and it's the recommended way of delegating access to infrastructure.
+The [infrastructure-live-access-control](/2.0/docs/pipelines/architecture/security-controls.md#infrastructure-access-control) repository is an optional but recommended component of DevOps Foundations for delegating access to infrastructure.
 
-If you don't have this repository set up, you can follow the steps in the [infrastructure-live-root-template](https://github.com/gruntwork-io/infrastructure-live-root-template) to provision it.
+If this repository is not already set up, you can provision it using the steps in the [infrastructure-live-root-template](https://github.com/gruntwork-io/infrastructure-live-root-template).
 
-This repository will be where you manage the IAM access that your delegated repository will have.
+This repository will serve as the control point for managing IAM access for your delegated repository.
 
 ## Step 3 - Provision the delegated role
 
-To provision a role that can be assumed by the delegated repository, you will want to add it to the `infrastructure-live-access-control` repository.
+To create a role for the delegated repository, add it to the `infrastructure-live-access-control` repository.
 
 :::tip
-Typically, CI roles created for Pipelines are created in pairs, one for the `plan` stage and one for the `apply` stage. This is because the `plan` stage should have more limited permissions than the `apply` stage, as plans typically only need read-only access.
+CI roles for Pipelines are typically created in pairs: one for the `plan` stage and another for the `apply` stage. This structure limits permissions, granting read-only access during the `plan` stage.
 
-If you are creating a role to do something like push a container image to ECR on push to the repository, you may only need a single role.
+For tasks such as pushing a container image to ECR, you might only need a single role.
 :::
 
-Use Terragrunt Scaffold to create the new role in your `infrastructure-live-access-control` repository.
+Use Terragrunt Scaffold to create the new role in the `infrastructure-live-access-control` repository.
+
+
 
 ```bash
 # Assuming your `infrastructure-live-access-control` repository is named exactly that,
@@ -63,14 +65,14 @@ cd acme/_global/ecr-push-role
 terragrunt scaffold '[email protected]:gruntwork-io/terraform-aws-security.git//modules/github-actions-iam-role?ref=v0.73.2'
 ```
 
-This will give you a placeholder `terragrunt.hcl` file for a new role in your repository that you can customize to your needs.
+This will create a placeholder `terragrunt.hcl` file for a new role in your repository, which you can modify to suit your specific requirements.
 
-Alternatively, you can copy and paste the following:
+Alternatively, you can use the example configuration below:
 
 :::note
-Note the value of `allowed_sources`, which should be the organization, name, and ref of the repository you are delegating to.
+Pay attention to the `allowed_sources` value. This field should specify the organization, name, and ref of the repository being delegated to.
 
-If you would like to make it so that all refs in a repository can assume this role, you can use `["*"]` as the value on the right hand side.
+If you want to allow all refs in a repository to assume this role, you can set the value to `["*"]`.
 :::
 
 ```hcl
@@ -83,8 +85,9 @@ include "root" {
   path = find_in_parent_folders()
 }
 
-# Include the component configuration, which has settings that are common for the component across all environments
-include "envcommon" {
+# Incorporate the component configuration. This includes settings that are shared across all environments for the component.
+include "envcommon"
+ {
   path           = "${dirname(find_in_parent_folders("common.hcl"))}/_envcommon/landingzone/delegated-pipelines-plan-role.hcl"
   merge_strategy = "deep"
 }
@@ -94,37 +97,37 @@ inputs = {
   github_actions_openid_connect_provider_url = "https://token.actions.githubusercontent.com"
 
   # ----------------------------------------------------------------------------------------------------------------
-  # This is the map of repositories to refs that are allowed to assume this role.
+  # This defines the map of repositories to refs that are permitted to assume this role.
   #
-  # Note that for a plan role, typically the only additional permissions that are required are read permissions that
-  # grant Terragrunt permission to read the existing state in provisioned infrastructure, such that a plan of proposed
-  # updates can be generated.
+  # For a plan role, additional permissions are generally limited to read access, enabling Terragrunt
+  # to access the existing state of provisioned infrastructure. This ensures that a plan of proposed updates can be generated.
   #
-  # Also note that all refs are allowed to assume this role, as the plan role is typically assumed in refs used
-  # as sources for pull requests. Assign permissions keeping this in mind.
+  # Note that all refs are permitted to assume this role since plan roles are typically assumed by refs
+  # used as sources for pull requests. Ensure permissions are assigned with this in mind.
   #
-  # Read more on least privilege below.
+  # Refer to the documentation on least privilege for further details.
+
   # ----------------------------------------------------------------------------------------------------------------
 
   allowed_sources = {
     "$$ORGANIZATION$$/$$REPO$$" : ["$$REF$$"]
   }
 
   # ----------------------------------------------------------------------------------------------------------------
-  # Least privilege is an important best practice, but can be a very difficult practice to engage in.
+  # Least privilege is a critical best practice but can be challenging to implement effectively.
   #
-  # The `envcommon` include above provides the minimal permissions required to interact with TF state, however
-  # any further permissions are up to the user to define as needed for a given workflow.
+  # The `envcommon` include above provides the foundational permissions necessary to interact with Terraform state. 
+  # Additional permissions, however, must be defined by the user based on the specific needs of a given workflow.
   #
-  # These permissions are meant to be continuously refined in a process of iteratively granting additional permissions
-  # as needed to have workflows updated in CI correctly, and then removing excess permissions through continuous review.
+  # The permissions should be continuously refined by iteratively granting additional access as workflows in CI evolve 
+  # and then removing excess permissions through regular reviews.
   #
-  # A common pattern used to refine permissions is to run a pipeline with a best guess at the permissions required, or
-  # no permissions at all, and then review access denied errors and add the necessary permissions to have the pipeline
-  # run successfully.
+  # A typical approach to refining permissions involves running a pipeline with an initial guess of required permissions 
+  # (or none at all), reviewing any access denied errors, and then adding only the permissions necessary to enable 
+  # successful execution of the pipeline.
   #
-  # As workload patterns become more commonplace, this repo will serve as a reference for the permissions required to
-  # run similar workloads going forward.
+  # Over time, as workload patterns stabilize, this repository will serve as a reference for permissions needed to 
+  # support similar workflows, streamlining the process for future updates.
   # ----------------------------------------------------------------------------------------------------------------
 
   iam_policy = {
@@ -133,11 +136,11 @@ inputs = {
 }
 ```
 
-Note the `envcommon` include, which includes the common minimal configurations recommended for delegated roles in DevOps Foundations.
+Take note of the `envcommon` include, which incorporates the recommended baseline configurations for delegated roles within DevOps Foundations.
 
-You will likely need to expand the `iam_policy` block to include the permissions required for your specific workflow.
+You will probably need to extend the `iam_policy` block to define permissions tailored to your specific workflow requirements.
 
-For example, if you would like permissions to push to ECR, you might add the following:
+For instance, if you require permissions to push to ECR, you might include the following:
 
 ```hcl
 iam_policy = {
@@ -163,7 +166,8 @@ iam_policy = {
 
 ## Step 4 - Apply the role
 
-Once you have customized the role to your needs, you can apply it by creating a pull request in the `infrastructure-live-access-control` repository.
+Once you’ve customized the role configuration, create a pull request in the `infrastructure-live-access-control` repository. Review and approval of the pull request will ensure the role is applied to the AWS account.
+
 
 ```bash
 git add .
@@ -172,11 +176,11 @@ git push
 gh pr create --base main --title "feat: Add ECR push role for acme account" --body "This PR adds the ECR push role for the acme account."
 ```
 
-Inspect the pull request, verify the plan, then merge the pull request to get it applied.
+Inspect the pull request thoroughly, review the associated plan output to confirm the role configuration aligns with your requirements, and merge the pull request to apply the changes.
 
-## Step 5 - Set up the delegated repository
+## Step 5 - Configure the delegated repository
 
-Depending on what the repository needs to do in CI, your GitHub Actions workflow may be as simple as a file like the following placed in `.github/workflows/ci.yml`:
+The configuration of the delegated repository depends on the specific tasks it needs to perform during CI/CD workflows. For basic setups, the GitHub Actions workflow can include a file like the following placed in `.github/workflows/ci.yml`:
 
 ```yaml
 name: CI