fixing merge conflict

Author: paulth1

articles/container-instances/azure-container-instances-support-policy.md

@@ -6,7 +6,7 @@ author: tomvcassidy
 ms.service: azure-container-instances
 services: container-instances
 ms.topic: conceptual
-ms.date: 04/16/2025
+ms.date: 11/17/2025
 ---
 # Support policy for Azure Container Instances
 

articles/container-instances/big-containers.md

@@ -6,7 +6,7 @@ author: tomvcassidy
 ms.service: azure-container-instances
 services: container-instances
 ms.topic: concept-article
-ms.date: 03/27/2025
+ms.date: 11/17/2025
 # Customer intent: As a cloud developer, I want to deploy high-performance container workloads with increased vCPU and memory on Azure Container Instances, so that I can efficiently handle data-intensive applications and scale resources seamlessly according to business demands.
 ---
 # Big Containers on Azure Container Instances

articles/container-instances/confidential-containers-attestation-concepts.md

@@ -6,7 +6,7 @@ ms.author: tomcassidy
 author: tomcassidy
 ms.service: azure-container-instances
 services: container-instances
-ms.date: 08/29/2024
+ms.date: 11/17/2025
 # Customer intent: As a cloud developer, I want to implement attestation in my confidential container groups on Azure Container Instances, so that I can ensure they run on trusted hardware and comply with security policies essential for safeguarding sensitive data.
 ---
 

articles/container-instances/container-instance-ngroups/container-instances-about-ngroups.md

@@ -7,7 +7,7 @@ ms.service: azure-container-instances
 ms.custom: devx-track-azurecli
 services: container-instances
 ms.topic: how-to
-ms.date: 11/05/2024
+ms.date: 11/17/2025
 # Customer intent: As a cloud architect, I want to manage multiple container group instances using a single API call through NGroups, so that I can streamline operations, enhance scalability, and improve the availability of my cloud applications.
 ---
 
@@ -47,14 +47,14 @@ NGroups references this Container Group Profile and then calls ACI APIs in order
 
 ### Container Group Profile (CG Profile)
 
-A large-scale cloud application may require you to manage multiple container groups. As of today, in order to run multiple CGs (Container Groups), customers need to provide relevant properties such as container images, restart policy, and other properties each time. This can result in throttling, duplicated effort, and management overhead.
+A large-scale cloud application may require you to manage multiple container groups. As of today, in order to run multiple CGs (Container Groups), customers need to provide relevant properties such as container images, restart policy, and other properties each time. This requirement can result in throttling, duplicated effort, and management overhead.
 
 To alleviate this concern, NGroups introduced Container Group Profiles. The container group profile (CGProfile) serves as a *template* for creating container groups with same set of properties.  
 
 Here are some of the common properties that can be specified in a container group profile:
 
 - osType (Example: Linux, Windows)
-- containers. Image name, memory, CPU etc.
+- containers. Image name, memory, CPU, etc.
 - restartPolicy
 - ipAddress protocol and internal port
 - shutdownGracePeriod
@@ -106,10 +106,10 @@ And here's a sample CG profile:
 
 ### NGroups
 
-NGroups resource provides a way to create and manage ‘n’ container groups with a rich set of operations. An NGroups resource references a container group profile resource and uses that to create N instances of similar looking CGs. Within NGroups resource, customers can also specify other properties including but not limited to number of CGs, update preferences (manual or rolling update), load balancers, subnets, and other relevant properties which they want to associate with CGs under an NGroups resource.
+NGroups resource provides a way to create and manage ‘n’ container groups with a rich set of operations. An NGroups resource references a container group profile resource and uses that to create N instances of similar looking CGs. Within NGroups resource, customers can also specify other properties including but not limited to number of CGs, update preferences (manual or rolling update), load balancers, subnets, and other relevant properties they want to associate with CGs under an NGroups resource.
 
 > [!NOTE]
-> A CG profile needs to be created **before** creating an NGroups resource. Since the CG profile is an ARM resource, it has its own ARM APIs. A CG profile needs to be created **before** creating an NGroups resource.
+> A CG profile needs to be created **before** creating an NGroups resource. Since the CG profile is an Azure Resource Manager (ARM) resource, it has its own Azure Resource Manager APIs. A CG profile needs to be created **before** creating an NGroups resource.
 
 #### Benefits of Referencing Container Group Profile
 
@@ -154,7 +154,7 @@ NGroups references a CG profile and adds other related properties and capabiliti
 - The subnet into which CGs are deployed when using a virtual network
 - The Load Balancer or Application Gateway to provide network ingress to the CGs
 
