https://quill.com.au learning@quill.com.au

AZ-104: Microsoft Azure Administrator

Manage Azure identities and governance (20–25%)

Manage Microsoft Entra users and groups

Create users and groups

To effectively manage Microsoft Entra users and groups, it’s essential to understand the process of creating users and groups within the Microsoft Entra ID (formerly known as Azure Active Directory). This is a fundamental skill for the AZ-104: Microsoft Azure Administrator exam. Below is a detailed explanation of how to create users and groups in Microsoft Entra ID.

Creating Users in Microsoft Entra ID

1. Sign in to the Azure Portal:
   • Navigate to the Azure Portal and sign in with your Azure account credentials.
2. Access Microsoft Entra ID:
   • In the left-hand navigation pane, select Azure Active Directory.
3. Create a New User:
   • In the Azure Active Directory pane, select Users.
   • Click on + New user to open the user creation pane.
4. Fill in User Details:
   • User name: Enter the user’s email address or user principal name (UPN).
   • Name: Enter the user’s first and last name.
   • Groups and roles: Optionally, assign the user to groups and roles.
   • Directory role: Choose the appropriate directory role for the user (e.g., User, Global administrator).
   • Password: Set an initial password for the user. The user will be prompted to change this password upon first sign-in.
5. Create the User:
   • Click Create to add the new user to Microsoft Entra ID.

Creating Groups in Microsoft Entra ID

1. Access Microsoft Entra ID:
   • In the Azure Active Directory pane, select Groups.
2. Create a New Group:
   • Click on + New group to open the group creation pane.
3. Fill in Group Details:
   • Group type: Select the type of group (e.g., Security, Microsoft 365).
   • Group name: Enter a name for the group.
   • Group description: Optionally, provide a description for the group.
   • Membership type: Choose the membership type (e.g., Assigned, Dynamic User, Dynamic Device).
4. Add Members:
   • Click on Members and select the users or devices you want to add to the group.
5. Create the Group:
   • Click Create to add the new group to Microsoft Entra ID.

Important Considerations

• Types of Users:
  • Microsoft Entra ID supports various types of users, including internal users, external users, guest users, and members of federated domains .
• Group Management:
  • Using groups simplifies access management by allowing you to manage user and application access based on group membership .
• Service Principals:
  • Applications can use service principals or managed identities to authenticate directly to Azure resources, which is preferred for its passwordless nature .
• Permissions and Roles:
  • Assigning appropriate roles and permissions is crucial for managing access to Azure resources. Microsoft Entra roles manage Azure resources, but database permissions must be granted directly within the database using Transact-SQL statements .
• External Users:
  • Users from other directories can be imported as external users and then used to create contained database users that can access SQL databases .

By following these steps and considerations, you can effectively create and manage users and groups in Microsoft Entra ID, which is a key responsibility for an Azure Administrator. This knowledge is essential for the AZ-104 exam and for managing Azure identities and governance in a real-world environment.

Refrence: https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-azure-ad-landing

Refrence: https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-configure

Refrence: https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/aad-security-configure-tutorial

Refrence: https://learn.microsoft.com/en-us/azure/azure-sql/database/security-best-practice

Refrence: https://learn.microsoft.com/en-AU/azure/lab-services/how-to-manage-lab-users

Manage user and group properties

Manage Microsoft Entra Users and Groups: Manage User and Group Properties

Managing user and group properties in Microsoft Entra ID (formerly Azure Active Directory) is a crucial aspect of identity and access management. This involves configuring and maintaining various attributes and settings for users and groups to ensure proper access control and governance within an Azure environment. Below is a detailed explanation of how to manage user and group properties:

1. User Properties

Creating and Managing Users: - Create Users: You can create new users in Microsoft Entra ID through the Azure portal, PowerShell, or programmatically using the Microsoft Graph API. When creating a user, you need to specify properties such as the username, display name, and password. - Manage User Properties: Once a user is created, you can manage their properties, including updating their profile information (e.g., job title, department), resetting passwords, and assigning roles.

Example:

# Create a new user
New-AzureADUser -DisplayName "John Doe" -UserPrincipalName "john.doe@contoso.com" -PasswordProfile (New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile -Property @{Password = "P@ssw0rd"; ForceChangePasswordNextSignIn = $true})

User Attributes: - Object ID: A unique identifier for the user in Microsoft Entra ID. - User Principal Name (UPN): The user’s login name. - Display Name: The name displayed in the directory. - Job Title, Department, etc.: Additional profile information.

2. Group Properties

Creating and Managing Groups: - Create Groups: Groups can be created to manage access to resources collectively. You can create security groups or Microsoft 365 groups depending on your needs. - Manage Group Properties: You can update group properties such as the group name, description, and membership rules.

Example:

# Create a new security group
New-AzureADGroup -DisplayName "IT Department" -MailEnabled $false -SecurityEnabled $true -MailNickname "ITDept"

Group Attributes: - Object ID: A unique identifier for the group in Microsoft Entra ID. - Group Name: The name of the group. - Description: A brief description of the group’s purpose. - Membership Type: Defines whether the group is assigned, dynamic user, or dynamic device.

3. Managing Memberships

Adding and Removing Members: - Add Members: You can add users to groups to grant them access to resources. - Remove Members: Similarly, you can remove users from groups to revoke access.

Example:

# Add a user to a group
Add-AzureADGroupMember -ObjectId <GroupObjectId> -RefObjectId <UserObjectId>

# Remove a user from a group
Remove-AzureADGroupMember -ObjectId <GroupObjectId> -MemberId <UserObjectId>

4. Managing Licenses

Assigning and Revoking Licenses: - Assign Licenses: You can assign licenses to users or groups to provide access to various Microsoft services. - Revoke Licenses: You can also revoke licenses when they are no longer needed.

Example:

# Assign a license to a user
Set-AzureADUserLicense -ObjectId <UserObjectId> -AddLicenses <LicenseSkuId>

# Remove a license from a user
Set-AzureADUserLicense -ObjectId <UserObjectId> -RemoveLicenses <LicenseSkuId>

5. Managing External Users

Inviting External Users: - Invite Users: You can invite external users (guests) to collaborate within your organization. This is useful for B2B scenarios. - Manage Guest Properties: You can manage properties for guest users, similar to internal users.

Example:

# Invite an external user
New-AzureADMSInvitation -InvitedUserEmailAddress "external.user@domain.com" -InviteRedirectUrl "https://myapps.microsoft.com"

6. Self-Service Password Reset (SSPR)

Configuring SSPR: - Enable SSPR: You can enable self-service password reset for users, allowing them to reset their passwords without administrator intervention. - Configure Authentication Methods: Define the methods users can use to verify their identity (e.g., email, phone).

Example:

# Enable SSPR for a user
Set-MsolUser -UserPrincipalName "john.doe@contoso.com" -StrongAuthenticationMethods @("Email", "Phone")

By effectively managing user and group properties, you can ensure that your organization’s resources are secure and that users have the appropriate access to perform their roles. This is a fundamental skill for any Azure administrator preparing for the AZ-104 exam.

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/bicep/scenarios-rbac

Refrence: https://learn.microsoft.com/en-AU/azure/aks/manage-local-accounts-managed-azure-ad

Refrence: https://learn.microsoft.com/en-us/azure/aks/manage-local-accounts-managed-azure-ad

Refrence: https://learn.microsoft.com/azure/data-factory/connector-azure-sql-database

Refrence: https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-directory-readers-role

Manage licenses in Microsoft Entra ID

Manage Licenses in Microsoft Entra ID

Managing licenses in Microsoft Entra ID (formerly known as Azure Active Directory) is a crucial task for ensuring that users have the appropriate access to the services and features they need. Here’s a detailed explanation of how to manage licenses in Microsoft Entra ID:

1. Understanding Microsoft Entra ID Licenses

Microsoft Entra ID offers various licensing options, each providing different levels of features and capabilities. The primary licenses include: - Microsoft Entra ID Free: Basic features for identity and access management. - Microsoft Entra ID P1: Includes advanced features like Conditional Access and self-service password reset. - Microsoft Entra ID P2: Adds additional security features such as Privileged Identity Management (PIM) and risk-based Conditional Access.

2. Assigning Licenses to Users

To assign licenses to users, follow these steps: 1. Navigate to the Microsoft Entra admin center: Go to the Microsoft Entra admin center. 2. Select Users: In the left-hand navigation pane, select “Users”. 3. Choose the User: Click on the user to whom you want to assign a license. 4. Licenses: In the user’s profile, select “Licenses”. 5. Assign Licenses: Click on “Assign licenses” and choose the appropriate license(s) from the list. 6. Save: Click “Save” to apply the changes.

3. Managing Group-Based Licensing

Group-based licensing allows you to assign licenses to a group of users, simplifying the management process. Here’s how to do it: 1. Navigate to Groups: In the Microsoft Entra admin center, select “Groups”. 2. Select the Group: Choose the group to which you want to assign licenses. 3. Licenses: In the group’s profile, select “Licenses”. 4. Assign Licenses: Click on “Assign licenses” and select the licenses you want to assign to the group. 5. Save: Click “Save” to apply the changes.

4. Managing License Assignments via PowerShell

For bulk operations or automation, you can use PowerShell to manage license assignments. Here’s a basic example: 1. Install the AzureAD Module: If not already installed, run Install-Module -Name AzureAD. 2. Connect to Microsoft Entra ID: Use Connect-AzureAD to authenticate. 3. Assign a License: Use the Set-AzureADUserLicense cmdlet to assign a license to a user.

Example:

# Connect to Azure AD
Connect-AzureAD

# Assign a license to a user
$UserId = "user@example.com"
$SkuId = "ENTERPRISEPREMIUM"
Set-AzureADUserLicense -ObjectId $UserId -AssignedLicenses @{Add=$SkuId}

5. Monitoring and Reporting on License Usage

Monitoring license usage is essential to ensure compliance and optimize costs. You can generate reports in the Microsoft Entra admin center: 1. Navigate to Reports: In the Microsoft Entra admin center, go to “Reports”. 2. License Reports: Select “License reports” to view detailed information about license assignments and usage.

6. License Management Best Practices

• Regular Audits: Periodically review license assignments to ensure users have the appropriate licenses.
• Optimize Costs: Remove licenses from inactive users or those who no longer need certain features.
• Use Group-Based Licensing: Simplify management by assigning licenses to groups rather than individual users.

By following these steps and best practices, you can effectively manage licenses in Microsoft Entra ID, ensuring that users have the necessary access while optimizing costs and maintaining compliance.

Refrence: https://learn.microsoft.com/en-AU/azure/aks/access-control-managed-azure-ad

Refrence: https://learn.microsoft.com/en-us/azure/virtual-desktop/faq

Refrence: https://learn.microsoft.com/en-us/azure/aks/access-control-managed-azure-ad

Refrence: https://learn.microsoft.com/en-us/azure/defender-for-cloud/multi-factor-authentication-enforcement

Refrence: https://learn.microsoft.com/en-us/azure/virtual-desktop/understand-estimate-costs

Manage external users

Managing external users in Microsoft Entra ID (formerly Azure Active Directory) involves several key tasks and considerations. Here is a detailed explanation based on the exam objective:

Manage External Users

Overview

External users, also known as guest users, are users who do not belong to your organization but need access to your resources. Microsoft Entra ID provides features to manage these users securely and efficiently.

Key Features and Steps

1. Inviting External Users:
   • External users can be invited to your directory using their own identity management solutions. This means they can use their existing work, school, or social identities to access your resources.
   • To invite an external user, you typically fill out a form with the guest user’s details and send them a custom invitation message. The guest user receives this invitation via email .
2. User Consent and Access:
   • When the guest user clicks the invite link for the first time, they are asked to provide consent for the permissions required by Microsoft Entra B2B. This step ensures that the user is aware of and agrees to the access they are being granted .
   • If multifactor authentication (MFA) is enabled, the user must provide additional verification details, such as a code sent to their mobile device, before they can access the resources .
3. Managing External User Access:
   • External users are managed similarly to internal users in terms of access control. You can assign them to groups, roles, and applications as needed.
   • External users can be added to Microsoft Entra groups, which can then be used to manage access to various resources. This is particularly useful for managing permissions at scale .
4. Security Considerations:
   • External users’ identities are managed by their own organizations or identity providers, which means you do not need to manage their accounts or passwords. This reduces the administrative overhead and enhances security .
   • It is important to configure Conditional Access policies to ensure that external users meet your organization’s security requirements, such as MFA or device compliance .
5. Deleting External Users:
   • If you need to remove an external user, you can do so from the Microsoft Entra admin center. Navigate to Identity > Overview > Manage tenants, select the tenant you want to delete, and then select Delete. You may need to complete required actions, such as deleting user flows and app registrations, before you can delete the tenant .
6. Using External Users in SQL Databases:
   • External users can be used to create contained database users in Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse. This allows them to access these databases using their Microsoft Entra identities .
   • To create a contained database user for an external user, you can use the CREATE USER [<Microsoft_Entra_principal_name>] FROM EXTERNAL PROVIDER; command in Transact-SQL .

Example Scenario

Imagine you are an administrator at Tailwind Traders, and you need to collaborate with an external partner. You can invite the partner’s users as guest users to your Microsoft Entra directory. These users will receive an email invitation, provide consent, and complete MFA if required. Once they are set up, you can add them to specific groups and assign them roles to access the necessary applications and resources.

By following these steps and considerations, you can effectively manage external users in Microsoft Entra ID, ensuring secure and efficient collaboration with external partners.

This detailed explanation should help you understand how to manage external users as part of the AZ-104 exam objectives.

Refrence: https://learn.microsoft.com/en-us/training/modules/enterprise-governance/1-introduction

Refrence: https://learn.microsoft.com/en-us/azure/app-service/scenario-secure-app-authentication-app-service

Refrence: https://learn.microsoft.com/en-us/training/modules/design-authentication-authorization-solutions/4-design-business-business

Configure self-service password reset (SSPR)

Configure Self-Service Password Reset (SSPR)

Self-Service Password Reset (SSPR) is a feature in Microsoft Entra ID that allows users to reset their passwords without needing to contact the help desk. This feature enhances security and reduces the administrative burden on IT staff. Here’s a detailed explanation of how to configure SSPR:

Steps to Configure SSPR

1. Enable SSPR for Users:
   • Navigate to the Azure portal and sign in with an account that has the necessary permissions.
   • Go to Azure Active Directory > Password reset.
   • Under Properties, set the Self-service password reset enabled option to Selected or All based on your requirement.
   • If you choose Selected, specify the groups that will have access to SSPR.
2. Configure Authentication Methods:
   • In the Password reset section, go to Authentication methods.
   • Choose the number of methods required to reset a password. Microsoft recommends at least two methods for better security.
   • Select the available methods for users to verify their identity. These can include:
     • Mobile app notification
     • Mobile app code
     • Email
     • Mobile phone
     • Office phone
     • Security questions
3. Set Up Registration:
   • Go to Password reset > Registration.
   • Enable the option to require users to register when they sign in.
   • Set the number of days before users are asked to reconfirm their authentication information.
4. Customize Notifications:
   • In the Password reset section, go to Notifications.
   • Enable notifications to alert users when their password is reset.
   • Optionally, enable notifications to alert administrators when other administrators reset their passwords.
5. Integrate with On-Premises Environment (if applicable):
   • If you have a hybrid environment, you can write back password changes to your on-premises directory.
   • Go to Password reset > On-premises integration.
   • Enable the option to write back passwords to your on-premises directory.
6. Test the Configuration:
   • Ensure that the configuration works as expected by testing the SSPR process with a user account.
   • Verify that users can register their authentication methods and successfully reset their passwords.

Benefits of SSPR

• Improved Security: By requiring multiple forms of authentication, SSPR reduces the risk of unauthorized access.
• Reduced Help Desk Load: Users can reset their passwords without needing to contact IT support, freeing up resources for other tasks.
• User Convenience: Users can reset their passwords from any device with internet access, ensuring they can regain access quickly.

Additional Resources

• For a step-by-step tutorial on enabling SSPR, see the tutorial for self-service password reset (SSPR) .
• To understand how SSPR works, refer to How Microsoft Entra self-service password reset works .

By following these steps, you can effectively configure and manage Self-Service Password Reset in Microsoft Entra ID, enhancing both security and user experience.

Refrence: https://learn.microsoft.com/en-us/azure/sentinel/data-connectors/microsoft-entra-id

Manage access to Azure resources

Manage built-in Azure roles

Manage Built-in Azure Roles

Managing built-in Azure roles is a crucial aspect of managing access to Azure resources. Azure provides a set of built-in roles that you can assign to users, groups, and services to grant them specific permissions. These roles are predefined and cover a wide range of Azure services and tasks. Here’s a detailed explanation of how to manage built-in Azure roles:

1. Understanding Built-in Roles

Built-in roles are predefined roles that provide a collection of permissions to perform specific tasks. These roles are designed to cover common scenarios and simplify the process of assigning permissions. Each built-in role has a unique ID and a set of permissions associated with it.

Examples of Built-in Roles:

• Owner: Grants full access to manage all resources, including the ability to assign roles in Azure RBAC (Role-Based Access Control) .
• Contributor: Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries .
• Reader: Allows viewing all resources, but does not allow making any changes .
• User Access Administrator: Lets you manage user access to Azure resources .

2. Assigning Built-in Roles

To manage access to Azure resources, you need to assign built-in roles to users, groups, or services. This can be done at different scopes, such as the management group, subscription, resource group, or resource level.

Steps to Assign a Role:

1. Navigate to the Azure Portal: Go to the Azure portal and select the resource you want to manage.
2. Access the Access Control (IAM) Blade: In the resource menu, select “Access control (IAM)”.
3. Add a Role Assignment: Click on “Add” and then “Add role assignment”.
4. Select the Role: Choose the built-in role you want to assign from the list.
5. Assign to User, Group, or Service Principal: Select the user, group, or service principal to whom you want to assign the role.
6. Review and Assign: Review the assignment and click “Save” to apply the role.

3. Managing Role Assignments

Once roles are assigned, you can manage and review these assignments to ensure that users have the appropriate level of access.

Reviewing Role Assignments:

• Access Control (IAM) Blade: Use the “Access control (IAM)” blade to view all role assignments for a resource.
• Role Assignments Tab: The “Role assignments” tab shows a list of all users, groups, and service principals with their assigned roles.

Modifying Role Assignments:

• Edit Role Assignments: You can edit existing role assignments to change the role or the scope.
• Remove Role Assignments: If a user no longer needs access, you can remove their role assignment.

4. Best Practices

• Least Privilege Principle: Assign the minimum permissions necessary for users to perform their tasks.
• Regular Reviews: Periodically review role assignments to ensure they are still appropriate.
• Use Groups: Assign roles to groups instead of individual users to simplify management.

5. Common Built-in Roles

Here are some common built-in roles and their descriptions:

By understanding and effectively managing built-in Azure roles, you can ensure that users have the appropriate access to perform their tasks while maintaining security and compliance within your Azure environment.

Refrence: https://learn.microsoft.com/en-us/azure/sentinel/../role-based-access-control/built-in-roles

Refrence: https://learn.microsoft.com/en-us/training/modules/configure-role-based-access-control/6-apply-authentication

Refrence: https://learn.microsoft.com/en-us/azure/sentinel/../role-based-access-control/built-in-roles#security

Assign roles at different scopes

Assign Roles at Different Scopes

In Azure, role-based access control (RBAC) allows you to manage who has access to Azure resources, what they can do with those resources, and what areas they have access to. Assigning roles at different scopes is a fundamental aspect of Azure RBAC, enabling you to grant the appropriate level of access to users, groups, and service principals.

Understanding Scopes

A scope is a boundary within which an Azure role assignment is valid. Azure RBAC allows you to assign roles at different scopes, which can be hierarchical. The scopes in Azure are:

1. Management Group: This is the highest level of scope. Management groups allow you to manage access, policies, and compliance across multiple Azure subscriptions.
2. Subscription: A subscription groups together user accounts and the resources that have been created by those user accounts. It is a billing entity.
3. Resource Group: A resource group is a container that holds related resources for an Azure solution. It can include all the resources for the solution or only those resources that you want to manage as a group.
4. Resource: This is the lowest level of scope. It refers to an individual Azure resource, such as a virtual machine, storage account, or database.

Assigning Roles at Different Scopes

When you assign a role, you specify the scope at which the role assignment applies. The role assignment can be inherited by resources within the scope. Here’s how you can assign roles at different scopes:

1. Management Group Scope:
   • Assigning a role at the management group level grants access to all subscriptions within the management group.
   • Example: Assigning the “Contributor” role at the management group level allows the user to manage resources in all subscriptions under that management group.
2. Subscription Scope:
   • Assigning a role at the subscription level grants access to all resource groups and resources within the subscription.
   • Example: Assigning the “Reader” role at the subscription level allows the user to view all resources in the subscription without making any changes.
3. Resource Group Scope:
   • Assigning a role at the resource group level grants access to all resources within that resource group.
   • Example: Assigning the “Virtual Machine Contributor” role at the resource group level allows the user to manage virtual machines within that resource group.
4. Resource Scope:
   • Assigning a role at the resource level grants access only to that specific resource.
   • Example: Assigning the “Storage Blob Data Contributor” role at the storage account level allows the user to manage blob data within that specific storage account.

Best Practices for Assigning Roles

• Least Privilege Principle: Always grant the least privilege necessary. Assign roles at the narrowest scope possible to minimize the risk of unauthorized access.
• Use Built-in Roles: Whenever possible, use built-in roles instead of creating custom roles. Built-in roles are predefined and cover most common scenarios.
• Review Role Assignments Regularly: Periodically review role assignments to ensure they are still necessary and appropriate.

Example

Consider the following scenario where different roles are assigned at various scopes:

• Management Group: The “Security Admin” role is assigned at the management group level to manage security policies across all subscriptions.
• Subscription: The “Owner” role is assigned at the subscription level to a user who needs full control over all resources within the subscription.
• Resource Group: The “Contributor” role is assigned at the resource group level to a team responsible for managing resources within a specific project.
• Resource: The “Reader” role is assigned at the resource level to a user who needs to view the configuration of a specific virtual machine.

By understanding and implementing role assignments at different scopes, you can effectively manage access to Azure resources and ensure that users have the appropriate level of access to perform their tasks.

For more detailed information on assigning Azure RBAC roles, you can refer to the official documentation: Assign Azure roles using the Azure portal .

Refrence: https://learn.microsoft.com/en-us/training/modules/configure-role-based-access-control/4-create-role-assignment

Refrence: https://learn.microsoft.com/en-us/training/modules/configure-role-based-access-control/5-compare-azure-roles-to-azure-ad-roles

Refrence: https://learn.microsoft.com/en-us/azure/storage/files/../common/customer-managed-keys-configure-new-account

Refrence: https://learn.microsoft.com/en-AU/azure/azure-monitor/logs/manage-access

Refrence: https://learn.microsoft.com/en-AU/azure/playwright-testing/how-to-manage-workspace-access

Interpret access assignments

Interpret Access Assignments

Interpreting access assignments in Azure involves understanding the roles and permissions assigned to users, groups, and service principals within your Azure environment. This is crucial for ensuring that the right level of access is granted to the appropriate resources, maintaining security, and adhering to the principle of least privilege.

Key Concepts

1. Azure Role-Based Access Control (RBAC):
   • Azure RBAC is a system that provides fine-grained access management of Azure resources.
   • It allows you to assign roles to users, groups, and service principals at different scopes such as subscription, resource group, or individual resources.
2. Built-in Roles:
   • Azure provides several built-in roles that you can assign to users. Each role has a predefined set of permissions.
   • Common built-in roles include:
     • Owner: Grants full access to manage all resources, including the ability to assign roles in Azure RBAC .
     • Contributor: Grants full access to manage all resources, but does not allow you to assign roles .
     • Reader: Allows viewing of all resources, but does not allow any changes .
     • User Access Administrator: Lets you manage user access to Azure resources .
3. Role Assignments:
   • A role assignment consists of three elements: security principal, role definition, and scope.
     • Security Principal: This can be a user, group, service principal, or managed identity.
     • Role Definition: This is a collection of permissions. It can be a built-in role or a custom role.
     • Scope: This defines the set of resources the access applies to. It can be a management group, subscription, resource group, or a specific resource.

Steps to Interpret Access Assignments

1. Identify the Role Assignments:
   • Navigate to the Azure portal and go to the resource (e.g., subscription, resource group, or specific resource).
   • Select Access Control (IAM) from the left-hand menu.
   • Click on Role assignments to view the list of role assignments.
2. Understand the Assigned Roles:
   • Review the roles assigned to each security principal.
   • Understand the permissions associated with each role. For example, the Owner role has full access, including the ability to assign roles, while the Reader role only allows viewing of resources .
3. Check the Scope of the Role Assignments:
   • Determine the scope at which the role is assigned. This could be at the subscription level, resource group level, or individual resource level.
   • The scope determines the breadth of access. For example, a role assigned at the subscription level applies to all resources within that subscription.
4. Evaluate the Permissions:
   • Ensure that the permissions granted by the role are appropriate for the tasks the security principal needs to perform.
   • Verify that the principle of least privilege is followed, meaning users have only the permissions they need and no more.
5. Review and Adjust as Necessary:
   • Regularly review role assignments to ensure they are still appropriate.
   • Remove or adjust role assignments as necessary to maintain security and compliance.

Example

Let’s say you have a user named “John Doe” who has been assigned the Contributor role at the resource group level. To interpret this access assignment:

1. Identify the Role Assignment:
   • Go to the Azure portal, navigate to the specific resource group.
   • Select Access Control (IAM) and then Role assignments.
   • Find “John Doe” in the list and note the assigned role.
2. Understand the Assigned Role:
   • The Contributor role allows John to manage all resources within the resource group but does not allow him to assign roles .
3. Check the Scope:
   • The role is assigned at the resource group level, so it applies to all resources within that resource group.
4. Evaluate the Permissions:
   • Ensure that John needs the ability to manage all resources within the resource group.
   • If John only needs to view resources, consider changing his role to Reader.
5. Review and Adjust:
   • Periodically review John’s role assignment to ensure it is still appropriate.
   • Adjust the role assignment if John’s responsibilities change.

By following these steps, you can effectively interpret and manage access assignments in Azure, ensuring that users have the appropriate level of access to perform their tasks while maintaining security and compliance.

Refrence: https://learn.microsoft.com/en-us/dotnet/azure/migration/appcat/dotnet-cli

Refrence: https://learn.microsoft.com/en-us/dotnet/azure/migration/appcat/visual-studio

Refrence: https://learn.microsoft.com/en-us/azure/storage/queues/../common/authorization-resource-provider

Manage Azure subscriptions and governance

Implement and manage Azure Policy

Implement and Manage Azure Policy

Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements. Azure Policy is crucial for maintaining governance, compliance, and security across your Azure environment.

Key Features of Azure Policy

1. Enforce Rules and Compliance:
   • Built-in and Custom Policies: Azure Policy provides a wide range of built-in policies that you can use out-of-the-box. Additionally, you can create custom policies tailored to your specific needs.
   • Real-time and Periodic Evaluation: Policies can be evaluated in real-time to ensure compliance as resources are created or updated. They can also be evaluated periodically or on-demand to check the compliance state of existing resources.
   • Policy Initiatives: You can group multiple policies into a single initiative to simplify management and ensure comprehensive compliance across multiple areas.
2. Apply Policies at Scale:
   • Management Groups: Policies can be applied at the management group level, allowing you to enforce rules across multiple subscriptions within your organization.
   • Policy Aggregation: You can aggregate the compliance state of multiple policies to get a holistic view of your environment’s compliance.
   • Exclusion Scopes: Define scopes where certain policies should not be applied, providing flexibility in policy enforcement.
3. Perform Remediation:
   • Real-time Remediation: Azure Policy can automatically remediate non-compliant resources in real-time as they are created or updated.
   • Existing Resources: Policies can also be used to remediate existing non-compliant resources, ensuring that your entire environment adheres to the defined standards.
4. Exercise Governance:
   • Support Multiple Teams: Azure Policy supports environments with multiple engineering teams, ensuring that all teams adhere to the same governance standards.
   • Manage Multiple Subscriptions: Policies can be applied across multiple subscriptions, making it easier to manage large and complex environments.
   • Standardization and Enforcement: Policies help standardize how cloud resources are configured and ensure that these configurations are enforced consistently.
   • Regulatory Compliance: Azure Policy helps manage regulatory compliance by enforcing rules that align with industry standards and regulations.
   • Cost Control and Security: Policies can be used to control costs by enforcing resource usage limits and enhancing security by ensuring that resources are configured securely.

Steps to Implement Azure Policy

1. Create a Policy Definition:
   • Define the policy rule using JSON syntax. The rule specifies the conditions under which the policy is enforced and the effect of the policy (e.g., deny, audit, append).
2. Assign the Policy:
   • Assign the policy to a scope, which can be a management group, subscription, resource group, or individual resource. During assignment, you can also specify parameters and exclusions.
3. Evaluate Compliance:
   • Azure Policy continuously evaluates resources within the assigned scope to ensure compliance. You can view the compliance state in the Azure Policy dashboard.
4. Remediate Non-compliant Resources:
   • For policies with remediation capabilities, Azure Policy can automatically bring non-compliant resources into compliance. You can also trigger remediation tasks manually.
5. Monitor and Report:
   • Use the Azure Policy dashboard to monitor compliance across your environment. Generate reports to understand the compliance state and identify areas that need attention.

By implementing and managing Azure Policy, you can ensure that your Azure environment remains compliant with your organization’s standards, regulatory requirements, and best practices.

Example of a Policy Definition

Here is an example of a simple policy definition that denies the creation of resources in a specific region:

