casing

Author: LiSeda

articles/load-balancer/quickstart-load-balancer-standard-internal-bicep.md

@@ -12,7 +12,7 @@ ms.custom: template-quickstart, subject-armqs, mode-arm, devx-track-bicep,engage
 
 # Quickstart: Create an internal load balancer to load balance VMs using Bicep
 
-In this quickstart, you learn to use a BICEP file to create an internal; Azure load balancer. The internal load balancer distributes traffic to virtual machines in a virtual network located in the load balancer's backend pool. Along with the internal load balancer, this template creates a virtual network, network interfaces, a NAT Gateway, and an Azure Bastion instance.
+In this quickstart, you learn to use a Bicep file to create an internal Azure load balancer. The internal load balancer distributes traffic to virtual machines in a virtual network located in the load balancer's backend pool. Along with the internal load balancer, this template creates a virtual network, network interfaces, a NAT Gateway, and an Azure Bastion instance.
 
 :::image type="content" source="media/quickstart-load-balancer-standard-internal-portal/internal-load-balancer-resources.png" alt-text="Diagram of resources deployed for internal load balancer." lightbox="media/quickstart-load-balancer-standard-internal-portal/internal-load-balancer-resources.png":::
 

articles/operator-service-manager/how-to-manage-artifacts-nexus.md

@@ -29,7 +29,7 @@ This How-To article describes how to push artifacts to and pull artifacts from a
 - [Enable AOSM](quickstart-onboard-subscription-azure-operator-service-manager.md) on your Azure subscription
 - Install the [Azure CLI](/cli/azure/install-azure-cli)
 - Deploy an Artifact Store resource of type Azure Container Registry
-- Deploy an Artifact manifest resource that contains an entry for the artifact you want to install. This example shows the artifact manifest BICEP definition for a fictional Contoso CNF container image
+- Deploy an Artifact manifest resource that contains an entry for the artifact you want to install. This example shows the artifact manifest Bicep definition for a fictional Contoso CNF container image
 
 ```bicep
 resource acrArtifactManifest 'Microsoft.Hybridnetwork/publishers/artifactStores/artifactManifests@2023-09-01' = {

articles/operator-service-manager/how-to-manage-artifacts-virtualized-network-function-cloud.md

@@ -27,7 +27,7 @@ This How-To article describes how to push VHD images to and pull VHD images from
 - [Enable AOSM](quickstart-onboard-subscription-azure-operator-service-manager.md) on your Azure subscription
 - Installed the [Azure CLI](/cli/azure/install-azure-cli)
 - Deploy an Artifact Store resource of type Azure Storage Account
-- Deploy an Artifact manifest resource that contains an entry for the image you want to push. This example shows the artifact manifest BICEP definition for a fictional Contoso VNF virtual machine image
+- Deploy an Artifact manifest resource that contains an entry for the image you want to push. This example shows the artifact manifest Bicep definition for a fictional Contoso VNF virtual machine image
 
 ```bicep
 resource storageAccountArtifactManifest 'Microsoft.Hybridnetwork/publishers/artifactStores/artifactManifests@2023-09-01' = {

articles/operator-service-manager/how-to-onboard-azure-resource-manager-resources-cli.md

@@ -18,7 +18,7 @@ Onboarding is a multi-step process. Once you meet the prerequisites, you'll use
 
 1. Modify an existing NSDV input file for a previously onboarded CNF.
 1. Fill the input file with the information required to build the AOSM resource definitions.
-1. Generate BICEP files that define a Network Service Design Group and Version (NSDV) based on the input file and your ARM template.
+1. Generate Bicep files that define a Network Service Design Group and Version (NSDV) based on the input file and your ARM template.
 1. Publish the NSDV and upload the ARM Template to an Artifact Store (AOSM-managed Azure Container Registry (ACR)).
 
 This how-to guide uses Azure Key Vault (AKV) as an example of an Azure Resource, however, any Azure resource can be onboarded by following the same steps. This article uses a CNF as the example NF; the process is identical for a Virtualized Network Function (VNF) apart from minor differences in the NSDV input file.
@@ -41,7 +41,7 @@ This how-to guide uses Azure Key Vault (AKV) as an example of an Azure Resource,
 - Any parameters you want to expose to the operator who will deploy your NSDV must be defined as parameters in the ARM template.
 
 > [!NOTE]
-> The Az CLI AOSM Extension does not support onboarding Azure resources defined in a BICEP template. However, you can use the `bicep build` command to convert your BICEP files to ARM templates. See [the bicep CLI documentation](/azure/azure-resource-manager/bicep/bicep-cli) for detailed information and instructions.
+> The Az CLI AOSM Extension does not support onboarding Azure resources defined in a Bicep file. However, you can use the `bicep build` command to convert your Bicep files to ARM templates. See [the bicep CLI documentation](/azure/azure-resource-manager/bicep/bicep-cli) for detailed information and instructions.
 
 ### Helm and Docker engine
 

articles/operator-service-manager/how-to-onboard-containerized-network-function-cli.md

@@ -15,9 +15,9 @@ In this how-to guide, Network Function Publishers and Service Designers learn ho
 
 Onboarding is a multi-step process. Once you meet the prerequisites, you'll use the Azure CLI AOSM extension to:
 
-1. Generate BICEP files that define a Network Function Definition Group and Version (NFD) based on your Helm charts and values.yaml.
+1. Generate Bicep files that define a Network Function Definition Group and Version (NFD) based on your Helm charts and values.yaml.
 2. Publish the NFD and upload the CNF images and charts to an Artifact Store (AOSM-managed Azure Container Registry (ACR)).
-3. Add your published NFD to the BICEP files that define a Network Service Design Group and Version (NSD).
+3. Add your published NFD to the Bicep files that define a Network Service Design Group and Version (NSD).
 4. Publish the NSD.
 
 ## Prerequisites

articles/operator-service-manager/how-to-onboard-virtualized-network-function-cli.md

@@ -14,9 +14,9 @@ ms.custom: devx-track-azurecli
 
 In this how-to guide, Network Function Publishers and Service Designers learn how to use the Azure CLI AOSM extension to onboard a virtualized network function to AOSM. This VNF can subsequently be deployed on [Azure Operator Nexus](/azure/operator-nexus/overview). Onboarding is a multi-step process. Once you meet the prerequisites, you'll use the Azure CLI AOSM extension to:
 
-1. Generate BICEP files that define a Network Function Definition Group and Version (NFD).
+1. Generate Bicep files that define a Network Function Definition Group and Version (NFD).
 2. Publish the NFD and upload the VNF image to an Artifact Store (AOSM-managed Azure Container Registry (ACR)).
-3. Add your published NFD to the BICEP files that define a Network Service Design Group and Version (NSD).
+3. Add your published NFD to the Bicep files that define a Network Service Design Group and Version (NSD).
 4. Publish the NSD.
 
 ## Prerequisites

articles/operator-service-manager/how-to-use-helm-option-parameters.md

@@ -74,7 +74,7 @@ This section explains how to override `--atomic` for an NF that consists of a si
     }]
     ```
 
-1. Find the network function application name by navigating to the `cnf-cli-output` directory, opening the `nfDefinition` directory, and copying the value from the only entry in the networkFunctionApplications array in the `nfdv` resource. Confirm you have the correct value by comparing against the following fictional Contoso example BICEP snippet. In this case, the network function application name is `Contoso`.
+1. Find the network function application name by navigating to the `cnf-cli-output` directory, opening the `nfDefinition` directory, and copying the value from the only entry in the networkFunctionApplications array in the `nfdv` resource. Confirm you have the correct value by comparing against the following fictional Contoso example Bicep snippet. In this case, the network function application name is `Contoso`.
 
     ```bicep
     resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' = {