-NGroups in turn invokes the ACI ARM APIs to create and manage each CG. Since it uses the same ARM APIs, there's no difference between the CGs created by NGroups and the CGs created directly by the customer. They have the exact same API experience.
+NGroups in turn invokes the ACI Azure Resource Manager APIs to create and manage each CG. Since it uses the same Azure Resource Manager APIs, there's no difference between the CGs created by NGroups and the CGs created directly by the customer. They have the exact same API experience.
 
 ### Updating an NGroups Resource
 
@@ -172,7 +172,7 @@ To update existing CGs with new CGProfile, we issue a *manual update* command wi
 
 This mode gives us flexibility to update CGs selectively and provides full control over impact on production workloads.  
 
-In **Rolling** mode, when we update the reference to cgprofile2 and issue an UPDATE NGroups command, existing CGs are updated with cgprofile2. The update to existing CGs happens in small batches (and not all at once). This ensures that there is a minimal impact on your workload since only a small percentage of CGs may be unavailable during the update.  
+In **Rolling** mode, when we update the reference to cgprofile2 and issue an UPDATE NGroups command, existing CGs are updated with cgprofile2. The update to existing CGs happens in small batches (and not all at once). This ensures that there's a minimal impact on your workload since only a small percentage of CGs may be unavailable during the update.  
 
 We can configure the batch size and other related rolling update mode settings with the NGroups API.
 
