Manage Azure identities and governance (20–25%)

Manage Microsoft Entra users and groups

Create Users and Groups

Creating users and groups is a fundamental task in managing an organization’s identity and access management. In Microsoft Entra, formerly known as Azure Active Directory (Azure AD), this process involves defining individual user accounts that represent people in the organization, and grouping these accounts to simplify the management of permissions and access to resources.

Users

A user in Microsoft Entra is an individual who has been given access to the organization’s cloud services. Each user has a profile that includes information such as their name, password, email address, and more. Users can be created one at a time or in bulk using tools like Azure AD Connect, PowerShell, or the Azure portal.

To manage users in Microsoft Entra, you can refer to the following resources: - Manage users and groups in Microsoft Entra ID: This training module covers the basic principles of managing users and groups.

Groups

Groups in Microsoft Entra are collections of users that can be managed as a single entity. Groups are used to assign permissions to multiple users at once, which simplifies the process of managing access to applications and resources. There are different types of groups, including security groups for managing access to resources, and distribution groups for sending email notifications to a list of users.

To create Azure users and groups, you can use the following resources: - Create Azure users and groups in Microsoft Entra ID (exercise, subscription required): This training module provides a hands-on exercise for creating users and assigning them to groups.

Best Practices

When creating users and groups, it’s important to follow best practices to ensure security and ease of management. This includes using role-based access control (RBAC) to assign the least privilege necessary, regularly reviewing group memberships, and implementing naming conventions for easy identification of groups.

For more information on role-based access control and roles in Microsoft Entra, consider these resources: - Understand Microsoft Entra role-based access control: This article describes how to understand and implement role-based access control in Microsoft Entra. - Understand roles in Microsoft Entra ID: This article explains the different roles available in Microsoft Entra and how they can be used. - Azure built-in roles: This article lists the Azure built-in roles for assigning permissions to users and groups.

By utilizing these resources, you can effectively create and manage users and groups in Microsoft Entra, ensuring that your organization’s identity and access management is secure and well-organized.

Manage Azure identities and governance (20–25%)

Manage Microsoft Entra users and groups

Manage User and Group Properties

When managing user and group properties, it is essential to understand the different types of user accounts and how to configure them. Microsoft Entra ID supports three primary types of user accounts:

1. Cloud Identities: These are standalone accounts that exist only in the cloud. They include profile information such as job title and office location, which can be customized to meet the needs of your organization[doc1].

2. Directory-Synchronized Identities: These accounts are synchronized from an on-premises directory to the cloud.

3. Guest User Identities: These are accounts for users who are not employees or do not belong to the organization but need access to its resources.

For group accounts, there are two main types:

1. Security Groups: Used to manage user access to resources.

2. Microsoft 365 Groups: Intended for collaboration, allowing access to shared mailboxes, calendars, and files.

Administrative units are also a crucial aspect of managing user and group properties. They provide a way to control administrator access to resources by segmenting the directory for administrative purposes[doc1].

Bulk Configuration: Azure allows the bulk creation of user and group accounts using a template file managed through the Azure portal. This feature is particularly useful for large organizations that need to manage many accounts simultaneously[doc1].

Group Account Organization: It is possible to manage accounts across multiple directories, which is beneficial for organizations with complex structures or those that have undergone mergers and acquisitions[doc1].

Additional Resources: - For more detailed information on managing user accounts and properties, you can refer to the Enterprise user management documentation[doc3]. - To learn about creating, editing, and deleting groups in Microsoft Entra, as well as managing group membership, roles, and dynamic rules, visit Manage Microsoft Entra groups and group membership[doc3].

By understanding these concepts and utilizing the available resources, you can effectively manage user and group properties within your organization.

Manage Azure identities and governance (20–25%)

Manage Microsoft Entra users and groups

Manage Licenses in Microsoft Entra ID

Managing licenses in Microsoft Entra ID is an essential aspect of administering an organization’s identity and access management. Microsoft Entra ID, formerly known as Azure Active Directory (Azure AD), provides a range of licensing options to cater to different organizational needs. Here’s a detailed explanation of how to manage licenses within Microsoft Entra ID:

Understanding Microsoft Entra ID Licensing Editions

Microsoft Entra ID comes in four editions: Free, Microsoft 365 Apps, Premium P1, and Premium P2[doc5]. The Free edition is included with an Azure subscription, while the Premium editions offer advanced features and are available through various licensing programs such as the Microsoft Enterprise Agreement, the Open Volume License Program, and the Cloud Solution Providers program[doc5]. Azure and Microsoft 365 subscribers can also purchase Microsoft Entra ID P1 and P2 licenses online[doc5].

Assigning and Managing Licenses

To manage licenses in Microsoft Entra ID, administrators should:

1. Access the Microsoft Entra Admin Center: Navigate to the Microsoft Entra Admin Center to view and manage licenses. This is the central hub for all identity and access management tasks.

2. Review Available Licenses: Check the available licenses within your organization’s subscription. This includes understanding the features and limitations of each license type.

3. Assign Licenses to Users: Assign the appropriate licenses to users based on their role and the access they require. Licenses can be assigned individually or in bulk.

4. Manage Group-Based Licensing: Utilize group-based licensing to automatically assign licenses to all members of a group. When new users are added to the group, they will automatically receive the necessary licenses[doc1].

5. Monitor License Usage: Regularly monitor license usage to ensure that licenses are utilized efficiently. Reassign or remove licenses from users who no longer need them to optimize costs.

6. Understand License Dependencies: Some services may require additional licenses or have dependencies on other Microsoft services. Ensure that all necessary licenses are in place for seamless service integration.

7. Plan for Changes: When planning changes to services or user roles, consider the impact on licensing. Ensure that license adjustments are made to support these changes.

For additional information on managing licenses in Microsoft Entra ID, refer to the following resources:

• Enterprise user management documentation
• Manage Microsoft Entra groups and group membership
• Microsoft Entra ID editions and features

By following these guidelines, administrators can effectively manage licenses in Microsoft Entra ID, ensuring that users have the appropriate access to resources and applications while maintaining cost efficiency and compliance with licensing agreements.

Manage Azure identities and governance (20–25%)

Manage Microsoft Entra users and groups

Managing external users involves understanding how to handle identities that are not part of your organization’s primary directory in Microsoft Entra (formerly known as Azure Active Directory). External users can include vendors, contractors, or users from other organizations that need access to your resources. Here’s a detailed explanation of how to manage external users:

Types of External User Accounts

1. Guest User Accounts:
   • Guest user accounts are for individuals who are not part of your primary Azure environment.
   • They can originate from other cloud providers or from Microsoft accounts such as Xbox LIVE.
   • The source for these accounts is typically marked as ‘Invited user’.
   • These accounts are essential for collaboration with external entities requiring access to certain Azure resources[doc5].
2. Cloud Identity:
   • A cloud identity can also be used for external users if they are defined in an external Microsoft Entra instance.
   • When a cloud identity is removed from the primary directory, the associated user account is deleted[doc5].

Managing External Users

• Plan Your Strategy: Determine the types of access required by external users and create security principals accordingly. Security principals can be users, groups, applications, services, or resources[doc1].

• Determine User Definition: Identify whether external users are defined within your Microsoft Entra organization or if they come from external instances. This will influence how you manage these users[doc4].

• Implement User Account Types: Choose the appropriate user account types that satisfy your business requirements. For external users, this will often be guest user accountsdoc2.

• Configure and Manage Accounts: Learn how to create and manage user and group accounts, including bulk operations. This is crucial for efficiently handling a large number of external users[doc3].

• Use Administrative Units: Administrative units can help control administrator access to resources, which is particularly useful when dealing with external users[doc3].

• Support Multiple Directories: If your organization uses multiple directories, ensure that you can manage accounts across all of them effectively[doc3].

Additional Resources

For more information on managing external users and understanding the different types of user accounts in Microsoft Entra, you can refer to the following resources:

• Microsoft Entra documentation
• Manage guest access with Azure AD
• Azure AD B2B collaboration

Please note that while these URLs provide additional information, they should be accessed and reviewed to ensure they align with the latest guidelines and practices provided by Microsoft.

By understanding these concepts and utilizing the resources provided, you can effectively manage external users within your organization’s Microsoft Entra environment.

Manage Azure identities and governance (20–25%)

Manage Microsoft Entra users and groups

Configure Self-Service Password Reset (SSPR)

Self-Service Password Reset (SSPR) is a feature provided by Microsoft Entra that empowers users to reset their own passwords without the need to contact the helpdesk. This capability enhances security and user productivity while reducing costs associated with password reset requests. Here is a detailed explanation of how to configure SSPR:

1. Enable SSPR in Microsoft Entra:
   • Navigate to the Microsoft Entra admin center.
   • Locate the ‘Password reset’ option under the ‘Manage’ section.
   • Select ‘All’ to enable SSPR for all users or choose ‘Selected’ to enable it for specific groups.
2. Configure Authentication Methods:
   • Decide on the authentication methods users can use to verify their identity. Options include mobile phone, alternate email, security questions, and authenticator app.
   • Set the number of methods required to reset the password.
3. Notification and Registration Policy:
   • Configure notifications to alert users and admins about password resets.
   • Set up a registration policy that prompts users to register for SSPR when they sign in.
4. Customize the SSPR Experience:
   • Customize the SSPR portal with your organization’s branding.
   • Define helpdesk contact information for users who need additional assistance.
5. Implement On-Premises Integration (if applicable):
   • For hybrid environments, ensure that the Azure AD Connect tool is configured with password writeback to enable SSPR for on-premises users.
6. Test the SSPR Configuration:
   • Perform tests to ensure that the SSPR process works as expected for different user scenarios.
7. Educate Users:
   • Inform users about the availability of SSPR and provide instructions on how to register and use the feature.
8. Monitor and Report:
   • Regularly review SSPR usage and attempted resets through the reporting feature in the Microsoft Entra admin center.

For additional information on configuring SSPR, you can refer to the following resources:

• How to configure self-service password reset
• SSPR with Azure AD Connect

By following these steps, you can successfully configure SSPR to provide a secure and efficient password reset experience for your users[doc1][doc3][doc5].

Manage Azure identities and governance (20–25%)

Manage access to Azure resources

Manage Built-in Azure Roles

Azure Role-Based Access Control (RBAC) is a system that provides fine-grained access management to Azure resources, allowing organizations to segregate duties within their teams and grant only the access their users need to perform their jobs[doc3].

Built-in Roles in Azure RBAC

Azure RBAC comes with several predefined built-in roles that cater to common access management requirements for Azure resources. These roles are designed to support various service categories, tasks, and user responsibilities[doc4].

Some of the key characteristics of these built-in roles include:

• Predefined Permission Sets: Each built-in role has a set of permissions that specify the actions allowed for users assigned to that roledoc2.
• Assignable at Different Scopes: Roles can be assigned at multiple levels, such as management groups, subscriptions, resource groups, or individual resources, to control the extent of access[doc2][doc3].
• Owner Role: The Owner role has the highest level of privileges, allowing full management of all resources, including the ability to delegate access to othersdoc2.
• Contributor Role: The Contributor role allows users to manage all types of Azure resources but does not allow them to grant access to others[doc1].
• Reader Role: The Reader role provides read-only access to Azure resources, allowing users to view but not modify any resources.

Custom Roles

In addition to built-in roles, Azure RBAC allows the creation of custom roles. Custom roles can be tailored to fit the specific needs and requirements of an organization. These roles are created by defining a new set of permissions or by modifying existing built-in rolesdoc2.

Managing Role Assignments

Role assignments are the association of a role definition with a user, group, or service principal at a particular scope. This determines the level of access that the assigned entity has. To manage access effectively, it is crucial to understand how to create and manage these role assignments[doc3].

Effective Permissions

The effective permissions of a role are determined by subtracting any ‘NotActions’ permissions from the ‘Actions’ permissions. This ensures that certain operations can be explicitly excluded from a role’s capabilitiesdoc2.

Azure RBAC and Microsoft Entra Roles

While Azure RBAC roles are specific to managing Azure resources, Microsoft Entra administrator roles are used to manage resources within Microsoft Entra ID, such as users, groups, and domains. These roles are applied at the tenant level and are separate from Azure RBAC roles[doc4][doc5].

For additional information on Azure RBAC and built-in roles, you can refer to the following resources: - Azure RBAC built-in roles - Understanding Azure role definitions - Managing access using RBAC and Azure policies

By understanding and effectively managing built-in Azure roles, organizations can ensure that their users have the appropriate level of access to perform their tasks securely and efficiently.

Manage Azure identities and governance (20–25%)

Manage access to Azure resources

Assigning Roles at Different Scopes

In Azure, role assignments are a critical aspect of access management, allowing administrators to grant the appropriate level of access to users, groups, and service principals. The concept of scope is integral to this process, as it defines the boundary of access permissions.

Core Concepts of Azure RBAC

• Security Principal: Represents an entity that requests access to Azure resources, such as a user, group, service principal, or managed identity[doc4].
• Role Definition: A collection of permissions specifying operations that can be performed, such as read, write, and delete. Azure provides built-in role definitions like Reader, Contributor, and Owner, and also allows for custom role definitions[doc4].
• Scope: Determines the extent of access that a role assignment grants. It can range from broad to specific, including management groups, subscriptions, resource groups, and individual resources.
• Assignment: The act of attaching a role definition to a security principal at a specific scope, thereby granting the permissions defined in the role to the principal at that scope[doc4].

Scopes in Azure RBAC

Scopes can be defined at multiple levels, allowing for flexible and precise access control:

• Management Group: This is the highest level at which you can assign a role, allowing the assigned principal to access all subscriptions within the management group[doc4].
• Subscription: A role assigned at the subscription level applies to all resource groups and resources within that subscription.
• Resource Group: Assigning a role at this level grants access to all resources within the specific resource group[doc4].
• Resource: The most granular level, where a role assignment affects only the specific resource.

Assigning Roles

To assign roles at different scopes, you can follow these general steps:

1. Identify the security principal (user, group, service principal, or managed identity) that requires access[doc4].
2. Determine the appropriate role definition that contains the necessary permissions for the tasks the principal needs to perform[doc4].
3. Decide on the scope at which the role should be assigned, based on the level of access required[doc4].
4. Create the role assignment by attaching the role definition to the security principal at the chosen scope[doc4].

Examples of Role Assignments

• Assigning the Contributor role to a user at the subscription level would allow the user to manage all resources within that subscription, except for granting access to othersdoc2.
• Assigning the Reader role to a group at the resource group level would enable the group members to view but not modify resources within that resource groupdoc2.

Additional Resources

For more detailed information on role assignments and scopes in Azure RBAC, you can refer to the following resources:

• Azure RBAC documentation
• Microsoft Entra administrator roles

By understanding and effectively implementing role assignments at different scopes, administrators can ensure that users have the access they need to perform their jobs without compromising security or granting excessive permissions.

Manage Azure identities and governance (20–25%)

Manage access to Azure resources

Interpreting access assignments involves understanding how permissions are granted and managed within an organization’s resources. Access assignments are a critical component of role-based access control (RBAC), which is a method for regulating access to computer or network resources based on the roles of individual users within an organization.

Here’s a detailed explanation of the concept:

Role Assignments and Access Control

• Purpose of Role Assignments: Role assignments are used to control access to resources. They define what actions a user, group, or service principal can perform on a given resource within a specified scope[doc1].

• Scope of Role Assignments: The scope of a role assignment can vary from broad to very specific. It limits the permissions that are available to the assigned requestor. Scopes can be set at different levels, such as management groups, subscriptions, resource groups, or individual resourcesdoc2.

• Revoking Access: To revoke access to a resource, the corresponding role assignment is removed. This ensures that the requestor no longer has the permissions that were granted by that role assignment[doc1].

• Inheritance of Role Assignments: Resources inherit role assignments from their parent resources. This means that if a user is granted access to a resource group, they automatically have access to all the resources within that group[doc1].

• Effective Permissions: The effective permissions for a requestor are the combination of the permissions for the requestor’s assigned roles and the permissions for the roles assigned to the requested resources. This means that a user’s total permissions are the sum of their individual permissions and the permissions inherited from the resource hierarchy[doc1].

Role Definitions and Customization

• Built-in Roles: Azure RBAC provides over 100 predefined built-in roles, such as Owner, Backup Operator, Website Contributor, and SQL Security Manager. These roles are designed to cover a wide range of common tasks and services[doc4].

• Custom Role Definitions: Organizations can create custom role definitions to meet specific business needs. Custom roles can be created from scratch or by modifying the permissions of an existing built-in role[doc4].

• Access Scope Limitation: It is recommended to assign roles with the minimum level of scope required to perform job duties. This helps in maintaining a principle of least privilege, where users are granted only the access that is necessary for their work[doc4].

• Controlling Data Changes: Tight access control should be applied to sensitive data or resources that should only be modified under specific conditions. This helps in preventing unauthorized changes and maintaining security[doc4].

• Deny Assignments: In addition to granting permissions, it is also possible to explicitly deny certain actions using deny assignments. This feature is used to block users from performing specific actions even if they have a role assignment that would otherwise allow it[doc4].

For additional information on these concepts, you can refer to the following resources: - Understand Microsoft Entra role-based access control[doc3]. - Azure built-in roles[doc3][doc4]. - Understand Azure role assignments[doc3].

By understanding and interpreting access assignments, organizations can effectively manage permissions and ensure that users have the appropriate level of access to perform their roles securely and efficiently.

Manage Azure identities and governance (20–25%)

Manage Azure subscriptions and governance

Implement and Manage Azure Policy

Azure Policy is a service within Azure that allows organizations to create, assign, and manage policies that enforce rules and ensure compliance with corporate standards and service level agreements. It is a key tool for Azure Administrators to define conventions for resources and to maintain governance across Azure environments.

Key Features of Azure Policy:

• Policy Definitions: These are the rules that govern resource properties and can be used to enforce compliance conditions. When a resource is evaluated against a policy definition, if it doesn’t comply, the policy definition states what action should be taken[doc5].

• Initiative Definitions: A collection of policy definitions that are intended to achieve a specific goal. Grouping policy definitions into initiatives helps in managing and enforcing related policies as a single unit[doc5].

• Management Groups: These provide a level of scope above subscriptions. You can aggregate multiple subscriptions into a management group and apply your governance conditions to the management group. This allows for a hierarchical structure for resource management and simplifies the assignment and management of policies at scale[doc1].

• Scope of Policies: Policies can be applied to resources at different scopes – from a management group down to a single resource. This allows for fine-grained control over where and how policies are enforced[doc1].

• Compliance Feature: Azure Policy includes a compliance feature that helps you assess the state of your resources and determine whether they are compliant with the policies you have set. This feature is crucial for auditing and ensuring that resources stay within the defined compliance boundaries[doc1].

• Enforcement and Remediation: Azure Policy supports real-time policy evaluation and enforcement. It also allows for remediation actions to be taken on existing resources that are found to be non-compliant, ensuring that they can be brought back into compliance[doc4].

Advantages of Azure Policy:

• Enforce Rules and Compliance: Azure Policy enables the enforcement of built-in or custom policies for all resource types, supporting real-time and periodic compliance evaluation[doc4].

• Apply Policies at Scale: Policies can be applied across an entire organization by targeting a management group, allowing for the application of multiple policies and aggregation of policy states[doc4].

• Perform Remediation: Azure Policy allows for real-time remediation as well as remediation of existing resources, ensuring that resources can be corrected to comply with policies[doc4].

• Exercise Governance: Azure Policy supports governance tasks such as managing multiple subscriptions, standardizing resource configurations, managing regulatory compliance, cost control, security, and ensuring design consistency[doc4].

For additional information on Azure Policy and how to implement it, you can refer to the following resources:

• Azure Policy Documentation
• Understand Azure Policy Definitions
• Organize Resources with Azure Management Groups

Please note that the URLs provided are for reference purposes and are part of the Azure documentation which can be accessed for more detailed guidance on Azure Policy.

Manage Azure identities and governance (20–25%)

Manage Azure subscriptions and governance

Resource locks are a critical feature in Azure that help protect resources from accidental deletion or modification. They can be applied to any resource or to a resource group, ensuring that critical resources remain unchanged unless explicitly decided by an administrator. There are two types of locks:

1. Read-only: This lock means authorized users can still read a resource, but they can’t delete or update the resource. Applying this lock is similar to restricting all users to the permissions granted by the Reader role.

2. Delete: This lock allows all operations against the resource but prevents the resource from being deleted.

Here is a step-by-step guide on how to configure resource locks:

1. Navigate to the Azure Portal: Open your web browser and go to the Azure Portal at https://portal.azure.com/[doc1].

2. Search for the Resource: Use the search bar to find the resource or resource group you want to apply the lock to.

3. Access the Settings: On the resource or resource group blade, select ‘Settings’ and then choose ‘Locks’.

4. Add a Lock: Click on ‘+ Add’ to create a new lock.

5. Configure the Lock:

   • Name: Enter a unique name for the lock. This name helps you identify the lock later.
   • Lock type: Select the type of lock you want to apply (Read-only or Delete).
   • Notes (optional): Add any notes that explain why the lock is being applied.

6. Save the Lock: Click ‘OK’ or ‘Save’ to apply the lock to the resource or resource group.

It’s important to note that resource locks apply only at the resource group or resource level. Therefore, if you apply a lock at a resource group level, it will apply to all resources within that group. However, you can also apply locks to individual resources within a resource group, which allows for more granular control.

For more detailed information and guidance on using resource locks, you can refer to the Azure documentation:

• Azure Resource Locks Documentation

Remember, while resource locks can prevent accidental deletions, they do not prevent users from performing operations that they have permissions to do. Always manage and review permissions and roles in conjunction with resource locks to ensure the appropriate level of security and governance.

Please ensure that you have the necessary permissions to apply or remove resource locks, as attempting to do so without the appropriate permissions will result in an error.

Manage Azure identities and governance (20–25%)

Manage Azure subscriptions and governance

Apply and Manage Tags on Azure Resources

Tags in Azure are key-value pairs that can be applied to resources and resource groups. They are used to organize resources, making it easier to sort, search, manage, and analyze the components of your Azure infrastructure.

Characteristics of Azure Resource Tags:

• Name and Value Pairs: Each tag consists of a name and a value. For example, you might have a tag with the name Environment and the value Productiondoc2.
• Consistent Names: The tag name is constant across all resources that have the tag applieddoc2.
• Unique or Set Values: The tag value can be unique for each resource or selected from a predefined set of valuesdoc2.
• Maximum Tags: A resource or resource group can have up to 50 tag name/value pairsdoc2.
• Inheritance: Tags applied to a resource group are not inherited by the resources within that groupdoc2.

Managing Tags:

1. Creating Tags: Tags can be created and assigned through the Azure portal. For instance, you can add a tag to a resource group and assign a value to it[doc4].
2. Enforcing Tags: To ensure that resources are not created without specific tags, you can use Azure policies. For example, the Require a tag and its value on resources policy can be assigned to a resource group to enforce the presence of a tag[doc4].
3. Automatic Tagging: If a resource is created without a required tag, you can configure Azure policies to automatically add the tag. The Inherit a tag from the resource group if missing policy can be used for this purpose[doc4].
4. Programmatic Tagging: Tags can also be created and managed programmatically using Azure PowerShell or the Azure CLI, which is useful for managing tags in bulk[doc5].

Practical Steps:

• Step 1: Identify a resource group and add a tag through the Azure portal[doc4].
• Step 2: Use an Azure policy to require a specific tag and value when creating resources[doc4].
• Step 3: Set up automatic tagging for resources missing the required tag using an Azure policy[doc4].

Additional Resources:

For more information on how to apply and manage tags on Azure resources, you can refer to the following resources:

• Azure Resource Tags
• Azure Policy Documentation

Please note that the URLs provided are for additional context and should be accessed directly for further details.

By effectively using tags, you can maintain a well-organized Azure environment that aligns with your operational and billing practices, making it easier to manage and report on your infrastructure.

Manage Azure identities and governance (20–25%)

Manage Azure subscriptions and governance

Manage Resource Groups

Resource groups in Azure are containers that hold related resources for an Azure solution. The management of resource groups is crucial for organizing resources, enforcing security practices, and managing billing. Here’s a detailed explanation of how to manage resource groups:

Creation and Organization

• Create a Resource Group: Resource groups are created to organize resources that share the same lifecycle, permissions, and policies. They can be created using the Azure portal, Azure PowerShell, or Azure CLI[doc5].
• Organize Resources: Place resources that share the same lifecycle and management policies in the same resource group. This simplifies resource management and deployment.

Access Management

• Role-Based Access Control (RBAC): Azure RBAC roles can be assigned at the resource group level to control access to the resources within the group. This ensures that only authorized users can perform actions on the resources[doc3].
• Security Principals: Assign roles to security principals, which include users, groups, service principals, and managed identities, to manage who has access to the resource group[doc3].

Policy Enforcement

• Azure Policy: Use Azure Policy to enforce organizational standards and to assess compliance at scale. Policies can be applied to resource groups to ensure resources within the group adhere to the defined standards[doc4].

Scope and Role Definitions

• Scope: The scope for resource groups can be defined at the subscription level. This means that a resource group is a way to group resources under a particular Azure subscription[doc3].
• Role Definitions: Define custom roles or use built-in roles like Reader, Contributor, Owner, or User Access Administrator to specify what actions the assigned security principal can perform within the resource group[doc3].

Management Tools

• Azure Portal: The Azure portal provides a user-friendly interface for managing resource groups and resources within them.
• Azure PowerShell: Azure PowerShell can be used for scripting and automating the management of resource groups and resources[doc5].
• Azure CLI: The Azure Command-Line Interface (CLI) is another tool that can be used for managing resource groups through commands.

Additional Information

For more details on managing resource groups and the associated roles and permissions, you can refer to the following resources: - Azure RBAC roles - Azure Policy documentation - Azure PowerShell documentation - Azure CLI documentation

By understanding and utilizing these concepts and tools, you can effectively manage resource groups in Azure, ensuring that resources are organized, secure, and compliant with organizational standards.

Manage Azure identities and governance (20–25%)

Manage Azure subscriptions and governance

Manage Subscriptions

Managing subscriptions in Azure is a critical skill for ensuring effective access control, cost management, and resource organization within an organization’s cloud infrastructure. Here are the key points to understand about managing Azure subscriptions:

• Azure Regions: Azure’s global infrastructure is divided into regions that provide flexibility in data residency, compliance with local regulations, and options for resiliency. Choosing the right region is essential for optimizing performance and adhering to data governance policies.

• Subscription Types: Azure offers a variety of subscription options to cater to different needs, including Free, Pay-As-You-Go, Enterprise Agreement, and Student subscriptions. Each type has its features and billing structures, allowing organizations to select the most appropriate one for their scenarios[doc1].

• Cost Management: Azure provides tools like Microsoft Cost Management to monitor and control spending. It helps in analyzing costs, creating budgets, and optimizing resource usage to reduce overall billing costs. Azure also offers cost-saving options such as reservations, Azure Hybrid Benefits, and Azure credits[doc1].

• Resource Tagging: Tagging resources in Azure allows for better organization and analysis. Tags can be used to categorize resources for cost tracking, management, and automation purposes[doc1].

• Billing and Cost Analysis: Understanding and managing costs is facilitated by tools such as the Azure Pricing Calculator, which provides billing estimates for various usage cases. Microsoft Cost Management + Billing is a comprehensive resource for monitoring and controlling Azure spending[doc1][doc3][doc4].

For additional information on managing subscriptions and costs in Azure, the following resources can be explored:

• Control Azure spending and manage bills with Microsoft Cost Management + Billing: A learning path to understand how to monitor and control Azure spending and optimize resource usage[doc3].

• Introduction to analyzing costs and creating budgets with Microsoft Cost Management: A module that teaches how to use cost analysis and budgeting within Azure Cost Management[doc3].

• Describe cost management in Azure: A module that explores different methods to estimate, track, and manage costs in Azure[doc3].

• Cost management in Azure: A collection of articles covering pricing, reporting, analytics, monitoring, and optimizing costs[doc4].

• Billing and subscriptions management in Azure: A collection of articles on managing accounts, subscriptions, bills, and payments[doc4].

• Azure Pricing Calculator: A tool for estimating the costs associated with Azure services[doc4].

Understanding and effectively managing Azure subscriptions is essential for maintaining control over the cloud environment, ensuring cost efficiency, and complying with organizational policies and external regulations.

Manage Azure identities and governance (20–25%)

Manage Azure subscriptions and governance

Managing costs in Azure is a critical aspect of cloud resource management. To effectively manage costs, you can utilize alerts, budgets, and Azure Advisor recommendations. Here’s a detailed explanation of each:

Alerts

Alerts in Azure notify you when your spending reaches a certain threshold. This helps prevent unexpected charges and enables you to take proactive measures to control costs. You can set up alerts based on a variety of metrics, such as cost thresholds or resource usage.

• How to set up alerts: Navigate to the Cost Management + Billing section in the Azure portal. Under the “Cost Management” section, select “Alerts” and then “Add cost alert.” Configure the alert criteria, threshold, and notification settings.

Budgets

Budgets help you plan and enforce spending limits for your Azure resources. By setting budgets, you can track your spending against your financial constraints and ensure that you do not exceed your allocated budget.

• How to create budgets: In the Azure portal, go to Cost Management + Billing, and under “Cost Management,” select “Budgets.” Click on “Add” to create a new budget, define the budget amount, the time period, and the scope (such as a subscription or resource group).

Azure Advisor Recommendations

Azure Advisor is a personalized cloud consultant that helps you follow best practices to optimize your Azure deployments. It provides recommendations on how to reduce costs by identifying idle resources, underutilized instances, and suggests reservation purchases for consistent workloads.

• How to access recommendations: Access Azure Advisor through the Azure portal by selecting “Advisor” from the navigation menu. Then, choose the “Cost” category to view cost-saving recommendations.

For additional information on managing costs in Azure, you can refer to the following resources:

• Control Azure spending and manage bills with Microsoft Cost Management + Billing.
• Introduction to analyzing costs and creating budgets with Microsoft Cost Management (exercise, subscription required).
• Describe cost management in Azure (exercise, subscription required).
• Cost management.
• Billing and subscriptions management.
• Pricing calculator.

By leveraging alerts, budgets, and Azure Advisor recommendations, you can effectively manage your Azure costs and optimize your resource usagedoc1[doc3][doc5].

Manage Azure identities and governance (20–25%)

Manage Azure subscriptions and governance

Configure Management Groups

Management groups in Azure are administrative containers that help you manage access, policies, and compliance across multiple Azure subscriptions. They provide a level of scope above subscriptions, allowing you to efficiently manage governance controls such as Azure policies and access permissions.

Characteristics of Azure Management Groups

• Hierarchical Structure: Management groups form a hierarchy that allows for efficient management of governance policies across multiple subscriptions. By default, new subscriptions are placed under the top-level management group, known as the root group [doc1].
• Inheritance: Subscriptions within a management group inherit all the governance conditions applied to the management group. This means that any policy or role assignment applied to a management group is automatically applied to all subscriptions within that group [doc1].
• Depth Levels: A management group tree can support up to six levels of depth, providing flexibility in organizing subscriptions according to the needs of your organization [doc1].
• Role-Based Access Control (RBAC): Azure RBAC is not enabled by default for management group operations. It must be set up to control access to management group actions [doc1].

Core Concepts of Azure RBAC

• Security Principal: Represents an entity that requests access to Azure resources, such as a user, group, service principal, or managed identity [doc3].
• Role Definition: A collection of permissions that define allowed operations within Azure. You can use built-in role definitions or create custom ones [doc3].
• Scope: Defines the boundary of access level granted. It can be a management group, subscription, resource group, or a single resource [doc3].
• Assignment: The process of attaching a role definition to a security principal at a specific scope to grant access [doc3].

Creating and Managing Azure Management Groups

• Creation: Management groups can be created using the Azure portal, PowerShell, or Azure CLI. Each management group is assigned a unique directory ID and an optional display name. The directory ID is immutable and is used to identify the management group across Azure [doc4].
• Policy Application: Azure Policy can be used to apply governance controls to management groups. For example, you can limit the regions where virtual machines can be created by applying a policy to a management group. This policy will then apply to all subscriptions and resources under that management group [doc5].

Additional Resources

For more information on configuring management groups and Azure RBAC, you can refer to the following resources:

• Organize your resources with Azure management groups
• What is Azure Policy?
• What is Azure role-based access control (Azure RBAC)?

By understanding and utilizing management groups and Azure RBAC, you can create a structured and secure environment that aligns with your organization’s governance requirements.

Implement and manage storage (15–20%)

Configure access to storage

Configure Azure Storage Firewalls and Virtual Networks

When configuring Azure Storage, it is essential to secure access to the storage account. This can be achieved through the Firewalls and virtual networks settings within the Azure portal. Here’s a detailed explanation of the steps and considerations involved:

1. Accessing Firewalls and Virtual Networks Settings:
   • Navigate to the Azure portal and locate your storage account.
   • Within the storage account settings, find the Firewalls and virtual networks section.
   • This is where you can define which virtual networks and IP addresses are allowed to access the storage services.
2. Restricting Network Access:
   • The primary purpose of the Firewalls and virtual networks settings is to limit access to your storage account[doc1].
   • You can specify which subnets on virtual networks or public IP addresses are permitted to connect to the storage accountdoc2.
3. Configuring Service Endpoints:
   • Service endpoints can be configured on your subnets for a straightforward setup and minimal maintenance[doc3].
   • This eliminates the need for reserved public IP addresses within your virtual networks to secure Azure resources through an IP firewall[doc3].
   • No Network Address Translation (NAT) or gateway devices are required to establish service endpoints[doc3].
4. Considerations for Virtual Networks and Subnets:
   • Ensure that the subnets and virtual networks you wish to grant access to exist in the same Azure region or paired region as your storage accountdoc2.
   • Be aware that when service endpoints are configured, the IP addresses of virtual machines will change from public to private IPv4 addresses[doc3].
   • Existing Azure service firewall rules that rely on Azure public IP addresses may need to be updated to accommodate this change[doc3].
5. Testing and Verification:
   • After configuring the service endpoints and firewall settings, it is crucial to test the setupdoc2.
   • Verify that the endpoint limits access as expected and that there are no unintended restrictions or exposuresdoc2.
6. Encryption and Data Security:
   • It’s important to note that all data written to Azure Storage is automatically encrypted using Azure Storage encryption, adding an additional layer of security[doc5].

For more detailed information and step-by-step guidance, you can refer to the official Azure documentation on configuring storage accounts and service endpoints.

Additional Resources: - Azure Storage Firewalls and Virtual Networks: Azure Storage Firewalls and Virtual Networks - Configuring Azure Storage Service Endpoints: Configuring Azure Storage Service Endpoints

Please note that while these URLs provide additional information, they should be accessed and reviewed to ensure they align with the latest Azure documentation and practices.

Implement and manage storage (15–20%)

Configure access to storage

Create and Use Shared Access Signature (SAS) Tokens

A Shared Access Signature (SAS) is a powerful tool in Azure Storage that grants restricted access rights to your storage resources. It is a secure method to share storage resources without exposing your account keys. SAS tokens are generated as a URI, which includes the Azure Storage resource URI and the SAS token itself[doc1][doc5].

How SAS Tokens Work

When you create a SAS, you specify the permissions, the time frame during which the SAS is valid, and optionally, an IP address range from which the SAS can be used. This creates a URI that can be used to access the storage resource within the constraints you’ve set[doc1].

Benefits of Using SAS Tokens

• Security: SAS tokens provide a way to grant access to storage resources without sharing your primary storage account keys[doc5].
• Control: You can define the scope of access, including the type of access (read, write, delete) and the duration of access.
• Flexibility: SAS tokens can be distributed to clients who require temporary access to a resource, making it ideal for scenarios where limited or time-bound access is necessary[doc5].

Potential Risks

• Compromise: If a SAS token is leaked, it can be used by anyone, including malicious usersdoc2.
• Expiration: If a SAS token expires and the client application cannot retrieve a new one, the application’s functionality may be affecteddoc2.

Steps to Create and Use SAS Tokens

1. Create the Infrastructure Environment: Use a template to set up the necessary virtual networks and virtual machines. Deploy the template using Azure PowerShell[doc3].

2. Create and Configure Azure Storage Accounts: Set up a new storage account and configure it with the appropriate redundancy and access tiers[doc3].

3. Generate SAS Token: Create a SAS token with limited time access for a storage resource. This is done by specifying the permissions and time frame for the SAS[doc3].

4. Verify SAS Token: Test the SAS token to ensure it grants the expected access to the storage resource and that it adheres to the specified constraints[doc3].

5. Distribute SAS Token: Provide the SAS URI to clients, granting them the specified access to the storage resource for the time period defined[doc5].

6. Manage Network Access: Restrict network access to the storage account to specific IP addresses, and verify that access from other sources, like the Cloud Shell, is denied[doc3].

Additional Resources

For more information on how to secure your storage and best practices for using SAS tokens, you can refer to the following resource: - Azure Tips and Tricks #272 Azure Security Best Practices: Azure Security Best Practicesdoc2.

For a practical example of creating and using a SAS token, you can review the lab template provided by Microsoft Learning: - Lab Template for Azure Storage: Lab Template[doc3].

By understanding and implementing SAS tokens, you can enhance the security and manageability of your Azure Storage resources.

Implement and manage storage (15–20%)

Configure access to storage

Stored access policies provide a way to manage shared access signatures (SAS) for a service within Azure Storage. They offer an additional level of control over SAS by allowing you to group shared access signatures and define common constraints for them. Here’s a detailed explanation of how to configure stored access policies:

Understanding Stored Access Policies

Stored access policies are set at the container level for blobs and at the queue, table, and file share levels for other services. They provide a centralized way to manage and enforce rules for SAS without having to regenerate them if the rules change[doc5].

Configuring Stored Access Policies

1. Create a Stored Access Policy:
   • Navigate to the Azure portal and locate the specific service within Azure Storage (e.g., Blob Containers, File Shares, Queues, or Tables).
   • Select the container or equivalent where you want to apply the stored access policy.
   • Access the ‘Access policy’ section.
   • Click on ‘Add policy’ to create a new stored access policy.
   • Define the policy by setting a name, permissions (read, write, delete, list), and the start and end times for the policy’s validity[doc5].
2. Define Permissions:
   • Specify the exact permissions that the SAS will grant. For example, you might grant read and write permissions but not delete permissions. This ensures that users have only the minimum required privileges[doc2][doc5].
3. Set Expiry Times:
   • Determine the start and end times for the SAS. It’s recommended to set near-term expiry times to mitigate the risk of a compromised SAS and to be mindful of clock skewdoc2.
4. Reference Stored Access Policies in SAS:
   • When creating a SAS, reference the stored access policy by name. This allows the SAS to inherit the rules defined in the stored access policy[doc5].
5. Revoke Permissions if Necessary:
   • If you need to revoke permissions granted by a SAS, you can do so by either updating or deleting the stored access policy. This eliminates the need to regenerate storage account keys, which can be disruptivedoc2.

Best Practices for Stored Access Policies

• Use HTTPS for Creation and Distribution: Always use HTTPS when creating and distributing a SAS to prevent man-in-the-middle attacksdoc2.
• Plan for SAS Start Time: Set the start time for a SAS to at least 15 minutes in the past to account for clock skewdoc2.
• Monitor with Azure Storage Analytics: Use Azure Storage Analytics to monitor authentication failures and other anomalies that might indicate issues with your SAS or stored access policiesdoc2.

Additional Resources

For more information on configuring stored access policies and shared access signatures, you can refer to the following URLs: - Azure SAS documentation: Shared Access Signatures, Part 1: Understanding the SAS Model - Azure Blob Storage documentation: Manage access to Azure Storage resources

Please note that the URLs provided are for additional information and should be accessed directly for the most up-to-date guidance.

By following these steps and best practices, you can effectively configure stored access policies to manage access to your Azure Storage resources securely and efficiently.

Implement and manage storage (15–20%)

Configure access to storage

Access keys are critical components for managing access to Azure Storage accounts. They serve as the primary means of authentication, allowing users and applications to interact with the storage account’s services, such as blobs, queues, tables, and files. Each Azure Storage account is provided with two access keys, known as the primary and secondary keys. These keys are crucial because they grant full access to the storage account, and therefore, they must be handled with the utmost care and security.

Best Practices for Managing Access Keys:

1. Secure Storage of Access Keys: It is imperative to store access keys securely to prevent unauthorized access. Access keys should be treated with the same level of security as a root password to a server.

2. Regular Key Regeneration: Microsoft recommends regularly regenerating your access keys. This practice helps to minimize the risk of the keys being compromised. When regenerating keys, it is important to update all Azure resources and applications that use these keys to ensure uninterrupted access.

3. Key Rotation Process: Implement a key rotation process that allows for the seamless transition from one key to another. This process involves updating the storage account with the new key, followed by updating all applications and services to use the new key before deactivating the old key.

4. Use of Secondary Key: The secondary key allows you to maintain connections using one key while regenerating the other. This ensures that there is no downtime or interruption in service during the key rotation process.

5. Update Applications and Resources: After regenerating an access key, it is crucial to promptly update any applications, services, or Azure resources that use the key to avoid any service disruptions.

For additional information on managing access keys and implementing best practices for Azure Storage security, you can refer to the following resources:

• Manage storage account access keys
• Azure Key Vault
• Azure Storage security guide

By adhering to these guidelines, you can ensure that your Azure Storage account remains secure and that access is controlled and monitored effectivelydoc1[doc4][doc5].

Implement and manage storage (15–20%)

Configure access to storage

To configure identity-based access for Azure Files, you need to understand the various authorization strategies available in Azure Storage, as well as the specific features of Azure Files that support identity-based access control. Here’s a detailed explanation:

Azure Files and Identity-Based Access Control

Azure Files offers fully managed file shares in the cloud that can be mounted concurrently by cloud or on-premises deployments of Windows, Linux, and macOS[doc3]. To secure these file shares, Azure provides several authorization strategies:

1. Microsoft Entra ID: This is Microsoft’s cloud-based identity and access management service. With Microsoft Entra ID, you can assign fine-grained access to users, groups, or applications using role-based access control (RBAC). This allows you to control who can access the Azure Files and what actions they can perform[doc4].

2. Shared Key: Shared Key authorization uses your Azure storage account access keys and other parameters to produce an encrypted signature string. This string is included in the Authorization header of the request to authenticate access[doc4].

3. Shared Access Signatures (SAS): A SAS is a token that grants delegated access to resources in your Azure storage account with specified permissions and for a specified time interval. This is useful for providing limited access to your Azure Files without exposing your account keys[doc4].

4. Anonymous Access: You can make blob resources in Azure Blob Storage publicly accessible at the container or blob level. However, for Azure Files, anonymous access is not typically recommended due to security concerns[doc4].

Steps to Configure Identity-Based Access for Azure Files

1. Enable Azure Active Directory (Azure AD) Authentication for Azure Files: Azure Files supports Azure AD authentication over SMB for certain performance tiers. This allows you to use Azure AD credentials to access Azure file shares.

2. Assign RBAC Roles: Assign appropriate RBAC roles to users, groups, or service principals for the Azure file share. Common roles include Reader, Contributor, and Storage File Data SMB Share Contributor.

3. Create Access Policies: Define access policies that specify the permissions and the duration for which the permissions are valid. This can be done using Shared Access Signatures.

4. Configure NTFS Permissions: If you have enabled Azure AD authentication for Azure Files, you can also set NTFS permissions on the file share to manage access at the file and directory level.

5. Monitor Access: Use Azure Monitor to track access and activities on your Azure file shares. Set up alerts for any unauthorized access attempts.

For additional information on configuring identity-based access for Azure Files, you can refer to the following resources:

• Azure Files documentation
• Azure Active Directory documentation
• Azure RBAC documentation
• Shared Access Signatures documentation

Please note that the URLs provided are for reference purposes and should be accessed for more detailed guidance on the implementation of the above steps.

Implement and manage storage (15–20%)

Configure and manage storage accounts

Create and Configure Storage Accounts

When creating and configuring storage accounts in Azure, it is essential to understand the various options and settings that can be tailored to meet specific business needs. Here is a detailed explanation of the key steps and considerations:

1. Creating an Azure Storage Account:
   • Navigate to the Azure portal and create a new storage account.
   • Select the appropriate subscription and resource group.
   • Choose a unique name for the storage account.
   • Select the region where the account will be hosted.
   • Decide on the performance tier (Standard or Premium) based on the type of storage disks (HDD or SSD).
   • Choose the account kind, such as General-purpose v2, BlobStorage, or BlockBlobStorage, depending on the required features and access tiers[doc1].