{
  "properties": {
    "displayName": "Deny resources in East US",
    "description": "This policy denies the creation of resources in the East US region.",
    "policyRule": {
      "if": {
        "field": "location",
        "equals": "eastus"
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

This policy can be assigned to a scope, and Azure Policy will enforce it by denying any resource creation attempts in the East US region.

By understanding and utilizing Azure Policy, you can effectively manage and govern your Azure resources, ensuring compliance and security across your environment.

References

• The main advantages of Azure Policy include enforcement and compliance, scaling, and remediation .
• Azure Policy helps in managing multiple subscriptions, standardizing configurations, and ensuring regulatory compliance .

Refrence: https://learn.microsoft.com/en-us/training/modules/configure-virtual-machine-backups/8-compare-backup-options

Refrence: https://learn.microsoft.com/en-us/training/modules/configure-azure-policy/3-implement-azure-policies

Refrence: https://learn.microsoft.com/security/zero-trust/azure-infrastructure-avd

Refrence: https://learn.microsoft.com/en-us/training/modules/configure-virtual-machine-backups/7-implement-azure-backup-server

Refrence: https://learn.microsoft.com/en-us/azure/developer/terraform/overview

Configure resource locks

Configure Resource Locks

Resource locks in Azure are a critical feature to prevent accidental deletion or modification of your resources. They are particularly useful in environments where multiple administrators have access to the resources. Here’s a detailed explanation of how to configure resource locks:

Types of Resource Locks

Azure provides two types of resource locks:

1. CanNotDelete (ReadOnly): This lock allows authorized users to read and modify a resource, but they cannot delete it.
2. ReadOnly: This lock allows authorized users to read a resource, but they cannot delete or update it. Applying this lock is similar to restricting all users to the Reader role.

Steps to Configure Resource Locks

1. Navigate to the Resource:
   • Go to the Azure portal.
   • Navigate to the resource you want to lock. This can be a resource group, a specific resource like a storage account, or even a subscription.
2. Access the Locks Blade:
   • In the resource’s settings, find and click on the “Locks” option. This is usually found under the “Settings” section.
3. Add a Lock:
   • Click on the “Add” button to create a new lock.
   • Provide a name for the lock. This name should be descriptive enough to indicate the purpose of the lock.
   • Choose the lock type: either “ReadOnly” or “CanNotDelete”.
   • Optionally, you can add notes to describe the purpose of the lock.
4. Save the Lock:
   • Click on the “OK” or “Save” button to apply the lock to the resource.

Example: Adding a Lock to a Storage Account

Here’s an example of how to add a lock to a storage account:

1. Navigate to the Storage Account:
   • Open the Azure portal and go to your storage account.
2. Access the Locks Blade:
   • In the storage account’s settings, click on “Locks” under the “Settings” section.
3. Add a Lock:
   • Click on “Add”.
   • Name the lock, for example, “PreventDeletion”.
   • Choose the lock type “CanNotDelete”.
   • Optionally, add notes like “This lock prevents accidental deletion of the storage account”.
4. Save the Lock:
   • Click “OK” to apply the lock.

Considerations

• Inheritance: Locks are inherited by child resources. For example, if you apply a lock to a resource group, all resources within that group will inherit the lock.
• Permissions: Only users with the appropriate permissions (e.g., Owner or User Access Administrator) can create or delete locks.
• Impact on Operations: Be aware that locks can impact operations. For example, a ReadOnly lock will prevent any updates to the resource, which might affect automated deployments or updates.

Managing Locks via Azure CLI

You can also manage resource locks using the Azure CLI. Here’s an example of how to add a lock to a resource group:

# Add a ReadOnly lock to a resource group
az lock create --name LockName --lock-type ReadOnly --resource-group ResourceGroupName

# Add a CanNotDelete lock to a specific resource
az lock create --name LockName --lock-type CanNotDelete --resource-group ResourceGroupName --resource-name ResourceName --resource-type ResourceType

Managing Locks via Azure PowerShell

Similarly, you can use Azure PowerShell to manage locks:

# Add a ReadOnly lock to a resource group
New-AzResourceLock -LockName "LockName" -LockLevel ReadOnly -ResourceGroupName "ResourceGroupName"

# Add a CanNotDelete lock to a specific resource
New-AzResourceLock -LockName "LockName" -LockLevel CanNotDelete -ResourceGroupName "ResourceGroupName" -ResourceName "ResourceName" -ResourceType "ResourceType"

Conclusion

Configuring resource locks is an essential practice to safeguard critical resources in Azure. By understanding and implementing resource locks, you can prevent accidental deletions and modifications, ensuring the stability and security of your Azure environment.

For more detailed information, you can refer to the official documentation on locking resources .

Refrence: https://learn.microsoft.com/en-us/training/modules/design-governance/5-design-for-resource-groups

Refrence: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals

Refrence: https://learn.microsoft.com/en-us/training/modules/describe-features-tools-azure-for-governance-compliance/5-exercise-configure-resource-lock

Refrence: https://learn.microsoft.com/en-us/azure/ddos-protection/../azure-resource-manager/management/overview

Refrence: https://learn.microsoft.com/en-AU/azure/azure-monitor/alerts/alerts-understand-migration

Apply and manage tags on resources

Apply and Manage Tags on Resources

Tags in Azure are name/value pairs that you can apply to resources and resource groups to logically organize them. Tags are particularly useful for managing and organizing resources for billing, monitoring, and access control. Here’s a detailed explanation of how to apply and manage tags on resources:

1. Understanding Tags

• Name/Value Pairs: Each tag consists of a name and a value. For example, a tag might have the name Environment and the value Production.
• Resource Support: Tags can be applied to various resources such as Compute VMs, NICs, IP addresses, load balancers, storage accounts, and managed disks .

2. Applying Tags

• During Resource Creation: Tags can be applied when creating resources. For example, when creating a virtual machine, you can specify tags in the creation process.

• Using Azure Portal: You can add tags to existing resources through the Azure Portal. Navigate to the resource, select the “Tags” blade, and add the desired name/value pairs.

• Using Azure CLI: You can use the Azure Command-Line Interface (CLI) to add tags. For example:

  az resource tag --tags Environment=Production --name myResource --resource-group myResourceGroup

• Using Azure PowerShell: Similarly, you can use PowerShell to add tags:

  Set-AzResource -ResourceGroupName myResourceGroup -ResourceName myResource -Tag @{Environment="Production"}

3. Managing Tags

• Viewing Tags: You can view tags applied to resources in the Azure Portal, CLI, or PowerShell. This helps in quickly identifying resources based on their tags.
• Updating Tags: Tags can be updated by modifying the name/value pairs. This can be done through the Azure Portal, CLI, or PowerShell.
• Removing Tags: Tags can be removed if they are no longer needed. This can also be done through the Azure Portal, CLI, or PowerShell.

4. Limitations of Tags

• Maximum Number of Tags: Each resource or resource group can have a maximum of 15 tag name/value pairs .
• Character Limits: The tag name is limited to 512 characters, and the tag value is limited to 256 characters. For storage accounts, the tag name is limited to 128 characters .
• Inheritance: Tags applied to a resource group are not inherited by the resources within that resource group .

5. Best Practices

• Consistent Naming: Use a consistent naming convention for tags to ensure they are easily understandable and manageable.
• Use for Billing: Tags can be used to clarify billing by viewing costs for a group of resources sharing the same tag .
• Organize by Function: Tags can help organize resources by their function, environment, or owner, making it easier to manage and monitor them.

6. Examples of Tag Usage

• Cost Center: Tag resources with a cost center to track expenses for different departments.

  az resource tag --tags CostCenter=Finance --name myResource --resource-group myResourceGroup

• Environment: Tag resources to differentiate between development, staging, and production environments.

  az resource tag --tags Environment=Production --name myResource --resource-group myResourceGroup

By applying and managing tags effectively, you can ensure better organization, management, and tracking of your Azure resources. This is crucial for maintaining a well-governed and cost-effective Azure environment.

Refrence: https://learn.microsoft.com/en-us/azure/aks/faq

Refrence: https://learn.microsoft.com/en-us/azure/firewall/../azure-resource-manager/management/overview

Refrence: https://learn.microsoft.com/en-AU/azure/devtest-labs/devtest-lab-add-tag

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machines/linux/image-builder-json

Manage resource groups

Manage Resource Groups

Managing resource groups is a crucial aspect of Azure governance and administration. Resource groups in Azure provide a way to manage and organize resources such as virtual machines, storage accounts, and databases. Here’s a detailed explanation of how to manage resource groups:

1. Creating Resource Groups

Resource groups can be created using various methods such as the Azure portal, Azure CLI, and Azure PowerShell.

• Azure Portal:

  1. Navigate to the Azure portal.
  2. Select “Resource groups” from the left-hand menu.
  3. Click on “Add”.
  4. Fill in the required details such as the resource group name and the region.
  5. Click “Review + create” and then “Create”.

• Azure CLI:

  az group create --name MyResourceGroup --location eastus

  This command creates a resource group named MyResourceGroup in the eastus region .

• Azure PowerShell:

  New-AzResourceGroup -Name MyResourceGroup -Location eastus

  This command creates a resource group named MyResourceGroup in the eastus region .

2. Managing Resource Group Properties

Once a resource group is created, you can manage its properties such as tags and policies.

• Tags: Tags are key-value pairs that help organize resources. You can add tags to a resource group to categorize and manage resources more effectively.

  • Azure Portal: Navigate to the resource group, select “Tags”, and add the desired tags.

  • Azure CLI:

    az group update --name MyResourceGroup --set tags.Environment=Production

  • Azure PowerShell:

    Set-AzResourceGroup -Name MyResourceGroup -Tag @{Environment="Production"}

3. Moving Resources Between Resource Groups

You can move resources from one resource group to another. This is useful for reorganizing resources or changing their management scope.

• Azure Portal:

  1. Navigate to the resource group containing the resources you want to move.
  2. Select the resources to move.
  3. Click on “Move” and then “Move to another resource group”.
  4. Select the target resource group and confirm the move.

• Azure CLI:

  az resource move --destination-group NewResourceGroup --ids $(az resource list --resource-group OldResourceGroup --query "[].id" -o tsv)

• Azure PowerShell:

  $resources = Get-AzResource -ResourceGroupName OldResourceGroup
  Move-AzResource -DestinationResourceGroupName NewResourceGroup -ResourceId $resources.ResourceId

4. Deleting Resource Groups

Deleting a resource group removes the group and all the resources contained within it. This action is irreversible, so it should be done with caution.

• Azure Portal:

  1. Navigate to the resource group you want to delete.
  2. Click on “Delete resource group”.
  3. Confirm the deletion by typing the resource group name and clicking “Delete”.

• Azure CLI:

  az group delete --name MyResourceGroup --yes --no-wait

• Azure PowerShell:

  Remove-AzResourceGroup -Name MyResourceGroup -Force

5. Best Practices for Managing Resource Groups

• Use Naming Conventions: Implement consistent naming conventions for resource groups to make them easily identifiable.
• Apply Tags: Use tags to categorize and manage resources effectively.
• Implement Policies: Apply Azure Policies to resource groups to enforce compliance and governance.
• Monitor Costs: Use Azure Cost Management to monitor and manage costs associated with resource groups.
• Regular Audits: Perform regular audits of resource groups to ensure they are organized and managed properly.

By effectively managing resource groups, you can ensure better organization, governance, and control over your Azure resources.

Refrence: https://learn.microsoft.com/en-us/azure/devops/repos/../pipelines/overview-azure

Refrence: https://learn.microsoft.com/en-us/azure/virtual-machines/move-virtual-machines-regional-zonal-powershell

Refrence: https://learn.microsoft.com/en-us/azure/container-instances/how-to-reuse-dns-names

Refrence: https://learn.microsoft.com/en-AU/azure/azure-functions/functions-container-apps-hosting

Manage subscriptions

Managing Azure subscriptions is a critical aspect of Azure governance and involves several tasks to ensure that resources are organized, costs are controlled, and access is appropriately managed. Here’s a detailed explanation of how to manage Azure subscriptions:

1. Understanding Azure Subscriptions

An Azure subscription is a logical container used to provision resources in Azure. It holds the details of all your resources like virtual machines (VMs), databases, and more. Each subscription has limits or quotas on the resources you can create and use.

2. Creating and Managing Subscriptions

To create and manage Azure subscriptions, you can use the Azure portal, Azure CLI, or ARM templates.

Using the Azure Portal:

1. Create a Subscription:
   • Navigate to the Azure portal.
   • Select Cost Management + Billing from the left-hand menu.
   • Click on Add to create a new subscription.
   • Follow the prompts to select the offer and configure the subscription.
2. Manage Subscriptions:
   • In the Azure portal, go to Cost Management + Billing.
   • Select Subscriptions to view and manage your subscriptions.
   • You can rename, change the billing account, or transfer ownership of the subscription.

Using Azure CLI:

1. Set Default Subscription:

   • If you have multiple subscriptions, you can set the default subscription using the following command:

     az account set --subscription "<subscription ID or name>"

   • This command ensures that all subsequent CLI commands are run against the specified subscription .

2. List Subscriptions:

   • To list all subscriptions associated with your account, use:

     az account list --output table

Using ARM Templates:

1. Programmatically Create Subscriptions:
   • You can use ARM templates to create new Azure subscriptions within a management group. This is useful for automating the creation of subscriptions in an enterprise environment.
   • Refer to the following resources for detailed steps:
     • Programmatically create Azure Enterprise Agreement subscriptions
     • Programmatically create Azure subscriptions for a Microsoft Customer Agreement
     • Programmatically create Azure subscriptions for a Microsoft Partner Agreement .

3. Managing Costs

Managing costs is crucial to avoid unexpected charges and optimize spending.

1. Cost Analysis:
   • Use the Cost Management + Billing service in the Azure portal to analyze costs.
   • Navigate to Cost Management + Billing > Subscriptions > select your subscription > Cost analysis.
   • The Cost analysis dashboard provides detailed insights into your spending, allowing you to filter by service or resource type and export data for further analysis .
2. Setting Budgets and Alerts:
   • You can set budgets to track your spending and create alerts to notify you when spending exceeds predefined thresholds.
   • In the Azure portal, go to Cost Management + Billing > Budgets to create and manage budgets.

4. Managing Access and Security

1. Role-Based Access Control (RBAC):
   • Use RBAC to manage who has access to your Azure resources and what they can do with those resources.
   • Assign roles to users, groups, and applications at different scopes (subscription, resource group, or resource level).
2. Policies and Compliance:
   • Implement Azure Policy to enforce organizational standards and assess compliance at scale.
   • Create and assign policies to ensure resources are compliant with your governance requirements.

5. Monitoring and Reporting

1. Azure Advisor:
   • Use Azure Advisor to get personalized recommendations on how to optimize your Azure resources for high availability, security, performance, and cost.
2. Reports:
   • Generate and review reports to monitor the usage and performance of your resources.
   • Use the Cost Management + Billing service to create detailed cost reports.

By effectively managing Azure subscriptions, you can ensure that your resources are well-organized, costs are controlled, and access is properly managed, which is essential for maintaining a secure and efficient Azure environment.

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machine-scale-sets/tutorial-create-and-manage-cli

Refrence: https://learn.microsoft.com/en-us/cli/azure/authenticate-azure-cli

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/bicep/deploy-to-management-group

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machine-scale-sets/tutorial-connect-to-instances-cli

Refrence: https://learn.microsoft.com/en-AU/azure/lab-services/cost-management-guide

Manage costs by using alerts, budgets, and Azure Advisor recommendations

To manage costs effectively in Azure, you can use alerts, budgets, and Azure Advisor recommendations. Here’s a detailed explanation of each:

1. Budgets

Budgets in Azure help you plan and control your spending. You can create budgets to monitor and alert on costs at various granularities, such as subscriptions or resource groups. Here’s how you can manage costs using budgets:

• Create Budgets: You can create budgets to track your spending. Budgets can be set to alert you when spending reaches certain thresholds, such as 60%, 80%, and 100% of the budget. This helps in proactively managing costs and avoiding overspending .
• Configure Alerts: When creating a budget, you can configure alerts to notify stakeholders when spending reaches specified percentages of the budget. This ensures that the relevant teams are aware of spending anomalies and can take corrective actions .
• Filters: Budgets can specify one or more filters, allowing you to monitor and alert on costs at various granularities, such as specific resource types or services .

2. Alerts

Alerts in Azure are used to notify you of spending anomalies and potential overspending. Here’s how you can manage costs using alerts:

• Set Up Alerts: You can set up alerts for various cost-related events. For example, you can create alerts for when spending exceeds a certain threshold or when a new recommendation from Azure Advisor is detected .
• Action Groups: When an alert is triggered, you can configure the action that will take place, such as sending an email or triggering an automation runbook. This is done by selecting or creating an action group .
• Azure Activity Log: Alerts can be based on events stored in the Azure Activity Log, such as new recommendations from Azure Advisor. This helps in keeping track of important cost-related events and taking timely actions .

3. Azure Advisor Recommendations

Azure Advisor provides personalized recommendations to help you optimize your Azure resources for high availability, security, performance, and cost. Here’s how you can manage costs using Azure Advisor recommendations:

• Cost Recommendations: Azure Advisor provides recommendations specifically aimed at cost optimization. These recommendations can help you identify underutilized resources, opportunities to resize or shut down VMs, and other cost-saving measures .
• Set Up Alerts for Recommendations: You can set up alerts to notify you when new cost recommendations are available. This ensures that you are always aware of potential cost-saving opportunities and can act on them promptly .
• Categories and Impact Levels: You can filter recommendations based on categories (e.g., cost) and impact levels to focus on the most critical recommendations .

By effectively using budgets, alerts, and Azure Advisor recommendations, you can manage and optimize your Azure costs, ensuring that you stay within your budget and make the most of your Azure resources.

Refrence: https://learn.microsoft.com/en-AU/azure/batch/plan-to-manage-costs

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/storage-plan-manage-costs

Refrence: https://learn.microsoft.com/en-us/azure/batch/plan-to-manage-costs

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/bicep/../../advisor/advisor-alerts-bicep

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/templates/../../advisor/advisor-alerts-arm

Configure management groups

Configure Management Groups

Azure management groups provide a way to organize and manage access, policy, and compliance across multiple Azure subscriptions. They are particularly useful for enterprises that have multiple subscriptions and need to apply governance at scale. Here’s a detailed explanation of how to configure management groups:

1. Understanding Management Groups

Management groups are containers that help you manage access, policy, and compliance across multiple Azure subscriptions. They allow you to apply governance conditions to a hierarchy of subscriptions. Here are some key characteristics:

• Hierarchy: Management groups can be organized in a hierarchy, with a root management group at the top. This hierarchy can support up to six levels of depth .
• Inheritance: Policies and access controls applied at a management group level are inherited by all subscriptions and resources within that group .
• Default Placement: By default, all new subscriptions are placed under the top-level management group, also known as the root group .

2. Creating and Configuring Management Groups

To create and configure management groups, follow these steps:

1. Access Management Groups:
   • Navigate to the Azure portal.
   • In the left-hand menu, select Management groups.
2. Create a Management Group:
   • Click on + Add management group.
   • Provide a unique Management Group ID and a Management Group Name.
   • Click Save to create the management group.
3. Organize Subscriptions:
   • Once the management group is created, you can add subscriptions to it.
   • Select the management group you created.
   • Click on + Add subscription.
   • Choose the subscriptions you want to add and click Save.
4. Apply Policies and Access Controls:
   • Navigate to the management group where you want to apply policies.
   • Select Policies from the left-hand menu.
   • Click on + Assign policy to apply a new policy.
   • Choose the policy definition and configure the assignment settings.
   • Click Review + create and then Create to apply the policy.
5. Manage Access:
   • To manage access, select the management group.
   • Click on Access control (IAM).
   • Click on + Add role assignment.
   • Choose the role and assign it to users, groups, or service principals.

3. Best Practices

• Use a Hierarchical Structure: Organize your management groups in a hierarchical structure that reflects your organization’s structure. This makes it easier to manage and apply policies consistently.
• Apply Policies at Higher Levels: Apply policies at higher levels in the hierarchy to ensure they are inherited by all lower levels. This reduces the need to apply the same policy multiple times.
• Monitor and Audit: Regularly monitor and audit the policies and access controls applied to your management groups to ensure compliance and security.

4. Example Scenario

Consider an organization with multiple departments, each having its own Azure subscription. The organization can create a management group for each department and apply department-specific policies and access controls. At the top level, the organization can have a root management group that applies global policies and access controls inherited by all departments.

By following these steps and best practices, you can effectively configure and manage Azure management groups to ensure consistent governance across your Azure environment.

For more detailed information, you can refer to the official Azure Management Groups documentation .

Refrence: https://learn.microsoft.com/en-us/azure/application-gateway/../azure-resource-manager/management/overview

Refrence: https://learn.microsoft.com/en-us/training/modules/configure-azure-policy/2-create-management-groups

Refrence: https://learn.microsoft.com/en-AU/azure/devtest-labs/devtest-lab-configure-cost-management

Refrence: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/external-ntpsource-configuration

Refrence: https://learn.microsoft.com/en-us/azure/sentinel/unified-connector-syslog-device

Implement and manage storage (15–20%)

Configure access to storage

Configure Azure Storage firewalls and virtual networks

To configure Azure Storage firewalls and virtual networks, follow these steps to ensure secure access to your storage account:

Step-by-Step Guide

1. Navigate to the Storage Account:
   • Open the Azure portal.
   • Go to your storage account by searching for it in the search bar or navigating through the resource groups.
2. Access the Networking Settings:
   • In the storage account settings, select Networking under the Settings section.
3. Configure Firewall and Virtual Network Rules:
   • In the Firewalls and virtual networks tab, you can configure the following settings:
     • Allow access from all networks: This setting allows access to the storage account from any network. This is not recommended for production environments due to security risks.
     • Selected networks: This option allows you to specify which virtual networks and IP addresses can access the storage account.
4. Add Virtual Networks:
   • To add a virtual network, click on Add existing virtual network.
   • Select the subscription, virtual network, and subnet you want to grant access to.
   • Click Add to include the selected virtual network.
5. Add IP Address Rules:
   • To add specific IP addresses or IP ranges, click on Add IP rule.
   • Enter the IP address or range in CIDR format (e.g., 192.168.1.0/24).
   • Click Add to include the IP rule.
6. Save the Configuration:
   • After configuring the virtual networks and IP rules, click Save to apply the changes.

Testing and Verification

• Testing Access:
  • To test if the virtual network or firewall rules are causing access issues, you can temporarily change the setting on the storage account to Allow access from all networks. This helps to identify if the restrictions are correctly configured .
• Verifying Configuration:
  • Ensure that the virtual network and firewall rules are correctly configured by accessing the storage account from the allowed networks and IP addresses.

Important Considerations

• Security Risks:
  • Allowing access from all networks can pose significant security risks. It is recommended to restrict access to specific virtual networks and IP addresses to enhance security.
• Anonymous Access:
  • By default, anonymous access to blob data is prohibited. Disabling anonymous access helps prevent data breaches caused by undesired anonymous access .

Example Scenario

Imagine you have a storage account that should only be accessible from your corporate network. You can configure the storage account to allow access only from the virtual network that represents your corporate network and specific IP addresses within that network. This ensures that only authorized users within your corporate network can access the storage account, enhancing security.

By following these steps and considerations, you can effectively configure Azure Storage firewalls and virtual networks to secure your storage account and control access based on your organizational requirements.

Refrence: https://learn.microsoft.com/troubleshoot/azure/azure-storage/files-troubleshoot-smb-connectivity

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/shared-key-authorization-prevent

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent

Create and use shared access signature (SAS) tokens

Create and Use Shared Access Signature (SAS) Tokens

A Shared Access Signature (SAS) is a secure way to grant limited access to resources in your Azure Storage account without exposing your account key. SAS tokens are appended to the URI for an Azure Storage resource and contain a special set of query parameters that indicate how the resources may be accessed by the client. Here’s a detailed explanation of how to create and use SAS tokens:

Types of SAS Tokens

1. User Delegation SAS:
   • Secured with Microsoft Entra credentials.
   • Recommended for superior security.
   • Uses OAuth 2.0 token requested on behalf of the user.
   • Example use case: Granting access to a blob for a specific user.
2. Service SAS:
   • Secured with a shared key.
   • Grants access to a specific service within the storage account.
   • Example use case: Allowing a client to read and write to a specific blob.
3. Account SAS:
   • Secured with a shared key.
   • Grants access to services across the entire storage account.
   • Example use case: Allowing a client to perform operations on multiple services within the storage account.

Creating a SAS Token

1. Using Microsoft Entra Credentials (User Delegation SAS):

   • Microsoft recommends using Microsoft Entra credentials for creating a user delegation SAS for enhanced security.

   • The OAuth 2.0 token used to sign the SAS is requested on behalf of the user.

   • Example:

     az storage blob generate-sas \
       --account-name <storage-account-name> \
       --container-name <container-name> \
       --name <blob-name> \
       --permissions r \
       --expiry <expiry-date> \
       --auth-mode login \
       --as-user

2. Using Shared Key (Service SAS and Account SAS):

   • A SAS token is generated by signing the SAS parameters with the account key.

   • Example:

     az storage container generate-sas \
       --account-name <storage-account-name> \
       --name <container-name> \
       --permissions rwdl \
       --expiry <expiry-date> \
       --account-key <account-key>

Using a SAS Token

• Appending SAS Token to URI:

  • The SAS token is appended to the URI of the Azure Storage resource.

  • Example:

    https://<storage-account-name>.blob.core.windows.net/<container-name>/<blob-name>?<sas-token>

• Accessing the Resource:
  • Any client that possesses a valid SAS can access the data in your storage account as permitted by the SAS.
  • It’s important to protect a SAS from malicious or unintended use.

Security Considerations

• Use Microsoft Entra Credentials:
  • When possible, use Microsoft Entra credentials to create a user delegation SAS for superior security .
• Restrict Permissions:
  • Be careful to restrict permissions that allow users to generate SAS tokens .
• Disallow Shared Key Access:
  • To prevent users from generating a SAS that is signed with the account key, you can disallow Shared Key access to the storage account .
• Revoking a Compromised SAS:
  • Have a plan in place for revoking a compromised SAS to protect your data .

Example Scenario

Imagine you have a storage account and you want to grant a user read access to a specific blob for a limited time. You can create a user delegation SAS using Microsoft Entra credentials, append the SAS token to the blob URI, and share the URI with the user. The user can then access the blob using the provided URI until the SAS token expires.

By following these steps and considerations, you can securely create and use SAS tokens to manage access to your Azure Storage resources.

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-user-delegation-sas-create-cli

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/storage-sas-overview

Refrence: https://learn.microsoft.com/en-AU/azure/azure-monitor/../virtual-machines/extensions/diagnostics-linux

Refrence: https://learn.microsoft.com/azure/virtual-machines/extensions/diagnostics-linux-v3

Configure stored access policies

Configure Stored Access Policies

A stored access policy provides an additional level of control over a service-level shared access signature (SAS) on the server side. It allows you to group shared access signatures and apply additional restrictions to them. Stored access policies can be used to change the start time, expiry time, or permissions for a signature, and they can also be used to revoke a signature after it has been issued .

Steps to Configure a Stored Access Policy

Configuring a stored access policy is a two-step process: defining the policy and then applying it to the container. Here are the detailed steps:

1. Navigate to the Containers List:
   • In the Azure portal, go to your storage account and navigate to the list of containers.
2. Select the Container:
   • Select the checkbox next to the name of the container for which you’ll generate an SAS token.
   • Click on the container’s More button (…), and select Access policy to display the Access policy pane.
3. Add a New Policy:
   • In the Access policy pane, click + Add policy in the Stored access policies section to open the Add policy pane.
   • Enter a name for your new policy in the Identifier box.
   • Select the desired permissions by checking the appropriate boxes in the Permissions field.
   • Optionally, set the policy’s validity period by providing date, time, and time zone values for the Start time and Expiry time fields.
4. Save the Policy:
   • Review your settings for accuracy and click OK to update the Access policy pane.
   • To apply the new policy to the container, click Save in the Access policy pane. If you navigate away from this pane without saving, the policy will not be applied, and you will lose your work .

Managing Stored Access Policies

• Revoke a Policy:

  • To revoke a stored access policy, you can delete the signed identifier and create a new one. This breaks the associations between any existing signatures and the stored access policy. Deleting or modifying the stored access policy immediately affects all associated shared access signatures .

  • Example code to revoke a policy by changing the Id property for the signed identifier:

    public static async Task RevokeStoredAccessPolicyAsync(BlobContainerClient containerClient)
    {
        BlobContainerAccessPolicy accessPolicy = await containerClient.GetAccessPolicyAsync();
        List<BlobSignedIdentifier> signedIdentifiers = accessPolicy.SignedIdentifiers.ToList();
        // Revoke a single policy by changing its name
        var samplePolicy = signedIdentifiers.FirstOrDefault(item => item.Id == "sample-read-policy");
        samplePolicy.Id = "sample-read-policy-revoke";
        // Update the container's access policy
        await containerClient.SetAccessPolicyAsync(permissions: signedIdentifiers);
    }

• Delete All Policies:

  • You can remove all access policies from a container resource by calling SetAccessPolicyAsync with an empty permissions parameter.

  • Example code to delete all stored access policies from a specified container:

    public static async Task DeleteStoredAccessPolicyAsync(BlobContainerClient containerClient)
    {
        // Remove all stored access policies for the container resource
        await containerClient.SetAccessPolicyAsync();
    }

Benefits of Using Stored Access Policies

• Centralized Management: Stored access policies allow you to manage permissions and expiry times centrally, making it easier to update or revoke access as needed.
• Enhanced Security: By grouping SAS tokens under a stored access policy, you can quickly revoke access to multiple tokens by modifying or deleting the policy.
• Flexibility: You can define multiple policies with different permissions and expiry times, providing fine-grained control over access to your storage resources.

By following these steps and understanding the benefits, you can effectively configure and manage stored access policies in Azure Storage, ensuring secure and controlled access to your resources.

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/sas-service-create-dotnet-container

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/blob-containers-portal

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/sas-service-create-dotnet

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/sas-service-create-python-container

Manage access keys

Manage Access Keys in Azure Storage

Managing access keys is a crucial aspect of securing your Azure Storage account. Access keys are used to authorize access to data in your storage account. Here’s a detailed explanation of how to manage access keys effectively:

1. Viewing and Copying Access Keys

To view and copy your storage account access keys, you can use the Azure portal, Azure CLI, or PowerShell. Here’s how you can do it using the Azure portal:

1. Navigate to your storage account in the Azure portal.
2. Under the Settings section, select Access keys.
3. You will see two keys (key1 and key2). You can copy the connection string or the individual keys by clicking the Copy button next to each key.

2. Regenerating Access Keys

For security reasons, it is recommended to periodically regenerate your access keys. This can be done through the Azure portal, Azure CLI, or PowerShell. Here’s how to regenerate keys using the Azure portal:

1. Navigate to your storage account in the Azure portal.
2. Under the Settings section, select Access keys.
3. Click the Regenerate button next to the key you want to regenerate (key1 or key2).
4. Confirm the regeneration action.

3. Using Azure Key Vault for Key Management

Microsoft recommends using Azure Key Vault to manage and rotate your access keys. This approach enhances security by avoiding the storage of keys within your application code. Here’s how you can manage storage account keys with Azure Key Vault:

1. Store Keys in Key Vault: Store your storage account keys in Azure Key Vault. This can be done using Azure CLI or PowerShell.
2. Access Keys Securely: Your application can securely access the keys stored in Key Vault, ensuring that the keys are not exposed in your application code.

For more information, you can refer to the following articles: - Manage storage account keys with Azure Key Vault and PowerShell . - Manage storage account keys with Azure Key Vault and the Azure CLI .

4. Disabling Shared Key Authorization

For optimal security, Microsoft recommends using Microsoft Entra ID with managed identities to authorize requests against blob, queue, and table data, whenever possible. Shared Key authorization can be disabled to enforce this security measure. Here’s how to verify that Shared Key authorization is no longer permitted:

1. Use the Azure CLI to query the storage account settings:

   az storage account show --name <storage-account-name> --resource-group <resource-group-name> --query "allowSharedKeyAccess"

2. The command returns false if Shared Key authorization is disallowed for the storage account .

5. Best Practices

• Rotate Keys Regularly: Regularly regenerate your access keys to minimize the risk of unauthorized access.
• Use Managed Identities: Whenever possible, use Microsoft Entra ID with managed identities for superior security and ease of use.
• Store Keys Securely: Use Azure Key Vault to store and manage your access keys securely.

By following these practices, you can ensure that your Azure Storage account remains secure and that access to your data is properly managed.

Refrence: https://learn.microsoft.com/en-us/azure/storage/files/../common/customer-managed-keys-overview

Refrence: https://learn.microsoft.com/en-us/azure/storage/queues/../common/customer-managed-keys-overview

Refrence: https://learn.microsoft.com/en-us/azure/storage/queues/../common/storage-configure-connection-string

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/storage-account-keys-manage

Configure identity-based access for Azure Files

Configure Identity-Based Access for Azure Files

Configuring identity-based access for Azure Files involves setting up authentication and authorization mechanisms that allow users to access Azure file shares using their existing identities. This can be achieved through integration with various identity providers such as Microsoft Entra ID (formerly Azure AD), on-premises Active Directory Domain Services (AD DS), or Microsoft Entra Domain Services. Here’s a detailed explanation of the steps involved:

1. Understanding Identity-Based Authentication Options

Azure Files supports identity-based authentication over SMB (Server Message Block) through the following methods: - On-premises Active Directory Domain Services (AD DS) - Microsoft Entra Domain Services - Microsoft Entra Kerberos (for hybrid user accounts only)

Each method has its own configuration steps and supported scenarios. You can only use one AD method for identity-based authentication with Azure Files .

2. Configuring Microsoft Entra ID for Hybrid Identities

For hybrid user identities (on-premises AD DS identities synced to Microsoft Entra ID), you can configure Microsoft Entra ID to issue Kerberos tickets for accessing Azure file shares. This allows users to access file shares over the internet without requiring direct network connectivity to domain controllers .

Steps: 1. Sync On-Premises AD DS with Microsoft Entra ID: Ensure your on-premises AD DS identities are synced with Microsoft Entra ID. 2. Enable Kerberos Authentication: Configure Microsoft Entra ID to issue Kerberos tickets for hybrid identities. 3. Configure Windows ACLs: Set up Windows access control lists (ACLs) and directory/file-level permissions, which require network connectivity to the on-premises domain controller .

3. Configuring On-Premises AD DS

For environments using on-premises AD DS, you need to configure NTFS and share permissions to allow access to the file shares.

Steps: 1. Assign Azure RBAC Roles: Assign the appropriate Azure role-based access control (RBAC) roles, such as the Storage File Data SMB Share Reader role, to the users or groups that need access . 2. Configure NTFS Permissions: Set NTFS permissions to give read access to each session host’s computer object .

4. Configuring Microsoft Entra Domain Services

For environments using Microsoft Entra Domain Services, the configuration is similar to on-premises AD DS.

Steps: 1. Assign Azure RBAC Roles: Assign the Storage File Data SMB Share Reader role as the default share-level permission . 2. Configure NTFS Permissions: Set NTFS permissions to give read access to each session host’s computer object .

5. Assigning Share-Level Permissions

To grant additional users access to your file share, you need to assign share-level permissions and configure Windows ACLs.

Steps: 1. Assign Share-Level Permissions: Follow the instructions to assign share-level permissions to the users or groups . 2. Configure Windows ACLs: Set up Windows ACLs to control access at the directory and file level .

6. Verifying Permissions

After configuring the permissions, it’s important to verify that they are set correctly.

Steps: 1. Use PsExec: You can use tools like PsExec to verify that the permissions are correctly configured . 2. Check File Share Access: Ensure that the users or session hosts can access the file shares as intended .

7. Additional Resources

For more detailed information and step-by-step guides, refer to the following resources: - Overview of Azure Files identity-based authentication options for SMB access . - Authorize access to data in Azure Storage . - Authorize access to file data in the Azure portal .

By following these steps, you can configure identity-based access for Azure Files, ensuring secure and seamless access to file shares for your users.

Refrence: https://learn.microsoft.com/en-us/azure/virtual-desktop/app-attach-overview

Refrence: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-domain-services-enable

Refrence: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/storage-introduction

Configure and manage storage accounts

Create and configure storage accounts

To create and configure storage accounts in Azure, follow these detailed steps:

1. Create a Storage Account

Using the Azure Portal:

1. Navigate to the Azure Portal: Go to the Azure Portal.
2. Create a New Storage Account:
   • In the left-hand menu, select Storage accounts.
   • Click on the + Create button.
3. Fill Out the Basics Tab:
   • Subscription: Select the Azure subscription you want to use.
   • Resource Group: Choose an existing resource group or create a new one.
   • Storage Account Name: Enter a unique name for your storage account.
   • Region: Select the Azure region where you want to create the storage account.
   • Performance: Choose between Standard and Premium based on your performance needs.
   • Redundancy: Select the redundancy option (e.g., LRS, GRS, ZRS, GZRS) that suits your data replication requirements.
4. Configure Advanced Settings:
   • Networking: Configure network access and connectivity options.
   • Data Protection: Set up data protection features like soft delete and versioning.
   • Encryption: Choose the encryption type (Microsoft-managed keys or customer-managed keys).
5. Review and Create:
   • Review your settings and click on the Create button to deploy the storage account.

Using Azure CLI:

az storage account create \
  --name <storage-account-name> \
  --resource-group <resource-group-name> \
  --location <location> \
  --sku Standard_LRS \
  --kind StorageV2

Using PowerShell:

New-AzStorageAccount -ResourceGroupName <resource-group-name> `
  -Name <storage-account-name> `
  -Location <location> `
  -SkuName Standard_LRS `
  -Kind StorageV2

2. Configure Storage Account Settings

Configure Redundancy:

• Locally Redundant Storage (LRS): Replicates data three times within a single data center.
• Geo-Redundant Storage (GRS): Replicates data to a secondary region.
• Zone-Redundant Storage (ZRS): Replicates data across multiple availability zones within a region.
• Geo-Zone Redundant Storage (GZRS): Combines the benefits of GRS and ZRS.

Configure Encryption:

• Microsoft-Managed Keys: Azure manages the encryption keys.
• Customer-Managed Keys: You manage the encryption keys using Azure Key Vault.
  • Azure Storage can automatically update the customer-managed key to use the latest key version from the key vault .

Configure Network Access:

• Public Endpoint: Allows access from any network.
• Private Endpoint: Restricts access to a specific virtual network.
• Firewall Rules: Define IP ranges that can access the storage account.

3. Manage Data in the Storage Account

Using Azure Storage Explorer:

• Download and Install: Install Azure Storage Explorer from the Microsoft website.
• Connect to Storage Account: Use your Azure credentials to connect to the storage account.
• Manage Data: Upload, download, and manage blobs, files, queues, and tables.

Using AzCopy:

• Download and Install: Install AzCopy from the Microsoft website.

• Copy Data: Use AzCopy commands to transfer data to and from the storage account.

  azcopy copy 'https://<storage-account-name>.blob.core.windows.net/<container-name>/<blob-name>' '<local-file-path>'

4. Configure Access Control

Using Shared Access Signatures (SAS):

• Generate SAS Token: Create a SAS token to grant limited access to storage account resources.
• Use SAS Token: Append the SAS token to the storage account URL to access resources.

Using Azure Active Directory (AAD):

• Assign Roles: Use Azure RBAC to assign roles to users and groups for accessing the storage account.
• Manage Access: Control access to storage account resources using AAD identities.

By following these steps, you can effectively create and configure storage accounts in Azure, ensuring that your data is stored securely and is accessible as needed.

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/customer-managed-keys-overview

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/customer-managed-keys-configure-new-account

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/network-file-system-protocol-support

Refrence: https://learn.microsoft.com/en-us/azure/azure-functions/storage-considerations

Refrence: https://learn.microsoft.com/en-us/azure/storage/files/geo-redundant-storage-for-large-file-shares

Configure Azure Storage redundancy

Configuring Azure Storage redundancy is a crucial aspect of managing storage accounts in Azure. Redundancy ensures that your data is replicated and protected against hardware failures, network or power outages, and even regional disasters. Here’s a detailed explanation of how to configure Azure Storage redundancy:

Types of Azure Storage Redundancy

Azure offers several redundancy options, each with different levels of replication and cost implications:

1. Locally Redundant Storage (LRS):
   • Replication: Data is replicated three times within a single data center in the primary region.
   • Use Case: Suitable for scenarios where data loss is acceptable and cost is a primary concern.
   • Cost: Least expensive option.
2. Zone-Redundant Storage (ZRS):
   • Replication: Data is replicated across three different availability zones within the primary region.
   • Use Case: Ideal for scenarios requiring higher availability and protection against data center failures within the same region.
   • Cost: More expensive than LRS due to increased replication.
3. Geo-Redundant Storage (GRS):
   • Replication: Data is replicated three times within the primary region (LRS) and asynchronously replicated to a secondary region.
   • Use Case: Provides protection against regional disasters by maintaining a copy of the data in a geographically distant region.
   • Cost: Higher than ZRS due to cross-region replication.
4. Read-Access Geo-Redundant Storage (RA-GRS):
   • Replication: Similar to GRS, but also allows read access to the data in the secondary region.
   • Use Case: Useful for applications that require read access to data even if the primary region is unavailable.
   • Cost: Higher than GRS due to the additional read access capability.
5. Geo-Zone-Redundant Storage (GZRS):
   • Replication: Combines ZRS in the primary region with asynchronous replication to a secondary region.
   • Use Case: Provides the highest level of availability and durability by combining zone and geo-redundancy.
   • Cost: More expensive than GRS.
6. Read-Access Geo-Zone-Redundant Storage (RA-GZRS):
   • Replication: Similar to GZRS, but also allows read access to the data in the secondary region.
   • Use Case: Ideal for applications that need the highest availability and read access during regional outages.
   • Cost: Most expensive option due to the combination of zone and geo-redundancy with read access.

Configuring Redundancy in Azure Storage

To configure redundancy for your Azure Storage account, follow these steps:

1. Create a Storage Account:
   • Navigate to the Azure portal.
   • Select “Create a resource” and choose “Storage account”.
   • Fill in the required details such as subscription, resource group, and storage account name.
2. Select Redundancy Option:
   • In the “Replication” section, choose the desired redundancy option (LRS, ZRS, GRS, RA-GRS, GZRS, RA-GZRS).
3. Change Redundancy for Existing Storage Account:
   • Navigate to your storage account in the Azure portal.
   • Select “Configuration” under the “Settings” section.
   • Choose the desired redundancy option from the “Replication” dropdown.
   • Save the changes.

Considerations for Changing Redundancy

• Cost Implications: Changing redundancy can incur costs, especially when moving to geo-redundant options due to data transfer and storage requirements .
• Downtime and Limitations: Some changes may require downtime or have limitations. For example, adding or removing zone-redundancy requires a conversion process .
• Failover and Failback: In the event of a regional disaster, you can perform a failover to the secondary region. After failover, the storage account becomes locally redundant (LRS) in the new primary region. To regain geo-redundancy, you need to reconfigure the account .

Example Scenario

Suppose you have a critical application that requires high availability and disaster recovery capabilities. You might choose RA-GZRS for your storage account to ensure that your data is replicated across zones within the primary region and also geo-replicated to a secondary region with read access. This configuration provides the highest level of protection and availability, ensuring that your application can continue to function even during regional outages.

By understanding and configuring Azure Storage redundancy appropriately, you can ensure that your data is protected and available according to your application’s requirements and budget constraints.

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/redundancy-migration

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/storage-failover-customer-managed-unplanned

Refrence: https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/automated-backups-overview

Refrence: https://learn.microsoft.com/en-us/azure/storage/queues/../common/geo-redundant-design

Refrence: https://learn.microsoft.com/en-us/azure/storage/queues/../common/redundancy-migration

Configure object replication

Configure Object Replication

Object replication in Azure Storage allows you to asynchronously copy block blobs from a container in one storage account to a container in another storage account. This feature is useful for scenarios such as disaster recovery, data migration, and data distribution across different regions.

Steps to Configure Object Replication

1. Create a Replication Policy:
   • A replication policy specifies the source storage account and the destination account.
   • The policy includes one or more rules that define the source container and the destination container, indicating which block blobs in the source container will be replicated .
2. Configure the Policy:
   • You can configure the replication policy using the Azure portal, PowerShell, or Azure CLI.
   • The policy can be set up to replicate create, update, and delete operations on the source objects to the destination objects .
3. Cross-Tenant Replication:
   • If the source and destination accounts are in different Microsoft Entra tenants, cross-tenant replication must be explicitly allowed.
   • By default, cross-tenant object replication is disabled for new storage accounts created after December 15, 2023, unless explicitly allowed .
4. Using JSON Files for Policy Definition:
   • If you do not have permissions to the source storage account or need to configure more than 10 container pairs, you can define the replication policy on the destination account and provide a JSON file to another user to create the same policy on the source account .
   • The JSON file includes the policy ID and rules that need to be replicated on the source account.
5. Example Configuration Using Azure Portal:
   • Navigate to the Object replication settings for the destination account.
   • Create a local JSON file that defines the replication policy.
   • Upload the JSON file to the Azure portal to create the replication policy on the destination account.
   • Download the JSON file containing the policy definition and share it with another user to configure the source account .
6. Example Configuration Using PowerShell:

   • Retrieve the policy from the destination account and convert it to JSON:

     $rgName = "<resource-group>"
     $destAccountName = "<destination-storage-account>"
     $destPolicy = Get-AzStorageObjectReplicationPolicy -ResourceGroupName $rgName -StorageAccountName $destAccountName
     $destPolicy | ConvertTo-Json -Depth 5 > C:\temp\json.txt

   • Use the JSON file to define the replication policy on the source account:

     $object = Get-Content -Path C:\temp\json.txt | ConvertFrom-Json
     Set-AzStorageObjectReplicationPolicy -ResourceGroupName $rgName -StorageAccountName $srcAccountName -PolicyId $object.PolicyId -SourceAccount $object.SourceAccount -DestinationAccount $object.DestinationAccount -Rule $object.Rules

7. Example Configuration Using Azure CLI:

   • Write the policy definition to a JSON file:

     az storage account or-policy show --account-name <dest-account-name> --policy-id <policy-id> > policy.json

   • Use the JSON file to configure the replication policy on the source account:

     az storage account or-policy create --resource-group <resource-group> --source-account <source-account-name> --policy @policy.json

Important Considerations

• Replication Latency: The replication latency depends on the size of the block blob being replicated .
• Security Policies: Ensure that your security policies allow or disallow cross-tenant replication as required .
• Lifecycle Management: After data has been replicated, you can reduce costs by moving it to the archive tier using lifecycle management policies .

By following these steps, you can effectively configure object replication in Azure Storage, ensuring that your data is replicated across different storage accounts as needed.

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/object-replication-overview

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/object-replication-prevent-cross-tenant-policies

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/object-replication-configure

Configure storage account encryption

Configure Storage Account Encryption

Azure Storage encryption helps protect and safeguard your data to meet your organizational security and compliance commitments. Azure Storage automatically encrypts all data written to a storage account. By default, data is encrypted with Microsoft-managed keys, but you can also choose to manage your own encryption keys. Here’s a detailed explanation of how to configure storage account encryption:

1. Microsoft-Managed Keys

By default, Azure Storage uses Microsoft-managed keys to encrypt your data. This means that Microsoft handles the encryption keys and the entire encryption process. You don’t need to perform any additional configuration to use Microsoft-managed keys.

2. Customer-Managed Keys

For more control over encryption keys, you can manage your own keys. Customer-managed keys must be stored in Azure Key Vault or Azure Key Vault Managed Hardware Security Model (HSM). Here’s how you can configure customer-managed keys for your storage account:

Prerequisites

• Ensure you have an Azure Key Vault or Managed HSM set up.
• Install Azure CLI 2.12.0 or later.

Steps to Configure Customer-Managed Keys

Using Azure CLI:

1. Create a Key in Managed HSM:
   • Create a key in your managed HSM. Supported key types include RSA-HSM keys of sizes 2048, 3072, and 4096.
   • For more details, see Create an HSM key.
2. Update Storage Account Encryption Settings:

   • Use the az storage account update command to update the storage account’s encryption settings.

   • Include the --encryption-key-source parameter and set it to Microsoft.Keyvault to enable customer-managed keys for the account.

   • Example:

     hsmurl=$(az keyvault show --hsm-name <hsm-name> --query properties.hsmUri --output tsv)
     az storage account update --name <storage-account> --resource-group <resource_group> --encryption-key-name <key> --encryption-key-source Microsoft.Keyvault --encryption-key-vault $hsmurl

3. Automatic Key Rotation:
   • To automatically update the key version for a customer-managed key, omit the key version when you configure encryption.
   • For more information, see Update the key version.
4. Manual Key Version Update:

   • If you prefer to manually update the key version, explicitly specify the version at the time you configure encryption.

   • Example:

     az storage account update --name <storage-account> --resource-group <resource_group> --encryption-key-name <key> --encryption-key-version $key_version --encryption-key-source Microsoft.Keyvault --encryption-key-vault $hsmurl

Using Azure Portal:

1. Locate Key URI:
   • Navigate to your key vault in the Azure portal.
   • Select the Keys setting, choose the desired key, and then select the key version.
   • Copy the value of the Key Identifier field.
2. Configure Encryption Key:
   • In the Encryption key settings for your storage account, choose the Enter key URI option.
   • Paste the URI copied earlier into the Key URI field.
   • Specify the subscription that contains the key vault.
   • Specify either a system-assigned or user-assigned managed identity.
   • Save your changes.

Using PowerShell:

1. Set Encryption Key:

   • Use the Set-AzStorageAccount command to update the storage account’s encryption settings.

   • Example:

     $accountName = "<storage-account>"
     Set-AzStorageAccount -ResourceGroupName $rgName -AccountName $accountName -IdentityType SystemAssignedUserAssigned -UserAssignedIdentityId $userIdentity.Id -KeyvaultEncryption -KeyVaultUri $keyVault.VaultUri -KeyName $key.Name -KeyVersion $key.Version -KeyVaultUserAssignedIdentityId $userIdentity.Id

2. Manual Key Version Update:
   • To manually update the key version, call Get-AzKeyVaultKey to get the latest version of the key.
   • Then call Set-AzStorageAccount to update the storage account’s encryption settings to use the new version.

Checking Encryption Model

To determine whether a storage account is using Microsoft-managed keys or customer-managed keys for encryption, you can use the Azure portal, PowerShell, or Azure CLI:

• Azure Portal:
  • Navigate to your storage account.
  • Select the Encryption setting and note the setting.
• PowerShell:

  • Call the Get-AzStorageAccount command and check the KeySource property.

  • Example:

    $account = Get-AzStorageAccount -ResourceGroupName <resource-group> -Name <storage-account>
    $account.Encryption.KeySource

• Azure CLI:

  • Call the az storage account show command and check the keySource property.

  • Example:

    key_source=$(az storage account show --name <storage-account> --resource-group <resource-group> --query encryption.keySource --output tsv)

If the value of the KeySource property is Microsoft.Storage, then the account is encrypted with Microsoft-managed keys. If the value is Microsoft.Keyvault, then the account is encrypted with customer-managed keys .

By following these steps, you can configure and manage encryption for your Azure Storage accounts effectively.

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/customer-managed-keys-configure-key-vault-hsm

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/customer-managed-keys-configure-existing-account

Refrence: https://learn.microsoft.com/en-us/azure/storage/queues/../common/customer-managed-keys-configure-existing-account

Refrence: https://learn.microsoft.com/en-us/azure/storage/files/../common/storage-encryption-key-model-get

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/storage-encryption-key-model-get

Manage data by using Azure Storage Explorer and AzCopy

Manage Data by Using Azure Storage Explorer and AzCopy

Azure Storage Explorer

Azure Storage Explorer is a free, graphical user interface (GUI) tool that allows you to manage your Azure storage resources and data. It is available for Windows, macOS, and Linux. Here are some key features and functionalities of Azure Storage Explorer:

1. Manage Storage Resources: You can manage blobs, files, queues, tables, and CosmosDB data. This includes creating, reading, updating, and deleting these resources.
2. Data Transfer: Azure Storage Explorer uses AzCopy for data transfer operations, which provides performance advantages. This means you can upload, download, and manage your data efficiently.
3. User-Friendly Interface: For those who prefer a GUI over command-line tools, Azure Storage Explorer offers an intuitive interface to interact with your files and storage resources.
4. Authentication: After signing into Azure Storage Explorer, it uses your account key to perform operations, eliminating the need for additional authorization credentials .

Example Use Case: - Uploading a Blob: You can easily upload a blob to your Azure Storage account by dragging and dropping the file into the desired container within Azure Storage Explorer.

AzCopy

AzCopy is a command-line utility designed for high-performance data transfer to and from Azure Storage. It supports various operations and is particularly useful for large-scale data movement. Here are some key features and functionalities of AzCopy:

1. High-Performance Data Transfer: AzCopy is optimized for speed and can handle large data transfers efficiently.
2. Versatile Operations: You can use AzCopy to copy blobs, files, and tables. It supports operations like uploading, downloading, and copying data between storage accounts.
3. Authentication: AzCopy supports OAuth authentication, allowing you to use user or application identities from Microsoft Entra ID. This eliminates the need to manage or distribute storage access keys .
4. Job Management: You can list and manage AzCopy jobs using commands like azcopy jobs list .

Example Use Case: - Copying Data: To copy a file from your local machine to an Azure Blob Storage container, you can use the following command: sh azcopy copy 'C:\local\path\to\file.txt' 'https://<storage-account-name>.blob.core.windows.net/<container-name>/file.txt'

Integration of Azure Storage Explorer and AzCopy

Azure Storage Explorer leverages AzCopy for its data transfer operations, combining the ease of a graphical interface with the performance benefits of AzCopy. This integration allows users to perform complex data management tasks without needing to use the command line directly.

Example Use Case: - Using Azure Storage Explorer for Data Transfer: When you upload or download files using Azure Storage Explorer, it internally uses AzCopy to perform these operations, ensuring efficient data transfer.

By understanding and utilizing both Azure Storage Explorer and AzCopy, you can effectively manage your Azure storage accounts, ensuring efficient and secure data operations.

Refrence: https://learn.microsoft.com/en-us/azure/storage/files/../common/storage-use-azcopy-v10

Refrence: https://learn.microsoft.com/en-us/dotnet/azure/azure-tools

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/storage-ref-azcopy-jobs-list

Refrence: https://learn.microsoft.com/en-us/azure/storage/files/authorize-oauth-rest

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/storage-use-data-movement-library

Configure Azure Files and Azure Blob Storage

Create and configure a file share in Azure Storage

To create and configure a file share in Azure Storage, follow these detailed steps:

Step 1: Create a Storage Account

2. Create a New Storage Account:
   • In the Azure portal, select Create a resource > Storage > Storage account.
   • Fill in the required fields:
     • Subscription: Select your Azure subscription.
     • Resource group: Select an existing resource group or create a new one.
     • Storage account name: Provide a unique name for your storage account.
     • Region: Choose the region where you want your storage account to be located.
     • Performance: Select either Standard or Premium based on your needs.
     • Redundancy: Choose the redundancy option (e.g., LRS, GRS, ZRS, GZRS) that suits your requirements.
   • Click Review + create and then Create to create the storage account.

Step 2: Create a File Share

1. Access the Storage Account:
   • Once the storage account is created, navigate to it by selecting Resource groups > your resource group > your storage account.
2. Create a File Share:
   • Under Data Storage, select File shares.
   • Click on + File share to create a new file share.
   • Provide a name for the file share (e.g., myfileshare).
   • Set the Quota (optional): Define the maximum size of the file share in GiB.
   • Click Create to create the file share.

Step 3: Configure the File Share

1. Access the File Share:
   • After creating the file share, you can configure it by selecting it from the list of file shares in your storage account.
2. Configure Access:
   • Shared Access Signature (SAS): You can create a SAS token to provide limited access to the file share for a specific period.
   • Stored Access Policies: Define policies to manage the SAS tokens.
   • Access Keys: Use the storage account keys to access the file share.
   • Identity-based Access: Configure Microsoft Entra ID (formerly Azure AD) for identity-based access to the file share.

Step 4: Optional Configurations

1. Enable Backups:
   • On the Backup tab, you can enable backups for your file share using Azure Backup.
2. Configure Networking:
   • Set up network rules to restrict access to the file share from specific virtual networks or IP addresses.
3. Enable Soft Delete:
   • Configure soft delete to recover deleted files within a specified retention period.

Example

Here is an example of creating a file share in the Azure portal:

2. Under Data Storage, select File Shares, and then choose +File share to create a new file share.
3. On the Basics tab, provide the name of the file share, such as log-shipping. You can leave the Tier at the default of Transaction optimized.
4. (Optional) On the Backup tab, use the checkbox to enable backups of your file share to Azure Backup.
5. Select Review + create to review your file share settings, and then select Create to create your new file share .

By following these steps, you can successfully create and configure a file share in Azure Storage.

Refrence: https://learn.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/log-shipping-configure

Refrence: https://learn.microsoft.com/en-AU/azure/aks/../migrate/tutorial-app-containerization-aspnet-kubernetes

Refrence: https://learn.microsoft.com/en-AU/azure/aks/../migrate/tutorial-app-containerization-java-kubernetes

Refrence: https://learn.microsoft.com/en-us/azure/storage/queues/../common/shared-key-authorization-prevent

Create and configure a container in Blob Storage

To create and configure a container in Azure Blob Storage, follow these detailed steps:

Step 1: Create a Storage Account

Before you can create a container, you need a storage account. Here’s how to create one:

2. Create a new storage account:
   • Select Create a resource in the upper left-hand corner.
   • Choose Storage account under the Storage category.
   • Fill in the required fields such as Subscription, Resource group, Storage account name, Region, Performance, and Replication.
   • Click Review + create and then Create.

Step 2: Create a Container

Once you have a storage account, you can create a container within it:

1. Navigate to your storage account:
   • In the Azure portal, go to Storage accounts and select the storage account you created.
2. Create a container:
   • Under the Data storage section, select Containers.
   • Click on the + Container button.
   • Provide a Name for your container.
   • Set the Public access level. You can choose from:
     • Private (no anonymous access): Only the account owner can access the container.
     • Blob (anonymous read access for blobs only): Anonymous users can read the blobs within the container.
     • Container (anonymous read access for container and blobs): Anonymous users can read both the container and the blobs within it.
   • Click Create.

Step 3: Configure the Container

After creating the container, you can configure various settings:

1. Access Policies:
   • Navigate to the container and click on the More button (three dots) next to the container name.
   • Select Access policy.
   • You can add policies to control access to the container. For example, you can set a Time-based retention policy to specify how long the data should be retained.
2. Immutability Policies:
   • You can configure immutability policies to prevent data from being modified or deleted for a specified period.
   • In the Access policy dialog, under the Immutable blob storage section, choose Add policy.
   • Select Time-based retention policy and specify the retention interval.
   • Choose whether to allow protected append writes. This option enables your workloads to add new blocks of data to the end of an append blob by using the Append Block operation.

Step 4: Upload Blobs to the Container

To upload blobs to your container:

1. Navigate to the container:
   • In the Azure portal, go to the container you created.
2. Upload a blob:
   • Click the Upload button.
   • Browse your local file system to find a file to upload.
   • Optionally, expand the Advanced section to configure other settings for the upload operation.
   • Click Upload.

Example Using Azure CLI

You can also create and configure a container using Azure CLI:

1. Create a container:

   az storage container create --name <container-name> --account-name <storage-account-name>

2. Set a time-based retention policy:

   az storage container immutability-policy create --account-name <storage-account-name> --container-name <container-name> --period <retention-interval-in-days> --allow-protected-append-writes true

Example Using PowerShell

Similarly, you can use PowerShell to create and configure a container:

1. Create a container:

   New-AzStorageContainer -Name <container-name> -Context $ctx

2. Set a time-based retention policy:

   Set-AzRmStorageContainerImmutabilityPolicy -ResourceGroupName <resource-group> -StorageAccountName <storage-account> -ContainerName <container> -ImmutabilityPeriod <retention-interval-in-days> -AllowProtectedAppendWrite $true

By following these steps, you can effectively create and configure a container in Azure Blob Storage, ensuring that your data is stored securely and managed according to your requirements.

References

• : Instructions on creating and configuring a storage account and container.
• : Details on configuring version-level immutability policies.
• : Steps for configuring time-based retention policies.
• : Overview of working with data resources in Azure Blob Storage.
• : Quickstart guide for uploading block blobs.

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-version-scope

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-container-scope

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-go-get-started

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/storage-quickstart-blobs-portal

Configure storage tiers

To configure storage tiers for Azure Blob Storage, you need to understand the different access tiers available and how to manage them effectively. Azure Blob Storage offers multiple access tiers to help you optimize costs based on how frequently your data is accessed. Here is a detailed explanation of the storage tiers and how to configure them:

Azure Blob Storage Access Tiers

Azure Blob Storage provides four access tiers:

1. Hot Tier:
   • Recommendation: This tier is suitable for data that is accessed or modified frequently.
   • Best Practice: Store data in this tier if it is in regular and active use.
   • Cost: Highest storage costs but the lowest access costs.
2. Cool Tier:
   • Recommendation: This tier is ideal for data that is accessed or modified infrequently.
   • Best Practice: Data should be stored in this tier for at least 30 days.
   • Cost: Lower storage costs and higher access costs compared to the hot tier.
3. Cold Tier:
   • Recommendation: This tier is for data that is accessed or modified rarely but still requires fast retrieval.
   • Best Practice: Data should be stored in this tier for a minimum of 90 days.
   • Cost: Lower storage costs and higher access costs than the cool tier.
4. Archive Tier:
   • Recommendation: This tier is for data that is rarely accessed and has lower latency requirements.
   • Best Practice: Data should be stored in this tier for a minimum of 180 days. Data removed from the archive tier within 180 days is subject to an early deletion charge.
   • Cost: Lowest storage costs but the highest access costs.

Configuring Storage Tiers

To configure storage tiers for your Azure Blob Storage, follow these steps:

1. Create a Storage Account:
   • You need an Azure storage account to store your blobs. You can create a storage account through the Azure portal, Azure CLI, or Azure PowerShell.
2. Create a Blob Container:
   • Within your storage account, create a blob container to organize your blobs. Containers provide a way to group blobs and manage access policies.
3. Upload Blobs:
   • Upload your data to the blob container. You can use tools like Azure Storage Explorer, AzCopy, or the Azure portal to upload your blobs.
4. Set the Access Tier:
   • You can set the access tier for your blobs at the time of upload or change it later. The access tier can be set at the blob level or the storage account level.
   • To set the access tier using the Azure portal:
     1. Navigate to your storage account.
     2. Select the blob container and then the specific blob.
     3. Click on “Change tier” and select the desired access tier (Hot, Cool, Cold, or Archive).
5. Manage Lifecycle Policies:
   • You can configure lifecycle management policies to automatically move blobs between access tiers based on their age or other criteria.
   • To configure lifecycle policies:
     1. Navigate to your storage account in the Azure portal.
     2. Select “Lifecycle Management” under the “Data Management” section.
     3. Create a new rule to define the conditions for moving blobs between tiers.

Example of Setting Access Tier Using Azure CLI

Here is an example of how to set the access tier for a blob using Azure CLI:

# Set the access tier to Cool for a specific blob
az storage blob set-tier --account-name <storage_account_name> --container-name <container_name> --name <blob_name> --tier Cool

Best Practices

• Regularly Review Access Patterns: Regularly review the access patterns of your data to ensure it is stored in the most cost-effective tier.
• Use Lifecycle Management: Implement lifecycle management policies to automate the movement of data between tiers based on predefined rules.
• Monitor Costs: Use Azure Cost Management and Billing to monitor and manage your storage costs effectively.

By understanding and configuring storage tiers appropriately, you can optimize your storage costs while ensuring that your data is available when needed.

References

• : Overview of Blob Storage configuration characteristics.
• : Detailed information and recommendations about Azure Storage access tiers.

Refrence: https://learn.microsoft.com/en-us/training/modules/configure-blob-storage/2-implement

Refrence: https://learn.microsoft.com/en-us/azure/databox/data-box-deploy-copy-data-via-nfs

Refrence: https://learn.microsoft.com/en-us/azure/storage/files/../../backup/azure-file-share-backup-overview

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/storage-use-azcopy-blobs-copy

Configure snapshots and soft delete for Azure Files

Configure Snapshots and Soft Delete for Azure Files

Snapshots in Azure Files

Snapshots are read-only, point-in-time copies of your file shares. They are useful for backup and recovery purposes, allowing you to restore files to a previous state. Here’s how you can configure and manage snapshots for Azure Files:

1. Create a Snapshot:
   • Navigate to your storage account in the Azure portal.
   • Select the file share you want to create a snapshot for.
   • Click on the “Add snapshot” button.
   • Provide a name for the snapshot and click “OK”.
2. Restore from a Snapshot:
   • Navigate to the file share that contains the snapshot.
   • Select the “Snapshots” tab.
   • Choose the snapshot you want to restore from.
   • You can either restore individual files or the entire file share from the snapshot.
3. Manage Snapshots:
   • Snapshots are managed through the Azure portal, Azure CLI, or PowerShell.
   • You can list, delete, and restore snapshots as needed.

Soft Delete for Azure Files

Soft delete is a feature that protects your Azure file shares from accidental or malicious deletions. When soft delete is enabled, deleted file shares are retained in a soft-deleted state for a configurable retention period, allowing you to recover them if needed.

1. Enable Soft Delete:
   • Soft delete is enabled at the storage account level.
   • When you configure backup for any file share in a storage account, Azure Backup service enables soft delete for all file shares in that storage account .
   • You can also manually enable soft delete through the Azure portal, Azure CLI, or PowerShell.
2. Configure Retention Period:
   • The retention period for soft-deleted file shares can be configured according to your requirements.
   • For storage accounts with backed-up file shares, the minimum retention setting should be 14 days .
   • You can adjust the retention period through the Azure portal or using Azure CLI/PowerShell.
3. Restore Soft-Deleted File Shares:
   • To restore a soft-deleted file share, navigate to the storage account in the Azure portal.
   • Select the “File shares” tab and then the “Deleted shares” tab.
   • Choose the file share you want to restore and click “Undelete”.
   • The file share and all its contents, including snapshots, will be restored to the state they were in prior to deletion .
4. Cost Considerations:
   • During the soft-deleted period, you will be charged for the used capacity at the regular rate for standard file shares and at the snapshot storage rate for premium file shares .
   • Premium file shares are billed at the snapshot rate while in the soft delete state, whereas standard file shares are billed at the regular rate .
5. Permanently Delete a File Share:
   • To permanently delete a file share in a soft-deleted state before its expiry time, you must first undelete the share, disable soft delete, and then delete the share again .
   • Re-enable soft delete afterward to protect other file shares in the storage account from accidental deletion.

Example Scenario

Imagine you have a file share that contains critical business data. You enable soft delete with a retention period of 30 days. One day, a user accidentally deletes the file share. Thanks to soft delete, the file share is not permanently lost. You can navigate to the “Deleted shares” tab in the Azure portal, find the deleted file share, and restore it within the 30-day retention period. This ensures that no data is lost, and business operations can continue smoothly.

By configuring snapshots and soft delete for Azure Files, you can enhance the resilience and recoverability of your data, protecting it from accidental or malicious deletions and ensuring that you can restore data to a previous state when needed.

Refrence: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-prevent-file-share-deletion

Refrence: https://learn.microsoft.com/en-us/azure/backup/soft-delete-azure-file-share

Configure blob lifecycle management

Configure Blob Lifecycle Management

Azure Blob Storage lifecycle management allows you to automate the transition of blob data to different access tiers or to expire data at the end of its lifecycle. This helps in optimizing storage costs and managing data efficiently. Here’s a detailed explanation of how to configure blob lifecycle management:

Steps to Configure Blob Lifecycle Management

1. Navigate to Lifecycle Management in Azure Portal:
   • In the Azure portal, go to your storage account.
   • Under Data management, select Lifecycle Management to view or change lifecycle management policies .
2. Add a New Rule:
   • Select the List View tab.
   • Click on Add a rule and name your rule on the Details form. You can set the Rule scope, Blob type, and Blob subtype values .
3. Set Conditions for the Rule:
   • Select Base blobs to set the conditions for your rule. For example, you can move blobs to cool storage if they haven’t been modified for 30 days .
   • The Last accessed option is available only if you have enabled access time tracking and selected Block blobs as the blob type .
4. Add Filters (Optional):
   • If you selected Limit blobs with filters on the Details page, go to the Filter set tab to add an optional filter. For example, you can filter blobs whose name begins with log in a container called sample-container .
5. Specify Actions:
   • Define actions based on conditions such as the number of days since the blob was created, last modified, or last accessed. For example, you can move a blob from the hot tier to the cool tier if it hasn’t been modified for 30 days .
   • Note that any operation that modifies the blob, including updating its metadata or properties, changes the last-modified time of the blob .
6. Add the Policy:
   • Click Add to add the new policy. Keep in mind that a lifecycle management policy won’t delete the current version of a blob until any previous versions or snapshots associated with that blob are deleted .

Important Considerations

• Archive Tier: Before moving data to the archive tier, ensure that the data does not need to be deleted or moved to another tier for at least 180 days to avoid early deletion fees. Data in the archive tier must be rehydrated before it can be read or modified, which can take several hours and incur costs .
• Supported Blob Types: Lifecycle management policies are supported for block blobs and append blobs in general-purpose v2, premium block blob, and Blob Storage accounts .
• Limitations:
  • Tiering is not supported in premium block blob storage accounts.
  • Lifecycle management policies must be read or written in full; partial updates are not supported.
  • Each rule can have up to 10 case-sensitive prefixes and up to 10 blob index tag conditions.
  • If firewall rules are enabled for your storage account, lifecycle management requests may be blocked unless exceptions for trusted Microsoft services are provided .
  • The delete action of a lifecycle management policy won’t work with any blob in an immutable container .

Example Scenario

Imagine you have a storage account with logs that are frequently accessed for the first 30 days and rarely accessed afterward. You can create a lifecycle management policy to move these logs to the cool tier after 30 days and to the archive tier after 180 days. This helps in reducing storage costs while ensuring that the data is still available when needed.

By following these steps and considerations, you can effectively configure blob lifecycle management in Azure to optimize your storage costs and manage your data lifecycle efficiently.

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-policy-configure

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/archive-blob

Refrence: https://learn.microsoft.com/en-us/training/modules/configure-blob-storage/5-add-blob-lifecycle-management-rules

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-overview

Configure blob versioning

To configure blob versioning in Azure Blob Storage, follow these steps:

What is Blob Versioning?

Blob versioning in Azure Blob Storage automatically maintains previous versions of a blob when it is modified or deleted. This feature allows you to restore an earlier version of a blob to recover your data if it is erroneously modified or deleted .

Enabling Blob Versioning

Using the Azure Portal

1. Navigate to your storage account:
   • Go to the Azure portal.
   • Navigate to your storage account.
2. Access Blob Service:
   • In the storage account menu, select Data protection under the Blob service section.
3. Enable Versioning:
   • In the Data protection pane, find the Blob versioning section.
   • Toggle the Enable versioning switch to On.
   • Click Save to apply the changes.

Using Azure Resource Manager Template

You can also enable blob versioning using an Azure Resource Manager (ARM) template. Here is an example of how to do this:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2019-06-01",
      "name": "<storage-account-name>",
      "location": "<location>",
      "kind": "StorageV2",
      "sku": {
        "name": "Standard_LRS"
      },
      "properties": {
        "supportsHttpsTrafficOnly": true,
        "isVersioningEnabled": true
      }
    }
  ]
}

Replace <storage-account-name> and <location> with your storage account name and location, respectively.

Managing Blob Versions

• Reading Versions: You can read a specific version of a blob by using the version ID.
• Deleting Versions: You can delete specific versions of a blob by using the version ID.
• Listing Versions: You can list all versions of a blob to see the history of changes.

Disabling Blob Versioning

Disabling blob versioning does not delete existing blobs, versions, or snapshots. When you turn off blob versioning, any existing versions remain accessible in your storage account. No new versions are subsequently created .

1. Navigate to your storage account:
   • Go to the Azure portal.
   • Navigate to your storage account.
2. Access Blob Service:
   • In the storage account menu, select Data protection under the Blob service section.
3. Disable Versioning:
   • In the Data protection pane, find the Blob versioning section.
   • Toggle the Enable versioning switch to Off.
   • Click Save to apply the changes.

Considerations

• Billing Impact: Enabling blob versioning may have a billing impact as each version of a blob is stored and billed separately .
• Object Replication: Object replication relies on blob versioning. Before you can disable blob versioning, you must delete any object replication policies on the account .

Additional Resources

• Enable and manage blob versioning
• Blob versioning overview

By following these steps, you can effectively configure and manage blob versioning in Azure Blob Storage, ensuring that you can recover data in case of accidental modifications or deletions.

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-delete

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-delete-java

Deploy and manage Azure compute resources (20–25%)

Automate deployment of resources by using Azure Resource Manager (ARM) templates or Bicep files

Interpret an Azure Resource Manager template or a Bicep file

Interpreting an Azure Resource Manager (ARM) Template or a Bicep File

Interpreting an ARM template or a Bicep file involves understanding the structure, syntax, and elements that define the resources to be deployed in Azure. Both ARM templates and Bicep files serve the same purpose but differ in syntax and ease of use.

ARM Template Structure

An ARM template is a JSON file that defines the infrastructure and configuration for your Azure solution. The template consists of several sections:

1. Schema: Specifies the version of the template language.

   {
     "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
     "contentVersion": "1.0.0.0",
   }

2. Content Version: Indicates the version of the template.

   "contentVersion": "1.0.0.0",

3. Parameters: Defines the values that can be provided during deployment to customize resource properties.

   "parameters": {
     "storageAccountType": {
       "type": "string",
       "defaultValue": "Standard_LRS",
       "allowedValues": [
         "Standard_LRS",
         "Standard_GRS",
         "Standard_ZRS",
         "Premium_LRS"
       ],
       "metadata": {
         "description": "Storage Account type"
       }
     }
   },

4. Variables: Defines values that are used to simplify template language expressions.

   "variables": {
     "storageAccountName": "[concat('storage', uniqueString(resourceGroup().id))]"
   },

5. Resources: Specifies the resources to be deployed or updated.

   "resources": [
     {
       "type": "Microsoft.Storage/storageAccounts",
       "apiVersion": "2019-06-01",
       "name": "[variables('storageAccountName')]",
       "location": "[resourceGroup().location]",
       "sku": {
         "name": "[parameters('storageAccountType')]"
       },
       "kind": "StorageV2",
       "properties": {}
     }
   ],

6. Outputs: Returns values from the deployed resources.

   "outputs": {
     "storageAccountName": {
       "type": "string",
       "value": "[variables('storageAccountName')]"
     }
   }

Bicep File Structure

Bicep is a domain-specific language (DSL) for deploying Azure resources declaratively. It simplifies the syntax of ARM templates while providing the same capabilities.

1. Parameters: Define input values for the deployment.

   param storageAccountType string = 'Standard_LRS'

2. Variables: Define reusable values.

   var storageAccountName = 'storage${uniqueString(resourceGroup().id)}'

3. Resources: Define the Azure resources to be deployed.

   resource storageAccount 'Microsoft.Storage/storageAccounts@2019-06-01' = {
     name: storageAccountName
     location: resourceGroup().location
     sku: {
       name: storageAccountType
     }
     kind: 'StorageV2'
     properties: {}
   }

4. Outputs: Return values from the deployment.

   output storageAccountName string = storageAccount.name

Key Differences

• Syntax: Bicep uses a more concise and readable syntax compared to JSON.
• Comments: Bicep supports // style comments, making it easier to document the code.
• Modularity: Bicep allows for better modularity and reuse of code.

Example

Here is an example of an ARM template and its equivalent Bicep file for creating a storage account:

ARM Template (JSON)

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageAccountType": {
      "type": "string",
      "defaultValue": "Standard_LRS",
      "allowedValues": [
        "Standard_LRS",
        "Standard_GRS",
        "Standard_ZRS",
        "Premium_LRS"
      ],
      "metadata": {
        "description": "Storage Account type"
      }
    }
  },
  "variables": {
    "storageAccountName": "[concat('storage', uniqueString(resourceGroup().id))]"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2019-06-01",
      "name": "[variables('storageAccountName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "[parameters('storageAccountType')]"
      },
      "kind": "StorageV2",
      "properties": {}
    }
  ],
  "outputs": {
    "storageAccountName": {
      "type": "string",
      "value": "[variables('storageAccountName')]"
    }
  }
}