@@ -199,9 +199,9 @@ If these prerequisites aren't met, requests fail, and the NGroups resource type
 Create CG Profile: [ContainerGroupProfile-Sample.json](#container-group-profile-sample)
 Create Zonal NGroups with CGProfile: [NGroups-Zonal-Sample.json](#ngroups-with-zones-sample)
 
-Customers can see if a container group is associated to an NGroups resource by checking container group orchestratorId property under the JSON view. The orchestratorId represents the associated NGroups ARM resource ID.
+Customers can see if a container group is associated to an NGroups resource by checking container group orchestratorId property under the JSON view. The orchestratorId represents the associated NGroups Azure Resource Manager resource ID.
 
-:::image type="content" source="../media/container-instances-ngroups/cg-arm-json-structure.png" alt-text="A screenshot of an NGroups CG ARM JSON displaying OrchestratorId property.":::
+:::image type="content" source="../media/container-instances-ngroups/cg-arm-json-structure.png" alt-text="A screenshot of an NGroups CG Azure Resource Manager JSON displaying OrchestratorId property.":::
 
 ## How-To Guide
 
@@ -284,7 +284,7 @@ While creating or updating container groups, NGroups relies on the same ACI APIs
 
 - Once an NGroups resource is created with a set of zones (for example, { “1”, “2” }), the zones can't be removed. However, a new zone can be added to the list. For example, { “1”, “2”, “3” }
 
-- If a specified zone is down, then the overall NGroups operation to create the CGs fails. Retry the request once the zone is back up. Another option is to delete the failed CGs.
+- If a specified zone is down, then the overall NGroups operation to create the CGs fails. Retry the request once the zone is operational again. Another option is to delete the failed CGs.
 
 - During scale down, NGroups randomly deletes instances, which might not always maintain AZ spread. However, subsequent scale-out operations always try to rebalance the AZ spread.  
 
@@ -326,15 +326,15 @@ This can be useful when you have multiple NGroups in a single resource group and
 
 Yes, you can set the properties.elasticProfile.maintainDesiredCount bool property to true.  
 
-It creates a new CG for every CG that is being deleted/detached from the NGroups. It tries to maintain the desiredCount property of the NGroups to its set value.
+It creates a new CG for every CG that's being deleted/detached from the NGroups. It tries to maintain the desiredCount property of the NGroups at its set value.
 
-This is useful when you want to use the NGroups as a *pool* which automatically gets replenished when you take away CGs from the pool for your workload scenarios.  
+This is useful when you want to use the NGroups as a *pool*, which automatically gets replenished when you take away CGs from the pool for your workload scenarios.  
 
-It is a nullable bool property. If you omit it for subsequent NGroups PUT/update calls, it doesn't reset to false. To reset, you must explicitly set it to false. When it is null/false, and when a CG is deleted/detached from the NGroups, the desiredCount property for the NGroups reduces accordingly.
+It's a nullable bool property. If you omit it for subsequent NGroups PUT/update calls, it doesn't reset to false. To reset, you must explicitly set it to false. When it's null/false, and when a CG is deleted/detached from the NGroups, the desiredCount property for the NGroups reduces accordingly.
 
 #### How do I get the CG name, NGroups ID and other metadata propagated down into the container?
 
-Currently, we expose only the CG name and orchestrator ID (the ARM resource ID). In the future, other relevant properties could be considered. These two properties show up as container environment variables.
+Currently, we expose only the CG name and orchestrator ID (the Azure Resource Manager resource ID). In the future, other relevant properties could be considered. These two properties show up as container environment variables.
 
 To get these environment variables on the container, specify these tags *at the NGroups level*:
 
@@ -358,7 +358,7 @@ For workloads that offer higher availability (for example, NGroups spread across
 
 This update is done AZ by AZ with not much automated coordination across AZs. Coordination is manually tracked and best-effort.
 
-So, if by chance, a platform update happens simultaneously across 2 or more AZs, then CGs across these AZs can be down simultaneously thus causing unavailability for your NGroups.
+So, if by chance, a platform update happens simultaneously across two or more AZs, then CGs across these AZs can be down simultaneously thus causing unavailability for your NGroups.
 
 #### How to use Confidential Containers with NGroups
 
@@ -538,7 +538,7 @@ Refer to the ACI documentation of confidential containers here: [Tutorial: Prepa
 }
 ```
 
-## Learn Related Topics
+## Related articles
 
 - [Azure Container Instances](../container-instances-overview.md)
 - [NGroups Rolling Update](container-instances-rolling-update.md)

articles/container-instances/container-instance-ngroups/container-instances-rolling-update.md

@@ -7,7 +7,7 @@ ms.service: azure-container-instances
 ms.custom: devx-track-azurecli
 services: container-instances
 ms.topic: how-to
-ms.date: 11/07/2024
+ms.date: 11/17/2025
 # Customer intent: As a cloud administrator, I want to perform rolling updates on container groups in NGroups, so that I can ensure minimal workload disruption and maintain service availability during updates.
 ---
 
@@ -57,11 +57,11 @@ NGroups then automatically group instances into batches and updates one batch at
 
 - An **in-place** update invokes a CG PUT call to update each CG of the batch.
 
-- A **replace** update invokes a CG PUT call to create new CGs and delete existing CGs of the batch. There exists a 1:1 correspondence between the CGs being created and the CGs being deleted. However, the CG names will be different.
+- A **replace** update invokes a CG PUT call to create new CGs and delete existing CGs of the batch. There exists a 1:1 correspondence between the CGs being created and the CGs being deleted. However, the CG names are different.
 
-If a sufficient number of CGs in the batch provide healthy signals after the pauseTimeBetweenBatches period, NGroups automatically starts the next batch for the update. Otherwise, it stops the rollout. The *maxUnhealthyPercent* parameter specifies the total number of unhealthy CGs, while the *maxUnhealthyUpdatedPercent* parameter specifies the total number of unhealthy CGs after the update.
+If a sufficient number of container groups in the batch provide healthy signals after the pauseTimeBetweenBatches period, NGroups automatically starts the next batch for the update. Otherwise, it stops the rollout. The *maxUnhealthyPercent* parameter specifies the total number of unhealthy CGs, while the *maxUnhealthyUpdatedPercent* parameter specifies the total number of unhealthy CGs after the update.
 
-Here is an example to issue a rolling update request to NGroups:
+Here's an example to issue a rolling update request to NGroups:
 
 ``` json
 { 
@@ -108,7 +108,7 @@ Here is an example to issue a rolling update request to NGroups:
 } 
 ```
 
-If image version is set to the **latest** tag for container images within the CG profile, then NGroups automatically picks up the latest image version during the RU. To prevent unexpected behavior in your application, it is recommended to not use the *latest* tag for images. Instead, use specific versions.  
+If image version is set to the **latest** tag for container images within the CG profile, then NGroups automatically picks up the latest image version during the RU. To prevent unexpected behavior in your application, it's recommended to not use the *latest* tag for images. Instead, use specific versions.  
 
 
 > [!NOTE]
@@ -131,17 +131,17 @@ This returns a response containing relevant information about the RU.
 
 ### Canceling a Rolling Update
 
-To cancel a rolling update, use the following API. Once canceled, the RU cannot be resumed/restarted. A new RU needs to be triggered.
+To cancel a rolling update, use the following API. Once canceled, the RU can't be resumed/restarted. A new RU needs to be triggered.
 
 `POST /subscriptions/{subscriptionId}/resourceGroups/{{rgName}}/providers/Microsoft.ContainerInstance/NGroups/{{ngroupsName}}/cancelRollingUpdate`
 
-You do not need to provide a request body when calling this API.
+You don't need to provide a request body when calling this API.
 
-It's also important to know that canceling an RU won't automatically roll it back to the previous state, but it will remain in the state that it was at the moment it was canceled.  For example, in case during an RU one wants to update a CG profile reference from *cgprofile1* to *cgprofile2*, and at some point the operation is canceled, some CGs might have the new profile *cgprofile2* and others remain with *cgprofile1*.
+It's also important to know that canceling an RU won't automatically roll it back to the previous state, but it remains in the state that it was at the moment it was canceled. For example, in case during an RU one wants to update a CG profile reference from *cgprofile1* to *cgprofile2*, and at some point the operation is canceled, some CGs might have the new profile *cgprofile2* and others remain with *cgprofile1*.
 
 ### Boundary of a Batch in a Rolling Update
 
-The CGs of a specific batch in an RU do not cross a fault model boundary. A fault model represents a zone/fault-domain (FD) combination. For example, zone 1 / FD 0 is a fault model boundary, zone 1 / FD 1 is another fault model boundary, and zone 2 / FD 0 is yet another fault model boundary.
+The CGs of a specific batch in an RU don't cross a fault model boundary. A fault model represents a zone/fault-domain (FD) combination. For example, zone 1 / FD 0 is a fault model boundary, zone 1 / FD 1 is another fault model boundary, and zone 2 / FD 0 is yet another fault model boundary.
 
 If a customer has a multi-zonal NGroups set up with three zones, a batch is confined to CGs belonging to only one zone at most. A batch never consists of CGs spread across multiple zones.
 
@@ -151,7 +151,7 @@ NGroups maintains this fault model boundary in a batch, even when the number of
 
 The only time a fault model boundary is crossed when the RU selects unhealthy CGs for the first batch. In this batch, the RU attempts to update all unhealthy CGs to improve the overall availability of NGroups. As a result, when updating unhealthy CGs, the RU may exceed the maxBatchPercent setting.
 
-## Learn Related Topics
+## Related articles
 
 - [Azure Container Instances](../container-instances-overview.md)
 - [About NGroups](container-instances-about-ngroups.md)

articles/container-instances/container-instances-application-gateway.md

@@ -7,7 +7,7 @@ ms.service: azure-container-instances
 ms.custom: devx-track-azurecli
 services: container-instances
 ms.topic: how-to
-ms.date: 08/29/2024
+ms.date: 11/17/2025
 # Customer intent: "As a cloud architect, I want to configure a static public IP address for a container group using an application gateway, so that I can ensure stable external access to my containerized web applications."
 ---
 

articles/container-instances/container-instances-best-practices-and-considerations.md

@@ -6,7 +6,7 @@ ms.author: tomcassidy
 author: tomvcassidy
 ms.service: azure-container-instances
 services: container-instances
-ms.date: 08/29/2024
+ms.date: 11/17/2025
 # Customer intent: As a cloud administrator, I want to implement best practices for deploying workloads on container instances, so that I can ensure security, efficiency, and scalability in my containerized applications.
 ---
 

articles/container-instances/container-instances-confidential-overview.md

@@ -6,7 +6,7 @@ ms.author: tomcassidy
 author: tomvcassidy
 ms.service: azure-container-instances
 services: container-instances
-ms.date: 08/29/2024
+ms.date: 11/17/2025
 ms.custom: mvc
 # Customer intent: "As a cloud operator, I want to implement confidential containers on Azure Container Instances, so that I can securely run containerized applications while protecting sensitive data through hardware-based execution environments and verifiable attestation."
 ---

articles/container-instances/container-instances-config-map.md

@@ -7,15 +7,15 @@ ms.service: azure-container-instances
 ms.custom:
   - ignite-2024
 ms.topic: how-to
-ms.date: 05/19/2025
+ms.date: 11/17/2025
 ms.reviewer: tomvcassidy
 # Customer intent: As a container orchestrator user, I want to implement config maps in Azure Container Instances so that I can modify container configurations dynamically without restarting the instances to ensure high availability and minimize downtime.
 ---
 # Config maps for Azure Container Instances
 
-A config map is a property that you can use to apply container configurations similar to environment variables and secret volumes. However, the process is unlike using environment variables or secret volumes where you must restart the pod to apply the settings. Using a config map to apply settings doesn't require any restarts for the changes to take effect.
+A config map is a property that you can use to apply container configurations similar to environment variables and secret volumes. The process is unlike using environment variables or secret volumes where you must restart the pod to apply the settings. Using a config map to apply settings doesn't require any restarts for the changes to take effect.
 
-You can use Azure Container Instances to create container instances with or without config maps. You can also update them at any point after creation by using config maps. Updating config maps in an existing running container group is a task you can accomplish quickly without compromising uptime of the container.
+You can use Azure Container Instances to create container instances with or without config maps. You can also update them at any point after creation by using config maps. Updating config maps in an existing running container group is a task that you can accomplish quickly without compromising uptime of the container.
 
 ## How it works