Merge pull request #1027 from Azure/hotfix/documentationSyntaxFix

Syntax fix

Author: sterit

Docs/manual-configuration.md

@@ -3,13 +3,14 @@
 This guide walks you through manually setting up EPAC when the Hydration Kit doesn't meet your specific requirements. 
 
 **When to use Manual Configuration:**
+
 - Complex multi-tenant scenarios
 - Custom folder structures or naming conventions 
 - Advanced customization requirements
 - Specific compliance or organizational constraints
 
 > [!TIP]
-> **Consider the Hydration Kit first** - Even for advanced scenarios, you might start with the Hydration Kit and then customize the generated configuration. This can save time and provide a solid foundation. If they Hydration Kit is lacking on specific functionality that prevents its use in your environment, please **[Open a GitHub Issue](https://github.com/Azure/enterprise-azure-policy-as-code/issues)** to provide feedback and feature requests.
+> **Consider the Hydration Kit first:** Even for advanced scenarios, you might start with the Hydration Kit and then customize the generated configuration. This can save time and provide a solid foundation. If they Hydration Kit is lacking on specific functionality that prevents its use in your environment, please **[Open a GitHub Issue](https://github.com/Azure/enterprise-azure-policy-as-code/issues)** to provide feedback and feature requests.
 
 ## Prerequisites
 
@@ -77,8 +78,9 @@ Deploy-RolesPlan -PacEnvironmentSelector "epac-dev"
 
 > [!NOTE]
 > Many scripts use parameters for input and output folders. They default to the current directory. We recommend that you do one of the following approaches instead of accepting the default to prevent your files being created in the wrong location:
-    - [Preferred] Set the environment variables `PAC_DEFINITIONS_FOLDER`, `PAC_OUTPUT_FOLDER`, and `PAC_INPUT_FOLDER`.
-    - [Alternative] Use the script parameters `-DefinitionsRootFolder`, `-OutputFolder`, and `-InputFolder`.
+>
+>- [Preferred] Set the environment variables `PAC_DEFINITIONS_FOLDER`, `PAC_OUTPUT_FOLDER`, and `PAC_INPUT_FOLDER`.
+>- [Alternative] Use the script parameters `-DefinitionsRootFolder`, `-OutputFolder`, and `-InputFolder`.
 
 ## Starter Kit Pipelines
 

Docs/start-hydration-kit.md

@@ -69,38 +69,38 @@ The Hydration Kit will present you with a series of questions that will drive co
 
 #### Initial Configuration
 
-1. **Confirm your Tenant ID** - Verify you're authenticated to the correct Azure tenant
-1. **Set a PAC Owner ID** - Manually Specify a `pacOwnerId` or let the Hydration Kit auto-generate a GUID
-1. **Implement CAFv3** - Decide whether to deploy the CAFv3 Management Group Structure within the specified `tenantIntermediateRoot`.
-1. **Confirm provided scope** - Verify the `tenantIntermediateRoot` Management Group specified exists, and create one if not.
+1. **Confirm your Tenant ID:** Verify you're authenticated to the correct Azure tenant
+1. **Set a PAC Owner ID:** Manually Specify a `pacOwnerId` or let the Hydration Kit auto-generate a GUID
+1. **Implement CAFv3:** Decide whether to deploy the CAFv3 Management Group Structure within the specified `tenantIntermediateRoot`.
+1. **Confirm provided scope:** Verify the `tenantIntermediateRoot` Management Group specified exists, and create one if not.
 
 #### Cloud Adoption Framework (CAF) Naming
 If you elect to deploy the CAFv3 Management Group structure, you will additionally be prompted for:
 
-1. **Prefix for Management Groups** - (optional) Add a prefix to the CAFv3 Management Groups that will be created
-1. **Suffix for Management Groups** - (optional) Add a suffix to the CAFv3 Management Groups that will be created
+1. **Prefix for Management Groups:** (optional) Add a prefix to the CAFv3 Management Groups that will be created
+1. **Suffix for Management Groups:** (optional) Add a suffix to the CAFv3 Management Groups that will be created
 
 #### EPAC Environment Setup
 
-1. **Main PacSelector** - Provide a symbolic `PacSelector` Name for the main EPAC Environment (`pacEnvironment`).
+1. **Main PacSelector:** Provide a symbolic `PacSelector` Name for the main EPAC Environment (`pacEnvironment`).
     - The `tenantIntermediateRoot` specified will be the `deploymentRootScope` for this `pacEnvironment`.
-1. **epac-dev Parent** - Provide a Management Group that the `epac-dev` environment will be created. 
+1. **epac-dev Parent:** Provide a Management Group that the `epac-dev` environment will be created. 
     - A copy of the `tenantIntermediateRoot` Management Group specified (and all its child Management Groups) will be created as a child of this management group.
-1. **Managed Identity Location** - Choose a default Managed Identity Location for DeployIfNotExists and Modify Policies
+1. **Managed Identity Location:** Choose a default Managed Identity Location for DeployIfNotExists and Modify Policies
 
 #### epac-dev Naming
 
 To support the `epac-dev` environment being deployed, a copy of the `tenantIntermediateRoot` Management Group (and all its child Management Groups) will be deployed. You have the option to:
 
-1. **Prefix for Management Groups** - (optional) Add a prefix to the copied Management Groups that will be created for `epac-dev`
-1. **Suffix for Management Groups** - (optional) Add a suffix to the  copied Management Groups that will be created for `epac-dev`
+1. **Prefix for Management Groups:** (optional) Add a prefix to the copied Management Groups that will be created for `epac-dev`
+1. **Suffix for Management Groups:** (optional) Add a suffix to the  copied Management Groups that will be created for `epac-dev`
 
 #### Policy Import and Compliance Frameworks
 
 The Hydration Kit can help you get started with some initial policies, as well as import existing polices. You will be given the option to:
 
-1. **Import Policies** - Import existing policies into EPAC - this will create the required EPAC files for managing these policies.
-1. **Deploy Compliance Frameworks** - Add additional compliance frameworks to EPAC.
+1. **Import Policies:** Import existing policies into EPAC - this will create the required EPAC files for managing these policies.
+1. **Deploy Compliance Frameworks:** Add additional compliance frameworks to EPAC.
     - PCI-DSS compliance framework
     - NIST 800-53 v5 compliance framework.
     - Additional Built-In Policy Sets (specified via definition ID)
@@ -114,8 +114,8 @@ The Hydration Kit can help you get started with some initial policies, as well a
 #### CI/CD Pipeline Configuration
 
 EPAC supports various options for running EPAC through CI/CD pipelines. Choose the DevOps approach that best fits your existing toolsets:
-1. **Execution method:** - Run EPAC via PowerShell Module (recommended) or source code
-1. **Platform:** - Select starter pipelines built for GitHub Actions or Azure DevOps Pipelines
+1. **Execution method:** Run EPAC via PowerShell Module (recommended) or source code
+1. **Platform:** Select starter pipelines built for GitHub Actions or Azure DevOps Pipelines
 
 ## Current Limitations
 

Docs/start-implementing.md

@@ -3,9 +3,10 @@
 EPAC (Enterprise Azure Policy as Code) enables you to manage Azure Policy at scale using Infrastructure as Code principles. This guide will help you understand core concepts and choose the right implementation path for your organization.
 
 > [!IMPORTANT]
-> **Take time to understand the concepts** - Understanding EPAC's core concepts is crucial for successful implementation. Don't skip the EPAC Overview section.
+> **Take time to understand the concepts:** Understanding EPAC's core concepts is crucial for successful implementation. Don't skip the EPAC Overview section.
 
 **What you'll learn:**
+
 - Core EPAC concepts and terminology
 - Prerequisites and permissions needed
 - Implementation options (Hydration Kit vs Manual)
@@ -17,6 +18,7 @@ Before implementing EPAC, ensure you have the required knowledge, software, and
 
 ### Knowledge Requirements
 You should understand these Azure concepts:
+
 - [Azure Management Groups](https://learn.microsoft.com/en-us/azure/governance/management-groups/overview)
 - [Azure Policy](https://learn.microsoft.com/en-us/azure/governance/policy/overview)  
 - [Scope in Azure Policy](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/scope)
@@ -81,20 +83,22 @@ The `deploymentRootScope` defines where EPAC manages policies. EPAC can deploy a
 ![Sample Management Group Structure](./Images/sample-mg-structure.png)
 
 > [!IMPORTANT]
-> **Avoid Tenant Root Group** - Set your `deploymentRootScope` to an Intermediate Root Management Group rather than the Tenant Root Group to maintain flexibility and avoid lockout scenarios.  This is discussed in further detail in the Azure Cloud Adoption Framework [guidance](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-management-groups).
+> **Avoid Tenant Root Group:** Set your `deploymentRootScope` to an Intermediate Root Management Group rather than the Tenant Root Group to maintain flexibility and avoid lockout scenarios.  This is discussed in further detail in the Azure Cloud Adoption Framework [guidance](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-management-groups).
 
 ### EPAC Environments Overview
 
 Like any other solution or application, a development area is required to test and validate the solution before deploying to production. EPAC is the same, **however**, since Azure Policy affects all resources in your tenant, you need isolated space for policy development. 
 
 **The Challenge:** Testing new policies, or policy updates anywhere within your standard Management Group hierarchy could:
+
 - Disrupt existing workloads
 - Create compliance issues
 - Impact other teams' work
 
 For example, you may have an Azure policy assigned to control networking configuration, say to manage the firewall settings on storage accounts. This applies afor all workload types (platform, security, applications) and for all SDLC environments (production, development, sandbox, etc). You may need to update this policy, for instance to add a new allowed IP address. This policy needs to be tested before it rolls out to any scope within your environment to ensure there's no issues and its behaving accordingly. 
 
 **The Solution:** EPAC has the concept of **EPAC Environments**, or `pacEnvironments` providing isolated policy management with its own deployment scope.
+
 - Each **EPAC Environment** has a symbolic name (`pacSelector`) and its own distinct `deploymentRootScope` 
 - Each **EPAC Environment** is targeted separately for deployments, allowing you to manage policies independently. 
 
@@ -103,10 +107,12 @@ For example, you may have an Azure policy assigned to control networking configu
 Each **EPAC Environment** provides isolated policy management with its own deployment scope. This separation is crucial for safe policy development.
 
 **Typical Setup:**
+
 - **Tenant Environment** (`tenant01`): Manages policies in your main Management Group hierarchy
 - **Development Environment** (`epac-dev`): Manages policies in a separate, cloned Management Group hierarchy
 
 **Benefits of Separate Environments:**
+
 - Test policy changes without affecting other workloads
 - Validate compliance frameworks before deployment
 - Safely experiment with new policy configurations
@@ -136,10 +142,10 @@ The `global-settings` file, would then look something like this:
 }
 ``` 
 > [!IMPORTANT]
-> **epac-dev** - It is **strongly recommended** to create your development **EPAC Environment** with a `deploymentRootScope` that is **separate** from the rest of your tenant. Remember that EPAC expects to manage **ALL** policies within its `deploymentRootScope` and each `pacEnvironment` is independent, so creating an **EPAC Environment** that is nested within the `deploymentRootScope` of another **EPAC Environment** is generally not recommended.
+> **epac-dev:**It is **strongly recommended** to create your development **EPAC Environment** with a `deploymentRootScope` that is **separate** from the rest of your tenant. Remember that EPAC expects to manage **ALL** policies within its `deploymentRootScope` and each `pacEnvironment` is independent, so creating an **EPAC Environment** that is nested within the `deploymentRootScope` of another **EPAC Environment** is generally not recommended.
 
 > [!Tip]
-> **Main pacEnvironment Name** - You'll notice that we gave our main `pacEnvironment` the name `tenant01` instead of something like `production` and that **"EPAC Environment"** has been consistently bolded throughout the documentation. This is to create a distinction between environments that EPAC uses (`pacEnvironments`) and your general SDLC environments within your company (Prod, test, qa, dev, etc.) and Azure tenant. As discussed, it is important to separate the "Development" **EPAC Environment** from your regular development environments.
+> **Main pacEnvironment Name:** You'll notice that we gave our main `pacEnvironment` the name `tenant01` instead of something like `production` and that **"EPAC Environment"** has been consistently bolded throughout the documentation. This is to create a distinction between environments that EPAC uses (`pacEnvironments`) and your general SDLC environments within your company (Prod, test, qa, dev, etc.) and Azure tenant. As discussed, it is important to separate the "Development" **EPAC Environment** from your regular development environments.
 
 ### Managed Identities
 
@@ -170,6 +176,7 @@ DeployifNotExists (DINE) policies require a managed identity to function. If you
 ### Multi-Tenant Capabilities
 
 EPAC supports single and multi-tenant configurations including: 
+
 - **Multiple Azure tenants** from a single EPAC instance
 - **Azure Lighthouse managed tenants** 
 - **Cross-tenant role assignments** for centralized management
@@ -206,6 +213,7 @@ EPAC uses a simple folder structure to organize all policy resources:
 ![Definitions Folder Structure](./Images/definitions-folder-structure.png)
 
 **Key Files:**
+
 - **`global-settings.jsonc`**: Central configuration file defining environments and settings
 - **`policyDefinitions/`**: Custom policy definitions
 - **`policySetDefinitions/`**: Policy initiative (set) definitions  
@@ -231,6 +239,7 @@ Do you have complex multi-tenant requirements? → YES → Manual Configuration
 **Best for:** Most users, especially those new to EPAC
 
 **What it provides:**
+
 - Interactive setup with guided decisions
 - Setup of folder structure & generation of `global-settings.jsonc`
 - Automatic creation of `epac-dev` environment 
@@ -244,6 +253,7 @@ Do you have complex multi-tenant requirements? → YES → Manual Configuration
 **Best for:** Advanced users with specific customization needs
 
 **What it provides:**
+
 - Full control over every configuration aspect
 - Ability to integrate with existing setups
 - Custom folder structures and naming