Bicep File

param storageAccountType string = 'Standard_LRS'

var storageAccountName = 'storage${uniqueString(resourceGroup().id)}'

resource storageAccount 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: storageAccountName
  location: resourceGroup().location
  sku: {
    name: storageAccountType
  }
  kind: 'StorageV2'
  properties: {}
}

output storageAccountName string = storageAccount.name

By understanding the structure and syntax of ARM templates and Bicep files, you can effectively interpret and modify these files to automate the deployment of Azure resources. For more detailed information, you can refer to the official documentation on ARM templates and Bicep files .

Refrence: https://learn.microsoft.com/en-AU/azure/azure-monitor/app/availability-overview

Refrence: https://learn.microsoft.com/en-us/azure/application-gateway/../azure-resource-manager/templates/syntax

Refrence: https://learn.microsoft.com/en-us/azure/azure-functions/legacy-proxies

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/templates/deploy-cli

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machines/extensions/export-templates

Modify an existing Azure Resource Manager template

To modify an existing Azure Resource Manager (ARM) template, follow these steps:

1. Export the Existing Template

First, you need to export the existing ARM template. This can be done in several ways:

• From the Azure Portal: Navigate to the resource group containing the resources you want to export. Select the resource group, and then click on “Export template” from the settings menu. This will generate a JSON file representing the current state of the resources in the resource group .

• From the Original Deployment: If you have the original deployment template, you can use that as a starting point .

• Using Azure CLI or PowerShell: You can also use Azure CLI or PowerShell commands to export the template. For example, using Azure CLI:

  az group export --name <ResourceGroupName> --output json > template.json

2. Open the Template in a JSON Editor

Once you have the template, open it in a JSON editor. Visual Studio Code is a popular choice for editing ARM templates due to its JSON editing features and extensions for Azure Resource Manager .

3. Modify the Template

Make the necessary modifications to the template. Here are some common modifications you might need to make:

• Add or Remove Resources: You can add new resources or remove existing ones by modifying the resources array in the template.
• Change Resource Properties: Update the properties of existing resources. For example, you might want to change the size of a virtual machine or update the configuration of a storage account.
• Update Parameters and Variables: Modify the parameters and variables sections to add new parameters or update existing ones. This allows you to make the template more flexible and reusable.

4. Validate the Template

Before deploying the modified template, it’s important to validate it to ensure there are no syntax errors or issues with the configuration. You can use the Azure CLI or PowerShell to validate the template:

az deployment group validate --resource-group <ResourceGroupName> --template-file template.json

5. Deploy the Modified Template

After validating the template, you can deploy it using the Azure CLI, PowerShell, or the Azure Portal. Here is an example using Azure CLI:

az deployment group create --resource-group <ResourceGroupName> --template-file template.json

Example: Modifying a Virtual Machine Configuration

Suppose you have an existing ARM template for a virtual machine, and you want to change the VM size. Here is a snippet of the original template:

{
  "resources": [
    {
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2021-03-01",
      "name": "myVM",
      "location": "[resourceGroup().location]",
      "properties": {
        "hardwareProfile": {
          "vmSize": "Standard_DS1_v2"
        },
        ...
      }
    }
  ]
}

To change the VM size to Standard_DS2_v2, modify the vmSize property:

{
  "resources": [
    {
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2021-03-01",
      "name": "myVM",
      "location": "[resourceGroup().location]",
      "properties": {
        "hardwareProfile": {
          "vmSize": "Standard_DS2_v2"
        },
        ...
      }
    }
  ]
}

Additional Considerations

• Incremental vs. Complete Deployment: By default, Azure Resource Manager performs an incremental update, which means it only updates the resources specified in the template and leaves other resources unchanged. If you need to replace the entire resource group, you can use a complete deployment mode .
• Handling Null Values: Be cautious with null values in the template. For example, setting availabilityZones to null will be treated as if the property doesn’t exist, which can affect the deployment of resources like AKS clusters .

By following these steps, you can effectively modify an existing ARM template to meet your deployment needs.

Refrence: https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/qs-configure-template-windows-vm

Refrence: https://learn.microsoft.com/en-AU/azure/batch/account-move

Refrence: https://learn.microsoft.com/en-AU/azure/aks/availability-zones

Refrence: https://learn.microsoft.com/en-us/azure/data-share/move-to-new-region

Refrence: https://learn.microsoft.com/en-AU/azure/devtest-labs/use-paas-services

Modify an existing Bicep file

To modify an existing Bicep file, you need to understand the structure and syntax of Bicep, which is a domain-specific language (DSL) for deploying Azure resources declaratively. Here’s a step-by-step guide to help you modify an existing Bicep file:

Step-by-Step Guide to Modify an Existing Bicep File

1. Open the Bicep File:
   • Use an editor like Visual Studio Code (VS Code) which has extensions for Bicep to provide syntax highlighting, IntelliSense, and other helpful features.
2. Understand the Structure:

   • A Bicep file typically contains parameters, variables, resources, and outputs. Here’s a basic structure:

     param location string = 'East US'
     param storageAccountName string
     
     resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = {
       name: storageAccountName
       location: location
       sku: {
         name: 'Standard_LRS'
       }
       kind: 'StorageV2'
       properties: {
         accessTier: 'Hot'
       }
     }
     
     output storageAccountId string = storageAccount.id

3. Modify Parameters:

   • Parameters are used to pass values into the Bicep file. You can add, remove, or change parameters as needed.

     param newParameter string = 'defaultValue'

4. Modify Variables:

   • Variables store values that can be reused in the Bicep file. You can add, remove, or change variables.

     var newVariable = 'someValue'

5. Modify Resources:

   • Resources define the Azure resources to be deployed. You can add new resources, remove existing ones, or modify their properties.

     resource newResource 'Microsoft.Example/resourceType@2021-01-01' = {
       name: 'exampleResource'
       location: location
       properties: {
         exampleProperty: 'exampleValue'
       }
     }

6. Modify Outputs:

   • Outputs are used to return values from the Bicep file. You can add, remove, or change outputs.

     output newOutput string = newResource.id

Example Modification

Let’s say you have an existing Bicep file that deploys a storage account, and you want to add a new parameter for the access tier and modify the storage account resource to use this new parameter.

Original Bicep File:

param location string = 'East US'
param storageAccountName string

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

output storageAccountId string = storageAccount.id