2. Configuring Redundancy and Replication:
   • Select the desired redundancy option to ensure data durability and high availability. Options include Locally Redundant Storage (LRS), Zone-Redundant Storage (ZRS), Geo-Redundant Storage (GRS), and Read-Access Geo-Redundant Storage (RA-GRS).
   • Consider implementing disaster recovery by replicating storage data across regions and configuring failover to a secondary location[doc1].
3. Access Tiers:
   • Choose between Hot, Cool, or Archive access tiers based on how frequently the data will be accessed. Hot is for frequently accessed data, Cool for infrequently accessed data, and Archive for rarely accessed data[doc4].
4. Container Creation:
   • Within the storage account, create containers to organize blobs. Containers act like folders that hold blobs, which are the files stored in Azure Blob Storagedoc2.
5. Security and Access:
   • Configure secure access to the storage account using Azure Private Link and virtual network service endpoints to limit access to authorized networks[doc1].
   • Manage authentication and authorization by generating Shared Access Signatures (SAS) for limited time access[doc4].
   • Limit access to the storage account from specific IP addresses to enhance security[doc4].
6. Custom Domains:
   • Set up a custom domain for accessing blob data, which allows users to use a familiar domain name instead of the default Azure endpoint.
   • Implement Azure Content Delivery Network (CDN) if HTTPS access is required with the custom domain[doc5].
7. Monitoring and Management:
   • Utilize Azure monitoring tools to track usage and access patterns.
   • Regularly review and adjust configurations to optimize costs and performance.

For additional information and step-by-step guidance on creating and configuring Azure Storage accounts, refer to the following resources: - Create an Azure storage account (sandbox) - Design and implement private access to Azure Services - Provide disaster recovery by replicating storage data across regions and failing over to a secondary location - Configure a custom domain for Azure Blob Storage

By following these steps and considerations, you can effectively create and configure Azure Storage accounts to support a variety of data storage needs.

Implement and manage storage (15–20%)

Configure and manage storage accounts

Configure Azure Storage Redundancy

Azure Storage redundancy is a critical feature that ensures the durability and high availability of data. It protects against data loss by replicating the data across different storage units within a data center, across data centers, or even across geographical regions. Here’s a detailed explanation of how to configure Azure Storage redundancy:

1. Understand Redundancy Options: Azure Storage offers several redundancy options, each providing a different level of data protection and availability. The options include:

   • Locally redundant storage (LRS): Replicates your data three times within a single physical location in the primary region.
   • Zone-redundant storage (ZRS): Replicates your data across three Azure availability zones in the primary region.
   • Geo-redundant storage (GRS): Replicates your data to a secondary region (hundreds of miles away from the primary region) after it has been replicated three times in the primary region.
   • Geo-zone-redundant storage (GZRS): Combines the features of GRS and ZRS by replicating data across three Azure availability zones in the primary region and then to a secondary regiondoc2.

2. Selecting Redundancy Option: When creating a storage account, you can select the desired redundancy option based on your business requirements for availability, durability, and cost. The choice should be made considering the trade-offs between these factors[doc1].

3. Configuring Redundancy: To configure redundancy for an existing storage account, navigate to the ‘Redundancy’ section of the storage account in the Azure portal. Here, you can change the redundancy option. Note that changing from a less durable to a more durable redundancy option (e.g., from LRS to GRS) is allowed, but the reverse may not be supported[doc1].

4. Cost Considerations: The cost of redundancy varies depending on the option chosen. Geo-redundant options are more expensive than locally redundant options due to the additional storage and data transfer costs involved in replicating data to a secondary region.

5. Data Recovery: In the event of a failure, Azure Storage automatically manages the failover process. For GRS and GZRS, if the primary region becomes unavailable, you can perform a failover to the secondary region. After the failover, the secondary region becomes the primary, and you can continue to access your datadoc2.

For additional information on Azure Storage redundancy, you can refer to the following resources: - Azure storage redundancy - Storage account overview

By understanding and configuring Azure Storage redundancy, you can ensure that your data remains safe and accessible, even in the face of hardware failures or natural disasters.

Implement and manage storage (15–20%)

Configure and manage storage accounts

Configure Object Replication in Azure Blob Storage

Object replication in Azure Blob Storage is a process that allows you to copy blobs asynchronously from a source container to a destination container within the same or different storage accounts. This feature is essential for scenarios requiring data redundancy, accessibility, and geographical distribution of content. Here’s a detailed explanation of how to configure object replication:

Prerequisites for Object Replication

• Blob Versioning: Ensure that blob versioning is enabled on both the source and destination storage accounts[doc1].
• Snapshot Support: Note that blob snapshots are not supported. Snapshots in the source account will not be replicated[doc1].
• Access Tiers: Object replication can occur when the source and destination accounts are in the Hot, Cool, or Cold access tiers. They can be in different tiers[doc1].

Steps to Configure Object Replication

1. Create a Replication Policy: A replication policy is created within the Azure portal, specifying the source and destination storage accounts[doc1].
2. Define Rules in the Policy: The policy includes rules that define which source container’s blobs should be replicated to which destination container[doc1].
3. Select Blobs for Replication: The policy identifies specific blobs in the source container to be replicated based on filters or a complete container[doc1].

What Gets Replicated?

• Blob Contents: The actual data contained within the blob is replicateddoc2.
• Metadata and Properties: The blob’s metadata and properties are also copied to the destinationdoc2.
• Blob Versions: Any versions of the blob data are replicated, provided versioning is enabled.

Benefits of Object Replication

• Redundancy: Provides data redundancy for disaster recovery scenarios[doc3].
• Reduced Latency: Enhances data access by reducing latency for read requests in different geographical regions[doc3].
• Efficiency: Improves efficiency for compute workloads by processing the same sets of blobs in different regions[doc4].

Additional Resources

For more information on configuring object replication in Azure Blob Storage, you can refer to the following resources: - Azure Blob Storage documentation: Azure Blob Storage Documentation - Object replication overview: Object Replication in Azure Blob Storage

By understanding and implementing object replication, you can ensure that your data is more resilient, accessible, and efficiently managed across different regions. This feature is a key component of a comprehensive Blob Storage strategy and can significantly contribute to the optimization of your storage solutions in the cloud.

Implement and manage storage (15–20%)

Configure and manage storage accounts

Configure Storage Account Encryption

When configuring encryption for an Azure storage account, you have two primary options for managing the encryption keys: customer-managed keys and Microsoft-managed keys.

Customer-Managed Keys

With customer-managed keys, you gain more control and flexibility over the encryption process:

• Creation and Management: You can create your own keys, which allows you to manage the lifecycle of the keys including creation, rotation, and deletion[doc1].
• Access Controls: You have the ability to define and audit access controls for your encryption keys, ensuring that only authorized users or applications can use them[doc1].
• Integration with Azure Storage: Customer-managed keys can be integrated with Azure Storage encryption. You can either generate a new key or use an existing one from your key vault. It’s important to note that the Azure storage account and the key vault must be located in the same region, although they can belong to different subscriptions[doc1].

For more information on customer-managed keys and how to implement them, you can visit the following resources: - Customer-managed keys for Azure Storage encryption

Microsoft-Managed Keys

Alternatively, you can opt for Microsoft-managed keys where Microsoft handles the key management:

• Simplicity: This option is simpler as it does not require you to manage the key lifecycle. Microsoft will manage the keys, including their rotation and security[doc3].
• Automatic Encryption: All data written to Azure Storage is automatically encrypted using Azure Storage encryption, which by default uses Microsoft-managed keys[doc5].

For additional details on Microsoft-managed keys and Azure Storage encryption, refer to the following links: - Azure Storage encryption for data at rest

Shared Access Signatures (SAS)

While configuring encryption, it’s also essential to understand how to grant limited access to Azure Storage resources securely:

• SAS Tokens: Shared Access Signatures (SAS) allow you to grant limited access to your storage account or specific resources within it. You can create account-level SAS, service-level SAS, or user delegation SAS[doc4].

For guidance on creating and using SAS tokens, explore these resources: - Grant limited access to Azure Storage resources with shared access signatures - Create a SAS for your Azure storage account - Create a service-level SAS - Construct a user delegation SAS

By understanding and implementing these encryption and access control mechanisms, you can ensure that your Azure Storage account is secure and compliant with your organization’s policies and regulatory requirements.

Implement and manage storage (15–20%)

Configure and manage storage accounts

Managing Data with Azure Storage Explorer and AzCopy

Azure Storage Explorer and AzCopy are essential tools for managing data in Azure Storage. Below is a detailed explanation of how these tools can be used effectively.

Azure Storage Explorer

Azure Storage Explorer is a graphical user interface (GUI) tool that allows users to manage Azure Storage data across different subscriptions. It provides a convenient way to work with Azure blobs, files, queues, tables, and Cosmos DB entities. Here are some key points about Azure Storage Explorer:

• Graphical User Interface: It offers a user-friendly interface for those who prefer not to use the Azure portal for data access.
• Integration with AzCopy: Azure Storage Explorer utilizes the AzCopy tool for data transfers, combining the ease of a GUI with the performance benefits of AzCopydoc2.
• Account Key Operations: After signing in, Azure Storage Explorer uses your account key to perform operations without requiring you to re-enter authorization credentialsdoc2.

AzCopy

AzCopy is a command-line utility designed for high-performance copying of data to and from Azure Blob Storage and Azure Files. It is suitable for transferring large volumes of data and offers several features to streamline the process:

• Job Orders and Log Files: Each AzCopy instance creates a job order and a log file, allowing users to track, restart, or resume jobs as needed[doc4].
• File Management: Users can list or remove files or blobs, with support for wildcard patterns and include/exclude flags[doc4].
• Automatic Retries: AzCopy automatically retries transfers when failures occur, ensuring reliability[doc4].
• Account-to-Account Copy: It enables copying of an entire storage account to another without transferring data to the client[doc4].
• Support for Data Lake Storage Gen2: AzCopy is compatible with Azure Data Lake Storage Gen2 APIs[doc4].
• Cross-Platform Availability: AzCopy is available on Windows, Linux, and macOS[doc4].
• Next-Generation CLI: AzCopy v10 features a redesigned command-line interface and new architecture for reliable data transfers[doc5].

Usage Scenarios

• Data Transfer: Both tools are ideal for moving data, especially large amounts. AzCopy can run as a background process, making it suitable for bulk data transfer[doc1].
• Data Import/Export: For importing large amounts of data securely to Azure Blob Storage and Azure Files, the Azure Import/Export service can be used in conjunction with these tools[doc1].
• Data Management: Azure Storage Explorer is particularly useful for users who need to manage their data visually, while AzCopy provides a robust command-line experience for automation and scripting[doc3].

Additional Resources

For more information on Azure Storage Explorer and AzCopy, you can refer to the following resources:

• Azure Storage Explorer documentation
• Get started with AzCopy

By understanding and utilizing Azure Storage Explorer and AzCopy, users can efficiently manage their data in Azure Storage, catering to a variety of data transfer and management needs.

Implement and manage storage (15–20%)

Configure Azure Files and Azure Blob Storage

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

1. Determine the Appropriate Storage Account Type:
   • Choose a Standard general-purpose v2 storage account for most scenarios, including file shares[doc5].
   • For enterprise or high-performance scale applications, consider a Premium file shares account, which supports both SMB and NFS file shares[doc5].
2. Create a Storage Account:
   • Navigate to the Azure portal and create a new storage account, selecting the appropriate performance tier (Standard or Premium) based on your needs[doc5].
3. Create a File Share:
   • In the storage account, go to the “File shares” section and click on “File share” to create a new share[doc1].
   • Specify the name for the file share and, if necessary, adjust the quota to limit the size of the file share[doc1].
4. Configure Access and Permissions:
   • Use the storage account credentials to provide authentication for access to the file share[doc3].
   • Set the desired access level, ensuring that all users who need to access the file share have the appropriate read/write permissions[doc3].
5. Implement Azure File Sync (Optional):
   • If you need to cache Azure Files shares on an on-premises Windows Server or cloud virtual machine, implement Azure File Sync[doc1].
   • Install the Azure File Sync agent on the Windows Server and configure the sync group and cloud endpoint[doc4].
6. Access the File Share:
   • Access the file share using the SMB or NFS protocol, depending on your configuration[doc3].
   • Mount the file share to the same drive letter that the on-premises application uses for seamless integration[doc3].
7. Manage and Monitor the File Share:
   • Configure Azure Files shares and file share snapshots for data protection[doc1].
   • Monitor the usage and performance of the file share, and adjust settings as necessary.

By following these steps, you can create and configure a file share in Azure Storage that is tailored to your application’s requirements. For additional information and detailed instructions, refer to the Azure documentation on general-purpose v2 storage accounts, Premium file shares, and Azure File Sync.

Please note that the URLs provided are for reference and further reading. They should be accessed to obtain more detailed guidance and step-by-step instructions on the creation and configuration of file shares in Azure Storage.

Implement and manage storage (15–20%)

Configure Azure Files and Azure Blob Storage

Create and Configure a Container in Blob Storage

When working with Azure Blob Storage, one of the fundamental tasks is to create and configure a container. A container serves as a unit to organize your blobs, which are the files you store in Azure Blob Storage. Below is a step-by-step guide to creating and configuring a container:

1. Create a Storage Account:
   • Before you can create a container, you need an Azure storage account. This account should be created in your region and configured with locally redundant storage for durabilitydoc2.
2. Access the Azure Portal:
   • Navigate to the Azure portal to manage your storage account and create a container within it[doc1].
3. Create a Container:
   • Within your storage account, you can create a new container. Containers are used to store and organize your blobs[doc3].
   • You can create the container directly in the Azure portal, providing a name for the container and setting the level of public access[doc3].
4. Configure Container Settings:
   • Decide on the level of access you want to grant to the container. You can create a private blob container to restrict access, ensuring that only authorized users can access the blobs withindoc2.
   • Configure additional settings such as Blob Storage access tiers, which can affect the cost and availability of the stored data[doc4].
5. Upload Files to the Container:
   • Once the container is created, you can upload files to it. These files are referred to as blobs and can be any type of text or binary data, such as documents, images, or videos[doc4].
6. Monitor and Manage the Container:
   • After setting up your container and uploading blobs, it’s important to monitor the storage container for performance, availability, and capacitydoc2.
   • Review common storage problems and troubleshooting guides to maintain the health of your Blob Storagedoc2.
7. Consider Object Replication:
   • If you need to replicate blobs across storage accounts, consider enabling object replication. This requires blob versioning to be enabled on both the source and destination accounts[doc5].
   • Create a replication policy that specifies the source and destination storage accounts, as well as the containers involved in the replication[doc5].

For additional information on configuring Blob Storage and containers, you can refer to the following resources: - Configure Azure Blob Storage - Blob Storage Documentation

Please note that the URLs provided are for reference purposes to supplement the study guide material.

Implement and manage storage (15–20%)

Configure Azure Files and Azure Blob Storage

Configure Storage Tiers

When configuring storage tiers in Azure Blob Storage, it is essential to understand the different tiers available and how they can be utilized to optimize performance and cost based on the data usage patterns.

Overview of Storage Tiers

Azure Blob Storage offers four access tiers:

1. Hot Tier: This tier is optimized for frequent access to objects in the storage account. It is ideal for data that is actively being processed and has the lowest access costs, although the storage costs are higher compared to the Cool and Archive tiers[doc1].

2. Cool Tier: Suitable for data that is infrequently accessed, the Cool tier offers lower storage costs than the Hot tier but has higher access costs. It is a good choice for data that will not be accessed frequently but needs to be retained for a short period[doc1].

3. Archive Tier: The Archive tier is designed for data that is rarely accessed and can tolerate several hours of retrieval latency. It provides the lowest storage cost but has the highest access costs and is suitable for long-term storage of data that is seldom accessed[doc1].

4. Premium Tier: This tier is not explicitly mentioned in the retrieved documents but is generally used for high-performance requirements and offers the highest transaction rates.

Configuring Lifecycle Management

To manage costs and maintain optimal performance, Azure Blob Storage allows you to configure lifecycle management policies. These policies can automatically transition data between access tiers and set expiration times for data, ensuring that data is stored in the most cost-effective manner without manual interventiondoc2.

For example, you can create a rule to move data from the Hot tier to the Cool tier after 30 days of inactivity, and then to the Archive tier after 180 days. This ensures that data is stored in the most cost-efficient tier based on how often it is accessed[doc4].

Object Replication

In addition to lifecycle management, object replication can be configured to asynchronously copy blobs between containers in different regions. This provides redundancy and can reduce latency for read requests, ensuring that data is readily available when neededdoc2.

Considerations

When choosing the appropriate storage tier, consider the following:

• The frequency of data access: Hot for active data, Cool for less frequent access, and Archive for rarely accessed data.
• The cost implications: Hot has higher storage costs but lower access costs, while Cool and Archive have lower storage costs but higher access costs[doc1][doc5].
• The performance requirements: Premium for high transaction rates, Hot for frequent access, and Cool or Archive for less critical performance needs.

For additional information on Azure Blob Storage and configuring storage tiers, you can visit the following URL: Azure Blob Storage Documentation.

By understanding and utilizing these storage tiers effectively, you can ensure that your Azure Blob Storage is configured to provide the best balance between cost and performance for your specific data usage patterns.

Implement and manage storage (15–20%)

Configure Azure Files and Azure Blob Storage

Configure Snapshots and Soft Delete for Azure Files

Azure Files offers the capability to create snapshots of file shares, which are point-in-time, read-only copies of data. These snapshots can be used to protect against application errors, data corruption, accidental deletions, or unintended changes. They serve as an incremental backup solution, allowing users to recover previous versions of files or entire file shares[doc4][doc5].

Benefits of Using File Share Snapshots:

• Protection Against Application Error and Data Corruption: Before deploying new application code, take a snapshot to safeguard against potential bugs or misconfigurations that could lead to data corruption or overwrite[doc5].
• Recovery from Accidental Deletions or Unintended Changes: If a file is accidentally renamed or deleted, snapshots can be used to recover previous versions of the file[doc5].
• Support for Backup and Recovery: Regularly scheduled snapshots can serve as a backup for audit requirements or disaster recovery, maintaining historical data versions[doc5].

Configuring Snapshots for Azure Files:

1. Navigate to the Azure portal and select the file share you want to snapshot.
2. Choose the ‘Snapshot’ option to create a point-in-time copy of the file share.
3. Manage snapshots by listing them, copying them, or promoting a snapshot to the base file share if needed.

Soft Delete for Azure Files:

Soft delete is a feature that allows for the recovery of blob objects in Azure Storage when they are modified or deleted. When soft delete is enabled, even after the file share is deleted, it is preserved in a soft-delete state for a specified period (up to 14 days by default)[doc3].

Benefits of Soft Delete:

• Protection of Backup Data: Soft delete helps protect backups from unintended deletion, preserving them for an additional period even after deletion[doc3].
• Recovery Assurance: Ensures that deleted backup data can be recovered, providing an extra layer of protection against data loss[doc3].

Configuring Soft Delete for Azure Files:

1. Go to the Azure portal and select the storage account where your file share resides.
2. Under ‘Data Protection’, find the ‘Soft Delete’ option and enable it.
3. Set the retention period for how long the deleted data should be recoverable.

Additional Resources:

• For more information on configuring snapshots for Azure Files, visit Azure Files Snapshot Documentation.
• To learn more about soft delete and how to enable it, refer to Soft Delete for Azure Blob Storage.

By implementing snapshots and soft delete for Azure Files, you can enhance the data protection and recovery capabilities of your Azure storage solution. These features are essential for maintaining data integrity and availability in the cloud.

Implement and manage storage (15–20%)

Configure Azure Files and Azure Blob Storage

Configure Blob Lifecycle Management

Azure Blob Storage is an essential service for storing large volumes of unstructured data in the cloud. It is optimized for storing data such as text documents, images, and videos. One of the key features of Azure Blob Storage is its lifecycle management capabilities, which allow you to automate the transition and expiration of data based on predefined rules[doc3].

Understanding Lifecycle Management

Lifecycle management in Azure Blob Storage is a policy-based system that enables you to:

• Transition blobs to a cooler storage tier (Hot to Cool, Hot to Archive, Cool to Archive) to optimize for performance and costdoc2.
• Delete blobs that are no longer needed, at the end of their lifecycledoc2.
• Define conditions that are evaluated once per day at the storage account level, applying these rules to containers or a subset of blobsdoc2.

Setting Up Lifecycle Management Policy Rules

To configure lifecycle management for your Azure Blob Storage, you need to create policy rules in the Azure portal. These rules consist of If - Then block conditions that specify when and how your data should transition between tiers or be deleted[doc1].

Here are the steps to set up lifecycle management policy rules:

1. Navigate to your Azure storage account in the Azure portal.
2. Access the ‘Lifecycle Management’ section under ‘Blob Service’.
3. Create a new rule by defining the If - Then conditions. For example:
   • If: A blob has not been accessed for 30 days.
   • Then: Transition the blob to the Cool tier.
4. You can also set rules to delete blobs after a certain period. For example:
   • If: A blob has been in the Archive tier for 365 days.
   • Then: Delete the blob.
5. Save the rule and it will be executed once per day, automatically managing your blobs according to the conditions set[doc1].

Additional Resources

For more detailed information and guidance on configuring and managing Azure Blob Storage, including lifecycle management, you can refer to the following resources:

• Azure Blob Storage documentation - Provides comprehensive information on configuring and managing blob storage[doc4].
• Azure Blob Storage Concepts - Offers an overview of key concepts related to Azure Blob Storage[doc4].
• Azure Blob Storage Security - Covers authentication, authorization, and encryption options for securing your blob storage[doc4].
• Azure Blob Storage Performance and Scalability - Discusses performance considerations for blob storage configuration[doc4].
• Azure Blob Storage Lifecycle Management - Explains how to configure and manage lifecycle policies[doc4].

By implementing lifecycle management policies, you can ensure that your data is stored efficiently, reducing costs and maintaining optimal performance throughout the data’s lifecycle[doc3][doc5].

Implement and manage storage (15–20%)

Configure Azure Files and Azure Blob Storage

Configure Blob Versioning

Blob versioning in Azure Blob Storage is a feature that allows you to maintain previous versions of an object automatically. When blob versioning is enabled, it provides a way to access earlier versions of a blob, which can be crucial for data recovery in case of accidental modifications or deletions.

To configure blob versioning, follow these steps:

1. Enable Blob Versioning: You must enable blob versioning on your storage account. This can be done through the Azure portal, Azure CLI, or Azure PowerShell.

2. Access Earlier Versions: Once blob versioning is enabled, each time a blob is modified or deleted, a new version is created. You can access these versions using version IDs.

3. Lifecycle Management: You can set up lifecycle management policies to automate the transition of old blob versions to cooler storage tiers or delete them after a certain period.

4. Considerations:

   • Blob versioning needs to be enabled on both the source and destination accounts if you plan to use object replication.
   • Blob snapshots are not supported with object replication; only blob versions are replicated.
   • The source and destination accounts can be in different storage tiers (Hot, Cool, or Cold).

For additional information and detailed guides on configuring and managing blob versioning, you can refer to the following resources:

• Azure Blob Storage documentation provides comprehensive information on configuring and managing blob storage, including blob versioning.
• Azure Blob Storage Lifecycle Management explains how to configure and manage lifecycle policies for blob versioning.

By enabling and configuring blob versioning, you ensure that your data is protected against accidental changes and deletions, providing a robust solution for data recovery and managementdoc1[doc4].

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

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

Interpretation of an Azure Resource Manager Template or a Bicep File

When interpreting an Azure Resource Manager (ARM) template or a Bicep file, it is essential to understand that both are used to define the infrastructure and configuration for your Azure resources in a declarative manner. Here’s a detailed explanation of each:

Azure Resource Manager Templates

ARM templates are JSON files that define the resources you need to deploy for your solution. To interpret an ARM template, you should be familiar with the following concepts:

• JSON Syntax: ARM templates are written in JSON, which is a lightweight data-interchange format. It is important to understand the structure of JSON, including objects, arrays, and key-value pairs[doc4].

• Template Structure: An ARM template contains several sections such as parameters, variables, resources, and outputs. Each section serves a specific purpose in the deployment process[doc4].

  • $schema: Specifies the location of the JSON schema file that describes the version of the template language[doc4].
  • contentVersion: A version number for the template itself.
  • parameters: Optional values provided at deployment time to customize the deployment[doc4].
  • variables: Reusable JSON fragments within the template[doc4].
  • resources: The Azure resources to be deployed or updated[doc4].
  • outputs: Values returned after the deployment, often used for debugging or passing data to subsequent deployments[doc4].

• Deployment: Deploying an ARM template is a single operation that can create or update a complete set of resources in an Azure resource groupdoc2.

Bicep Files

Bicep is a domain-specific language (DSL) that acts as a transparent abstraction over ARM templates, providing a more concise syntax:

• Bicep Syntax: Bicep uses a simpler, cleaner syntax compared to the verbose JSON used in ARM templates. It is designed to make the code more readable and easier to write[doc1].

• Type Safety and Reusability: Bicep provides reliable type safety and supports code reuse, which can help prevent errors and improve the efficiency of your infrastructure as code practices[doc1].

• Transpilation: Bicep tooling converts Bicep files into ARM template JSON during deployment. This process is known as transpilation, and it ensures that Bicep maintains all capabilities of ARM templates[doc5].

Additional Resources

To further your understanding of ARM templates and Bicep files, consider exploring the following resources:

• Azure Bicep Overview: Learn more about Bicep, its syntax, and its advantages over traditional JSON templates[doc1].
• Azure Resource Manager Template Documentation: Comprehensive documentation on ARM templates, including their structure and how to author them[doc3].
• Azure Quickstart Templates: A repository of templates to quickly start deploying Azure resources[doc3].
• Deploy Azure Infrastructure Using JSON ARM Templates (Sandbox): A hands-on exercise to practice deploying Azure infrastructure using ARM templates[doc3].
• Build Your First Bicep Template (Sandbox): A guided exercise to help you create your first Bicep template[doc3].

By understanding the structure and syntax of ARM templates and Bicep files, you can effectively interpret and create templates to automate the deployment of Azure resources.

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

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

Modify an Existing Azure Resource Manager Template

When working with Azure Resource Manager templates, you may find the need to modify an existing template to suit new requirements or to update resources. Here’s a step-by-step guide on how to approach this task:

1. Understand the Template Structure: Before making any changes, familiarize yourself with the structure of the ARM template. An ARM template is a JSON file that defines the infrastructure and configuration for your project. The template has five main sections: $schema, contentVersion, parameters, variables, resources, and outputs[doc1].

2. Retrieve the Current Template: Obtain the current ARM template that you wish to modify. This could be from your source control repository or exported from existing Azure resources.

3. Edit the Template: Open the ARM template in your preferred JSON editor. You can modify the template directly in JSON or use Azure Bicep, a domain-specific language that simplifies the authoring experience[doc1].

4. Parameters and Variables: Adjust the parameters and variables sections to change the input values and any dynamic content used within the template. Parameters allow you to input custom values each time you deploy the template, while variables are used to simplify complex expressions within the template.

5. Resource Modifications: In the resources section, make the necessary changes to the resource definitions. This could involve adding new resources, removing existing ones, or updating resource properties.

6. Validate the Template: After making changes, validate the template to ensure there are no syntax errors. You can use tools like the Azure portal, Azure PowerShell, or Azure CLI to validate ARM templates.

7. Test the Deployment: Before applying the changes to a production environment, deploy the modified template to a test environment. This helps to catch any issues with the deployment logic or resource configuration.

8. Review and Document Changes: Document the changes made to the template for future reference and for team members. Include comments in the template to explain complex logic or important modifications.

9. Update Parameter Files: If you have separate parameter files (azuredeploy.parameters.json), ensure they are updated to match the changes made in the templatedoc2.

10. Commit Changes: Once the modified template has been validated and tested, commit the changes to your source control repository to maintain version history.

For additional information and resources on working with Azure Resource Manager templates, you can refer to the following URLs:

• Azure Resource Manager template documentation: ARM Template Documentation
• Azure Quickstart Templates: Azure Quickstart Templates
• Deploy Azure infrastructure using JSON ARM templates: Deploy Azure Infrastructure with ARM Templates
• Create Azure resources using ARM templates: Create Resources with ARM Templates
• Build your first Bicep template: Build Your First Bicep Template

By following these steps and utilizing the provided resources, you can effectively modify an existing Azure Resource Manager template to meet your evolving infrastructure needs.

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

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

To modify an existing Bicep file, you will need to understand the structure and syntax of Bicep as well as the resources you intend to manage within your Azure environment. Here is a step-by-step guide to help you with the process:

1. Understand Bicep Syntax: Bicep is a domain-specific language that simplifies the authoring of Azure Resource Manager templates. It uses a declarative syntax that is more concise and easier to read than JSON[doc1].

2. Review the Existing Bicep File: Open the Bicep file you wish to modify in a text editor or integrated development environment (IDE) that supports Bicep. Examine the resources, parameters, variables, and outputs defined in the file.

3. Make Changes to Resources: To modify a resource, locate its declaration in the Bicep file. You can change properties such as size, location, or tags. Bicep allows you to reference parameters and variables directly, and you can use string interpolation for combining values[doc3].

4. Add or Remove Resources: If you need to add new resources, you can do so by defining a new resource block with the required properties. To remove a resource, delete the corresponding resource block from the Bicep file.

5. Manage Dependencies: Bicep automatically detects dependencies between resources, which can simplify the modification process. Ensure that any new resources you add have the correct dependencies defined if they are not automatically detected[doc4].

6. Validate the Bicep File: After making changes, it’s important to validate the Bicep file to ensure there are no syntax errors. You can use the Bicep CLI or Azure PowerShell to validate the file.

7. Transpile Bicep to JSON: Before deploying your changes, the Bicep file must be transpiled into a JSON template. This is done automatically by the Bicep tooling when you deploy the template to Azuredoc2.

8. Deploy the Changes: Use the Azure CLI, Azure PowerShell, or the Azure portal to deploy the modified Bicep file. The deployment will update the Azure resources as defined in your Bicep file.

For additional information on Bicep, you can refer to the following resources: - Bicep Overview: Azure Bicep Overview - Bicep GitHub Repository: Bicep GitHub - Bicep Documentation: Bicep Documentation

Remember to test your changes in a non-production environment before applying them to your live resources. This will help you catch any potential issues and ensure that your deployment goes smoothly.

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

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

Deploying Resources with Azure Resource Manager Templates and Bicep Files

When deploying resources in Azure, you have the option to use Azure Resource Manager templates or Bicep files. Both methods are designed to implement infrastructure as code, which allows for consistent and repeatable deployments.

Azure Resource Manager Templates

Azure Resource Manager templates are JSON files that define the infrastructure and configuration for your Azure solutions. They use a declarative syntax, meaning you specify what you intend to deploy without writing the sequence of commands to create it. The advantages of using Azure Resource Manager templates include:

• Declarative Syntax: Clearly define what you want to deploy without the need to script the deployment process[doc3].
• Resource Group Deployment: Deploy into a resource group as a single operation, which can include all the necessary Azure service resources[doc5].
• Repeatability and Speed: Make deployments faster and more repeatable, avoiding the need to manually create resources one by one[doc5].

For more information and documentation on Azure Resource Manager templates, you can visit: - Azure Resource Manager template documentation[doc1]. - Azure Quickstart Templates[doc1]. - Deploy Azure infrastructure using Azure Resource Manager templates (Sandbox)[doc1]. - Create Azure resources using Azure Resource Manager templates[doc1].

Bicep Files

Bicep is a domain-specific language (DSL) that simplifies the authoring of Azure Resource Manager templates. It is an abstraction over the underlying ARM template JSON, which means it provides the same capabilities but with a more concise and readable syntax. The benefits of using Bicep include:

• Concise Syntax: Bicep reduces the complexity of JSON syntax in ARM templates, making it easier to read and writedoc2.
• Type Safety: Offers reliable type safety to help catch errors during developmentdoc2.
• Code Reuse: Supports modules for code reuse, allowing you to define and deploy resources more efficientlydoc2.

For additional details on Bicep, including tutorials and documentation, refer to: - Azure Bicep overviewdoc2. - Build your first Bicep template (Sandbox)[doc1].

By utilizing Azure Resource Manager templates or Bicep files, you can streamline the deployment of Azure resources, ensuring that your infrastructure is deployed consistently and efficiently.

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

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

Exporting a Deployment as an Azure Resource Manager Template

Azure Resource Manager templates are JSON files that define the resources you need to deploy for your solution. When you have an existing deployment in Azure, you can export the current state of your resources to a template. This template can then be used to replicate the deployment or to manage infrastructure as code.

To export a deployment:

1. Navigate to the Azure portal.
2. Select the resource group containing the deployment you want to export.
3. Click on the “Deployments” option to see a list of deployments.
4. Choose the deployment you wish to export.
5. Click on the “Export template” option.
6. The portal will display the template JSON. You can download it or copy it to your clipboard.

For more information on Azure Resource Manager templates, you can visit the Azure Resource Manager template documentation.

Converting an Azure Resource Manager Template to a Bicep File

Bicep is a domain-specific language for deploying Azure resources that aims to simplify the authoring experience and provide a cleaner syntax. It is an abstraction over Azure Resource Manager JSON templates and does not lose any of the capabilities of ARM templates.

To convert an ARM template to a Bicep file:

1. Install the Bicep CLI tool on your machine. Instructions can be found on the Bicep GitHub repository.

2. Use the Bicep CLI to decompile the ARM template JSON file to a Bicep file using the following command:

   bicep decompile <your-template>.json

3. The Bicep CLI will generate a .bicep file with the same declarative structure as the ARM template but in the Bicep syntax.

For a hands-on exercise and more information on Bicep, you can refer to the Build your first Bicep template (Sandbox).

By using these methods, you can effectively manage your Azure infrastructure as code, making your deployments more repeatable and maintainable.

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

Create and configure virtual machines

Creating a virtual machine (VM) in Azure involves several steps that ensure the VM is configured according to your requirements. Here’s a detailed explanation of the process:

1. Access the Azure Portal: Begin by signing in to the Azure Portal, which is the web-based user interface for managing Azure services.

2. Navigate to Virtual Machines: Once logged in, navigate to the “Virtual Machines” section to start the process of creating a new VM.

3. Basics Tab Configuration:

   • Project Details: Select the appropriate subscription and resource group for your VM.
   • Instance Details: Provide a name for your VM, choose the region where it will be hosted, and select the desired availability options.
   • Administrator Account: Set up the username and password or SSH key that will be used to access the VM.
   • Inbound Port Rules: Define the network security rules for incoming traffic, such as allowing specific ports for remote access (e.g., RDP for Windows or SSH for Linux)[doc5].

4. Disks Tab Configuration:

   • OS Disk: Choose the type of operating system disk (HDD or SSD) and select the operating system image.
   • Data Disks: Attach additional disks if needed for storage purposes[doc5].

5. Networking Tab Configuration:

   • Virtual Network: Create a new virtual network or connect to an existing one. Add subnets if necessary.
   • Public IP: Assign a public IP address if the VM needs to be accessible from the internet. Ensure to configure the IP address settings to be static if you require the IP to remain constant over time[doc1][doc5].

6. Management Tab Configuration:

   • Monitoring: Enable monitoring and diagnostics features to keep track of the VM’s performance and health.
   • Auto-shutdown: Set up an auto-shutdown schedule to reduce costs by automatically turning off the VM during non-working hours.
   • Backup: Configure backup options to protect your data against loss[doc5].

7. Advanced Tab Configuration:

   • Extensions: Add any required agents, scripts, or extensions that enhance the functionality or management of the VM[doc5].

8. Finalize and Create:

   • Review all settings and configurations.
   • Click the “Review + create” button to validate your configurations.
   • Once validation passes, click “Create” to deploy your virtual machine.

For additional information on creating a virtual machine in Azure, you can refer to the Azure documentation on virtual machines: Create a virtual machine in Azure.

Please note that the URLs provided are for reference purposes to supplement the study guide and should be accessed for more detailed guidance on each step of the VM creation process.

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

Create and configure virtual machines

Azure Disk Encryption is a critical feature for securing your virtual machines in Azure by encrypting the operating system and data disks. Here’s a detailed explanation of how to configure Azure Disk Encryption:

1. Prerequisites: Before you begin, ensure that you have a running Azure Virtual Machine that you want to encrypt. You should also have an Azure Key Vault set up to store the encryption keys.

2. Azure Key Vault: Azure Disk Encryption utilizes keys and secrets stored in an Azure Key Vault. You can either generate new keys or use existing ones. To create a new key within the Azure Key Vault, navigate to your Key Vault resource, select ‘Keys’ and then ‘Generate/Import’. This key will be used to wrap and unwrap the disk encryption key[doc3].

3. Enabling Encryption:

   • Navigate to the Azure Virtual Machine that you want to encrypt.
   • In the settings pane, select ‘Disks’.
   • Click on the OS disk or any data disks that you want to encrypt.
   • Under ‘Encryption’, select ‘Azure Disk Encryption’.
   • Choose the Key Vault and the Key Encryption Key (KEK) that you want to use for encrypting your disk[doc1].

4. Encryption Process: Once you have selected the Key Vault and KEK, you can initiate the encryption process. Azure Disk Encryption uses the BitLocker feature on Windows VMs and the dm-crypt feature on Linux VMs to provide volume encryption[doc1].

5. Monitoring Encryption Status: After initiating the encryption, you can monitor the status of the encryption process. This can be done from the Azure portal by navigating to the Virtual Machine’s disks and checking the encryption settings.

6. Encryption at Rest: Azure Disk Encryption ensures that all data on the VM’s disks is encrypted at rest using 256-bit AES encryption. This encryption is transparent to the user, and data is automatically decrypted when accessed by authorized users or servicesdoc2.

7. Compliance and Security: By encrypting your disks, you can meet compliance requirements for sensitive data and add an additional layer of security to protect against unauthorized access.

For additional information on configuring Azure Disk Encryption, you can refer to the following resources: - Azure Disk Encryption Overview - Set up Azure Key Vault - Encrypt a Windows or Linux VM

Please note that the URLs provided are for reference purposes and should be accessed for more detailed guidance on the configuration process.

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

Create and configure virtual machines

Moving a Virtual Machine in Azure

When managing Azure virtual machines (VMs), you may encounter scenarios where you need to move a VM to a different resource group, subscription, or region. This process involves several steps and considerations to ensure a smooth transition.

Moving a VM to Another Resource Group or Subscription

To move a VM to another resource group or subscription, you can use the Azure portal, Azure PowerShell, or Azure CLI. The general steps are as follows:

1. Review Move Limitations: Before initiating the move, check for any limitations or considerations that might prevent the VM from being moved. For example, certain resources or configurations may not support movement across subscriptions or resource groups.

2. Prepare the VM: Ensure that the VM is in a stable state. It’s recommended to stop the VM before moving it to avoid any data corruption or loss.

3. Initiate the Move: Navigate to the resource group containing the VM in the Azure portal. Select the VM and use the ‘Move’ option to specify the target resource group or subscription. Confirm the move and monitor the process.

4. Validate the Move: Once the move is complete, validate that the VM is functioning correctly in the new resource group or subscription. Update any policies or role-based access controls (RBAC) as needed.

For detailed instructions, refer to the Azure documentation on moving resources to a new resource group or subscription: - Move resources to new resource group or subscription

Moving a VM to Another Region

Moving a VM to another region is a more complex process, as it involves creating a copy of the VM in the target region. Here are the steps:

1. Assess Regional Availability: Ensure that the VM’s size and services are available in the target region.

2. Create a Snapshot or Backup: Take a snapshot of the VM’s disk or use Azure Backup to create a recovery point.

3. Replicate the VM: Use Azure Site Recovery to replicate the VM to the target region. Alternatively, you can manually copy the VM’s disk to the target region and create a new VM using that disk.

4. Validate and Test: After the replication or manual creation, validate that the new VM in the target region is operational. Test the applications and services running on the VM to ensure they are working as expected.

5. Clean Up: Once the new VM is confirmed to be working, you can decommission the original VM in the source region to avoid incurring additional costs.

For additional information on moving VMs to another region, refer to the following Azure documentation: - Quickstart: Set up disaster recovery to a secondary Azure region for an Azure VM - An overview of Azure VM backup

Remember to consider the networking, storage, and application dependencies when moving a VM. Adjustments may be necessary to ensure that the VM continues to interact correctly with other resources in its new location.

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

Create and configure virtual machines

Manage Virtual Machine Sizes

When managing Azure Virtual Machines (VMs), it is crucial to understand the concept of VM sizes. Azure provides a variety of virtual machine sizes that cater to different combinations of CPU, memory, and storage to suit various workloads. Here’s a detailed explanation of managing virtual machine sizes:

Research Region and Service Availability

Before selecting a VM size, it’s important to research which services and features are available in your desired region. Some VM sizes or storage types may be region-specific[doc1].

Understanding VM Size Options

Azure offers a range of VM sizes, allowing you to choose the right mix of compute, memory, and storage for your needs. These predefined sizes help streamline the selection process by providing balanced configurations for a variety of applicationsdoc2.

Resizing Virtual Machines

Azure’s flexibility allows you to change the VM size to adapt to your evolving needs. If the current hardware configuration is supported by the new size, you can resize your VM. This feature is particularly useful for maintaining agility and elasticity in VM management. However, be cautious when resizing production VMs, as it may require a restart and could lead to temporary outages or configuration changes[doc3].

Selecting the Appropriate Machine Size

To determine the most suitable VM size, consider the workload requirements. Azure offers different memory and storage options tailored to specific VM sizes, which can be matched to the type of workload you intend to run on the machine[doc4].

Configuration Checklist

When configuring a VM, follow this checklist to ensure all aspects are considered:

1. Start with the network configuration.
2. Choose a name for the virtual machine.
3. Decide on the location for the virtual machine.
4. Determine the size of the virtual machine based on your workload.
5. Review the pricing model and estimate your costs.
6. Identify which Azure Storage options to use with the virtual machine.
7. Select an operating system for the virtual machine[doc5].

For additional information on Azure virtual machine sizes and options, you can refer to the official Microsoft documentation on VM sizes: Azure Virtual Machine Sizes[doc4].

By carefully managing virtual machine sizes, you can optimize your Azure resources for performance, cost, and scalability, ensuring that your VMs are well-suited for their intended tasks.

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

Create and configure virtual machines

Manage Virtual Machine Disks

Managing virtual machine disks in Azure involves understanding the storage options available and how to configure them for optimal performance and reliability. Azure Managed Disks simplify disk management by handling the creation, management, and scaling of storage accounts in the background. Here’s a detailed explanation of managing virtual machine disks:

Azure Managed Disks Overview

Azure Managed Disks offer a simplified disk management experience by abstracting the underlying storage accounts. When you provision a Managed Disk, Azure takes care of the rest, including handling storage in the background[doc1]. Managed Disks come in several types, each designed to suit different performance and cost requirements:

• Ultra Solid State Drives (SSD): Highest performance tier suitable for IO-intensive workloads.
• Premium SSD: High-performance tier for production workloads.
• Standard SSD: Cost-effective tier for web servers and lightly used enterprise applications.
• Standard Hard Disk Drives (HDD): Economical tier for backup and non-critical workloadsdoc2.

Disk Performance Tiers

When creating a Managed Disk, you can select the disk size and performance tier (Standard or Premium), depending on your virtual machine’s requirements. Azure will create and manage the disk accordingly[doc1].

Storage Categories

Azure Storage supports three categories of data, which include virtual machine data:

• Virtual Machine Data: This includes disks and files where disks provide persistent block storage for Azure IaaS virtual machines. The number of data disks you can add depends on the virtual machine size, with each data disk having a maximum capacity of 32,767 GB[doc3].

Backup and Recovery

Azure Backup Center supports backing up Azure Virtual Machines, including the backup of Azure-managed disks. This ensures that your virtual machine data is protected and can be recovered in case of data loss or corruption[doc4].

Disk Configuration Process

The Azure portal provides a guided configuration process for creating your virtual machine image, which includes disk configuration:

• Basics Tab: Set project details, administrator account, and inbound port rules.
• Disks Tab: Select the OS disk type and specify your data disks.
• Networking Tab: Configure virtual networks and load balancing.
• Management Tab: Enable auto-shutdown and specify backup details.
• Advanced Tab: Configure agents, scripts, or virtual machine extensions[doc5].

For additional information on Azure Managed Disks and their configuration, you can refer to the following URL: Azure Managed Disks Overview.

By understanding and effectively managing virtual machine disks, you can ensure that your Azure infrastructure is optimized for both performance and cost.

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

Create and configure virtual machines

Deploying Virtual Machines to Availability Zones and Availability Sets

When deploying virtual machines (VMs) in Azure, it is crucial to understand the concepts of availability zones and availability sets to ensure high availability and fault tolerance for your applications.

Availability Zones are unique physical 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. This is because if one zone is compromised, the other continues to function.

Availability Sets are a logical grouping of VMs that allows Azure to understand how your application is built to provide for redundancy and availability. VMs in the same availability set are distributed across multiple physical servers, computer racks, storage units, and network switches. If a hardware or software failure happens within Azure, only a subset of your VMs is impacted and your overall solution remains available and operational.

Deployment Considerations:

• SKU Selection: The SKU type you select determines the number of pool instances allowed and the endpoint configurations supported. The Basic SKU allows up to 300 pools, while the Standard SKU allows up to 1,000 pools[doc1].

• Back-end Pool Configuration: When configuring the back-end pools, you can connect to availability sets, virtual machines, or Azure Virtual Machine Scale Sets. For the Basic SKU, you can select VMs in a single availability set or VMs in an instance of Azure Virtual Machine Scale Sets. For the Standard SKU, you can select VMs or Virtual Machine Scale Sets in a single virtual network, including a combination of VMs, availability sets, and Virtual Machine Scale Sets[doc1].

• Region and Service Availability: It’s important to research region and service availability as some services or Azure Virtual Machines features are available only in certain regions, such as specific VM sizes or storage types[doc3].

Additional Resources:

• For more information on the differences between containers and virtual machines, and when to use each, you can refer to the article Containers versus virtual machines[doc5].

• To learn how to deploy a container instance in Azure using the Azure portal, you can follow the Quickstart: Deploy a container instance in Azure using the Azure portal[doc5].

• For a deeper understanding of container groups in Azure Container Instances and the types of scenarios they enable, read the article Container groups in Azure Container Instances[doc5].

By carefully planning the deployment of VMs to availability zones and availability sets, you can ensure that your applications are resilient to failures and maintain high availability.

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

Create and configure virtual machines

Deploying and configuring Azure Virtual Machine Scale Sets (VMSS) involves several steps to ensure that your virtual machines are set up correctly and can scale according to your application’s needs. Here is a detailed explanation of the process:

Deploying Azure Virtual Machine Scale Sets

1. Choose a Region and Resource Group: Begin by selecting the Azure region where you want to deploy your VMSS and create or choose an existing resource group to organize your Azure resources.

2. Select the VM Instance Size: Decide on the size of the VM instances based on the workload requirements. Azure offers a variety of VM sizes to cater to different scenarios, from general-purpose to compute-optimized instances.

3. Configure Scaling Settings: Define the scaling settings for your VMSS, including the minimum and maximum number of VM instances, default number of instances, and auto-scale rules based on metrics like CPU usage or memory demand.

4. Select and Configure the VM Image: Choose an operating system image from the Azure Marketplace or use a custom image. Configure the VM image with the necessary software and settings for your application.

5. Set Up Network and Load Balancer: Configure the network settings for your VMSS, including virtual network and subnet. Set up an Azure Load Balancer with a front-end IP configuration and back-end pools that include your VMSS instances[doc3].

6. Define Health Probes: Create health probes to monitor the health of VM instances. The load balancer uses these probes to determine which instances can receive new traffic[doc3].

7. Establish Load-Balancing Rules: Determine how incoming traffic should be distributed across the VM instances in your scale set. These rules are based on ports and protocols[doc3].

8. Configure Extensions and Scripts: Use VM extensions to automatically configure VMs as they’re provisioned. Scripts can be used to install software, configure settings, or run tasks.

9. Set Up Autoscaling: Implement autoscaling to automatically increase or decrease the number of VM instances in response to the workload. This ensures that you have enough resources to handle the load while minimizing costs.

10. Review and Create: Review all settings and create the VMSS. Azure will provision the initial instances and set up the infrastructure according to your configurations.

Configuring Azure Virtual Machine Scale Sets

After deployment, you may need to configure or update your VMSS settings:

1. Update Scaling Settings: Adjust the scaling settings as needed based on the actual performance and demand of your application.

2. Manage VM Instances: You can manually increase or decrease the number of instances, or update the VM instances with new images or configurations.

3. Monitor Performance: Use Azure Monitor and Azure Application Insights to track the performance of your VMSS and the applications running on it. Set up alerts for specific metrics to stay informed about the health and performance of your scale set[doc5].

4. Security and Compliance: Apply security and compliance settings, including patching of VMs, configuring firewalls, and monitoring for security threats.

5. Backup and Disaster Recovery: Set up backup and disaster recovery strategies to protect your data and ensure high availability.

For additional information on deploying and configuring Azure Virtual Machine Scale Sets, you can refer to the following resources:

• Azure Virtual Machine Scale Sets documentation: Azure VMSS Documentation
• Azure Load Balancer overview: Azure Load Balancer Documentation
• Azure Monitor and Application Insights: Azure Monitor Documentation

Please note that the URLs provided are for reference purposes and should be accessed for more detailed guidance on each topic.

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

Provision and manage containers in the Azure portal

Create and Manage an Azure Container Registry

An Azure Container Registry is a managed Docker registry service based on the open-source Docker Registry 2.0. It provides a secure location to store and manage your private Docker container images. To create and manage an Azure container registry, you would typically follow these steps:

1. Create the Registry: You can create an Azure container registry instance using the Azure portal, Azure CLI, or Azure Resource Manager templates. When creating the registry, you can choose from different service tiers (Basic, Standard, Premium) depending on your needs for storage and throughput.

2. Authenticate: Before pushing and pulling images to and from the registry, you need to authenticate using the Azure CLI or Docker CLI. Azure Active Directory (AAD) authentication can also be configured for greater security.

3. Push and Pull Images: After authentication, you can push your local Docker images to the Azure container registry using the docker push command and pull images from the registry using the docker pull commanddoc1.

4. Manage Images: You can manage your container images by deleting old images, setting up webhooks for notifications when images are pushed or pulled, and using Azure Container Registry Tasks to build, test, and patch images in the cloud.

5. Automate Builds: Azure Container Registry Tasks can automate Docker builds when you commit code to a source control repository (like GitHub or Azure DevOps), which simplifies the CI/CD pipeline for containerized applications.

6. Secure the Registry: Apply security measures such as enabling the firewall and virtual network, content trust, and dedicated private endpoints. Use role-based access control (RBAC) to manage permissions for users and services that interact with the registry.

7. Monitor and Audit: Use Azure Monitor to track the usage and performance of the container registry, and Azure Security Center for continuous security assessment and threat protection.

For additional information on Azure Container Registry, you can refer to the following resources:

• Introduction to Azure Container Registry
• Quickstart: Create an Azure container registry using the Azure portal
• Authenticate with an Azure container registry
• Azure Container Registry Tasks
• Securing an Azure Container Registry

By following these steps and utilizing the provided resources, you can effectively create and manage an Azure container registry as part of your containerization strategy.

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

Provision and manage containers in the Azure portal

Provisioning a Container Using Azure Container Instances

Azure Container Instances (ACI) offers a straightforward way to run a container in Azure without having to manage servers. ACI provides a serverless experience and is an ideal choice for any scenario that can operate in isolated containers, including simple applications, task automation, and build jobs.

To provision a container using Azure Container Instances, follow these general steps:

1. Choose a Docker Image: Select an appropriate Docker image for your container. This can be an image from a public registry like Docker Hub or a private registry such as Azure Container Registry[doc3].

2. Create a Container Instance: Deploy your container by creating a new instance in Azure. You can do this using the Azure portal, Azure CLI, or Azure Resource Manager templates. When creating the instance, you will need to configure settings such as the container name, image source, resource allocation (CPU, memory), and restart policies[doc2][doc3][doc4].

3. Set Environment Variables: Environment variables can be used to pass configuration data into your container. These can be set during the creation of the container instance and are accessible by the application running inside the containerdoc2.

4. Configure Networking: Assign a DNS name label to create a fully qualified domain name (FQDN) for your container. This allows you to access the application hosted in the container from the internet[doc4].

5. Deploy Multi-container Groups (if needed): If your application requires multiple containers to work together, you can deploy them as a container group. A container group is similar to a Kubernetes pod and allows containers to share a lifecycle, resources, local network, and storage volumes[doc5].

6. Verify Deployment: After the deployment, ensure that the container instance is running and accessible. You can test this by navigating to the FQDN or using the Azure portal to check the status of the container instance[doc3].

For additional information and step-by-step guides, you can refer to the following resources:

• Run container images in Azure Container Instances
• Quickstart: Deploy a container instance in Azure using the Azure portal
• Container groups in Azure Container Instances

By following these steps and utilizing the provided resources, you can successfully provision and manage containers using Azure Container Instances.

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

Provision and manage containers in the Azure portal

Provisioning a Container Using Azure Container Apps

Azure Container Apps is a serverless platform that enables you to deploy and manage microservices and containerized applications. It provides a way to run containers without managing the underlying infrastructure, as it operates on top of Azure Kubernetes Service (AKS). Here’s a detailed explanation of how to provision a container using Azure Container Apps:

1. Choose the Right Service: Understand when to use Azure Container Apps as opposed to other services like Azure Container Instances or Azure virtual machines. Azure Container Apps is ideal for microservices and containerized applications that require orchestration, auto-scaling, and a serverless environmentdoc1.

2. Create a Container App: Navigate to the Azure portal and create a new Container App. You will need to provide details such as the name of the app, the resource group, and the region where you want to deploy the app.

3. Configure the App: Set up the environment for your Container App by specifying configuration settings. This includes environment variables that your application might need to operate correctly[doc1].

4. Select the Source: Choose the source of your container image. You can use a pre-built image from a public registry like Docker Hub or upload your custom image to a private Azure Container Registry[doc3].

5. Set Up Networking: Configure the networking settings for your Container App. This includes setting up the ingress, which controls how external traffic reaches your app, and egress, which controls how your app accesses resources outside of Azure Container Apps.

6. Define Scaling Rules: Azure Container Apps provides auto-scaling capabilities. Define the rules based on CPU or memory usage, or on a custom metric, to automatically scale your application in response to demand.

7. Deploy the App: Once you have configured all the necessary settings, deploy your Container App. Azure will pull the container image from the specified source and start the container.

8. Monitor and Manage: After deployment, monitor the performance and health of your Container App using Azure Monitor. You can also manage the app by updating configurations, scaling manually, or redeploying with a new version of the container image.

For additional information on Azure Container Apps and how to provision containers using this service, you can refer to the following resources:

• Implement Azure Container Apps: This module provides an overview of Azure Container Apps and guides you through the deployment and management of microservices and containerized apps on the platform.

• Introduction to Docker containers: Learn about the benefits of using Docker containers and the infrastructure provided by the Docker platform, which is integral to understanding how to work with containerized applications.

By following these steps and utilizing the provided resources, you can effectively provision and manage containers using Azure Container Apps, taking advantage of its serverless nature and integration with AKS for a robust and scalable containerized application deployment.

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

Provision and manage containers in the Azure portal

Manage Sizing and Scaling for Containers

When managing containers in Azure, it’s essential to understand how to size and scale them effectively. This involves configuring the appropriate resources for Azure Container Instances and Azure Container Apps to ensure optimal performance and cost-efficiency.

Azure Container Instances (ACI)

Azure Container Instances is a service that allows you to run containers in Azure without managing the underlying virtual machines. It is suitable for scenarios that can operate in isolated containers, such as simple applications, task automation, and build jobs[doc5].

• Sizing: When you create a container instance, you can specify the amount of CPU and memory for the container. These resources are defined when you deploy the container and are critical for the container’s performance. You can set environment variables and specify container restart policies as well[doc1].
• Scaling: ACI does not natively support autoscaling. To handle increased load, you would need to manually create additional container instances or use an orchestrator that supports autoscaling. Containers can be rapidly recreated on another cluster node if a node fails, ensuring availability[doc3].

For more information on Azure Container Instances, visit: - Run container images in Azure Container Instances

Azure Container Apps

Azure Container Apps is a serverless platform for deploying and managing microservices and containerized applications. It runs on top of Azure Kubernetes Service and offers dynamic scaling and microservices orchestration[doc1].

• Sizing: In Azure Container Apps, you define the size of the containers by setting CPU and memory resources during the deployment process. These settings determine the resources available to each container instance.
• Scaling: Azure Container Apps supports both manual and automatic scaling:
  • Manual Scaling: You can manually scale the number of container instances based on your application’s needs.
  • Autoscaling: The service can automatically adjust the number of container instances based on the load. Autoscaling can be configured with metric-based or time-based rules, allowing the system to add or remove instances as requireddoc2.

For more information on Azure Container Apps, visit: - Implement Azure Container Apps

General Scaling Concepts for Azure Services

• Scale Up: Increasing the CPU, memory, and disk space by changing the pricing tier of the service plandoc2.
• Scale Out: Increasing the number of virtual machine instances running the application to handle more loaddoc2.
• Autoscale: Automatically adjusting the number of resources based on the application load, which can be configured with metric-based or time-based rulesdoc2.

Understanding these concepts is crucial for deploying and managing containers in Azure effectively. By managing sizing and scaling appropriately, you can ensure that your containerized applications perform well and remain cost-effective.

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

Create and configure Azure App Service

Provisioning an App Service Plan

When provisioning an App Service plan, you are essentially setting up a set of compute resources where your web applications will run. Here’s a step-by-step guide to help you understand the process:

1. Choose a Region: Begin by selecting the region where you want your App Service plan’s resources to be located. This is important for latency considerations and data sovereignty[doc5].

2. Define Compute Resources: An App Service plan allows you to define the size and number of VM instances that you need for your applications. These resources can be shared among multiple applications, which can be cost-effective[doc2][doc4].

3. Select a Pricing Tier: Azure offers various pricing tiers for App Service plans, each with different capabilities and scale options. The tier you choose will determine the features available to you, such as custom domains, SSL support, scaling options, and more[doc3].

4. Configure Scaling Options: Decide if you want to manually scale your plan by specifying a set number of VM instances or if you want to enable autoscaling. Autoscaling will automatically adjust the number of VM instances based on the load or schedule.

5. Create the App Service Plan: With the region, resources, and pricing tier decided, you can create the App Service plan through the Azure portal, Azure CLI, or Azure PowerShell[doc1].

6. Deploy Applications: Once the App Service plan is provisioned, you can deploy your web applications to it. All applications in the plan will run on the defined set of compute resources[doc5].

For additional information on App Service plans and how to manage them, you can refer to the following resources:

• Overview of App Service plans: Azure App Service plans
• Guide on creating and managing an App Service plan: Manage an App Service plan in Azure
• Instructions on scaling an app in Azure App Service: Scale up an app in Azure App Service

Remember, the App Service plan is a critical component of your application’s infrastructure in Azure, and choosing the right configuration is essential for optimal performance and cost management.

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

Create and configure Azure App Service

Configure Scaling for an Azure App Service Plan

When configuring scaling for an Azure App Service plan, it is essential to understand the two primary methods available: scale up and scale out. Additionally, scaling can be performed manually or automatically through autoscale.

Scale Up

Scaling up, also known as vertical scaling, involves increasing the compute resources available to your applications by enhancing the CPU, memory, and disk space. This is achieved by changing the pricing tier of your Azure App Service plan. Higher pricing tiers provide additional features such as:

• Dedicated virtual machines
• Custom domains and SSL certificates
• Staging slots
• Autoscaling capabilities
• Increased storage options

To scale up your App Service plan, you would adjust the pricing tier to a higher level that meets your application’s requirements[doc3].

Scale Out

Scaling out, or horizontal scaling, increases the number of virtual machine instances that run your application. Depending on the pricing tier of your App Service plan, you can scale out to as many as 30 instances, or up to 100 instances with App Service Environments in the Isolated tier. Scaling out helps to handle increased load by distributing traffic across multiple instances[doc3].

Autoscale

Autoscale is a feature that allows you to automatically adjust the number of instances or resources based on the load on your application. Autoscale can be configured with metric-based rules, such as CPU usage or memory consumption, or time-based rules, which scale resources according to a scheduledoc2.

Autoscale settings apply to all applications within the App Service plan, and the scaling actions are triggered when the defined rules or schedules are met. This ensures that your applications maintain performance during demand spikes without manual intervention[doc4].

Additional Resources

For more detailed information on configuring scaling for an Azure App Service plan, refer to the following resources:

• Azure App Service plans: Provides an overview of App Service plans and features.
• Manage an App Service plan in Azure: A guide on how to create and manage an App Service plan.
• Scale up an app in Azure App Service: Instructions on how to scale up your app in Azure App Service.

By understanding and utilizing these scaling methods, you can ensure that your applications are running efficiently and are capable of handling varying loads, thus providing a reliable and responsive experience for your users.

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

Create and configure Azure App Service

Create an App Service

Creating an App Service in Azure is a straightforward process that allows you to host web applications, mobile back ends, and RESTful APIs. The service supports multiple programming languages, is highly scalable, and can be run on both Windows and Linux environments. Below is a detailed explanation of how to create an App Service:

Step 1: Choose the App Service Type

Azure App Service provides various types of app services, including Web Apps, Mobile Apps, and API Apps. You can select the type that best fits your application needs[doc1].

Step 2: Create the App Service in the Azure Portal

To create an App Service, you can use the Azure portal. The process involves:

1. Logging into the Azure portal.
2. Navigating to the “App Services” section.
3. Clicking on “Add” to create a new service.
4. Configuring the App Service with the required settings such as the runtime stack, operating system, region, and selecting an App Service plan[doc3].

Step 3: Configure App Service Plan

An App Service plan defines the region (Datacenter) that your web app will run in, the size of VM instances, and the number of VM instances. The plan determines the cost and capabilities of the apps you rundoc2.

Step 4: Deployment and Management

After creating your App Service, you can manage it by configuring deployment settings, setting up deployment slots for different stages (development, test, stage, production), and customizing the domain name[doc3].

Step 5: Monitoring

Integrate Azure Application Insights with your App Service to monitor live applications, automatically detect performance anomalies, and continuously monitor the performance and usability of your apps[doc3].

Step 6: Scale Your App

You can scale your app in Azure App Service either manually or automatically, based on performance metrics or schedulesdoc2.

Step 7: Custom Domain Name

For a more professional look, you can map a custom domain name to your App Service. Note that a paid tier of an App Service plan is required to map a custom DNS name to your app[doc5].

Additional Resources

• Azure App Service overview
• Manage an App Service plan in Azure
• Scale up an app in Azure App Service
• Configure an App Service app
• Set up staging environments in Azure App Service

This guide provides a comprehensive overview of creating and managing an Azure App Service, which is essential for hosting and scaling web applications in the cloud.

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

Create and configure Azure App Service

Configure Certificates and Transport Layer Security (TLS) for an App Service

When configuring certificates and Transport Layer Security (TLS) for an Azure App Service, it is important to understand the role of these components in securing your web applications. TLS is a protocol that ensures privacy between communicating applications and their users on the internet. When secured by TLS, connections between a client (for example, a web browser) and a server (your App Service) have three key properties: encryption, authentication, and integrity.

Encryption

Encryption ensures that data exchanged between the client and server is unreadable to any third parties who may intercept the communication. This is achieved by encrypting the data before it is sent over the network and decrypting it upon arrival at its destination.

Authentication

Authentication provides a way to verify the identity of the server to which the client is connecting. This is typically done using a digital certificate issued by a trusted Certificate Authority (CA). When a client connects to an App Service, it can request to view the server’s certificate to confirm the server’s identity.

Integrity

Integrity checks ensure that the data has not been tampered with during transit. TLS uses cryptographic checksums to detect any changes to the data.

Steps to Configure TLS and Certificates in Azure App Service

1. Obtain a TLS/SSL Certificate: Before you can configure TLS for your App Service, you need a TLS/SSL certificate. You can purchase a certificate from a trusted CA or generate a self-signed certificate for testing purposes.

2. Upload the Certificate to Azure App Service: Once you have your certificate, you can upload it to your App Service. In the Azure portal, navigate to your App Service and select “TLS/SSL settings” from the menu. Under the “Private Key Certificates (.pfx)” tab, you can upload your certificate file.

3. Bind the Certificate to Your Custom Domain: After uploading the certificate, you need to bind it to your custom domain. This is done in the same “TLS/SSL settings” section by selecting “Add TLS/SSL Binding” and choosing the uploaded certificate and the domain you want to secure.

4. Configure TLS/SSL Settings: Azure App Service allows you to configure the version of TLS your app will use. It is recommended to use the latest version for maximum security. You can set this under the “TLS/SSL settings” by selecting the minimum TLS version that your app will accept.

5. Set up Forced Redirect to HTTPS: To ensure that all connections to your app use TLS, you can enforce HTTPS-only traffic. This setting is found in the “Custom domains” section of your App Service settings. Enabling “HTTPS Only” will redirect all HTTP requests to HTTPS.

6. Monitor and Manage Your Certificates: Keep track of your certificates’ expiration dates and renew them as necessary. Azure App Service provides notifications for expiring certificates to help you manage them effectively.

For additional information on configuring certificates and TLS for an Azure App Service, you can refer to the following resources:

• Configure an App Service appdoc2.
• Azure App Service plans[doc4].
• Manage an App Service plan in Azure[doc4].
• Scale up an app in Azure App Service[doc4].

By following these steps and utilizing the provided resources, you can ensure that your Azure App Service is secured with the appropriate certificates and TLS settings.

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

Create and configure Azure App Service

To map an existing custom DNS name to an Azure App Service, you will need to follow a series of steps to ensure that your custom domain properly points to your Azure-hosted application. Here is a detailed explanation of the process:

1. Prerequisites:
   • Ensure that you have a paid tier of an App Service plan, as custom DNS names are not supported on the free tier[doc1].
2. Create a DNS Record:
   • The first step is to create a CNAME or an A record with your DNS provider. The CNAME record will alias your custom domain to the Azure App Service domain, while an A record will point directly to the IP address of your App Service[doc4].
3. Validate the Custom Domain:
   • Use the Azure portal to validate your custom domain. This is done by adding a verification ID provided by Azure as a TXT record in your DNS settings. This step is crucial to prove ownership of the domain[doc5].
4. Add the Custom Domain to Your App Service:
   • After validation, you can add the custom domain to your App Service through the Azure portal. Navigate to the ‘Custom domains’ section of your App Service and enter the custom domain name you wish to use[doc4].
5. SSL Binding:
   • If you want to secure your custom domain with HTTPS, you will need to add an SSL certificate. Azure App Service supports uploading your own certificate or purchasing one through Azure. Note that Azure Storage does not natively support HTTPS with custom domains, so you may need to use Azure Content Delivery Network (CDN) for this purposedoc2.
6. Testing:
   • Before making your domain live, it’s important to test that everything is configured correctly. You can do this by navigating to your custom domain in a web browser and ensuring that it correctly displays your Azure App Service[doc4].

For additional information on configuring a custom domain for Azure App Service, you can refer to the following resources: - Learn more about custom domains in Azure App Service - Learn more about intermediary domain mapping

Please note that the URLs provided are for reference purposes to supplement the study guide and should be accessed for more detailed guidance on the steps outlined above.

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

Create and configure Azure App Service

Configure Backup for an Azure App Service

When configuring a backup for an Azure App Service, it is essential to understand the process and requirements to ensure that your app or site can be restored to a previous state if necessary. Here are the steps and considerations for setting up backups for your Azure App Service:

1. Prerequisites:
   • Ensure that you have the Standard or Premium tier App Service plan for your app or sitedoc2.
   • You must have an Azure storage account and container in the same subscription as the app you wish to back updoc2.
2. Backup Content:
   • Azure App Service can back up the following informationdoc2:
     • App configuration settings
     • File content
     • Databases connected to your app (SQL Database, Azure Database for MySQL, Azure Database for PostgreSQL, MySQL in-app)
3. Backup Files:
   • Each backup is stored as a Zip file containing the backup data and an XML file with a manifest of the Zip file contents in your Azure storage accountdoc2.
4. Backup Configuration:
   • Backups can be configured manually or on a scheduledoc1.
   • You can opt for full backups (default) or partial backups, where you can specify files and folders to excludedoc2.
   • Backups can hold up to 10 GB of app and database contentdoc2.
5. Backup Retention:
   • Configure the backups to be retained for a specific or indefinite amount of time[doc1].
6. Restoration:
   • Restore your app or site to a snapshot of a previous state by overwriting the existing content or restoring to another app or site[doc1].
   • Partial backups are restored the same way as regular backupsdoc2.
7. Monitoring and Management:
   • Backups for your app or site are visible on the Containers page of your storage account and app (or site) in the Azure portaldoc2.

For additional information and guidance on configuring backups for Azure App Service, you can refer to the following resources: - Azure Tips and Tricks #28 - Configure a backup for Azure App Service[doc1]. - Azure App Service plans[doc5]. - Manage an App Service plan in Azure[doc5]. - Scale up an app in Azure App Service[doc5].

By following these steps and considerations, you can effectively configure backups for your Azure App Service apps, ensuring data protection and recovery capabilities.

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

Create and configure Azure App Service

Configure Networking Settings for an Azure App Service

When configuring networking settings for an Azure App Service, it is essential to understand the various components and options available to ensure that your web applications are secure, scalable, and performant. Below is a detailed explanation of the key networking settings that can be configured for an Azure App Service:

1. Custom Domain Names

Azure App Service allows you to configure custom domain names for your web apps. This means you can have a personalized web address that reflects your organization’s branding instead of the default domain provided by Azuredoc2.

2. SSL/TLS Bindings and Certificates

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are protocols for establishing authenticated and encrypted links between networked computers. In Azure App Service, you can bind SSL/TLS certificates to your custom domains to ensure secure connections[doc5].

3. Networking Features

Azure App Service provides several networking features that can be configured, such as:

• Hybrid Connections: This feature allows your app to access on-premises resources by creating a secure connection between your App Service and an on-premises resource[doc5].
• Service Endpoints: Service endpoints provide secure and direct connectivity to Azure services over the Azure backbone network. This can help enhance security and potentially reduce latency[doc5].
• Azure Content Delivery Network (CDN): Integrating Azure CDN with App Service can improve the performance and experience for users by caching content at strategically placed physical nodes across the world[doc5].
• Virtual Network Integration: This feature enables your app to access resources in a virtual network, including Azure services and on-premises resources, providing enhanced security and control over the network traffic[doc5].

4. IP Restrictions

IP restrictions in Azure App Service allow you to define a list of IP addresses that are allowed or denied access to your web app. This can help protect your app from unauthorized access and potential attacks[doc5].

5. Scale Settings

The Azure App Service plan determines how your applications run and scale. You can configure autoscaling settings to automatically scale out your app based on metrics such as CPU usage or request queue length[doc3].

6. Deployment Slots

Deployment slots are a feature of Azure App Service that allows you to have different environments for your app, such as development, testing, staging, and production. You can configure settings for each slot, and settings can be swapped between slots as part of your deployment process[doc1][doc4].

For more detailed information on configuring these settings, you can refer to the following resources:

• App Service overview
• Configure an App Service app
• Set up staging environments in Azure App Service

By carefully configuring these networking settings, you can ensure that your Azure App Service web applications are well-integrated with your organization’s infrastructure, secure, and capable of handling the desired load with optimal performance.

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

Create and configure Azure App Service

Configure Deployment Slots for an App Service

Deployment slots are a feature of Azure App Service that allow developers to manage different stages of their web applications, such as development, testing, staging, and production. These slots enable a streamlined deployment process and the ability to roll back to previous versions if necessary. Here’s a detailed explanation of how to configure deployment slots for an App Service:

1. Accessing Deployment Slots: Deployment slots are configured within the Azure portal. You can navigate to your App Service and find the “Deployment slots” option in the menu.

2. Creating Deployment Slots: You can create a new deployment slot either as an empty slot or by cloning the configuration from an existing slot. This is useful for setting up a staging environment that mirrors your production environment.

3. Configuration Settings: Deployment slot settings are categorized into three groups:

   • Slot-specific app settings and connection strings: These settings are unique to each slot and can be configured to use different databases or external services.
   • Continuous deployment settings: If continuous deployment is enabled, these settings control how new code is automatically deployed to the slot.
   • Azure App Service authentication settings: These settings manage the authentication mechanisms for the slot when enabled.

4. Swapping Slots: Once you have configured your deployment slots, you can swap content and configuration elements between them. For example, you can swap from a staging slot to the production slot once you’re ready to go live with the latest version of your app.

5. Customizing Domain Names: The default domain name provided by Azure App Service can be customized to match your organization’s branding.

6. Monitoring with Application Insights: Azure Application Insights can be integrated with your App Service to monitor live applications and automatically detect performance anomalies.

For additional information on configuring and using deployment slots in Azure App Service, you can refer to the following resources:

• Stage a web app deployment for testing and rollback by using App Service deployment slots.
• Explore Azure App Service deployment slots.
• Set up staging environments in Azure App Service.

These resources provide comprehensive guidance on the usage of deployment slots, including how to set them up, configure them, and integrate them with other Azure services for monitoring and performance managementdoc1[doc3][doc4][doc5].

Implement and manage virtual networking (15–20%)

Configure and manage virtual networks in Azure

Virtual Networks and Subnets Configuration

When configuring virtual networks and subnets in Azure, it is essential to understand their role in providing private connectivity between Azure Virtual Machines and other Azure services. Virtual networks enable resources within the same network to communicate with each other, while by default, preventing access from external services. However, configurations can be made to allow such access, including connections from on-premises servers[doc1].

Considerations for Virtual Networks:

• Network Topology: Before deploying virtual machines, carefully plan the network topology, especially if you intend to connect Azure services with your private company network. Changing network addresses and subnets can be complex after they are set up[doc1].

Subnets within Virtual Networks:

• Subnet Creation: Subnets are subdivisions of a virtual network that allow for more granular control of IP address allocations and network security. Each subnet can be configured with a range of IP addresses[doc1].
• Security: Assign network security groups to subnets to create protected areas such as a demilitarized zone (DMZ). This acts as a buffer between resources within your virtual network and the internet[doc4].

Network Security Groups (NSGs):

• Traffic Filtering: NSGs are used to filter network traffic to and from Azure resources. Security rules within NSGs can be defined to control the flow of traffic in and out of virtual network subnets and network interfaces[doc5].
• Rule Evaluation: For inbound traffic, Azure processes NSG rules for subnets first, then network interfaces. For outbound traffic, this order is reversed. Azure also evaluates how rules apply to intra-subnet trafficdoc2.
• Effectiveness: The way Azure applies your defined security rules determines the overall effectiveness of your network securitydoc2.

Service Access Settings:

• Firewalls and Virtual Networks: These settings can restrict access to your storage account from specific subnets on virtual networks or public IPs[doc3].
• Public IP Ranges: The service can be configured to allow access from one or more public IP ranges[doc3].
• Regional Restrictions: Subnets and virtual networks must exist in the same Azure region or region pair as your storage account[doc3].
• Testing: Always test service endpoints to verify that they limit access as expected[doc3].

For additional information on configuring virtual networks and subnets, you can refer to the following resources: - Azure Virtual Network documentation - Network Security Groups documentation - Subnet and NSG association documentation

Please note that the URLs provided are for reference purposes and should be accessed for more detailed guidance on the configuration of virtual networks and subnets in Azure.

Implement and manage virtual networking (15–20%)

Configure and manage virtual networks in Azure

Create and Configure Virtual Network Peering

Virtual network peering in Azure is a mechanism that connects two virtual networks, allowing resources in one virtual network to communicate with resources in another virtual network. This connection is direct and uses the Azure backbone network, ensuring high-bandwidth, low-latency connectivity. Here’s a detailed explanation of how to create and configure virtual network peering:

Types of Virtual Network Peering

• Regional Peering: Connects virtual networks within the same Azure region[doc1].
• Global Peering: Connects virtual networks across different Azure regions[doc1].

Steps to Create and Configure Virtual Network Peering

1. Navigate to the Azure Portal: Begin by logging into the Azure Portal.
2. Select or Create Virtual Networks: Identify the virtual networks you wish to peer. If they do not exist, create them within the desired regions.
3. Initiate Peering: In the settings of one virtual network, find the ‘Peering’ option and select ‘Add peering’.
4. Configure Peering Settings: Enter the peering details such as the name of the peering and the virtual network with which you want to establish the peering.
5. Select Peering Type: Choose between regional or global peering based on the locations of your virtual networks[doc1].
6. Configure VPN Gateway (if necessary): If you want to use the VPN gateway for transit connectivity, ensure that one of the virtual networks has a VPN gateway configured[doc3].
7. Enable Gateway Transit: This allows the peered virtual network to use the VPN gateway of the other network for accessing additional resources[doc3].
8. Review and Create: Review the peering settings and create the peering. Repeat the process for the other virtual network to establish a bi-directional peering connection.

Considerations for Virtual Network Peering

• Network Traffic: Traffic between peered virtual networks is private and stays within the Azure network[doc1].
• VPN Gateway: Only one VPN gateway can be used per virtual network, and gateway transit is supported for both regional and global peering[doc3].
• Network Security Groups (NSGs): NSGs can be applied to control access between peered virtual networks[doc1].

Additional Resources

For more information on virtual network peering, you can refer to the following URLs: - Azure Virtual Network peering overviewdoc2. - Create, change, or delete a virtual network peeringdoc2.

By following these steps and considerations, you can successfully create and configure virtual network peering in Azure, enabling seamless connectivity between virtual networks.

Implement and manage virtual networking (15–20%)

Configure and manage virtual networks in Azure

The requested information is not available in the retrieved data. Please try another query or topic.

Implement and manage virtual networking (15–20%)

Configure and manage virtual networks in Azure

Configure User-Defined Network Routes

User-defined routes (UDRs) are a critical component in Azure networking that allow for the customization of network traffic routing within virtual networks. UDRs provide the flexibility to direct traffic flow according to specific requirements, which can be essential for scenarios such as implementing complex network architectures or integrating network virtual appliances (NVAs).

Characteristics of User-Defined Routes:

• Control of Traffic Flow: UDRs enable the definition of routes that dictate the next hop in the traffic flow[doc5].
• Next Hop Targets: The next hop in a UDR can be directed to various targets, including a virtual network gateway, virtual network, the internet, or a network virtual appliance (NVA)[doc5].
• Route Tables: UDRs are accessed through route tables, which can be associated with multiple subnets within the virtual network[doc5].
• Subnet Associations: Each subnet within a virtual network can be associated with only one route table, ensuring clear and unambiguous routing paths[doc5].
• Cost: There are no additional charges for creating route tables in Microsoft Azure[doc5].

Implementation Steps:

1. Create a Route Table: Begin by creating a route table in the Azure portal. This table will hold the UDRs.
2. Define Routes: Within the route table, define the UDRs by specifying the address prefix and the next hop type. The next hop can be a virtual appliance, virtual network, internet, or other specified targets[doc5].
3. Associate Route Table with Subnets: Once the UDRs are defined, associate the route table with the relevant subnets within the virtual network. This association ensures that the custom routes are applied to the traffic originating from these subnets[doc5].
4. Test the Routes: After configuration, it’s important to test the routes to ensure that traffic is flowing as expected. This can be done by using network monitoring tools or performing connectivity tests from the resources within the subnets.

Considerations:

• Forced Tunneling: In scenarios where internet traffic is forced to an on-premises location or through NVAs, UDRs can be used to implement forced tunneling. This ensures that Azure service traffic can bypass the forced tunneling and use optimal routes[doc3].
• Service Endpoints: Utilize service endpoints to direct traffic to the Microsoft network, keeping it on the Azure backbone network. This is particularly useful when auditing and monitoring outbound internet traffic without affecting service traffic[doc3].
• Hub and Spoke Networks: UDRs can be used in hub and spoke network architectures to direct traffic through NVAs or VPN gateways located in the hub virtual network[doc4].

For additional information on configuring user-defined network routes, you can refer to the following resources: - User-defined routes and forced-tunneling - Configure VNet peering and service chaining

Please note that while these URLs provide further details, they should be used to supplement the understanding of the concepts and not as a replacement for hands-on experience with Azure networking.

Implement and manage virtual networking (15–20%)

Configure and manage virtual networks in Azure

Troubleshooting Network Connectivity in Azure

When troubleshooting network connectivity in Azure, it is essential to understand the tools and features available to diagnose and resolve issues. Azure provides several services and features that can help you troubleshoot connectivity problems effectively.

Azure Virtual Network Peering

Azure Virtual Network peering allows for the seamless connection of two Azure virtual networks. Once peered, the networks operate as if they were a single network, which simplifies the connectivity and communication between resources in different virtual networksdoc2.

Azure Network Watcher

Azure Network Watcher is a suite of tools that provides network monitoring and diagnostic capabilities. Here are some of the key features that can be used for troubleshooting network connectivity:

• IP Flow Verify: This feature helps diagnose connectivity issues to or from the internet or on-premises environments. It can identify if a security rule is blocking traffic to or from a virtual machine[doc3].

• Next Hop: This tool allows you to view the next hop in the network route and analyze the network routing configuration to ensure traffic reaches the intended destination[doc3].

• VPN Troubleshoot: This feature is used to diagnose the health of virtual network gateways or connections. It provides connection statistics, CPU and memory information, and details on security errors and packet drops[doc3].

• NSG Diagnostics: Network Security Group (NSG) flow logs help map IP traffic through an NSG, which is useful for security compliance and auditing. It allows comparison of prescriptive NSG rules against the effective rules for each virtual machine[doc3].

• Connection Troubleshoot: This recent addition to Network Watcher checks direct TCP or ICMP connections from a source like a virtual machine to a target. It is useful for troubleshooting network performance and connectivity issues[doc3].

Documentation and Tutorials

For more detailed guidance on using these tools, the following URLs to the Azure documentation can be referenced:

• Azure Network Watcher documentation provides a collection of articles as a starting point for using Network Watcher[doc4].

• The overview article “What is Azure Network Watcher?” reviews monitoring, diagnostic tools, and traffic troubleshooting capabilities[doc4].

• The tutorial “Diagnose a virtual machine network routing problem using the Azure portal” uses the next hop tool to troubleshoot a VM routing problem[doc4].

• The tutorial “Diagnose a communication problem between virtual networks using the Azure portal” shows how to use the VPN troubleshoot capability to diagnose connectivity issues between virtual networks[doc4].

Considerations for Virtual Networks

When working with virtual networks in Azure, it is important to plan the network topology carefully, especially if you intend to connect your private company network to Azure services. Network addresses and subnets should be thoughtfully configured as they are not trivial to change later[doc5].

By utilizing these tools and following best practices for network configuration, you can effectively troubleshoot network connectivity issues in Azure.

Implement and manage virtual networking (15–20%)

Configure secure access to virtual networks

Create and Configure Network Security Groups (NSGs) and Application Security Groups

Network Security Groups (NSGs) are a critical component in Azure for controlling network traffic to resources within a virtual network. NSGs contain a list of security rules that dictate the flow of inbound and outbound network traffic. These rules can be associated with either subnets within the virtual network or individual network interfaces attached to virtual machines (VMs) doc2.

Steps to Create and Configure NSGs:

1. Determine the Scope: Decide whether the NSG will be applied to a subnet or a network interface.
2. Create the NSG: In the Azure portal, create a new NSG resource.
3. Define Security Rules: Establish rules that specify allowed and denied traffic based on factors such as source/destination IP addresses, ports, and protocols.
4. Set Rule Priority: Rules are processed in order of priority, with lower numbers processed first. Ensure that the rules are prioritized correctly to avoid conflicts.
5. Associate NSG: Attach the NSG to the chosen subnet or network interface.

Application Security Groups (ASGs) provide an application-centric way to manage network security rules. They allow you to group VMs and define network security policies based on those groups, rather than individual IP addresses. This simplifies the management of network security rules, especially for complex applications spread across multiple VMs [doc1][doc4].

Steps to Create and Configure ASGs:

1. Create ASGs: Define ASGs that represent different components of your application, such as web servers or database servers.
   • For example, create WebASG for web server VMs and DBASG for database server VMs [doc3].
2. Assign VMs to ASGs: Assign network interfaces of VMs to the appropriate ASG.
3. Use ASGs in NSG Rules: When creating NSG rules, use ASGs as the source or destination instead of individual IP addresses. This allows for more natural expression of security policies that align with the structure of your application [doc1].

By combining NSGs and ASGs, you can create a robust network security framework that is both flexible and easy to manage. This approach ensures that as your application grows or changes, your network security rules can be easily updated to match the new architecture.

For additional information on implementing NSGs and ASGs in Azure, you can refer to the following resources: - Azure Network Security Groups - Azure Application Security Groups

Remember to review and test your security rules to ensure they work as intended and provide the necessary protection for your resources.

Implement and manage virtual networking (15–20%)

Configure secure access to virtual networks

Evaluate Effective Security Rules in NSGs

Network Security Groups (NSGs) in Azure are critical for controlling the flow of network traffic to resources within a virtual network. They contain a list of security rules that dictate how inbound and outbound traffic should be managed for subnets and network interfacesdoc2.

Understanding Security Rules

Security rules within NSGs are used to filter network traffic. Each rule is defined with specific conditions that determine how traffic is allowed or denied. Azure provides several default security rules for each NSG, such as DenyAllInbound to block all incoming traffic and AllowInternetOutbound to allow outgoing traffic to the internet[doc5].

Rule Evaluation and Processing

For inbound traffic, Azure processes the NSG security rules for associated subnets first, followed by rules for any associated network interfaces. Conversely, for outbound traffic, the order is reversed, with network interface rules evaluated before subnet rules[doc1].

The rules are processed based on priority, with lower numbered rules having higher precedence. It’s important to manage rule priority effectively to ensure that the intended rules are applieddoc2.

Intra-Subnet Traffic

In addition to inbound and outbound rules, NSGs also evaluate how rules apply to traffic within the same subnet (intra-subnet traffic). This is an important consideration when defining security rules to ensure that communication between resources in the same subnet is correctly managed[doc1].

Application Security Groups

Application Security Groups (ASGs) offer an application-centric view of the infrastructure, allowing for grouping of virtual machines based on workload. This simplifies rule management by enabling you to apply security rules to a group of VMs sharing similar functionsdoc2.

Verifying Effective Security Rules

To determine which security rules are actively being applied to virtual machines, subnets, and network interfaces, you can use the Effective security rules feature in the Azure portal. This tool helps to verify and understand the cumulative impact of all associated NSG rules[doc3].

Additional Resources

For more information on NSGs and security rules in Azure, you can refer to the following resources:

• Azure Network Security Groups
• How to Create and Manage NSG
• Application Security Groups in Azure

By understanding and evaluating the effective security rules in NSGs, you can ensure that your Azure virtual networks are secured according to your organization’s requirements and best practices.

Implement and manage virtual networking (15–20%)

Configure secure access to virtual networks

Implementing Azure Bastion

Azure Bastion is a fully managed platform-as-a-service (PaaS) that provides secure and seamless Remote Desktop Protocol (RDP) and Secure Shell (SSH) access to virtual machines over Secure Sockets Layer (SSL). This service is integrated within the Azure portal and does not require any public IP addresses on the virtual machines, offering a more secure approach to accessing virtual machines.

Key Features of Azure Bastion:

• Secure Connectivity: Azure Bastion provides RDP and SSH access directly in the Azure portal over SSL, which eliminates the need for public IP addresses on your Azure virtual machinesdoc2.
• Simplified Access: You can access your virtual machines through the Azure portal using Azure Bastion without the need for additional clients, agents, or softwaredoc2.
• Protection: By using Azure Bastion, you are protecting your virtual machines from exposing RDP/SSH ports to the public internet, which significantly reduces the surface area for potential attacksdoc2.

Steps to Implement Azure Bastion:

1. Create a Bastion Host: In your Azure portal, you need to create a new Bastion host in the virtual network where your virtual machines are located.
2. Configure the Bastion Host: Set up the required settings, such as the AzureBastionSubnet, and ensure that the subnet is properly configured to support the Bastion service.
3. Connect to Virtual Machines: Once the Bastion host is provisioned, you can connect to your virtual machines through the Azure portal. Select the virtual machine you want to connect to, and then click on the ‘Connect’ button. Choose the Bastion option and provide the necessary authentication credentials.

Additional Resources:

• For a visual guide on how Azure Bastion connections work, you can refer to the diagram provided in the Azure training content[doc3].
• To learn more about Azure Bastion and how to set it up, you can visit the following URL: Introduction to Azure Bastion.

By implementing Azure Bastion, you can enhance the security posture of your virtual machine access, streamline connectivity, and reduce the risk of exposing RDP/SSH to the internet. It is an essential service for maintaining secure remote access within the Azure ecosystem.

Implement and manage virtual networking (15–20%)

Configure secure access to virtual networks

Service endpoints play a crucial role in securing Azure Platform as a Service (PaaS) resources by extending the virtual network’s identity to Azure services. When configuring service endpoints, it is important to understand their characteristics and how they can be implemented to enhance security and connectivity within Azure.

Characteristics of Service Endpoints

• Extension of Virtual Network Identity: Service endpoints allow Azure services to be secured by extending the virtual network’s identity to them[doc3].
• Use of Virtual Network Rules: Azure service resources are secured to the virtual network using virtual network rules, which can restrict public internet access and allow traffic only from the virtual network[doc3].
• Direct Traffic: Service traffic is taken directly from the virtual network to the service on the Microsoft Azure backbone network, ensuring a secure and efficient connection[doc3].
• Configuration Through Subnet: Service endpoints are configured at the subnet level, which simplifies the setup and maintenance without requiring additional overhead[doc3].

Steps to Configure Service Endpoints

1. Select the Azure Service: In the Azure portal, choose the Azure service for which you want to create the endpoint, such as Azure Cosmos DB, Event Hubs, Key Vault, or SQL Database[doc5].
2. Configure the Subnet: Service endpoints are added to a subnet within the virtual network. This process involves selecting the service and enabling the service endpoint for that particular service[doc1].
3. Update Firewall Rules: After enabling service endpoints, the IP addresses of the virtual machines in the subnet will switch from public to private IPv4 addresses. It is essential to update any existing Azure service firewall rules to accommodate this change[doc1].
4. Validate Connectivity: Ensure that the service resources are accessible from the virtual network after the service endpoints are configured. This may involve testing connectivity from a virtual machine within the subnet to the Azure service[doc3].

Considerations

• Service Traffic Interruption: There might be a temporary interruption to service traffic from the subnet while configuring service endpoints[doc1].
• Time for Activation: Adding service endpoints can take up to 15 minutes to complete, so plan accordingly[doc5].
• Documentation: Each service endpoint integration has its own Azure documentation page, which provides specific instructions and considerations for that service[doc5].

Additional Resources

For more detailed information on configuring service endpoints for specific Azure services, you can refer to the Azure documentation pages for each service. Here are some examples:

• Azure Storage: Azure Storage Service Endpoints
• Azure SQL Database: Azure SQL Database Service Endpoints
• Azure Cosmos DB: Azure Cosmos DB Service Endpoints
• Azure Key Vault: Azure Key Vault Service Endpoints

By following these guidelines and utilizing the provided resources, you can effectively configure service endpoints for Azure PaaS, enhancing the security and connectivity of your Azure resources.

Implement and manage virtual networking (15–20%)

Configure secure access to virtual networks

Configure Private Endpoints for Azure PaaS

Azure Private Link is a service that enables private connectivity from a virtual network to Azure Platform as a Service (PaaS) offerings, customer-owned services, or services provided by Microsoft partners. It is designed to simplify the network architecture and enhance security by eliminating data exposure to the public internet[doc3][doc5].

Key Features of Azure Private Link:

• Private Connectivity: Azure Private Link keeps all network traffic on the Microsoft global network, avoiding any exposure to the public internet[doc5].
• Global Reach: There are no regional restrictions with Private Link, allowing private connections to services in other Azure regions[doc5].
• Integration with Virtual Networks: Services on Azure can be integrated into your private virtual network through the mapping of your network to a private endpoint[doc5].
• Direct Service Delivery: Private Link can be used to deliver your services privately within your customer’s virtual networks[doc5].
• Simplified Routing: All traffic to the service is routed through the private endpoint without the need for gateways, NAT devices, Azure ExpressRoute or VPN connections, or public IP addresses[doc5].

Steps to Configure Private Endpoints:

1. Map Private Endpoints: Map private endpoints to Azure PaaS resources to ensure that only the mapped resources are accessible within your network. This approach is crucial for mitigating the risk of data exfiltration during a security incident[doc1].

2. Service Endpoints Configuration: Configure service endpoints in your subnets for a straightforward setup and minimal maintenance. This eliminates the need for reserved public IP addresses in your virtual networks to secure Azure resources through an IP firewall, as no NAT or gateway devices are requireddoc2.

   • Note: When configuring service endpoints, the virtual machine IP addresses will change from public to private IPv4 addresses. It is important to update Azure service firewall rules to accommodate this change. There may also be a temporary interruption to service traffic from the subnet during the configuration processdoc2.

Additional Resources:

• For a comprehensive understanding of Azure storage accounts, refer to the Storage account overview[doc4].
• To learn about the trade-offs between cost and availability for Azure storage, review the Azure storage redundancy article[doc4].
• For guidance on when and how to configure Azure private endpoints for storage, consult the Use private endpoints for Azure Storage article[doc4].

By following these steps and utilizing the provided resources, you can effectively configure private endpoints for Azure PaaS, ensuring a secure and private connection to Azure services.

Implement and manage virtual networking (15–20%)

Configure name resolution and load balancing

Configure Azure DNS

When configuring Azure DNS, there are several key steps and considerations to ensure proper setup and management of your domain names within the Azure ecosystem. Below is a detailed explanation of the process:

1. Creating a DNS Zone

A DNS zone in Azure is the container for all of your DNS records for a particular domain. To create a DNS zone:

• Navigate to the Azure portal and specify the DNS zone name, number of records, resource group, zone location, associated subscription, and DNS name servers.
• Ensure that the DNS zone name is unique within the resource group. Azure checks for uniqueness to prevent conflicts[doc1].
• It is possible to have multiple DNS zones with the same name, but they must be in different resource groups or Azure subscriptions[doc1].
• Each DNS zone with the same name will have different DNS name server addresses assigned[doc1].
• The root or parent domain must be registered with a domain registrar and then pointed to Azure DNS, while child domains can be registered directly in Azure DNS[doc1].

2. Verifying Domain Ownership

After adding a custom domain name to your Azure service, you must verify that you own the domain:

• Initiate the verification process by adding a DNS record (either MX or TXT) to your domain’s DNS configurationdoc2.
• The MX record is used for mail exchange servers, while the TXT record can contain human-readable text or machine-readable data about your domaindoc2.
• Azure will then query the DNS domain to check for the presence of the DNS recorddoc2.
• The verification process by Azure can take from several minutes to hoursdoc2.
• Once verified, Azure will add the custom domain name to your subscriptiondoc2.

3. Identifying DNS Name Servers

To manage your DNS zone, you need to know which DNS name servers have been assigned to it:

• The Azure portal provides information on the DNS name servers assigned to your DNS zone[doc3].
• For example, a domain like azureadmininc.org might have name servers such as ns1-02.azure-dns.com, ns2-02.azure-dns.net, ns3-02.azure-dns.org, and ns4-02.azure-dns.info[doc3].

4. Delegating Your Domain

To delegate your domain to Azure DNS, follow these steps:

• Identify the DNS name servers for your DNS zone, which Azure DNS allocates from a pool each time a DNS zone is created[doc5].
• Update your parent domain’s DNS settings with the Azure DNS name servers to point to Azure’s infrastructure[doc5].
• Optionally, delegate subdomains by creating additional DNS zones and updating the respective NS records[doc5].

5. Adding Security Rules

Azure allows you to add security rules to control inbound and outbound traffic:

• Use the Azure portal to configure virtual network security group rule settings[doc4].
• Select from various communication services such as HTTPS, RDP, FTP, and DNS to manage traffic[doc4].

For additional information and guidance on configuring Azure DNS, you can refer to the official Azure documentation: Configure Azure DNS.

Please note that while URLs are provided for further reading, they should not be explicitly mentioned in the study guide. The information above is structured to give a comprehensive understanding of the Azure DNS configuration process.

Implement and manage virtual networking (15–20%)

Configure name resolution and load balancing

Configure an Internal or Public Load Balancer

When configuring a load balancer in Azure, you have the option to set up either an internal or a public load balancer, depending on your application’s architecture and access requirements.

Internal Load Balancer: - An internal load balancer is used to balance traffic within a private network. - It is ideal for multi-tier applications where you want to balance load on internal services, such as a database tier subnet with several virtual machines[doc5]. - The internal load balancer receives requests and uses load-balancing rules to distribute the traffic to back-end resources, ensuring that no single server is overwhelmeddoc2. - Health probes are used to monitor the health of the resources in the backend pooldoc2.

Public Load Balancer: - A public load balancer is used to distribute incoming internet traffic to resources in your public-facing services. - It is suitable for applications that require access from the internet[doc1]. - You can also configure a public load balancer in front of an internal load balancer to create a multi-tier application, allowing for both internal and external traffic management[doc1].

Configuration Components: - Front-end IP configuration: Specifies the IP address that the load balancer responds to. This can be a public IP or an internal IPdoc2. - Back-end pools: Consist of the services and resources that will receive the traffic, such as Azure Virtual Machines or instances in Azure Virtual Machine Scale Setsdoc2. - Load-balancing rules: Define how traffic is distributed to the back-end resourcesdoc2. - Health probes: Monitor and ensure that the back-end resources are healthy and able to process requestsdoc2.

SKU Options: - Azure Load Balancer offers three SKU options: Basic, Standard, and Gateway, each providing different features, scaling capabilities, and pricing[doc3].

Additional Resources: - For more information on Azure Load Balancer, you can refer to the Azure Load Balancer documentation[doc4]. - To learn how to create a public load balancer for virtual machines in the Azure portal, you can visit Create a public load balancer for virtual machines in the Azure portal[doc4].

When preparing for an exam, it is crucial to understand the differences between internal and public load balancers, their use cases, and how to configure them properly to ensure efficient traffic management and high availability of services.

Implement and manage virtual networking (15–20%)

Configure name resolution and load balancing

When troubleshooting load balancing, it is essential to understand the configuration and operation of the load balancer to effectively identify and resolve issues. Here is a detailed explanation of the key points to consider:

Load Balancer Configuration

• Frontend and Backend Configuration: Ensure that the load balancer has a properly configured frontend that receives incoming traffic and a backend pool that consists of the servers intended to handle the traffic[doc4].
• Health Probes: Verify that health probes are set up and functioning correctly. Health probes are used by the load balancer to determine the health of the backend servers. If a server fails a health check, it is removed from the pool until it passes the health checks again[doc4].
• Load-Balancing Rules: Check the load-balancing rules, which define how traffic is distributed to the backend servers. These rules are based on IP version, front-end IP address, port, protocol, backend pool, backend port, and session persistence settings[doc4].

Session Persistence

• Session Persistence Settings: Review the session persistence settings to ensure that they match the application requirements. For applications like shopping carts, where session persistence is crucial, the settings should be configured to maintain client IP or client IP and protocol persistence[doc4].

Traffic Distribution

• Traffic Distribution Mechanism: Azure Load Balancer uses a five-tuple hash consisting of source IP address, source port, destination IP address, destination port, and protocol type to map traffic to servers. This ensures that traffic is distributed evenly unless session persistence settings override this behavior[doc4].

NAT Rules

• NAT and Load-Balancing Rules: If Network Address Translation (NAT) is used, ensure that NAT rules are correctly combined with load-balancing rules. This is important for scenarios like enabling remote desktop access from outside of Azure[doc4].

Additional Scenarios

• Multi-tier Applications: For internet-facing multi-tier applications where the backend tiers are not internet-facing, ensure that traffic load balancing is correctly implemented from the internet-facing tier to the backend tiers[doc1].
• On-premises to Azure: When applying load balancing from on-premises computers to virtual machines within the same virtual network, confirm that the setup allows for efficient traffic management[doc2][doc5].
• Internal Load Balancer: For scenarios that require an internal load balancer, such as line-of-business applications hosted in Azure, make sure it is implemented to achieve the desired load balancing[doc3][doc5].

For more detailed information on configuring and troubleshooting Azure Load Balancer, you can refer to the official Azure documentation: - Azure Load Balancer Overview - Load Balancer Configuration - Troubleshoot Azure Load Balancer

Please note that while URLs are provided for additional information, they should be accessed and reviewed to ensure they contain the most current and relevant information as of the date of the study guide’s creation.

Monitor and maintain Azure resources (10–15%)

Monitor resources in Azure

Interpretation of Metrics in Azure Monitor

Azure Monitor is a comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and on-premises environments. It helps you understand how your applications are performing and proactively identifies issues affecting them and the resources they depend on.

Overview of Azure Monitor Metrics

Metrics in Azure Monitor are numerical values that are collected at regular intervals and describe some aspect of a system at a particular time. They are lightweight and capable of supporting near real-time scenarios, making them essential for performance monitoring and operational health assessments[doc4].

Accessing Metrics

Metrics data collected by Azure Monitor can be viewed directly on the Overview page for many Azure resources within the Azure portal. For instance, an Azure virtual machine’s overview page may display several charts showing performance metrics[doc1].

Metrics Explorer

For a more detailed analysis, Azure Monitor provides the metrics explorer in the Azure portal. This tool allows you to:

• View and chart the values of multiple metrics over time.
• Interact with the charts to understand different aspects of your resources’ performance.
• Pin charts to a dashboard for a consolidated view of various metrics[doc1].

Interpreting Metrics

When interpreting metrics, consider the following:

• Time Series Data: Metrics are time-stamped records that can be analyzed to track resources’ performance over time.
• Aggregation: Metrics can be aggregated to provide summaries such as averages, counts, and maximum or minimum values, which are useful for identifying trends.
• Alerts: You can set up alerts based on specific metrics to notify you when certain thresholds are reached, indicating potential issues.

Additional Resources

For further information on Azure Monitor metrics, you can refer to the following URLs:

• Azure Monitor documentation: https://learn.microsoft.com/en-us/azure/azure-monitor/
• Azure Monitor Metrics overview: https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/data-platform-metrics
• Azure Monitor Logs overview: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/data-platform-logs

By utilizing these resources, you can gain a deeper understanding of how to interpret metrics in Azure Monitor and leverage them for monitoring and diagnostics purposes[doc3].

---

Please note that the URLs provided are for additional information and should be accessed to expand on the topics covered in this explanation.

Monitor and maintain Azure resources (10–15%)

Monitor resources in Azure

To configure log settings in Azure Monitor, you need to understand the various components and steps involved in setting up and managing logs for monitoring the performance and health of your applications and services. Here’s a detailed explanation of how to configure log settings in Azure Monitor:

Azure Monitor Logs (Log Analytics)

Azure Monitor Logs collects and organizes log and performance data from monitored resources. The data is used for analysis, visualization, and alerting. To work with Azure Monitor Logs, you typically use the Azure portal to write log queries for your datadoc2.

Provisioning and Setting Up

1. Provision the Lab Environment: Start by provisioning your environment, which may include deploying resources using an Azure Resource Manager (ARM) template. This sets the stage for testing monitoring scenarios[doc5].

2. Register Resource Providers: Ensure that the Microsoft Insights and Microsoft Alerts Management resource providers are registered. These providers are necessary for certain monitoring features to function[doc5].

3. Create a Log Analytics Workspace: A Log Analytics workspace is a unique environment for Azure Monitor log data. Each workspace has its own data repository and configuration. Data sources and solutions are associated with a workspace[doc5].

4. Configure Diagnostic Settings: Diagnostic settings in Azure allow you to specify which data you want to collect about the operation of your resources. This includes logs and metrics that describe the operation of the Azure resource[doc5].

Using Azure Monitor Logs

1. Constructing Queries: Learn how to construct queries to interactively analyze the collected log data. This is essential for making the most of Azure Monitor Logs and applying them to business scenarios[doc4].

2. Log Queries: Create log queries to analyze and visualize the data. For example, you can create a log query to chart a virtual machine’s available memory over the last hour[doc5].

3. Alert Rules: Configure alert rules based on the metrics or logs. For instance, you can create an alert rule based on the average percentage CPU and configure notifications for an action group[doc5].

4. Review and Adjust Settings: Regularly review the default monitoring settings of Azure virtual machines and adjust as necessary. Enable guest-level monitoring and Azure Monitor Agent to collect additional metrics[doc5].

Additional Resources

• For a practical demonstration, you can refer to the lab simulation provided by Microsoft, which guides you through the process of configuring Azure Monitor[doc5].
• To learn more about writing log queries, you can explore the documentation on Azure Monitor Logs and Log Analytics in the Azure portaldoc2.

By following these steps and utilizing the resources provided, you can effectively configure log settings in Azure Monitor to gain insights into your applications and services, ensuring their performance and availability.

Please note that while URLs have been included for additional information, they are not clickable in this format. You can copy and paste them into a browser to access the resources directly.

Monitor and maintain Azure resources (10–15%)

Monitor resources in Azure

Query and Analyze Logs in Azure Monitor

Azure Monitor is a comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and on-premises environments. It helps you understand how your applications are performing and proactively identifies issues affecting them and the resources they depend on.

Log Analytics

One of the core features of Azure Monitor is Log Analytics, which allows you to query and analyze the logs collected from various sources. Here’s how you can leverage Log Analytics for your monitoring data:

1. Log Analytics Workspace: Before you can query any data, you need to create a Log Analytics workspace. This is a unique environment for Azure Monitor log data, where you can collect and aggregate data from various sources[doc3][doc4].

2. Kusto Query Language (KQL): Azure Monitor Logs utilize KQL, a rich language designed to be easy to read and write, yet powerful enough to enable complex data analysis tasks. KQL is used to query large datasets and return results quickly, even with complex queries[doc3][doc5].

3. Interactive Analysis: Azure Monitor Logs can be interactively analyzed using the Azure portal. This allows you to write and run log queries on your data and visualize the results in various formats, such as charts and tablesdoc2.

4. Insights and Solutions: Some features in Azure Monitor process log data and provide insights without the need for you to write queries. These can help you quickly identify and troubleshoot issues[doc1].

5. Structured Queries: With KQL, you can structure your queries to consolidate data, perform calculations, and create projections. This enables you to analyze your data in a way that suits your specific needs[doc3].

Additional Resources

To deepen your understanding and enhance your ability to query and analyze logs in Azure Monitor, here are some resources:

• Log Analytics in Azure Monitor Overview[doc4].
• Get Started with Kusto Query Language (KQL)[doc4].
• Create a Log Analytics Workspace[doc4].
• Learn How to Write Log Queries in Azure Monitor[doc4].
• Analyze and Visualize Data in Azure Monitor[doc4].
• KQL Quick Reference Guide[doc4].
• Azure Monitor Logs Table Reference[doc4].
• Log Analytics REST API Reference[doc4].

By utilizing these resources, you can effectively query and analyze logs in Azure Monitor, gaining insights into your applications and infrastructure to maintain optimal performance and reliability.

Monitor and maintain Azure resources (10–15%)

Monitor resources in Azure

Setting Up Alert Rules, Action Groups, and Alert Processing Rules in Azure Monitor

Azure Monitor is a comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and on-premises environments. It helps you understand how your applications are performing and proactively identifies issues affecting them and the resources they depend on.

Alert Rules

Alert rules in Azure Monitor are the conditions that you set to automatically monitor your cloud resources. When the conditions of an alert rule are met, an alert is created and the corresponding action group is triggered[doc1].

To set up alert rules:

1. Identify the Target Resource: Determine which Azure resources you want to monitor[doc4].
2. Select the Signal: Choose the telemetry signal that you want to monitor for the resource. Signals can be metrics, logs, or activity logs.
3. Define the Criteria: Specify the conditions that will trigger the alert. This includes setting thresholds for metrics or particular patterns in logs.
4. Set the Severity: Assign a severity level to the alert rule to indicate its importance.
5. Create the Alert Rule: In the Azure portal, navigate to the Azure Monitor section, select the target resource, signal type, and define the criteria for triggering the alert[doc4].

Action Groups

Action groups in Azure Monitor define a collection of actions to take when an alert is triggered. These actions can include sending emails, SMS messages, pushing notifications, making voice calls, or triggering automated tasks[doc1].

To configure action groups:

1. Define Notification Preferences: Set up the methods by which you want to be notified when an alert is triggered[doc1].
2. Automate Responses: Optionally, you can define automated actions such as running Azure Functions, Logic Apps, or triggering an Azure Automation runbook[doc1].
3. Reuse Action Groups: Action groups can be reused across multiple alert rules, making it easier to manage alert responses[doc3].
4. Create or Manage Action Groups: Use the Azure portal to create new action groups or manage existing ones. This can be done by navigating to the Azure Monitor section and selecting “Action Groups”doc2.

Alert Processing Rules

Alert processing rules allow you to manage and route alerts effectively. They help you to ensure that the right people are notified and that alerts are handled in a timely manner.

To set up alert processing rules:

1. Separate Active Alerts and Alert Rules: Understand the difference between an alert rule (the condition to trigger an alert) and the active alert (the triggered state)[doc3].
2. Improve Workflow: Utilize the Azure alerts authoring experience to guide you through configuring alert rules and processing rules[doc3].
3. Monitor and Manage Alerts: Keep track of your active alerts and manage them according to your operational procedures[doc1].

For additional information and step-by-step guidance, you can refer to the following resources:

• What are Azure Monitor alerts?
• Create or edit an alert rule
• Create and manage action groups
• Manage your alert rules

By setting up alert rules, action groups, and alert processing rules in Azure Monitor, you can ensure that your Azure environment is continuously monitored and that appropriate actions are taken when potential issues are detected. This proactive approach to monitoring can help maintain the health and performance of your applications and services.

Monitor and maintain Azure resources (10–15%)

Monitor resources in Azure

Monitoring Virtual Machines with Azure Monitor Insights

Azure Monitor Insights offers a comprehensive solution for monitoring the performance and health of virtual machines (VMs) in Azure. To configure and interpret monitoring for VMs, you can follow these steps:

1. Provision the Lab Environment: Start by deploying a VM using an Azure Resource Manager (ARM) template, which defines the infrastructure and configuration for your deploymentdoc2.

2. Register Resource Providers: Ensure that the Microsoft Insights and Microsoft Alerts Management resource providers are registered, as they are necessary for monitoring and alertingdoc2.

3. Create and Configure Log Analytics Workspace: Set up a Log Analytics workspace, which is a unique environment for Azure Monitor Logs data. This workspace will store, aggregate, and analyze all the monitoring datadoc2.

4. Enable Monitoring Settings: Review and enable the default monitoring settings for Azure VMs. This includes enabling guest-level monitoring and the Azure Monitor Agent, which collects and sends monitoring data to Azure Monitordoc2.

5. Configure Diagnostic Settings: Diagnostic settings allow you to specify which performance metrics and logs are sent to Azure Monitor. This includes enabling guest-level diagnostic settings to collect more detailed data from the VM’s operating systemdoc2.

6. Review Azure Monitor Functionality: Configure Azure Monitor metrics and create alert rules based on specific metrics, such as average CPU utilization. Set up notifications for an action group to receive alerts when certain conditions are metdoc2.

7. Interpret Monitoring Data: Use Azure Monitor Logs to create log queries, such as charting the VM’s available memory over time. Run these queries to interpret the data and gain insights into the VM’s performancedoc2.

For additional information on configuring and interpreting monitoring for VMs with Azure Monitor Insights, you can refer to the following resources: - Azure Monitor VM Insights: Monitor virtual machine performance by using Azure Monitor VM Insights (sandbox)[doc4]. - Writing Queries: Write your first query with the Kusto Query Language (KQL)[doc4].

Monitoring Storage Accounts with Azure Monitor Insights

To monitor Azure Storage accounts, Azure Monitor provides you with metrics and logs that help you understand the performance and health of your storage services. You can analyze the data using Azure Monitor Logs and set up alerts based on specific metrics.

Monitoring Networks with Azure Monitor Insights

Azure Monitor also extends its capabilities to network monitoring. You can monitor network communication, analyze network performance, and detect network issues by using Azure Monitor metrics and logs. This includes monitoring data such as network traffic, connectivity, and security.

For a detailed guide on monitoring networks with Azure Monitor Insights, you can explore the Azure Monitor documentation, which provides in-depth information on how to set up and interpret network monitoring.

By following these steps and utilizing the provided resources, you can effectively configure and interpret monitoring for VMs, storage accounts, and networks using Azure Monitor Insights. This will help ensure the optimal performance and availability of your Azure resources.

Monitor and maintain Azure resources (10–15%)

Monitor resources in Azure

Use Azure Network Watcher and Connection Monitor

Azure Network Watcher is an essential tool for monitoring, diagnosing, and gaining insights into network performance and health. It provides a suite of capabilities that can help you understand, diagnose, and gain metrics about your Azure network infrastructure.

Key Features of Azure Network Watcher:

• Network Monitoring Tools: Utilize tools such as Network Watcher diagnostics and logs to identify and resolve networking issues within your Azure infrastructure[doc1].
• Connection Monitor: Azure Network Watcher Connection Monitor offers end-to-end monitoring and performance analysis of network infrastructure. It helps in verifying that network performance meets the requirements of your applications and services[doc1].

How to Use Azure Network Watcher and Connection Monitor:

1. Monitoring Virtual Networks: Configure Azure Network Watcher to monitor virtual networks. This includes setting up Connection Monitor, flow logs, NSG diagnostics, and packet capture to ensure the smooth operation of your network[doc1].

2. Diagnostic Tools: Leverage Network Watcher’s diagnostic tools to troubleshoot network and connectivity issues. Tools such as the next hop feature, IP flow verify, and VPN diagnostics can be used to diagnose problems effectively[doc2][doc3].

3. Traffic Troubleshooting: Use Network Watcher to troubleshoot traffic flow issues. This can be done by analyzing routing problems using the next hop tool or diagnosing communication problems between virtual networksdoc2.

4. Metrics and Logs: Enable metrics and logs for resources in an Azure virtual network to gain insights into network performance and health. Network Watcher provides the ability to view metrics and enable or disable logs for network resources[doc4].

5. Optimization: Utilize Network Watcher to optimize your network infrastructure. Features such as IP flow verify, next hop analysis, and network topology visualization can help you understand and improve your network setup[doc5].

Additional Resources:

• For a comprehensive understanding of Azure Network Watcher, refer to the Azure Network Watcher documentation.
• To learn about the capabilities of Network Watcher, including monitoring and diagnostic tools, visit What is Azure Network Watcher?.
• For tutorials on diagnosing network routing and communication problems, explore the following:
  • Diagnose a virtual machine network routing problem using the Azure portal.
  • Diagnose a communication problem between virtual networks using the Azure portal.

By integrating Azure Network Watcher and Connection Monitor into your network management practices, you can ensure that your Azure network infrastructure operates efficiently and meets the needs of your applications and services.

Monitor and maintain Azure resources (10–15%)

Implement backup and recovery

Create a Recovery Services vault

A Recovery Services vault is an essential component in Azure for managing and organizing your backup data. It is a storage entity that holds the backup copies of your data and workloads, ensuring that you can restore them in case of data loss or corruption. Here’s a step-by-step explanation of how to create a Recovery Services vault:

1. Access the Azure Portal: Begin by signing into the Azure portal. This is where you can manage all your Azure resources, including the creation of a Recovery Services vault.

2. Navigate to the Backup Center: Once logged in, locate the Backup center dashboard. This is a centralized place to manage and monitor backup services across Azure.

3. Create a New Vault: In the Backup center, you can create a new Recovery Services vault. To do this, you will need to provide some basic information:

   • Subscription: Choose the Azure subscription in which you want to create the vault.
   • Resource Group: Select an existing resource group or create a new one to organize your resources.
   • Vault Name: Assign a unique name to your Recovery Services vault.
   • Region: Specify the geographic region where your vault will be located. It’s recommended to choose the same region as the resources you plan to back up for optimal performance.

4. Configure Storage Redundancy: Decide on the type of storage redundancy for your vault. Azure offers locally redundant storage (LRS), zone-redundant storage (ZRS), and geo-redundant storage (GRS) options. Choose based on your backup and restore strategy requirements.

5. Set Up Soft Delete: Enable soft delete to protect your backup data from accidental or malicious deletion. With soft delete, even if a backup item is deleted, the data is retained for an additional period, allowing for recovery if needed.

6. Complete the Vault Creation: After configuring the settings, create the vault. It may take a few minutes for the vault to be provisioned. You can monitor the status in the Backup center’s Notifications area.

7. Configure Backup Policies: Once the vault is created, you can set up backup policies. These policies define when and how often the backups should occur, as well as retention rules for how long the backup data should be kept.

8. Enable Backup for Resources: Finally, enable backup for your Azure resources, such as virtual machines, SQL databases, or Azure file shares. This involves selecting the resources and associating them with the appropriate backup policy you’ve created.

For additional information on creating and configuring a Recovery Services vault, you can refer to the following resources: - Azure Recovery Services vaults overview - Set up a Recovery Services vault

Remember, the Recovery Services vault is a critical part of your data protection strategy in Azure, providing a secure and scalable solution to back up your important data and applications[doc3][doc4][doc5].

Monitor and maintain Azure resources (10–15%)

Implement backup and recovery

Create an Azure Backup Vault

An Azure Backup vault, known as a Recovery Services vault, is a storage entity in Azure that houses data for various types of Azure services, including Azure Virtual Machines, SQL workloads, Azure File shares, and more. It is a critical component for data protection and recovery strategies.

Here’s a step-by-step explanation of how to create a Recovery Services vault:

1. Navigate to the Azure Portal: Begin by logging into the Azure portal.

2. Access the Backup Center: Go to the Backup center dashboard, which provides a unified experience to manage and monitor your backups.

3. Create a New Vault: Within the Backup center, you can create a new Recovery Services vault. Click on the “+ New” button to initiate the creation process.

4. Configure Vault Settings:

   • Subscription: Select the Azure subscription in which you want to create the vault.
   • Resource Group: Choose an existing resource group or create a new one to organize your resources.
   • Vault Name: Assign a unique name to your Recovery Services vault.
   • Region: Select the geographic region where your vault will be located. It’s recommended to choose the region closest to your resources to minimize latency and ensure compliance with data residency requirements.

5. Review and Create: Once you have filled in all the necessary information, review the settings and click “Create” to provision the Recovery Services vault.

6. Configure Storage Replication: After the vault is created, you can configure the storage replication type. Azure offers two types—Locally Redundant Storage (LRS) and Geo-Redundant Storage (GRS). LRS replicates your data three times within a single physical location in the primary region, while GRS replicates your data to a secondary region to protect against regional outages.

7. Set Up Backup Policies: Define backup policies that dictate how often the data is backed up and how long the backup data is retained.

8. Monitor and Manage: Use the Azure portal to monitor the status of backup jobs, restore data, and manage the Recovery Services vault.

For additional information and detailed steps, you can refer to the following URLs:

• What is the Azure Backup service?
• Create and configure a Recovery Services vault
• Manage Azure file share backups

Remember, within an Azure subscription, you can create up to 500 Recovery Services vaults per region[doc1]. It’s also important to note that creating a Recovery Services vault can take several minutes, and you can monitor the operation status in the Backup center Notifications area[doc1].

By following these steps, you can successfully create an Azure Backup vault to protect your data and ensure business continuity.

Monitor and maintain Azure resources (10–15%)

Implement backup and recovery

Creating and configuring a backup policy is an essential step in ensuring data protection and recovery in the event of data loss or corruption. Here’s a detailed explanation of how to create and configure a backup policy:

1. Selecting the Backup Tool: Begin by choosing the appropriate backup tool for your data. For Azure services, you can use the Azure Backup service, which provides a range of backup options tailored to different Azure resources.

2. Installation of Backup Agent (if required): For certain types of backups, you may need to install a backup agent on the resource you wish to protect. For example, the Microsoft Azure Recovery Services (MARS) agent, also known as the Azure Backup agent, is used for backing up files, folders, and system state data[doc4].

3. Creating a Backup Policy: A backup policy defines the schedule and settings for your backups. In the Azure portal, you can create a backup policy by specifying:

   • Frequency of Backups: Decide how often you want to back up your data. This could be daily, weekly, or at any other regular interval.
   • Type of Data to Backup: Select the specific data or resources you want to protect. This could range from files and folders to entire virtual machines.
   • Retention Period: Determine how long you want to retain each backup. Retention settings can vary based on the importance of the data and compliance requirements.

4. Configuring Advanced Settings:

   • Network Throttling: To manage bandwidth usage during backup operations, you can configure network throttling settings[doc1].
   • Soft Delete: This feature allows you to retain backup data for a period even after it has been deleted, providing an additional layer of protection against accidental deletions[doc5].

5. Implementing the Policy: Once the policy is created, apply it to the resources you want to back up. You can do this by associating the policy with the backup items in your Azure Backup Recovery Services vault[doc4].

6. Monitoring and Management: After the backup policy is in place, monitor the backup jobs to ensure they are completing successfully. You can also manage existing backups, such as performing restores or changing backup policiesdoc2.

7. Lifecycle Management: For Azure Blob storage, you can create lifecycle management policy rules to automate the transition or expiration of data based on your specifications. This helps in managing the data lifecycle without manual intervention[doc3].

For additional information and step-by-step guidance, you can refer to the following resources: - What is the Azure Backup service? - Back up Azure file shares in the Azure portal - Create and configure a Recovery Services vault - Manage Azure file share backups - Install the Azure Backup MARS agent

By following these steps and utilizing the provided resources, you can effectively create and configure a backup policy to protect your Azure resources.

Monitor and maintain Azure resources (10–15%)

Implement backup and recovery

Perform Backup and Restore Operations Using Azure Backup

Azure Backup is a versatile and secure service designed to protect your data in the Microsoft cloud. It serves as a replacement for traditional on-premises or off-site backup solutions, offering a reliable and cost-effective cloud-based alternative. Azure Backup is capable of backing up data to a Recovery Services vault in Azure, ensuring that your data is safeguarded and restorable in the event of data loss or corruptiondoc2.

Key Features of Azure Backup:

• Independent and Isolated Backups: Azure Backup ensures that backups are independent and isolated, providing protection against accidental data destruction[doc1].
• Application-Consistent Backups: It provides application-consistent backups, which means that the backups include all the necessary data to restore the backup copy without requiring additional fixes, thus reducing restoration time[doc3].
• Unlimited Data Transfer: There are no charges for inbound or outbound data transfer during backup or restore operations, except for data imported using the Azure Import/Export service[doc3].
• Data Encryption: Azure Backup secures your data during transmission and storage in the cloud. The encryption passphrase is stored locally and never transmitted or stored in Azure[doc3].
• Long-Term Retention: You can retain data in a Recovery Services vault for as long as needed, with Azure Backup supporting up to 9,999 recovery points per protected instance[doc3].
• Automatic Storage Management: Azure Backup automatically allocates and manages backup storage, using a pay-as-you-use model to minimize costs[doc3].
• Multiple Storage Options: Azure Backup offers locally redundant storage (LRS) and geo-redundant storage (GRS) to ensure high availability and durability of your data[doc3].

Backup and Restore Operations:

1. Configuring Azure Backup:
   • Determine the appropriate Azure Backup component to deploy based on what you want to protect.
   • Deploy the component on the computer, server, or in the cloud.
   • Configure the backup policy and scheduledoc2.
2. Performing Backups:
   • Use Azure Backup to create a backup job.
   • Monitor the backup job to ensure that it completes successfully.
   • Backups are stored in an Azure Recovery Services vault, with management of recovery points[doc1][doc3].
3. Restoring Data:
   • In the event of data loss, you can restore entire virtual machines or specific files from the Azure Backup service.
   • The restoration process involves selecting the appropriate recovery point and initiating the restore operation.
   • Azure Backup allows for the restoration of data in a secure and efficient manner[doc1].
4. Soft Delete:
   • Azure Backup includes a feature called soft delete, which provides an additional layer of protection by retaining backup data for a period even after it has been deleted, allowing for recovery if the deletion was unintended[doc1].

For additional information and training on Azure Backup, you can refer to the following resources:

• Introduction to Azure Backup
• Protect your virtual machines by using Azure Backup (exercise, subscription required)
• Implement hybrid backup and recovery with Windows Server IaaS (exercise, subscription required)

Azure Backup integrates seamlessly with existing Azure services, providing a centralized solution for backup governance, monitoring, operation, and analysis. It is designed to simplify the backup process for both on-premises and cloud resources, ensuring that your data is always protected and recoverable[doc5].

Monitor and maintain Azure resources (10–15%)

Implement backup and recovery

Configure Azure Site Recovery for Azure Resources

Azure Site Recovery is a critical service for ensuring business continuity by enabling failover and continued access to applications in the event of an outage. It provides a range of features that support various backup and disaster recovery scenarios. Here’s a detailed explanation of how to configure Azure Site Recovery for Azure resources:

1. Consolidated Management:
   • Azure Site Recovery allows you to set up, manage replication, failover, and failback from a single location within the Azure portal[doc5].
2. Replication Options:
   • You can replicate Azure virtual machines from one Azure region to another, ensuring that your applications remain available even if one region goes down[doc4].
   • Azure Site Recovery also supports replication of on-premises VMware VMs, Hyper-V VMs, physical servers (Windows and Linux), and Azure Stack VMs to Azure[doc4].
3. Replication Resilience:
   • The service orchestrates replication without intercepting your application data, leveraging the resilience of Azure Storage. During failover, Azure VMs are created based on the replicated data[doc5].
4. Continuous Replication:
   • Azure Site Recovery offers continuous replication for Azure VMs and VMware VMs, with replication frequency as low as 30 seconds for Hyper-V[doc5].
5. Snapshot Recovery Points:
   • Replication can be performed using recovery points with application-consistent snapshots that capture disk data, all data in memory, and all transactions in process[doc5].
6. Failover and Easy Fall Back:
   • The service enables planned failovers for expected outages with zero data loss and unplanned failovers with minimal data loss, depending on replication frequency. It also allows for easy fallback to the primary site when it becomes available again[doc5].
7. Integration:
   • Azure Site Recovery integrates with Azure for simplified application network management, including reserving IP addresses, configuring load balancers, and integrating Azure Traffic Manager for efficient network switchovers[doc5].

For additional information and step-by-step guidance on configuring Azure Site Recovery for Azure resources, you can refer to the following URLs:

• Introduction to Azure Site Recovery
• Protect your Azure infrastructure with Azure Site Recovery
• Quickstart: Set up disaster recovery to a secondary Azure region for an Azure VM

By following the above steps and utilizing the provided resources, you can effectively configure Azure Site Recovery to protect your Azure resources and ensure that your applications remain available and resilient in the face of potential disruptions.

Monitor and maintain Azure resources (10–15%)

Implement backup and recovery

Perform a Failover to a Secondary Region Using Azure Site Recovery

Azure Site Recovery is a critical service designed to ensure business continuity by enabling the replication of workloads from a primary site to a secondary location. In the event of an outage at the primary site, Azure Site Recovery facilitates a smooth transition to the secondary site, ensuring that applications remain accessible and business operations can continue with minimal disruption[doc1].

Steps to Perform a Failover to a Secondary Region:

1. Set Up Replication:
   • Begin by setting up and managing replication from a single location within the Azure portal. This involves configuring the replication of virtual machines from the primary region to the secondary regiondoc2.
2. Continuous Replication:
   • Azure Site Recovery offers continuous replication for Azure virtual machines, VMware virtual machines, and Hyper-V, with replication frequencies as low as 30 seconds. This ensures that the secondary region has the most up-to-date data possibledoc2.
3. Snapshot Recovery Points:
   • Utilize recovery points with application-consistent snapshots. These snapshots capture disk data, all data in memory, and all transactions in process, providing a reliable recovery point for failoverdoc2.
4. Initiate Failover:
   • In the event of an outage, initiate a failover from the Azure portal. You can perform planned failovers for expected outages with zero data loss or unplanned failovers with minimal data loss, depending on the replication frequencydoc2.
5. Failover and Easy Fall Back:
   • Once the failover is initiated, Azure virtual machines are created in the secondary region based on the replicated data. After the primary site is available again, you can easily fall back to itdoc2.
6. Integration with Azure Services:
   • Integrate with Azure services for efficient network management during failover. This includes reserving IP addresses, configuring load balancers, and integrating Azure Traffic Manager for network switchoversdoc2.

Additional Resources:

• To learn more about creating an Azure storage account, which is a prerequisite for implementing Azure Site Recovery, visit the following module: Create an Azure storage account (sandbox)[doc3].

• For a deeper understanding of Azure Site Recovery and its capabilities, refer to the module: Introduction to Azure Site Recovery[doc4].

• To explore how to complete site-to-site recovery using Azure Site Recovery, review the module: Protect your Azure infrastructure with Azure Site Recovery[doc4].

By following these steps and utilizing the resources provided, you can effectively perform a failover to a secondary region using Azure Site Recovery, ensuring that your applications and services remain available to your customers even during unforeseen outages.

Monitor and maintain Azure resources (10–15%)

Implement backup and recovery

Configure and Interpret Reports and Alerts for Backups

When configuring and interpreting reports and alerts for backups, it is essential to understand the tools and services provided by Azure to manage and monitor backup operations effectively. Azure Backup Center and Azure Monitor are two critical services that facilitate these tasks.

Backup Center: Azure Backup Center provides a unified management experience that allows you to govern, monitor, operate, and analyze backups across various Azure services. It leverages the Azure Policy experience to help you implement governance over your backup tasks and uses Azure Workbooks and Azure Monitor Logs to deliver detailed reporting on backup activitiesdoc2.

Key features of Backup Center include: - Native Integrations: Backup Center integrates with existing Azure services, enabling management at scale without the need to learn new principlesdoc2. - Governance: Utilize Azure Policy to enforce and audit backup policies across your Azure environmentdoc2. - Reporting: Access detailed reports through Azure Workbooks and Azure Monitor Logs, which provide insights into the backup status and healthdoc2.

Azure Monitor Alerts: Azure Monitor offers the capability to create and manage alerts that notify you of any issues with your backup operations. Alerts can be configured based on specific conditions and can trigger various response actions[doc3].

To configure and interpret alerts, you should: - Create Alert Rules: Define the conditions under which an alert should be triggered, such as failures or deviations from expected backup schedules[doc3]. - Manage Alert Instances: Review and manage active alerts to address any ongoing issues[doc3]. - Set Up Response Actions: Determine the actions that should be taken when an alert is triggered, which could include automated scripts or notifications[doc3].

Additional Resources: For more detailed guidance on using Azure Backup and configuring alerts, the following resources can be helpful: - What is the Azure Backup service?: Reviews the benefits of Azure Backup. - Back up Azure file shares in the Azure portal: Covers the steps to use Azure Backup for file and folder backups. - Create and configure a Recovery Services vault: Describes how to create and configure an Azure Backup Recovery Services vault. - Manage Azure file share backups: Shows how to monitor and create reports for Azure file and folder backups. - Install the Azure Backup MARS agent: Explains how to install the Microsoft Azure Recovery Services (MARS) agent for backing up files and folders.

By utilizing these tools and resources, you can ensure that your backup operations are well-managed, and you are promptly alerted to any issues, allowing for quick resolution and maintaining the integrity of your data backups.

Monitor and maintain Azure resources (10–15%)

Implement backup and recovery

Configure and Interpret Reports and Alerts for Backups

When configuring and interpreting reports and alerts for backups, it is essential to understand the tools and services provided by Azure to manage and monitor backup operations effectively.

Backup Center Integration with Azure Services Backup Center offers native integrations with existing Azure services, allowing for management at scale. It leverages the Azure Policy experience to help govern backups and utilizes Azure Workbooks and Azure Monitor Logs (Log Analytics) for detailed reporting on backup activitiesdoc2.

Azure Monitor Alerts Azure Monitor provides options for creating and managing alert instances, rules, conditions, and response actions. These alerts can notify you of any issues with your backup operations, ensuring that you can respond promptly to any potential problems[doc3].

Azure Backup Reports Azure Backup provides detailed reports that help you monitor and analyze your backups. These reports can be accessed through Backup Center and are essential for understanding the status and health of your backupsdoc2.

Recovery Services Vault The Recovery Services vault is a storage entity in Azure that houses your backups and recovery points. It is crucial to create and configure a Recovery Services vault properly to ensure that your backups are secure and recoverable[doc4].

Azure Backup MARS Agent The Microsoft Azure Recovery Services (MARS) agent, also known as the Azure Backup agent, is used to back up files and folders from on-premises machines and Azure VMs. It is an integral part of the backup process and must be installed and configured correctly[doc4][doc5].

Main Takeaways - Azure Backup simplifies the backup process for both on-premises and cloud resources. - Backup Center allows for enterprise-level governance, monitoring, operation, and analysis of backups in Azure. - Detailed reports on backups are provided through integration with Azure services. - The MARS agent is used for backing up on-premises files and folders, as well as Azure VMs. - Backups are securely stored in the Recovery Services vault[doc5].

For additional information on configuring and interpreting reports and alerts for backups, you can refer to the following resources: - What is the Azure Backup service? - Back up Azure file shares in the Azure portal - Create and configure a Recovery Services vault - Manage Azure file share backups - Install the Azure Backup MARS agent