Merge pull request #196 from bhgtankita/patch-1

Update how-to-manage-compute-instance.md

Author: v-dirichards

articles/machine-learning/how-to-manage-compute-instance.md

@@ -55,6 +55,9 @@ Start at [Azure Machine Learning studio](https://ml.azure.com).
 
 ---
 
+> [!NOTE]
+> When configuring a Virtual Network (VNet) located in a different resource group from your Azure Machine Learning workspace, be aware that resources such as Network Security Groups (NSGs), Public IPs, and Load Balancers will be created in the same resource group as the VNet. This behavior ensures proper network management and isolation.
+
 ## Manage
 
 Start, stop, restart, and delete a compute instance. A compute instance doesn't always automatically scale down, so make sure to stop the resource to prevent ongoing charges. Stopping a compute instance deallocates it. Then start it again when you need it. While stopping the compute instance stops the billing for compute hours, you'll still be billed for disk, public IP, and standard load balancer. 
@@ -155,6 +158,9 @@ For each compute instance in a workspace that you created (or that was created f
 
 ---
 
+> [!Caution]
+> Applying resource locks, such as "Delete" or "Read-only", to the resource group containing your compute instances can prevent operations like creation, resizing, or deletion of these instances. Ensure that resource locks are configured appropriately to avoid unintended disruptions. 
+
 [Azure RBAC](/azure/role-based-access-control/overview) allows you to control which users in the workspace can create, delete, start, stop, restart a compute instance. All users in the workspace contributor and owner role can create, delete, start, stop, and restart compute instances across the workspace. However, only the creator of a specific compute instance, or the user assigned if it was created on their behalf, is allowed to access Jupyter, JupyterLab, and RStudio on that compute instance. A compute instance is dedicated to a single user who has root access. That user has access to Jupyter/JupyterLab/RStudio running on the instance. Compute instance has single-user sign-in and all actions use that user's identity for Azure RBAC and attribution of experiment jobs. SSH access is controlled through public/private key mechanism.
 
 These actions can be controlled by Azure RBAC: