posted on June 02, 2024, last updated on Saturday, November 23, 2024 at 10:51 AM

Availability set

Fault Domain

• Definition: A fault domain is essentially a group of VMs that share a common power source and network switch. By default, Azure distributes VMs in an availability set across up to three fault domains.
• Purpose: Fault domains are designed to protect against hardware failures, such as issues with the physical server, rack, or data center. If one fault domain fails, the VMs in the other fault domains remain unaffected.
• Example: If you have three VMs in an availability set, they might be placed in three different fault domains, ensuring that a failure in one domain (e.g., a network switch failure) does not affect the VMs in the other domains.

Update Domain

• Definition: An update domain is a group of VMs that can be updated or rebooted at the same time. By default, Azure distributes VMs in an availability set across up to five update domains.
• Purpose: Update domains are used to manage the application of updates (e.g., patches or software updates) without causing downtime for all VMs in an availability set. Updates are applied one update domain at a time, ensuring that the VMs in other update domains remain available during the process.
• Example: If you have five VMs in an availability set, they might be placed in five different update domains. During maintenance, Azure will update VMs in one update domain at a time, so only one-fifth of your VMs might be rebooted at any given time.

Key Differences

• Scope of Protection:
  • Fault Domain: Protects against hardware failures.
  • Update Domain: Protects against simultaneous reboots during maintenance or updates.
• Number:
  • Fault Domain: Typically up to 3 fault domains.
  • Update Domain: Typically up to 5 update domains.
• Function:
  • Fault Domain: Ensures VMs are spread across different physical hardware to mitigate hardware failure risk.
  • Update Domain: Ensures VMs are updated or rebooted in phases to maintain service availability during maintenance.

Management group

In Microsoft Azure, a subscription can indeed be a member of only one management group at a time. Management groups in Azure are used to manage access, policy, and compliance across multiple Azure subscriptions. Each subscription must be associated with a single management group, but management groups can be nested to provide a hierarchical structure for management.

SAS

Shared Access Signatures (SAS) in Microsoft Azure provide secure delegated access to resources in your storage account. A SAS token can be used to grant limited access to storage resources without exposing your account key. SAS tokens are supported by various Azure storage services, allowing you to fine-tune permissions and duration of access.

Supported services: Blob, Queue, Table, File.

Services Supported by SAS Keys

1. Azure Blob Storage:
   • Containers
   • Blobs
   • Blob snapshots
   • Supports operations like reading, writing, deleting, listing, and setting metadata on blobs and containers.
2. Azure Queue Storage:
   • Queues
   • Messages
   • Supports operations like adding, updating, reading, and deleting messages.
3. Azure Table Storage:
   • Tables
   • Entities
   • Supports operations like querying, inserting, updating, and deleting table entities.
4. Azure File Storage:
   • File shares
   • Directories
   • Files
   • Supports operations like reading, writing, deleting files, and managing file shares and directories.

Types of SAS Tokens

1. Service SAS:
   • Grants access to resources in a specific service (Blob, Queue, Table, File).
   • You can specify permissions, resource types, start and expiry times, and IP address range.
2. Account SAS:
   • Grants access to resources in any service within the storage account.
   • Provides more granular control, including access to service-level operations like listing the blobs in the account.
   • Permissions include service operations, service-level actions, and the ability to use specific protocols.
3. User Delegation SAS:
   • Available for Azure Blob Storage.
   • Uses Azure Active Directory (Azure AD) credentials to secure the SAS.
   • Allows generating SAS tokens with permissions defined by the user’s Azure AD roles.

Permissions in SAS Tokens

• Read (r): Permits reading resources.
• Write (w): Permits writing or creating new resources.
• Delete (d): Permits deleting resources.
• List (l): Permits listing resources.
• Add (a): Permits adding messages (Queue Storage) or new resources.
• Create (c): Permits creating new resources.
• Update (u): Permits updating resources.
• Process (p): Permits processing messages (Queue Storage).

Example Use Cases