Modified Bicep File:

param location string = 'East US'
param storageAccountName string
param accessTier string = 'Hot'  // New parameter added

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: accessTier  // Modified to use the new parameter
  }
}

output storageAccountId string = storageAccount.id

Additional Tips

• Use Modules: If your Bicep file is getting large, consider breaking it into smaller modules. This makes it easier to manage and modify.
• Linting and Validation: Use the Bicep linter to check for syntax errors and best practice violations. You can configure the linter settings in bicepconfig.json .
• Decompilation: If you have an ARM template in JSON format, you can decompile it to Bicep using the Azure CLI command az bicep decompile --file main.json .

By following these steps, you can effectively modify an existing Bicep file to meet your deployment needs.

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/bicep/operators-access

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/bicep/bicep-functions-resource

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/bicep/decompile

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/bicep/bicep-cli

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/bicep/bicep-config

Deploy resources by using an Azure Resource Manager template or a Bicep file

To deploy resources using an Azure Resource Manager (ARM) template or a Bicep file, follow these detailed steps:

Deploying Resources Using an ARM Template

1. Understand the Structure of ARM Templates:
   • ARM templates are JSON files that define the infrastructure and configuration for your Azure solution. They consist of several sections, including parameters, variables, resources, and outputs. For a detailed description of these sections, refer to the ARM template structure and syntax documentation .
2. Create or Obtain an ARM Template:
   • You can create an ARM template from scratch, use a custom template from the Azure Marketplace, or derive it from an existing resource group by exporting the template from the original deployment or the current state of the deployment .
3. Edit the ARM Template:
   • Use a JSON editor like Visual Studio Code to edit the template. You can also use the Visual Studio Azure Resource Group project to create and deploy the template .
4. Deploy the ARM Template:
   • You can deploy the ARM template using various methods, including the Azure portal, Azure PowerShell, Azure CLI, or GitHub Actions. For example, to deploy using Azure PowerShell, use the New-AzResourceGroupDeployment command .

   New-AzResourceGroupDeployment -ResourceGroupName <ResourceGroupName> -TemplateFile <PathToTemplateFile>

5. Incremental and Complete Deployments:
   • By default, Azure Resource Manager performs an incremental update to deployments, which means it only adds or modifies resources defined in the template. You can also perform a complete deployment, which deletes resources not defined in the template .

Deploying Resources Using a Bicep File

1. Understand Bicep Files:
   • Bicep is a domain-specific language (DSL) for deploying Azure resources. It offers a more concise syntax compared to JSON ARM templates. Bicep files are transpiled into JSON before deployment .
2. Create or Obtain a Bicep File:
   • You can create a Bicep file from scratch or use existing samples. Bicep files define the same infrastructure and configuration as ARM templates but with a simpler syntax.
3. Edit the Bicep File:
   • Use a code editor like Visual Studio Code with the Bicep extension to edit the Bicep file. This extension provides syntax highlighting, IntelliSense, and other features to help you write Bicep code.
4. Deploy the Bicep File:
   • Similar to ARM templates, you can deploy Bicep files using the Azure portal, Azure PowerShell, Azure CLI, or GitHub Actions. For example, to deploy using Azure CLI, use the following command:

   az deployment group create --resource-group <ResourceGroupName> --template-file <PathToBicepFile>

5. Using GitHub Actions for Deployment:
   • You can automate the deployment of Bicep files using GitHub Actions. This involves setting up a GitHub Actions workflow that uses the azure/arm-deploy action to deploy the Bicep file to Azure. For detailed steps on setting up GitHub Actions, refer to the Deploy Azure resources by using Bicep and GitHub Actions documentation .

By following these steps, you can effectively deploy resources using either ARM templates or Bicep files, leveraging the tools and methods that best fit your workflow and preferences.

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/templates/template-functions-scope

Refrence: https://learn.microsoft.com/en-AU/azure/service-fabric/service-fabric-diagnostics-event-aggregation-wad

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/bicep/quickstart-create-template-specs

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/bicep/deploy-github-actions

Export a deployment as an Azure Resource Manager template or convert an Azure Resource Manager template to a Bicep file

Export a Deployment as an Azure Resource Manager Template or Convert an Azure Resource Manager Template to a Bicep File

Exporting a Deployment as an Azure Resource Manager Template

Exporting a deployment as an Azure Resource Manager (ARM) template allows you to capture the current state of your Azure resources and redeploy them as needed. Here are the steps to export a deployment:

1. Select the Resource Group:
   • Navigate to the Azure portal.
   • Select the resource group that contains the resources you want to export.
2. Access Deployment History:
   • Under the resource group, click on the Deployments link.
   • This will show you the history of deployments for that resource group.

   

3. Select a Deployment:
   • From the deployment history, select the specific deployment you want to export.

   

4. Export the Template:
   • Click on the Template tab.
   • The template used for this deployment will be displayed.
   • You can download this template for future use.

   

This exported template can be used to redeploy the resources in the same or different resource group, subscription, or even another Azure environment.

Converting an Azure Resource Manager Template to a Bicep File

Bicep is a domain-specific language (DSL) for deploying Azure resources declaratively. It simplifies the syntax and improves the development experience compared to JSON ARM templates. Here’s how you can convert an ARM template to a Bicep file:

1. Install Bicep CLI:

   • Ensure you have the Bicep CLI installed on your local machine. You can install it using the following command:

     az bicep install

2. Convert JSON to Bicep:

   • Use the Bicep CLI to decompile the ARM template JSON to a Bicep file. Run the following command:

     bicep decompile <path-to-arm-template.json>

   • This command will generate a .bicep file from the provided ARM template JSON.

3. Review and Refactor:
   • Open the generated Bicep file in your preferred code editor.
   • Review the file and refactor if necessary to take advantage of Bicep’s concise syntax and features.

Benefits of Using Bicep

• Simplified Syntax: Bicep offers a more concise and readable syntax compared to JSON. For example, you don’t need to use bracketed expressions [...] and can directly call functions and reference parameters and variables .
• Automatic Dependency Management: Bicep automatically manages dependencies between resources, reducing the need to explicitly set dependsOn .
• Flexibility: You can declare parameters, variables, and outputs anywhere in the Bicep file, unlike JSON where they must be within specific sections .

By exporting ARM templates and converting them to Bicep files, you can streamline your Azure resource management and take advantage of the improved development experience offered by Bicep.

For more detailed steps and examples, you can refer to the official documentation on Comparing JSON and Bicep for templates .

Refrence: https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/qs-configure-portal-windows-vm

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/bicep/overview

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/templates/export-template-portal

Refrence: https://learn.microsoft.com/azure/azure-resource-manager/managed-applications/cli-samples

Create and configure virtual machines

Create a virtual machine

Creating a virtual machine (VM) in Azure involves several steps. Below is a detailed explanation of how to create a virtual machine using the Azure portal:

Steps to Create a Virtual Machine in Azure

1. Sign in to the Azure Portal:

2. Navigate to the Virtual Machines Service:

   • In the Azure portal, click on the “Create a resource” button in the upper left corner.
   • In the search box, type “Virtual Machine” and select “Virtual Machine” from the dropdown list.

3. Create a Virtual Machine:

   • Click on the “Create” button to start the VM creation process.

4. Basics Tab:

   • Subscription: Select the Azure subscription you want to use.
   • Resource Group: Choose an existing resource group or create a new one.
   • Virtual Machine Name: Enter a name for your VM.
   • Region: Select the region where you want to deploy the VM.
   • Availability Options: Choose the availability options (e.g., Availability Zone, Availability Set) if needed.
   • Image: Select the operating system image for the VM (e.g., Windows Server, Ubuntu).
   • Size: Choose the VM size based on your requirements.
   • Administrator Account: Provide the username and password for the VM’s administrator account.

5. Disks Tab:

   • OS Disk Type: Select the type of disk for the operating system (e.g., Standard SSD, Premium SSD).
   • Data Disks: Add any additional data disks if required.

6. Networking Tab:

   • Virtual Network: Select an existing virtual network or create a new one.
   • Subnet: Choose a subnet within the virtual network.
   • Public IP: Decide if you want to assign a public IP address to the VM.
   • NIC Network Security Group: Configure the network security group (NSG) to control inbound and outbound traffic.

7. Management Tab:

   • Monitoring: Enable or disable monitoring options such as Boot diagnostics, OS guest diagnostics, and Auto-shutdown.
   • Identity: Enable system-assigned managed identity if needed.

8. Advanced Tab:

   • Extensions: Add any VM extensions if required (e.g., Custom Script Extension, Desired State Configuration).
   • Custom Data and Cloud Init: Provide any custom data or cloud-init configuration.

9. Tags Tab:

   • Tags: Add any tags to organize your resources (e.g., Environment: Production, Department: IT).

10. Review + Create Tab:

    • Review all the configurations and settings.
    • Click on the “Create” button to deploy the VM.

Example: Creating a Windows Virtual Machine

1. Sign in to the Azure Portal:

2. Navigate to Virtual Machines:

   • Click on “Create a resource” and select “Virtual Machine”.

3. Basics Tab:

   • Subscription: Select your subscription.
   • Resource Group: Create a new resource group named MyResourceGroup.
   • Virtual Machine Name: Enter MyWindowsVM.
   • Region: Select East US.
   • Image: Choose Windows Server 2019 Datacenter.
   • Size: Select Standard D2s v3.
   • Administrator Account: Enter azureuser as the username and a strong password.

4. Disks Tab:

   • OS Disk Type: Select Premium SSD.

5. Networking Tab:

   • Virtual Network: Create a new virtual network named MyVNet.
   • Subnet: Use the default subnet.
   • Public IP: Enable public IP.

6. Management Tab:

   • Monitoring: Enable Boot diagnostics.
   • Identity: Enable system-assigned managed identity.

7. Advanced Tab:

   • Extensions: Add the Custom Script Extension if needed.

8. Tags Tab:

   • Tags: Add tags such as Environment: Test.

9. Review + Create Tab:

   • Review the settings and click “Create”.

By following these steps, you can successfully create a virtual machine in Azure. For more detailed instructions, you can refer to the Quickstart guide for creating a Windows virtual machine .

Refrence: https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/qs-configure-cli-windows-vm

Refrence: https://learn.microsoft.com/en-AU/azure/azure-resource-manager/bicep/../../virtual-machine-scale-sets/quick-create-bicep-windows

Refrence: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/standby-pools-overview

Refrence: https://learn.microsoft.com/en-us/training/modules/configure-virtual-machine-availability/11-simulation-machine-scale

Configure Azure Disk Encryption

To configure Azure Disk Encryption for virtual machines, follow these detailed steps:

Prerequisites

1. Azure Subscription: Ensure you have an active Azure subscription.
2. Azure Key Vault: Create and configure an Azure Key Vault to store the encryption keys. Refer to the Creating and configuring a key vault for Azure Disk Encryption article for detailed instructions .

Steps to Configure Azure Disk Encryption

1. Create a Key Vault and Key:
   • Navigate to the Azure portal.
   • Create a new Key Vault or use an existing one.
   • In the Key Vault, create a new key or import an existing key.
2. Grant Permissions to the Key Vault:
   • Go to the Key Vault’s Access policies.
   • Add an access policy for the Azure Disk Encryption service principal.
   • Grant the necessary permissions (Get, Wrap Key, Unwrap Key).
3. Enable Azure Disk Encryption on a Virtual Machine:
   • Navigate to the virtual machine you want to encrypt.
   • Select “Disks” from the VM settings.
   • Click on “Encryption” and then “Select a key vault and key”.
   • Choose the Key Vault and the key you created earlier.
   • Click “Save” to apply the encryption settings.
4. Monitor the Encryption Process:
   • The encryption process will start and may take some time depending on the size of the disks.
   • You can monitor the progress in the Azure portal under the “Disks” section of the VM.

Important Considerations

• Key Auto-Rotation: Azure Key Vault supports key auto-rotation, but it is not compatible with Azure Disk Encryption. Azure Disk Encryption will continue to use the original encryption key even after it has been auto-rotated .
• Disabling Old Keys: Rotating an encryption key won’t break Azure Disk Encryption, but disabling the old encryption key (the key Azure Disk Encryption is still using) will .
• Encryption Compatibility: Azure Disk Encryption does not work for custom Linux images .

Comparison with Other Encryption Methods

Next Steps

• Ensure that you have configured the Key Vault correctly and granted the necessary permissions.
• Regularly monitor the encryption status and ensure that the keys are managed securely.
• Be aware of the limitations and compatibility issues with custom images and key auto-rotation.

By following these steps and considerations, you can effectively configure Azure Disk Encryption for your virtual machines, ensuring that your data is protected at rest.

Refrence: https://learn.microsoft.com/en-us/azure/virtual-machines/disk-encryption-overview

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machine-scale-sets/disk-encryption-key-vault

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machines/linux/disk-encryption-faq

Refrence: https://learn.microsoft.com/en-us/azure/virtual-machines/linux/disk-encryption-faq

Move a virtual machine to another resource group, subscription, or region

Moving a Virtual Machine to Another Resource Group, Subscription, or Region

When managing Azure virtual machines (VMs), you might need to move them to a different resource group, subscription, or region. This process involves several steps and considerations to ensure a smooth transition without disrupting your services. Below is a detailed explanation of how to perform these tasks.

Moving a VM to Another Resource Group or Subscription

1. Prerequisites:
   • Ensure that the destination resource group or subscription exists.
   • Verify that all dependent resources are included in the move request or already exist in the destination.
2. Using Azure CLI:

   • Install and configure the Azure CLI.

   • Use the following command to move the VM:

     az resource move --destination-group <destinationResourceGroup> --ids <resourceId1> <resourceId2> ...

   • Example:

     az resource move --destination-group newResourceGroup --ids /subscriptions/{subscription-id}/resourceGroups/oldResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM

3. Using Azure PowerShell:

   • Install and configure Azure PowerShell.

   • Use the following command to move the VM:

     Move-AzResource -DestinationResourceGroupName <destinationResourceGroup> -ResourceId <resourceId1>,<resourceId2>,...

   • Example:

     Move-AzResource -DestinationResourceGroupName newResourceGroup -ResourceId /subscriptions/{subscription-id}/resourceGroups/oldResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM

4. Considerations:
   • Ensure that all dependent resources (e.g., network interfaces, public IP addresses, disks) are included in the move request.
   • If a dependent resource is missing, you will receive a MissingMoveDependentResources error .

Moving a VM to Another Region

1. Prerequisites:
   • Ensure that the destination region supports the VM size and resources you are using.
   • Prepare a new resource group in the destination region.
2. Using Azure Resource Mover:
   • Azure Resource Mover is a tool designed to simplify the process of moving resources between regions.
   • Follow the steps in the Azure Resource Mover tutorial to move your VM.
3. Steps:
   • Prepare the resources: Identify the resources to move and prepare them for the move.
   • Initiate the move: Use Azure Resource Mover to initiate the move.
   • Validate the move: Ensure that all resources are correctly configured in the destination region.
   • Commit the move: Finalize the move to the new region.
4. Considerations:
   • Moving a VM to another region involves creating a copy of the VM in the destination region and then deleting the original VM.
   • Ensure that all data is backed up before initiating the move.
   • Validate the configuration and dependencies in the new region to avoid any service disruptions.

Additional Resources

• Move resources to a new resource group or subscription .
• Migrate Virtual Machines and Virtual Machine Scale Sets to availability zone support .

By following these steps and considerations, you can successfully move your Azure virtual machines to different resource groups, subscriptions, or regions, ensuring minimal disruption to your services.

Refrence: https://learn.microsoft.com/en-us/azure/app-service/../azure-resource-manager/management/move-resource-group-and-subscription

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machine-scale-sets/../reliability/reliability-virtual-machines

Refrence: https://learn.microsoft.com/azure/reliability/reliability-virtual-machines

Refrence: https://learn.microsoft.com/en-us/azure/storage/blobs/../common/storage-account-overview

Refrence: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/../reliability/reliability-virtual-machines

Manage virtual machine sizes

Manage Virtual Machine Sizes

Managing virtual machine (VM) sizes in Azure is a crucial task for optimizing performance and cost. Azure offers a variety of VM sizes tailored to different workloads, and understanding how to manage these sizes is essential for an Azure Administrator. Here’s a detailed explanation of how to manage VM sizes:

1. Understanding VM Sizes

Azure VMs come in various sizes, each offering different combinations of CPU, memory, and storage. The sizes are grouped into series, such as:

• General Purpose: Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers.
• Compute Optimized: High CPU-to-memory ratio. Suitable for medium traffic web servers, network appliances, batch processes, and application servers.
• Memory Optimized: High memory-to-CPU ratio. Best for relational database servers, medium to large caches, and in-memory analytics.
• Storage Optimized: High disk throughput and IO. Ideal for big data, SQL, and NoSQL databases.
• GPU: Specialized VMs for heavy graphics rendering and video editing.
• High Performance Compute: For high-performance computing workloads.

For detailed information on VM sizes, refer to the Sizes for Virtual Machines documentation.

2. Changing the Size of a Virtual Machine

To change the size of an existing VM, follow these steps:

1. Stop the VM: Before resizing, the VM must be in a stopped (deallocated) state.
   • Go to the Azure portal and navigate to your VM.
   • Select Stop and confirm the action.
   • Wait until the status changes to Stopped (deallocated).
2. Resize the VM:
   • In the Azure portal, go to the Settings section of your VM.
   • Select Size.
   • Choose the new size from the list of available sizes. The list will show only the sizes that are available in the current region and compatible with the VM’s configuration.
   • Click Resize to apply the changes.
3. Start the VM: Once the resize operation is complete, start the VM.
   • Go to the Overview section of your VM.
   • Select Start.

For more detailed steps, refer to the Change the size of a virtual machine documentation.

3. Considerations When Resizing VMs

• Downtime: Resizing a VM requires it to be stopped and deallocated, which means there will be downtime.
• Disk and Data: Ensure that the new VM size supports the number of data disks and the type of storage you are using.
• Network Interfaces: Verify that the new size supports the number of network interfaces attached to the VM.
• Availability: Not all VM sizes are available in all regions. Check the availability of the desired size in your region.

4. Using Azure CLI and PowerShell

You can also resize VMs using Azure CLI or PowerShell:

• Azure CLI:

  az vm resize --resource-group <ResourceGroupName> --name <VMName> --size <NewVMSize>

• PowerShell:

  Resize-AzVM -ResourceGroupName <ResourceGroupName> -VMName <VMName> -Size <NewVMSize>

5. Monitoring and Optimization

After resizing, monitor the VM’s performance to ensure it meets the workload requirements. Use Azure Monitor to track metrics and set up alerts for CPU, memory, and disk usage. This helps in optimizing the VM size for cost and performance.

By understanding and managing VM sizes effectively, you can ensure that your Azure resources are used efficiently, providing the best performance for your applications while controlling costs.

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machines/windows/faq

Refrence: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/faq

Refrence: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface-vm