@@ -122,7 +122,7 @@ resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for
 
 ### Build the edited ARM Template and upload it to the Artifact Store
 
-1. Navigate to the `nsd-cli-output/artifacts` directory created by the `az aosm nsd build` command and build the Network Function ARM Template from the BICEP file generated by the CLI.
+1. Navigate to the `nsd-cli-output/artifacts` directory created by the `az aosm nsd build` command and build the Network Function ARM Template from the Bicep file generated by the CLI.
 
     ```azurecli
     bicep build <nf-name>.bicep
@@ -210,4 +210,4 @@ resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for
 
 ## Next steps
 
-You can now retry the SNS deployment. You can submit the deployment again through ARM, BICEP, or the AOSM REST API. You can also delete the failed SNS through the Azure portal SNS overview and redeploy following [the operator quickstart](quickstart-containerized-network-function-operator.md), replacing the quickstart NF parameters with the parameters for your network function. The helm releases deployed to the Kubernetes cluster won't be removed on failure. [How to debug SNS deployment failures](troubleshoot-helm-install-failures.md) describes a toolkit for debugging common helm install failures.
+You can now retry the SNS deployment. You can submit the deployment again through ARM, Bicep, or the AOSM REST API. You can also delete the failed SNS through the Azure portal SNS overview and redeploy following [the operator quickstart](quickstart-containerized-network-function-operator.md), replacing the quickstart NF parameters with the parameters for your network function. The helm releases deployed to the Kubernetes cluster won't be removed on failure. [How to debug SNS deployment failures](troubleshoot-helm-install-failures.md) describes a toolkit for debugging common helm install failures.

articles/operator-service-manager/quickstart-publish-containerized-network-function-definition.md

@@ -97,7 +97,7 @@ To construct the Network Function Definition (NFD), initiate the build process.
 az aosm nfd build -f input-cnf-nfd.jsonc --definition-type cnf
 ```
 
-The Az CLI AOSM extension generates a directory called `cnf-cli-output`. This directory contains the BICEP files defining the AOSM resources required to publish an NFDV and upload the images required to deploy it to AOSM-managed storage. Examine the generated files to gain a better understanding of the Network Function Definition (NFD) structure.
+The Az CLI AOSM extension generates a directory called `cnf-cli-output`. This directory contains the Bicep files defining the AOSM resources required to publish an NFDV and upload the images required to deploy it to AOSM-managed storage. Examine the generated files to gain a better understanding of the Network Function Definition (NFD) structure.
 
 | Directory/File             | Description                                                                                                                                    |
 | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |

articles/operator-service-manager/troubleshoot-cli-common-issues.md

@@ -49,7 +49,7 @@ Confirm that you have the `Contributor` and `AcrPush` role assignments on the su
 **Option 2.**
 If these permissions don't resolve the issue, run the following commands from the `nsd-cli-output/artifacts` folder created by the `az aosm nsd build` command:
 
-- Build the Network Function ARM Template from the BICEP file generated by the CLI
+- Build the Network Function ARM Template from the Bicep file generated by the CLI
 
 ```azurecli
 bicep build <nf-name>.bicep