• Blob Storage: Generate a SAS token to allow a client to upload images to a blob container without granting full access to the storage account.
• File Storage: Create a SAS token to enable temporary access to a file share for a user to download files.
• Queue Storage: Provide limited access to a queue for an application to add messages without exposing the queue’s full access key.
• Table Storage: Grant access to a table for querying specific entities without exposing the entire storage account key.

Using an Azure file share with Windows

To use an Azure file share with Windows, you must either mount it, which means assigning it a drive letter or mount point path, or access it via its UNC path.

This article uses the storage account key to access the file share. A storage account key is an administrator key for a storage account, including administrator permissions to all files and folders within the file share you’re accessing, and for all file shares and other storage resources (blobs, queues, tables, etc.) contained within your storage account. If this isn’t sufficient for your workload, you can use Azure File Sync or identity-based authentication over SMB. Shared access signature (SAS) tokens aren’t currently supported for mounting Azure file shares.

Conclusion

SAS tokens provide a secure and flexible way to grant limited access to various Azure storage services. By leveraging SAS tokens, you can control access to your storage resources precisely, ensuring that users and applications have the permissions they need without exposing sensitive account keys.

Authorization methods for AzCopy

• MS Entra ID (AzureAD)
• SAS token

VM scale set

Virtual Machine Scale Sets support both Linux and Windows VMs in Azure and can run up to 1,000 VMs on a single scale set.

The criteria used to activate the upscale or downscale can depend on a customized schedule or actual demand and usage. Scale sets can apply the same configuration to a group of VMs simultaneously. They don’t require you to manually configure instances individually if you don’t want to.

Before you begin the upgrade process, the orchestrator will ensure that no more than 20% of instances in the entire scale set are unhealthy (for any reason), and for 1 instance at minimum (leq 5 instances).

OS image upgrade versus reimage

Both OS Image Upgrade and Reimage are methods used to update VMs within a scale set, but they serve different purposes and have distinct impacts.

OS image upgrade involves updating the underlying operating system image that is used to create new instances in a scale set. When you perform an OS image upgrade, Azure will create new VM instances with the updated OS image and gradually replace the old VM instances in the scale set with the new ones. This process is typically performed in stages to ensure high availability. OS image upgrades are a non-disruptive way to apply updates or changes to the underlying OS of the VMs in a scale set. Existing VM instances are not affected until they are replaced with the new instances.

Reimaging a VM instance in a scale set is a more immediate and disruptive action. When you choose to reimage a VM instance, Azure will stop the selected VM instance, perform the reimage operation, and then restart the VM using the same OS image. This effectively reinstalls the OS on that specific VM instance. Reimaging is typically used when you need to troubleshoot or reset a specific VM instance due to issues with that instance.

General roles

Built-in role	Description	ID
Contributor	Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.	b24988ac-6180-42a0-ab88-20f7382dd24c
Owner	Grants full access to manage all resources, including the ability to assign roles in Azure RBAC.	8e3af657-a8ff-443c-a75c-2fe8c4bcb635
Reader	View all resources, but does not allow you to make any changes.	acdd72a7-3385-48ef-bd42-f606fba81ae7
Role Based Access Control Administrator	Manage access to Azure resources by assigning roles using Azure RBAC. This role does not allow you to manage access using other ways, such as Azure Policy.	f58310d9-a9f6-439a-9e8d-f62e7b41a168
User Access Administrator	Lets you manage user access to Azure resources.	18d7d88d-d35e-4fb5-a5c3-7773c20a72d9

VM size naming convention

1. General purpose:
   • Prefix: D, A, B
   • Suffix: s (standard), v (version), p (premium), l (low priority), d (disk), a (availability)
   • Examples: B, Dsv3, Dv3, Dasv4, Dav4, DSv2, Dv2, Av2, Dpdsv5, Dpldsv5, Dpsv5, Dplsv5, Dv4, Dsv4, Ddv4, Ddsv4, Dv5, Dsv5, Ddv5, Ddsv5, Dasv5, Dadsv5, DCasv5, DCadsv5, DCesv5, DCedsv5
2. Compute optimized:
   • Prefix: F
   • Suffix: s (standard), v (version), X (special)
   • Examples: F, Fs, Fsv2, FX
3. Memory optimized:
   • Prefix: E, M, D (some overlap with general purpose)
   • Suffix: s (standard), v (version), p (premium), d (disk), a (availability), C (confidential)
   • Examples: Esv3, Ev3, Easv4, Eav4, Epdsv5, Epsv5, Ev4, Esv4, Edv4, Edsv4, Ev5, Esv5, Edv5, Edsv5, Easv5, Eadsv5, Mv2, M, DSv2, Dv2, ECasv5, ECadsv5, ECesv5, ECedsv5
4. Storage optimized:
   • Prefix: L
   • Suffix: s (standard), v (version), a (availability)
   • Examples: Lsv2, Lsv3, Lasv3
5. GPU:
   • Prefix: N
   • Suffix: v (version), A (specific GPU type), T (Tesla), r (remote), X (special), s (standard), m (multi-instance)
   • Examples: NC, NCv2, NCv3, NCasT4_v3, NCA100v4, ND, NDv2, NGadsV620, NV, NVv3, NVv4, NDasrA100_v4, NDm_A100_v4
6. High performance compute:
   • Prefix: H
   • Suffix: B (batch), C (compute), X (special), v (version)
   • Examples: HB, HBv2, HBv3, HBv4, HC, HX

VPN gateways

https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal

VM scale set az vmss

az vmss scale - change the number of VMs within a VMSS.

Port numbers for common protocols

Protocol	Port Number	Description
HTTP	80	Hypertext Transfer Protocol for web traffic.
HTTPS	443	Secure Hypertext Transfer Protocol for encrypted web traffic.
FTP	21	File Transfer Protocol for transferring files.
FTPS	990	Secure File Transfer Protocol over SSL/TLS.
SFTP	22	Secure File Transfer Protocol over SSH.
SSH	22	Secure Shell for secure remote login and command execution.
Telnet	23	Telnet protocol for unencrypted remote login (not recommended).
SMTP	25	Simple Mail Transfer Protocol for sending emails.
SMTPS	465	Secure SMTP over SSL.
IMAP	143	Internet Message Access Protocol for retrieving emails.
IMAPS	993	Secure IMAP over SSL.
POP3	110	Post Office Protocol version 3 for retrieving emails.
POP3S	995	Secure POP3 over SSL.
RDP	3389	Remote Desktop Protocol for remote desktop access.
DNS	53	Domain Name System for resolving domain names.
MySQL	3306	MySQL database service.
PostgreSQL	5432	PostgreSQL database service.
SQL Server	1433	Microsoft SQL Server database service.
Oracle DB	1521	Oracle database service.
MongoDB	27017	MongoDB database service.
Redis	6379	Redis in-memory data structure store.
Memcached	11211	Memcached caching service.
NTP	123	Network Time Protocol for clock synchronization.
LDAP	389	Lightweight Directory Access Protocol.
LDAPS	636	Secure LDAP over SSL.
Kerberos	88	Kerberos authentication protocol.
NetBIOS	137, 138, 139	NetBIOS over TCP/IP for network services.
SMB/CIFS	445	Server Message Block/Common Internet File System for file sharing.
VPN (PPTP)	1723	Point-to-Point Tunneling Protocol for VPN.
IKEv2	500	Internet Key Exchange for VPN.
L2TP	1701	Layer 2 Tunneling Protocol for VPN.
ESP	50	Encapsulating Security Payload for VPN.
GRE	47	Generic Routing Encapsulation for VPN.

Tutorial: Create a site-to-site VPN connection

VNet preparation

Name	Type	Address	Note
TestRG1	Resource Group
VNet1	Virtual Network	10.1.0.0/16	Central Canada
FrontEnd	Subnet	10.1.0.0/24

Create a gateway subnet

Create a VPN gateway

1. In search bar, search “Virtual network gateways”

2. Create a virtual network gateway with the following configs:

   

VM backup

https://learn.microsoft.com/en-us/azure/backup/backup-azure-vms-first-look-arm

SSPR

SSPR is a centralized self-service password reset portal for accounts under Azure tenants.

Requirements:

• P1 license and up
• Users with admin roles have more strict reset policies.
  • a strong default two-gate policy is enforced.
    • requires two pieces of authentication data:
      • Email address
      • authenticator app
      • phone number
    • security questions are prohibited
  • cmdlet Update-MgPolicyAuthorizationPolicy can be used to enable/disable SSPR for admin users with parameter -AllowedToUseSspr

DNS verification process

The purpose of DNS verification using a TXT or MX record (containing a random token) is to confirm that the entity requesting the service owns the target domain. After verification, Azure provides the detailed configuration information to the verified domain owner.

To use custom domains, first we need to register this domain at a registrar, then, configure the name server to one of the Azure NSs. Then, we can use Azure to manage the domain (including connecting to vnets and more).

DNS Resolution Process

1. Local DNS Resolver:
   • When a user enters a domain name (e.g., example.com) in their browser, the request first goes to the user’s local DNS resolver, which is usually managed by their ISP or configured on their network.
2. Check Local Cache:
   • The local DNS resolver checks its cache to see if it already has a recent response for the domain name. If it does, it returns the cached result, skipping further steps.
3. Query the Root DNS Servers:
   • If the local DNS resolver does not have the cached result, it queries one of the root DNS servers. The root DNS servers know the authoritative servers for all top-level domains (TLDs, like .com, .net, etc.).
4. TLD DNS Servers:
   • The root DNS server responds with the address of the TLD DNS server responsible for .com domains.
   • The local DNS resolver then queries the TLD DNS server for example.com.
5. Authoritative DNS Servers (Azure DNS):
   • The TLD DNS server responds with the address of the authoritative DNS servers for example.com, which are the Azure DNS servers you configured.
   • The local DNS resolver queries one of the Azure DNS servers for example.com.
6. Retrieve DNS Records:
   • The Azure DNS server responds with the DNS records for example.com (e.g., the IP address associated with the domain).
7. Return Response to Client:
   • The local DNS resolver caches the response and returns the result to the user’s machine.
   • The browser can now connect to the IP address returned and load the website.

Example Walkthrough

1. User Input:
   • User enters www.example.com in their browser.
2. Local DNS Cache:
   • The local DNS resolver checks if www.example.com is in its cache.
3. Root Server Query:
   • If not in cache, the local DNS resolver queries a root DNS server.
4. TLD Server Query:
   • Root DNS server responds with the TLD DNS server for .com.
5. Authoritative DNS Server Query:
   • The local DNS resolver queries the TLD DNS server for example.com.
   • TLD DNS server responds with the Azure DNS servers.
6. Azure DNS Response:
   • The local DNS resolver queries the Azure DNS server for www.example.com.
   • Azure DNS server responds with the IP address (e.g., 192.0.2.1).
7. Browser Connects:
   • The local DNS resolver caches the response and returns the IP address to the browser.
   • The browser connects to 192.0.2.1 and loads the website.

Storage replication strategies

LRS

ZRS

GRS

GZRS

Node in data center unavailable	Entire data center unavailable	Region-wide outage	Read access during region-wide outage
- LRS - ZRS - GRS - RA-GRS - GZRS - RA-GZRS	- ZRS - GRS - RA-GRS - GZRS - RA-GZRS	- GRS - RA-GRS - GZRS - RA-GZRS	- RA-GRS - RA-GZRS

SAS features

• Signing method
• Signing key
  • MS-managed keys
  • customer-managed keys
• Permissions
• Start and Expiry date/time
• Allowed IP
• Allowed protocols

URI definitions

• Resource URI
• sv - storage version
• ss - storage service
• st - start time
• se - expiry time
• sr - resource
• sp - permissions
• sip - ip range
• spr - protocol
• sig - signature

Summary of supported authentication methods in azcopy

Service	Supported Authentication Methods
Azure Blob Storage	SAS, OAuth
Azure Files	Share/Directory SAS
Azure Data Lake Storage Gen2	SAS, OAuth, Shared Key
AWS S3 to Azure Blob	Access Key (AWS) to SAS, OAuth (Azure Blob)
Google Cloud Storage to Azure Blob	Service Account Key (GCS) to SAS, OAuth (Azure Blob)

Azure backup services

Access tiers

Feature	Snapshot Tier	Vault-Standard Tier	Archive Tier
Storage Location	Customer’s subscription	Microsoft-managed tenant	Long-term, low-cost storage
Restoration Speed	Fastest	Moderate	Slowest
Availability	Locally available	Isolated copy	For compliance, rarely accessed
Use Cases	Quick restores	Regular backup and restore operations	Long-term retention for compliance
RTO	Low	Moderate	High
Pricing	Higher storage cost	Moderate cost	Lowest cost

Built-in security measures

• RBAC
• Encryption
• Soft-delete

VM Protections

• Azure Backup

  Snapshot of the entire vm. Restore the entire

• Azure Site Recovery

• Azure managed disks

  • snapshot
  • image

images - the whole vm

snapshots - one disk

operating disk backups - for vm with only one disk

Soft delete

Steps:

• Stop backup job
• Apply soft-delete state
• View soft-delete data in the vault - during the 14 day retention period.
• Undelete backup items
• Restore items
• Resume backups

Entra ID

Your company makes use of Multi-Factor Authentication for when users are not in the office. The

Per Authentication option has been configured as the usage model.

After the acquisition of a smaller business and the addition of the new staff to Azure Active

Directory (Azure AD) obtains a different company and adding the new employees to Azure Active

Directory (Azure AD), you are informed that these employees should also make use of Multi-

Factor Authentication.

To achieve this, the Per Enabled User setting must be set for the usage model.

Solution: You reconfigure the existing usage model via the Azure portal.

Does the solution meet the goal?

Your company has an Azure Active Directory (Azure AD) tenant named weyland.com that is

configured for hybrid coexistence with the on-premises Active Directory domain.

You have a server named DirSync1 that is configured as a DirSync server.

You create a new user account in the on-premise Active Directory. You now need to replicate the

user information to Azure AD immediately.

Solution: You run the Start-ADSyncSyncCycle -PolicyType Initial PowerShell cmdlet.

Does the solution meet the goal?

Start-ADSyncSyncCycle -PolicyType Delta

Move an app to a different region

The region in which your app runs is the region of the App Service plan it’s in. However, you cannot change an App Service plan’s region. If you want to run your app in a different region, one alternative is app cloning. Cloning makes a copy of your app in a new or existing App Service plan in any region.

You can find Clone App in the Development Tools section of the menu.

Steps:

1. Create a back up of the source app.
2. Create an app in a new App Service plan, in the target region.
3. Restore the back up in the target app
4. If you use a custom domain, bind it preemptively to the target app with asuid. and enable the domain in the target app.
5. Configure everything else in your target app to be the same as the source app and verify your configuration.
6. When you’re ready for the custom domain to point to the target app, remap the domain name.

Load Balancer SKUs

	Standard Load Balancer	Basic Load Balancer
Scenario	Equipped for load-balancing network layer traffic when high performance and ultra-low latency is needed. Routes traffic within and across regions, and to availability zones for high resiliency.	Equipped for small-scale applications that don’t need high availability or redundancy. Not compatible with availability zones.
Backend type	IP based, NIC based	NIC based
Protocol	TCP, UDP	TCP, UDP
Backend pool endpoints	Any virtual machines or virtual machine scale sets in a single virtual network	Virtual machines in a single availability set or virtual machine scale set
Health probes	TCP, HTTP, HTTPS	TCP, HTTP
Health probe down behavior	TCP connections stay alive on an instance probe down and on all probes down.	TCP connections stay alive on an instance probe down. All TCP connections end when all probes are down.
Availability Zones	Zone-redundant, zonal, or non-zonal frontend IP configurations can be used for inbound and outbound traffic	Not available
Type	Internal, Public	Internal, Public
Frontend IP configuration	When using a Public Standard Load Balancer, the SKU of the public IP must be Standard. Basic Public IPs are not supported on Standard LB	When using a Public Basic Load Balancer, the SKU of the public IP must be Basic. Standard Public IPs are not supported on Basic LB
Diagnostics	Azure Monitor multi-dimensional metrics	Not supported
HA Ports	Available for Internal Load Balancer	Not available
Secure by default	Closed to inbound flows unless allowed by a network security group. Internal traffic from the virtual network to the internal load balancer is allowed.	Open by default. Network security group optional.
Outbound Rules	Declarative outbound NAT configuration	Not available
TCP Reset on Idle	Available on any rule	Not available
Multiple front ends	Inbound and outbound	Inbound only
Management Operations	Most operations < 30 seconds	60-90+ seconds typical
SLA	99.99%	Not available
Global VNet Peering Support	Standard Internal Load Balancer is supported via Global VNet Peering	Not supported
NAT Gateway Support	Both Standard Internal Load Balancer and Standard Public Load Balancer are supported via Nat Gateway	Not supported
Private Link Support	Standard Internal Load Balancer is supported via Private Link	Not supported
Global tier	Standard Load Balancer supports the Global tier for Public Load Balancers enabling cross-region load balancing	Not supported

Azure governance tools

A. Azure Traffic Analytics

Azure Traffic Analytics is a cloud-based solution that provides visibility into user and application traffic on your Azure virtual network. It leverages Network Security Group (NSG) flow logs to give you insights into traffic patterns and identify potential security threats.

Key Features:

• Network Traffic Visibility: Provides a comprehensive view of the traffic flow in your Azure network.
• Threat Detection: Helps identify potential security threats and anomalies in network traffic.
• Performance Monitoring: Monitors network performance and identifies bottlenecks.
• Compliance Reporting: Assists in compliance reporting by providing detailed traffic logs and analytics.
• Integration: Integrates with other Azure security services like Azure Security Center.

B. Azure Monitor

Azure Monitor is a full-stack monitoring service that provides a comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and on-premises environments. It helps you maximize the availability and performance of your applications and services.

Key Features:

• Data Collection: Collects data from various sources, including applications, guest operating systems, Azure resources, and custom sources.
• Metrics and Logs: Provides powerful metrics and log analytics capabilities.
• Dashboards: Customizable dashboards to visualize monitoring data.
• Alerts: Configurable alerts based on specific criteria to notify you of performance issues.
• Insights: Application Insights for monitoring application performance and dependencies.
• Diagnostics: Detailed diagnostics to troubleshoot issues.

C. Azure Activity Log

Azure Activity Log provides a record of all the activities that happen in your Azure subscription. It helps you understand the operations that were performed on resources in your subscription and provides insights into the “what, who, and when” for any write operations (PUT, POST, DELETE) taken on the resources.

Key Features:

• Operation Logs: Logs of all create, update, and delete operations performed on Azure resources.
• User and System Actions: Tracks actions performed by users and systems.
• Event Insights: Provides insights into the events that have occurred within your Azure resources.
• Audit and Compliance: Useful for auditing and compliance purposes by providing detailed logs of resource changes.
• Integration: Can be integrated with Azure Monitor and other services for deeper analytics and alerts.

D. Azure Advisor

Azure Advisor is a personalized cloud consultant that helps you follow best practices to optimize your Azure deployments. It analyzes your resource configuration and usage telemetry and offers recommendations to help you improve the cost-effectiveness, performance, reliability, and security of your resources.

Key Features:

• Cost Recommendations: Provides suggestions to reduce your overall Azure spending.
• Performance Recommendations: Offers advice to improve the performance of your applications.
• Security Recommendations: Identifies potential security vulnerabilities and provides recommendations to mitigate them.
• Reliability Recommendations: Helps improve the reliability of your applications with best practices.
• Actionable Insights: Provides actionable insights and recommendations that you can implement directly from the Advisor portal.
• Integration: Integrates with other Azure services to provide a holistic view of your resource optimization.

These tools collectively help you manage, monitor, and optimize your Azure environment effectively.