Refrence: https://learn.microsoft.com/en-us/training/modules/configure-virtual-machine-availability/8-create-scale-sets

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machines/auto-shutdown-vm

Manage virtual machine disks

Managing virtual machine disks is a crucial aspect of administering Azure virtual machines (VMs). Here’s a detailed explanation of how to manage virtual machine disks, including the types of disks available, how to attach and detach disks, and how to manage disk performance and redundancy.

Types of Disks

1. Operating System Disks: These disks contain the operating system for the VM. They are created automatically when you create a VM.
2. Data Disks: These disks are used to store application data or other data you need to persist. You can attach multiple data disks to a VM.
3. Temporary Disks: These disks provide temporary storage for the VM. Data on these disks is not persisted and is lost when the VM is stopped or deallocated.

Azure Managed Disks

Azure Managed Disks are the recommended disk storage offerings for use with Azure VMs for persistent storage of data. Managed Disks handle the storage account creation and management in the background, ensuring scalability and performance without the need to manage storage accounts directly .

Types of Managed Disks

1. Premium Managed Disks: These disks offer high-performance, low-latency disk storage for VMs running I/O-intensive workloads.
2. Standard Managed Disks: These disks provide cost-effective storage for less critical workloads.

Creating and Attaching Data Disks

1. Create a Managed Disk:
   • You can create a managed disk using the Azure portal, Azure CLI, or Azure PowerShell.
   • Specify the disk size and performance tier (Standard or Premium).
2. Attach a Data Disk to a VM:
   • In the Azure portal, navigate to the VM to which you want to attach the disk.
   • Under the “Settings” section, select “Disks”.
   • Click on “Add data disk” and select the managed disk you created.
   • Save the changes to attach the disk to the VM.
3. Initialize and Format the Disk:
   • After attaching the disk, you need to initialize and format it within the operating system.
   • For Windows VMs, use the Disk Management tool.
   • For Linux VMs, use the fdisk and mkfs commands.

Managing Disk Performance and Redundancy

1. Disk Performance:
   • The performance of a managed disk is determined by its size and the performance tier.
   • Premium disks offer higher IOPS and throughput compared to standard disks.
2. Disk Redundancy:
   • Managed disks are automatically replicated within the same region to ensure high availability and durability.
   • When VMs with managed disks are in the same availability set, Azure distributes the storage resources to provide appropriate redundancy .

Moving Disks

1. Move a Disk to Another Resource Group or Subscription:
   • You can move a managed disk to another resource group or subscription using the Azure portal, Azure CLI, or Azure PowerShell.
   • Ensure that the VM to which the disk is attached is deallocated before moving the disk.

Converting Unmanaged Disks to Managed Disks

1. Convert Unmanaged Disks:
   • If you have VMs with unmanaged disks, you can convert them to managed disks.
   • Use the Azure portal, Azure CLI, or Azure PowerShell to perform the conversion.
   • This process involves creating a snapshot of the unmanaged disk and then creating a managed disk from the snapshot .

Best Practices

1. Use Managed Disks: Always use managed disks for better scalability, performance, and ease of management.
2. Monitor Disk Performance: Regularly monitor the performance of your disks using Azure Monitor to ensure they meet your application’s requirements.
3. Backup Disks: Implement regular backups of your disks using Azure Backup to protect against data loss.

By understanding and effectively managing virtual machine disks, you can ensure that your Azure VMs perform optimally and that your data is stored securely and reliably.

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machine-scale-sets/../virtual-machines/linux/faq

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machines/virtual-machines-disaster-recovery-guidance

Refrence: https://learn.microsoft.com/en-AU/azure/aks/concepts-identity

Refrence: https://learn.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/availability-group-manually-configure-prerequisites-tutorial-single-subnet

Refrence: https://learn.microsoft.com/en-AU/azure/service-fabric/service-fabric-managed-disk

Deploy virtual machines to availability zones and availability sets

Deploy Virtual Machines to Availability Zones and Availability Sets

When deploying virtual machines (VMs) in Azure, ensuring high availability and resilience is crucial. Azure provides two primary methods to achieve this: Availability Zones and Availability Sets. Below is a detailed explanation of each method and how to deploy VMs using them.

Availability Zones

Availability Zones are physically separate locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. By deploying VMs across multiple Availability Zones, you can protect your applications and data from datacenter failures.

Key Features: - High Availability: Guarantees VM connectivity to at least one instance at least 99.99% of the time when you have two or more instances deployed across two or more Availability Zones in the same Azure region . - Fault Isolation: Each zone is isolated from failures in other zones, ensuring that a failure in one zone does not affect the others.

Steps to Deploy VMs to Availability Zones: 1. Create a Virtual Machine: - In the Azure portal, navigate to “Create a resource” and select “Virtual Machine.” - Fill in the required details such as subscription, resource group, and VM name. 2. Select Availability Options: - Under the “Availability options” section, choose “Availability zone.” - Select the desired zone (e.g., Zone 1, Zone 2, Zone 3) for your VM. 3. Configure Other Settings: - Complete the remaining configuration settings such as size, disk, networking, and management. 4. Review and Create: - Review the configuration and click “Create” to deploy the VM.

Availability Sets

Availability Sets are a logical grouping of VMs that allow Azure to understand how your application is built to provide redundancy and availability. When you place your VMs in an Availability Set, Azure ensures that the VMs are distributed across multiple fault domains and update domains.

Key Features: - Fault Domains: Provide physical separation of VMs across different hardware to protect against hardware failures. - Update Domains: Ensure that VMs are not all updated at the same time, reducing the risk of downtime during maintenance.

Steps to Deploy VMs to Availability Sets: 1. Create an Availability Set: - In the Azure portal, navigate to “Create a resource” and select “Availability Set.” - Fill in the required details such as subscription, resource group, and name. - Specify the number of fault domains and update domains. - Click “Create” to create the Availability Set. 2. Create a Virtual Machine: - In the Azure portal, navigate to “Create a resource” and select “Virtual Machine.” - Fill in the required details such as subscription, resource group, and VM name. 3. Select Availability Options: - Under the “Availability options” section, choose “Availability set.” - Select the previously created Availability Set. 4. Configure Other Settings: - Complete the remaining configuration settings such as size, disk, networking, and management. 5. Review and Create: - Review the configuration and click “Create” to deploy the VM.

Comparison

By understanding and utilizing Availability Zones and Availability Sets, you can ensure that your applications are resilient and highly available, meeting the requirements of the AZ-104 exam objective for deploying virtual machines.

For more detailed information, you can refer to the following resources: - Availability Zones Overview - Virtual Machine Scale Sets Overview - Availability Options for Azure Virtual Machines - SLA for Azure Virtual Machines

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machines/overview

Refrence: https://learn.microsoft.com/azure/availability-zones/migrate-vm

Refrence: https://learn.microsoft.com/en-us/azure/virtual-machines/virtual-machines-disaster-recovery-guidance

Refrence: https://learn.microsoft.com/en-us/azure/virtual-machines/overview

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-scale-in-policy

Deploy and configure an Azure Virtual Machine Scale Sets

Deploy and Configure an Azure Virtual Machine Scale Sets

Azure Virtual Machine Scale Sets (VMSS) allow you to deploy and manage a set of identical, auto-scaling virtual machines (VMs). This feature is particularly useful for applications that require high availability, scalability, and redundancy. Here’s a detailed explanation of how to deploy and configure an Azure Virtual Machine Scale Set:

1. Create a Virtual Machine Scale Set

To create a VMSS, you can use the Azure portal, Azure CLI, or an Azure Resource Manager (ARM) template. Here’s how to do it using the Azure portal:

1. Navigate to the Azure Portal:

2. Create a New Scale Set:

   • In the left-hand menu, select Create a resource.
   • In the search box, type Virtual Machine Scale Set and select it from the list.
   • Click Create.

3. Configure Basic Settings:

   • Subscription: Select your Azure subscription.
   • Resource Group: Create a new resource group or select an existing one.
   • Region: Choose the region where you want to deploy the scale set.
   • Name: Provide a name for the scale set.
   • Orchestration Mode: Choose Uniform for identical VMs or Flexible for varied VMs.
   • Image: Select the OS image for the VMs (e.g., Windows Server, Ubuntu).
   • Size: Choose the VM size (e.g., Standard_DS1_v2).

4. Configure Instance Settings:

   • Instance Count: Specify the initial number of VMs.
   • Authentication Type: Choose between password or SSH public key for Linux VMs.
   • Username and Password: Provide the admin username and password.

5. Configure Networking:

   • Virtual Network: Select an existing virtual network or create a new one.
   • Subnet: Choose a subnet within the virtual network.
   • Public IP Address: Optionally, configure a public IP address for the scale set.

6. Configure Scaling and Load Balancing:

   • Scaling: Set up autoscaling rules based on metrics like CPU usage.
   • Load Balancer: Optionally, configure a load balancer to distribute traffic across the VMs.

7. Review and Create:

   • Review the configuration settings.
   • Click Create to deploy the scale set.

2. Configure Virtual Machine Extensions

VM extensions are small applications that provide post-deployment configuration and automation tasks on Azure VMs. Here’s how to configure VM extensions for a scale set:

1. Navigate to the Scale Set:
   • Go to the Virtual Machine Scale Sets section in the Azure portal.
   • Select the scale set you created.
2. Add Extensions:
   • In the scale set menu, select Extensions.
   • Click Add to add a new extension.
   • Choose the desired extension (e.g., Custom Script Extension, Azure Monitor Agent).
   • Configure the extension settings (e.g., script location, parameters).
3. Apply the Extension:
   • Click OK to apply the extension to the scale set.

3. Configure Autoscaling

Autoscaling allows the scale set to automatically adjust the number of VM instances based on demand. Here’s how to configure autoscaling:

1. Navigate to the Scale Set:
   • Go to the Virtual Machine Scale Sets section in the Azure portal.
   • Select the scale set you created.
2. Configure Autoscale Settings:
   • In the scale set menu, select Scaling.
   • Click Add a rule to create a new autoscale rule.
   • Define the rule based on metrics (e.g., CPU percentage, memory usage).
   • Set the scale-out and scale-in thresholds and the number of instances to add or remove.
3. Save the Autoscale Configuration:
   • Click Save to apply the autoscale settings.

4. Deploy Applications to the Scale Set

To deploy applications to the VMs in the scale set, you can use various methods such as custom scripts, Azure DevOps, or Azure Resource Manager templates. Here’s a basic example using a custom script:

1. Create a Custom Script:
   • Write a script that installs and configures your application.
   • Upload the script to an Azure Storage account or a public URL.
2. Add the Custom Script Extension:
   • Navigate to the scale set in the Azure portal.
   • Select Extensions and add the Custom Script Extension.
   • Provide the script location and any required parameters.
3. Apply the Extension:
   • Click OK to apply the extension and run the script on all VMs in the scale set.

5. Monitor and Maintain the Scale Set

Monitoring and maintaining the scale set is crucial for ensuring its performance and availability. Use Azure Monitor to track metrics, set up alerts, and analyze logs:

1. Configure Monitoring:
   • Navigate to the scale set in the Azure portal.
   • Select Monitoring and configure metrics, logs, and alerts.
2. Set Up Alerts:
   • Create alert rules based on specific metrics (e.g., CPU usage, disk I/O).
   • Define the actions to take when an alert is triggered (e.g., send an email, run an automation script).
3. Analyze Logs:
   • Use Azure Monitor logs to analyze the performance and health of the scale set.
   • Set up log queries to gain insights into the scale set’s operations.

Refrence: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-mvss-guest-based-autoscale-linux

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-mvss-start

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-health-extension

Refrence: https://learn.microsoft.com/en-AU/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-manage-powershell

Provision and manage containers in the Azure portal

Create and manage an Azure container registry

To create and manage an Azure Container Registry (ACR) in the Azure portal, follow these steps:

Step 1: Create an Azure Container Registry

1. Sign in to the Azure portal:

2. Create a new container registry:

   • In the Azure portal, select Create a resource.
   • In the search box, type Container Registry and select Container Registry from the results.
   • Click Create.

3. Configure the container registry:

   • Subscription: Select the Azure subscription you want to use.
   • Resource group: Select an existing resource group or create a new one.
   • Registry name: Enter a unique name for your container registry. The name must be globally unique within Azure.
   • Location: Choose the Azure region where you want to create the registry.
   • SKU: Select the SKU (Basic, Standard, or Premium) that meets your requirements. The SKU determines the features and pricing of the registry.

4. Review and create:

   • Review the settings and click Create to create the container registry.

Step 2: Manage the Azure Container Registry

1. Access the container registry:
   • Once the registry is created, navigate to it by selecting All resources in the Azure portal and then selecting your container registry.
2. Push and pull container images:

   • To push images to the registry, you need to authenticate with the registry and use Docker commands. For example:

     docker login <registry-name>.azurecr.io
     docker tag <image-name> <registry-name>.azurecr.io/<image-name>
     docker push <registry-name>.azurecr.io/<image-name>

   • To pull images from the registry, use the following command:

     docker pull <registry-name>.azurecr.io/<image-name>

3. Configure authentication:

   • You can configure authentication using Azure Active Directory (AAD) tokens, service principals, or managed identities. For example, to allow ARM tokens for authentication, use the following command:

     az acr config authentication-as-arm update -r <registry-name> --status enabled

4. Manage access and permissions:
   • You can manage access to the registry by assigning roles to users or service principals. Go to the Access control (IAM) section of the registry in the Azure portal and assign roles such as AcrPull or AcrPush.
5. Enable content trust:
   • To ensure the integrity of your images, you can enable content trust. This feature ensures that only signed images are pulled from the registry.
6. Configure webhooks:
   • You can configure webhooks to notify external services when certain events occur in the registry, such as image pushes or deletes. Go to the Webhooks section of the registry in the Azure portal to set up webhooks.
7. Monitor and manage registry usage:
   • Use the Metrics and Logs sections in the Azure portal to monitor the usage and performance of your container registry. You can also set up alerts to notify you of specific conditions.

By following these steps, you can effectively create and manage an Azure Container Registry in the Azure portal, ensuring that your container images are securely stored and easily accessible for deployment.

Refrence: https://learn.microsoft.com/en-AU/azure/container-apps/microservices-dapr-bindings

Refrence: https://learn.microsoft.com/en-us/azure/application-gateway/for-containers/overview

Refrence: https://learn.microsoft.com/en-us/azure/aks/../defender-for-cloud/defender-for-containers-introduction

Refrence: https://learn.microsoft.com/en-us/azure/aks/../defender-for-cloud/defender-for-containers-enable

Refrence: https://learn.microsoft.com/en-AU/azure/container-apps/managed-identity-image-pull

Provision a container by using Azure Container Instances

To provision a container using Azure Container Instances (ACI), follow these detailed steps:

Step 1: Prepare Your Container Image

Before provisioning a container in ACI, you need a container image. You can create a container image using Docker and store it in a container registry like Docker Hub or Azure Container Registry.

1. Clone Application Source Code: Start by cloning the source code of your application from a repository like GitHub.
2. Create a Container Image: Use Docker to build a container image from your application source code.
3. Test the Image Locally: Run the container image in your local Docker environment to ensure it works correctly.

Step 2: Upload the Container Image to a Registry

Once your container image is ready and tested, upload it to a container registry.

1. Azure Container Registry: You can use Azure Container Registry to store your container images. This is a private registry that integrates well with Azure services.
2. Docker Hub: Alternatively, you can use Docker Hub, a public registry, to store your container images.

Step 3: Provision the Container in Azure Container Instances

Now that your container image is available in a registry, you can provision it in Azure Container Instances.

1. Navigate to Azure Portal: Go to the Azure portal and search for “Container Instances”.
2. Create a Container Instance:
   • Click on “Create” to start the provisioning process.
   • Fill in the required details such as the subscription, resource group, and container instance name.
   • Choose the region where you want to deploy the container.
3. Configure the Container:
   • Image Source: Select the container image source (e.g., Azure Container Registry, Docker Hub).
   • Image Name: Provide the name of the container image.
   • Resource Allocation: Allocate the necessary resources for your container. ACI requires a minimum of 1 CPU and 1 GB of memory for a container group, but individual container instances can be provisioned with less .
   • OS Type: Choose the operating system type (Linux or Windows) for your container.
4. Networking and Advanced Settings:
   • DNS Name Label: Optionally, configure a DNS name label for your container instance to make it accessible via a public endpoint.
   • Environment Variables: Set any environment variables required by your application.
   • Volumes: If your container needs persistent storage, configure volumes.
5. Review and Create: Review your configuration and click on “Create” to provision the container instance.

Step 4: Monitor and Manage the Container Instance

Once the container instance is provisioned, you can monitor and manage it through the Azure portal.

• Logs: View the logs to monitor the container’s output and troubleshoot any issues.
• Metrics: Use Azure Monitor to track metrics such as CPU and memory usage.
• Scaling: If needed, you can scale your container instances by adjusting the resource allocation.

Benefits of Using Azure Container Instances

• No VM Management: ACI allows you to run containers without provisioning and managing virtual machines .
• Fast Startup: Containers can start in seconds, providing a quick and efficient way to deploy applications .
• Integration with Azure Services: ACI integrates seamlessly with other Azure services, making it easier to build and manage containerized applications.

By following these steps, you can successfully provision and manage containers using Azure Container Instances, leveraging the benefits of containerization without the overhead of managing virtual machines.

Refrence: https://learn.microsoft.com/en-AU/azure/container-instances/container-instances-tutorial-prepare-app

Refrence: https://learn.microsoft.com/en-us/azure/container-instances/container-instances-container-groups

Refrence: https://learn.microsoft.com/rest/api/container-instances

Refrence: https://learn.microsoft.com/en-AU/azure/container-instances/container-instances-overview

Refrence: https://learn.microsoft.com/en-us/azure/container-instances/container-instances-overview

Provision a container by using Azure Container Apps

To provision a container using Azure Container Apps, follow these detailed steps:

Step 1: Initialize the Project

1. Run azd init to initialize the project:

   azd init

   When prompted in the terminal, provide the following parameters:

   • Environment Name: Prefix for the resource group created to hold all Azure resources.
   • Azure Location: The Azure location for your resources.
   • Azure Subscription: The Azure subscription for your resources .

Step 2: Provision the Infrastructure and Deploy the Application

1. Run azd up to provision the infrastructure and deploy the Dapr application to Azure Container Apps:

   azd up

   This command will:

   • Create and configure all necessary Azure resources via the provided Bicep files in the ./infra directory using azd provision.
   • Deploy the code using azd deploy.

   The CLI output will display two Azure portal links to monitor the deployment progress and show the resources created, such as:

   • Resource group
   • Log Analytics workspace
   • Application Insights
   • Portal dashboard
   • Azure Database for PostgreSQL flexible server
   • Key vault
   • Container Apps Environment
   • Container App .

Step 3: Create a New Azure Container Apps Environment

1. Select “Create new” to create a new Azure Container Apps environment, or select an existing environment from the dropdown menu: