rollback

Author: mumian

articles/azure-resource-manager/bicep/bicep-using.md

@@ -10,9 +10,9 @@ ms.custom: devx-track-bicep
 
 A `using` or a `using none` declaration must be present in all Bicep parameters files.
 
-A Bicep parameter file typically uses a `using` statement to tie the file to a [Bicep file](./file.md), a [JSON Azure Resource Manager template (ARM template)](../templates/syntax.md), a [Bicep module](./modules.md), or a [template spec](./template-specs.md). This linkage allows the Bicep language server and compiler to validate the parameter file—checking for correct names, types, and required values based on the template’s inputs.
+A Bicep parameter file typically uses a `using` statement to tie the file to a [Bicep file](./file.md), a [JSON Azure Resource Manager template (ARM template)](../templates/syntax.md), a [Bicep module](./modules.md), or a [template spec](./template-specs.md). This linkage allows the Bicep language server and compiler to validate the parameter file-checking for correct names, types, and required values based on the template’s inputs.
 
-In contrast, the `using none` statement explicitly indicates that the parameter file isn't tied to any particular template at compile time. This means the parameters aren't validated against a specific template and are instead intended for more general use—such as being consumed by external tools or serving as shared, reusable parameter sets.
+In contrast, the `using none` statement explicitly indicates that the parameter file isn't tied to any particular template at compile time. This means the parameters aren't validated against a specific template and are instead intended for more general use-such as being consumed by external tools or serving as shared, reusable parameter sets.
 
 > [!NOTE]
 > Bicep parameters files are supported only in [Bicep CLI version 0.18.4](https://github.com/Azure/bicep/releases/tag/v0.18.4) or later, [Azure CLI](/cli/azure/install-azure-cli) version 2.47.0 or later, and [Azure PowerShell](/powershell/azure/install-azure-powershell) version 9.7.1 or later. The `using none` feature is supported in [Bicep CLI version 0.31.0](https://github.com/Azure/bicep/releases/tag/v0.31.92) or later.
@@ -113,7 +113,7 @@ The primary benefit of `using none` in Bicep lies in scenarios where parameter f
 
 - **Centralized Parameter Repositories**
 
-  Organizations often maintain standard parameter values—such as default regions, naming conventions, or global tags—used across multiple Bicep deployments. A Bicep parameters file with using none can act as a central store for these shared values, improving consistency and minimizing duplication. These parameters can then be programmatically merged with template-specific values at deployment time.
+  Organizations often maintain standard parameter values-such as default regions, naming conventions, or global tags-used across multiple Bicep deployments. A Bicep parameters file with using none can act as a central store for these shared values, improving consistency and minimizing duplication. These parameters can then be programmatically merged with template-specific values at deployment time.
 
   For example, a shared Bicep parameters file might define:
 
@@ -129,7 +129,7 @@ The primary benefit of `using none` in Bicep lies in scenarios where parameter f
 
   In CI/CD pipelines or automation scripts, parameter files may be created on-the-fly or associated with templates at runtime. By omitting a fixed template reference, `using none` allows these files to remain flexible and adaptable to different deployment contexts.
 
-When `using none` is specified in a Bicep parameter file, the compiler doesn't validate the parameters against a specific Bicep template, meaning no compile-time warnings or errors are raised for mismatched names or types due to the absence of a linked template. However, this decoupling applies only during authoring and compilation—at deployment time, Azure Resource Manager (ARM) still requires both a Bicep template and a parameter file. The ARM engine performs validation during deployment by resolving the parameters in the file against those defined in the target template.
+When `using none` is specified in a Bicep parameter file, the compiler doesn't validate the parameters against a specific Bicep template, meaning no compile-time warnings or errors are raised for mismatched names or types due to the absence of a linked template. However, this decoupling applies only during authoring and compilation-at deployment time, Azure Resource Manager (ARM) still requires both a Bicep template and a parameter file. The ARM engine performs validation during deployment by resolving the parameters in the file against those defined in the target template.
 
 ## Next steps
 

articles/azure-resource-manager/bicep/deploy-what-if.md

@@ -59,7 +59,7 @@ The what-if operation in Bicep deployments may encounter "short-circuiting," a s
 
 ## Running the what-if operation
 
-Using a recent version of the Az PowerShell module (13.1.0 or later) or the Azure CLI (2.75.0 or later) will provide diagnostics when what-if cannot analyze part of the deployment. Earlier versions of these tools behave the same way, but they do not display the diagnostics. For example, if you use CLI version 2.74.0, the issue still occurs—it just happens silently.
+Using a recent version of the Az PowerShell module (13.1.0 or later) or the Azure CLI (2.75.0 or later) will provide diagnostics when what-if cannot analyze part of the deployment. Earlier versions of these tools behave the same way, but they do not display the diagnostics. For example, if you use CLI version 2.74.0, the issue still occurs-it just happens silently.
 
 ### What-if commands
 

articles/azure-resource-manager/bicep/deployment-script-develop.md

@@ -465,7 +465,7 @@ output result object = deploymentScript.properties.outputs
 
 ## Work with outputs
 
-The approach to handling outputs varies based on the type of script you're using—the Azure CLI or Azure PowerShell.
+The approach to handling outputs varies based on the type of script you're using-the Azure CLI or Azure PowerShell.
 
 # [CLI](#tab/CLI)
 

articles/azure-resource-manager/bicep/modules.md

@@ -551,7 +551,7 @@ With Bicep version 0.35.1 and later, the `@secure()` decorator can be applied to
 
 ## Module identity
 
-Starting with Bicep version 0.36.1, you can assign a user-assigned managed identity to a module. This makes the identity available within the module—for example, to access a Key Vault. However, this capability is intended for future use and is not yet supported by backend services.
+Starting with Bicep version 0.36.1, you can assign a user-assigned managed identity to a module. This makes the identity available within the module-for example, to access a Key Vault. However, this capability is intended for future use and is not yet supported by backend services.
 
 ```bicep
 param identityId string

articles/azure-resource-manager/bicep/resource-declaration.md

@@ -102,7 +102,7 @@ Markdown-formatted text can be used for the description text.
 
 ### onlyIfNotExists
 
-By default, when a Bicep deployment runs, Azure Resource Manager (ARM) creates the resource if it doesn’t exist or updates it if it does. If an existing resource has properties that differ from your template, ARM might attempt to update it—or fail if updates aren’t permitted.
+By default, when a Bicep deployment runs, Azure Resource Manager (ARM) creates the resource if it doesn’t exist or updates it if it does. If an existing resource has properties that differ from your template, ARM might attempt to update it-or fail if updates aren’t permitted.
 
 Starting with Bicep version v0.38.3, the `@onlyIfNotExists()` decorator instructs ARM to create the resource only if it does not already exist. If a resource with the resource ID is found, ARM skips creation and leaves the existing resource unchanged.
 

articles/azure-resource-manager/managed-applications/approve-just-in-time-access.md

@@ -44,9 +44,9 @@ This article focuses on the actions consumers take to enable JIT access and appr
 
    By default, a managed application with JIT enabled has the following settings:
 
-   - Approval mode – automatic
-   - Maximum access duration – 8 hours
-   - Approvers – none
+   - Approval mode - automatic
+   - Maximum access duration - 8 hours
+   - Approvers - none
 
    When the approval mode is set to **automatic**, the approvers receive a notification for each request but the request is automatically approved. When set to **manual**, the approvers receive a notification for each request, and one of them must approve it.
 

articles/azure-resource-manager/management/request-limits-and-throttling.md

@@ -125,7 +125,7 @@ Microsoft Compute implements throttling to provide an optimal experience for Vir
 
 [Azure Resource Graph](../../governance/resource-graph/overview.md) limits the number of requests to its operations. The steps in this article to determine the remaining requests and how to respond when the limit is reached also apply to Resource Graph. However, Resource Graph sets its own limit and reset rate. For more information, see [Resource Graph throttling headers](../../governance/resource-graph//concepts/azure-resource-graph-get-list-api.md).
 
-Azure Resource Graph also has a solution that enables an additional mechanism for getting resource data when you have reached resource provider throttling limits by seamlessly integrating with existing Azure Resource Manager control plane GET and LIST APIs—offering a powerful, scalable solution for resource data access. For more information, see [ARG GET/LIST API](../../governance/resource-graph//concepts/azure-resource-graph-get-list-api.md).
+Azure Resource Graph also has a solution that enables an additional mechanism for getting resource data when you have reached resource provider throttling limits by seamlessly integrating with existing Azure Resource Manager control plane GET and LIST APIs-offering a powerful, scalable solution for resource data access. For more information, see [ARG GET/LIST API](../../governance/resource-graph//concepts/azure-resource-graph-get-list-api.md).
 
 
 ### Other resource providers

articles/azure-resource-manager/management/tls-support.md

@@ -54,11 +54,11 @@ For a more detailed guidance, see the [checklist to deprecate older TLS versions
 
 ## Next steps
 
-* [Solving the TLS 1.0 Problem, 2nd Edition](/security/engineering/solving-tls1-problem) – deep dive into migrating to TLS 1.2.
-* [How to enable TLS 1.2 on clients](/mem/configmgr/core/plan-design/security/enable-tls-1-2-client) – for Microsoft Configuration Manager.
-* [Configure Transport Layer Security (TLS) for a client application](../../storage/common/transport-layer-security-configure-client-version.md) – contains instructions to update TLS version in PowerShell.
-* [Enable support for TLS 1.2 in your environment for Microsoft Entra TLS 1.1 and 1.0 deprecation](/troubleshoot/azure/active-directory/enable-support-tls-environment) – contains information on updating TLS version for WinHTTP.
-* [Transport Layer Security (TLS) best practices with the .NET Framework](/dotnet/framework/network-programming/tls) – best practices when configuring security protocols for applications targeting .NET Framework.
-* [TLS best practices with the .NET Framework](https://github.com/dotnet/docs/issues/4675) – GitHub to ask questions about best practices with .NET Framework.
-* [Troubleshooting TLS 1.2 compatibility with PowerShell](https://github.com/microsoft/azure-devops-tls12) – probe to check TLS 1.2 compatibility and identify issues when incompatible with PowerShell.
+* [Solving the TLS 1.0 Problem, 2nd Edition](/security/engineering/solving-tls1-problem) - deep dive into migrating to TLS 1.2.
+* [How to enable TLS 1.2 on clients](/mem/configmgr/core/plan-design/security/enable-tls-1-2-client) - for Microsoft Configuration Manager.
+* [Configure Transport Layer Security (TLS) for a client application](../../storage/common/transport-layer-security-configure-client-version.md) - contains instructions to update TLS version in PowerShell.
+* [Enable support for TLS 1.2 in your environment for Microsoft Entra TLS 1.1 and 1.0 deprecation](/troubleshoot/azure/active-directory/enable-support-tls-environment) - contains information on updating TLS version for WinHTTP.
+* [Transport Layer Security (TLS) best practices with the .NET Framework](/dotnet/framework/network-programming/tls) - best practices when configuring security protocols for applications targeting .NET Framework.
+* [TLS best practices with the .NET Framework](https://github.com/dotnet/docs/issues/4675) - GitHub to ask questions about best practices with .NET Framework.
+* [Troubleshooting TLS 1.2 compatibility with PowerShell](https://github.com/microsoft/azure-devops-tls12) - probe to check TLS 1.2 compatibility and identify issues when incompatible with PowerShell.
 

articles/azure-resource-manager/templates/deployment-history-deletions.md

@@ -8,7 +8,7 @@ ms.custom: devx-track-azurecli, devx-track-arm-template
 
 # Automatic deletions from deployment history
 
-When you deploy resources to Azure, the deployment details are recorded in the deployment history at the scope where the deployment occurs. Each scope—whether it's a [resource group](./deploy-to-resource-group.md), [subscription](./deploy-to-subscription.md), [management group](./deploy-to-management-group.md), [tenant](./deploy-to-tenant.md)—can store up to **800 deployments** in its history. Once this limit is reached, Azure **automatically deletes the oldest deployments** to make space for new ones. This automatic cleanup process was implemented on **August 6, 2020**.
+When you deploy resources to Azure, the deployment details are recorded in the deployment history at the scope where the deployment occurs. Each scope-whether it's a [resource group](./deploy-to-resource-group.md), [subscription](./deploy-to-subscription.md), [management group](./deploy-to-management-group.md), [tenant](./deploy-to-tenant.md)-can store up to **800 deployments** in its history. Once this limit is reached, Azure **automatically deletes the oldest deployments** to make space for new ones. This automatic cleanup process was implemented on **August 6, 2020**.
 
 > [!NOTE]
 > Deleting a deployment from the history doesn't affect any of the resources that were deployed.

articles/azure-resource-manager/templates/deployment-script-template.md

@@ -47,7 +47,7 @@ If you would rather learn about deployment scripts through step-by-step guidance
 
 For deployment script API version 2020-10-01 or later, there are two principals involved in deployment script execution:
 
-- **Deployment principal** (the principal used to deploy the template): this principal is used to create underlying resources required for the deployment script resource to execute — a storage account and an Azure container instance. To configure the least-privilege permissions, assign a custom role with the following properties to the deployment principal:
+- **Deployment principal** (the principal used to deploy the template): this principal is used to create underlying resources required for the deployment script resource to execute - a storage account and an Azure container instance. To configure the least-privilege permissions, assign a custom role with the following properties to the deployment principal:
 
     ```json
     {