Azure SQL Improved Flashcards

Question

What type of SSD is used for storage in the General-Purpose tier of an Azure SQL Managed Instance?

Answer 1

Azure Premium SSD.

Answer 2

The Business-Critical Tier for Azure SQL Database uses local SSDs to provide low-latency read and write operations.

Answer 3

The Business-Critical Tier for Azure SQL Managed Instance uses local SSDs to provide low-latency reads and writes.

Answer 4

High availability for the Business-Critical tier in Azure SQL Database is achieved through Always On availability groups. This setup includes multiple replicas: one primary replica and two or more secondary replicas within the same region. These replicas are automatically synchronized to ensure data consistency and provide failover support, ensuring that the database remains available even if one replica fails.

Answer 5

High availability in the Business-Critical tier of Azure SQL Managed Instance is achieved through the use of Always On Availability Groups. This setup involves multiple replicas: one primary replica and two or more secondary replicas within the same region. These replicas ensure data redundancy and high availability. The data is continuously synchronized between the primary and secondary replicas, allowing for automatic failover in case of a failure, thus minimizing downtime and ensuring business continuity.

Answer 6

Azure SQL Database automatically manages the backup process, which includes the following types of backups: 1. **Full Backup**: Performed once a week. This backup captures the entire database. 2. **Differential Backup**: Conducted every 12 to 24 hours. It includes only the changes made since the last full backup, making it quicker and smaller than a full backup. 3. **Transaction Log Backup**: Occurs every 5 to 10 minutes. This backup records all the transactions since the last transaction log backup, allowing for point-in-time recovery. All backups are stored in geo-redundant storage (GRS) by default, providing high availability and disaster recovery capabilities.

Answer 7

1. Basic Tier: Backups are retained for 7 days. 2. Standard and Premium Tiers: Backups are retained for 35 days. 3. Long-Term Retention (LTR): You can configure long-term retention for up to 10 years by storing backups in Azure Blob Storage.

Answer 8

1. Basic Tier: Backups are retained for 7 days by default. 2. Standard and Premium Tiers: Backups are retained for 35 days by default. 3. You can configure a custom retention period for backups up to 10 years using the Azure SQL Database long-term retention (LTR) feature.

Answer 9

Yes, you can restore an Azure SQL Database to any point in time within the retention period. This feature is enabled by automatic backups that Azure performs regularly. These backups allow you to recover your database to a specific point in time, which is useful for recovering from accidental data changes or corruption. The retention period for these backups depends on the service tier and can range from 7 to 35 days.

Answer 10

1. Full Backup: Taken once a week. 2. Differential Backup: Taken every 12 to 24 hours. 3. Transaction Log Backup: Taken every 5 to 10 minutes. 4. Backups are stored in geo-redundant storage (GRS) by default, ensuring high availability and disaster recovery capabilities.

Answer 11

1. **Short-Term Retention**: Automated backups for Azure SQL Managed Instance are retained for a period ranging from 7 to 35 days. The retention period can be configured based on your specific requirements and the service tier you are using. 2. **Long-Term Retention (LTR)**: You can configure long-term retention policies to keep backups for up to 10 years. This allows you to store backups in Azure Blob Storage for compliance and archival purposes.

Answer 12

1. vCore: General Purpose 2. vCore: Business Critical 3. vCore: Hyperscale 4. DTU: Basic 5. DTU: Standard 6. DTU: Premium

Answer 13

Yes, Azure SQL Managed Instance supports SQL Server Integration Services (SSIS) through the Azure Data Factory integration runtime. You can deploy and run SSIS packages in Azure using this service.

Answer 14

Azure SQL Database does not support SQL Server Integration Services (SSIS) directly. SSIS cannot be natively hosted or run within Azure SQL Database. However, there are alternative methods to use SSIS with Azure SQL Database: 1. **Azure Data Factory**: Utilize **Azure Data Factory (ADF)** with the SSIS integration runtime to execute SSIS packages in the cloud. ADF provides a managed SSIS service that allows you to host, execute, and manage SSIS packages, enabling connectivity to Azure SQL Database as part of your ETL (Extract, Transform, Load) processes. 2. **On-premises SSIS**: If you have SSIS running on-premises, you can connect to Azure SQL Database as a data source or destination by configuring your SSIS packages to point to your Azure SQL Database instance. 3. **SQL Managed Instance**: For native SSIS support, consider using **Azure SQL Managed Instance**, which includes a wider range of SQL Server features, such as the ability to host SQL Agent jobs to run SSIS packages. In summary, while Azure SQL Database does not natively support SSIS, you can leverage Azure Data Factory, on-premises SSIS, or Azure SQL Managed Instance to work with SSIS packages in conjunction with Azure SQL Database.

Answer 15

Yes, Azure SQL Managed Instance supports cross-database transactions within the same instance. This feature allows you to perform operations across multiple databases using traditional Distributed Transaction Coordinator (DTC) support, ensuring transactional consistency across several databases within the same managed instance. However, for transactions involving different Azure SQL Managed Instances or between an on-premises SQL Server and an Azure SQL Managed Instance, additional configurations are required. In such cases, you might need to use Azure SQL Database elastic transactions or other alternative methods, as DTC support is limited to a single managed instance.

Answer 16

Yes, Azure SQL Managed Instance supports linked servers. This feature allows you to connect to and query external data sources directly from the SQL Managed Instance, similar to how you would in an on-premises SQL Server environment. With linked servers, Azure SQL Managed Instance can connect to other SQL Servers, Azure SQL Databases, and even non-SQL data sources. This capability enables distributed queries and data integration across different environments. To set up linked servers in Azure SQL Managed Instance, you generally need: 1. **Credentials for Authentication**: Ensure you have the necessary credentials to authenticate with the external data source. 2. **Network Configurations**: Configure network settings to allow connectivity to the external source, ensuring any necessary firewall rules or virtual network settings are in place. 3. **Transact-SQL (T-SQL) Configuration**: Use T-SQL commands to define and manage the linked server settings. This feature enhances Azure SQL Managed Instance's flexibility, making it suitable for hybrid and multi-cloud database scenarios where integration with external databases is required.

Answer 17

Yes, Azure SQL Managed Instance supports CLR (Common Language Runtime) integration. This feature enables you to create user-defined functions, stored procedures, triggers, and aggregates using managed code like C# or VB.NET. These can then be executed within SQL Managed Instance, allowing for more complex logic and custom functions that might be challenging to implement with T-SQL alone.

Answer 18

Yes, Azure SQL Managed Instance supports Service Broker.

Answer 19

No, Azure SQL Managed Instance does not support SQL Server Replication. While SQL Server Replication is available in SQL Server on-premises for data distribution and synchronization, this feature is not supported in Azure SQL Managed Instance. For similar functionality, you may consider using alternatives like Azure Data Sync for synchronizing data across multiple databases or using Azure Data Factory for data movement and transformation tasks.

Answer 20

No, Azure SQL Managed Instance does not support Database Mail. Instead, you can use alternative methods such as Azure Logic Apps, Azure Functions, or external SMTP services to send emails from your databases.

Answer 21

No, Azure SQL Managed Instance does not support Stretch Database.

Answer 22

No, Azure SQL Managed Instance does not support Data Quality Services.

Answer 23

The maximum retention period for automatic backups in Azure SQL Database and Azure SQL Managed Instance is 10 years.

Answer 24

1. Backups are managed automatically by Azure. 2. A full database backup is performed weekly. 3. Differential backups are taken every 12 to 24 hours. 4. Transaction log backups occur every 5 to 10 minutes.

Answer 25

1. The default retention period for backups is between 7 to 35 days. 2. With Long-Term Retention (LTR), backups can be retained for up to 10 years.

Answer 26

To recover a recent backup in an Azure SQL Managed Instance, use the point-in-time restore feature. This allows you to restore the database to a specific point in time within the retention period.

Answer 27

1. Backups are managed automatically by Azure. 2. A full database backup is performed weekly. 3. Differential backups occur every 12 to 24 hours. 4. Transaction log backups are taken every 5 to 10 minutes.

Answer 28

1. The default retention period for backups in an Azure SQL Managed Instance is between 7 and 35 days. 2. For Long-Term Retention (LTR), backups can be retained for up to 10 years.

Answer 29

To perform a point-in-time restore in an Azure SQL Database, navigate to the Azure portal, select your SQL database, and go to the "Restore" option. Choose "Point-in-time restore," specify the desired restore point by selecting the date and time, and then follow the prompts to complete the restoration process.

Answer 30

Azure SQL Database and Azure SQL Managed Instance offer automatic performance tuning features, which can automatically optimize performance by identifying and implementing tuning recommendations. However, you can also manually review and apply these recommendations if you prefer more control over the tuning process.

Answer 31

Microsoft automatically manages updates to ensure that your instance is running the latest stable version, which includes the latest features, performance improvements, and security patches. This process is designed to be seamless and minimize downtime, allowing you to focus on your applications without the need to manage version updates manually.

Answer 32

No, you do not need to be concerned about the version of Azure SQL Database you are using. Azure SQL Database is a fully managed service, and Microsoft automatically updates it to the latest version to ensure security, performance, and feature improvements. It operates as a version-less service, meaning you always have access to the latest capabilities without needing to manage version upgrades yourself.

Answer 33

Use the vCore-based purchasing model.

Answer 34

Yes, Azure Hybrid Benefit can be applied to Azure SQL. This allows you to use your existing SQL Server licenses with Software Assurance to save on Azure SQL Database and Azure SQL Managed Instance costs.

Answer 35

RLS (Row-Level Security) is a feature in Azure SQL Database that restricts data access for specific rows in a table based on the characteristics of the user executing the query. To implement RLS, you should define security predicates as inline table-valued functions and create security policies that apply these predicates to the tables. This ensures that users can only view and manipulate rows of data they are authorized to access, meeting the requirement of allowing users to access only the relevant data while minimizing administrative overhead.

Answer 36

1. Security Policies: You create a security policy that specifies the restrictions for each query executed by a user. This policy includes a filter predicate that is evaluated for each query. 2. Filter Predicate: A function that returns a boolean value to determine which rows a user can access. This predicate is applied every time a query is executed on a table with RLS enabled. 3. Automatic Enforcement: Users are automatically prevented from accessing rows that do not satisfy the filter predicate.

Answer 37

Row-Level Security (RLS) in Azure SQL Database is implemented by creating security policies that define predicates, which are functions that filter rows based on the current user's context. This ensures that users can only access the subset of data they are authorized to see.

Answer 38

An Azure SQL Server-level Firewall Rule is a security feature that controls access to all databases hosted on a specific SQL Server. It allows you to define network ranges or specific IP addresses that are permitted to connect to the server. This is useful for managing access for multiple applications or clients that need to connect to different databases on the same server, ensuring they adhere to consistent security policies.

Answer 39

No, SQL Server-level firewall rules in Azure SQL cannot be used to restrict access to a single database for a particular IP address. These rules apply to the entire server, granting access to all databases hosted on that server for the specified IP address. Access to individual databases is controlled through authentication and permissions, not firewall rules.

Answer 40

The scope of SQL Server-level Firewall Rules when using an Azure SQL Database server applies to all databases hosted on that server.

Answer 41

To configure specific IP addresses to access each of your three databases (DB1, DB2, and DB3) on an Azure SQL server instance, you should use both server-level and database-level firewall rules. First, set up server-level firewall rules to allow access to the Azure SQL server instance. Then, configure database-level firewall rules for each database to specify the IP addresses that can access them individually. This approach ensures that only the specified IP addresses can access each database.

Answer 42

Always Encrypted Client-Side Encryption in Azure SQL Database ensures that sensitive data is encrypted and decrypted on the client side. This means that the data remains encrypted while stored in the database, and only authorized client applications can decrypt it. As a result, the database and database administrators never have access to the plaintext data, enhancing data security and privacy.

Answer 43

Always Encrypted Column-Level Encryption in Azure allows you to encrypt specific sensitive columns, such as those containing credit card numbers or social security numbers, in a database. This ensures that the data remains encrypted both at rest and in transit, while the rest of the data in the table remains unencrypted. This feature helps protect sensitive data from unauthorized access and ensures that only authorized applications or users can decrypt and access the data.

Answer 44

The role separation feature in Always Encrypted ensures that database administrators can manage the database without having access to the encryption keys. This prevents them from viewing sensitive data in plaintext, while application developers or administrators, who have access to the encryption keys, can handle the data securely.

Answer 45

Deterministic Encryption: This type of encryption always generates the same encrypted value for a given plaintext value. It allows for equality searches, meaning you can query encrypted columns using equality operators. However, it may reveal patterns in the data, which could potentially be exploited. Randomized Encryption: This type of encryption generates different encrypted values each time for the same plaintext value, enhancing security by making it more difficult to identify patterns. However, it does not support equality searches, so you cannot use equality operators to query encrypted columns.

Answer 46

Always Encrypted is a feature in Azure SQL Database that ensures sensitive data is encrypted both at rest and in transit. It allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to the database engine. This means that the database engine, Azure SQL Database, and even Azure administrators cannot access the encrypted data. The client driver (e.g., ADO.NET) handles the encryption and decryption process transparently when configured with the necessary keys, allowing applications to interact with the data without needing to be aware of the encryption process.

Answer 47

Always Encrypted in Azure SQL Database is a feature designed to protect sensitive data by encrypting it at the column level. It uses two types of keys: 1. **Column Encryption Key (CEK):** This key is used to encrypt the actual data within the database columns. 2. **Column Master Key (CMK):** This key is used to encrypt the CEK. The CMK is stored securely in an external key store, such as Azure Key Vault, ensuring that the encryption keys are managed separately from the encrypted data.

Answer 48

Yes, data loss can occur when using an auto-failover group in Azure. The potential duration of data loss is up to 5 seconds.

Answer 49

No, the secondary database in an auto-failover group can only be used for read operations, not write operations.

Answer 50

No, it is not a requirement for the secondary database to be in the same resource group as the primary database when using an auto-failover group in Azure. The primary and secondary databases can be in different resource groups.

Answer 51

No, the primary and secondary databases should be located in different regions to ensure high availability and disaster recovery.

Answer 52

Yes, Azure SQL Managed Instance supports server-side transactions. This means you can execute transactions on the server, allowing for operations such as commit and rollback to be managed directly within the database environment.

Answer 53

Yes, you can deploy an Azure SQL Database with connectivity through a private virtual network (vNET) by using Azure Private Link. This allows you to access the database securely over a private endpoint within your vNET. Additionally, you can use service endpoints to extend your vNET to the Azure SQL Database service, enhancing security by restricting access to your database from specific vNETs.

Answer 54

No, Azure SQL Managed Instance is not a single-tenant environment. It is a multi-tenant service where multiple customers share the same physical infrastructure, but each managed instance is isolated at the network level and provides dedicated resources to ensure performance and security.

Answer 55

Yes, Azure SQL Database is a multi-tenant environment.

Answer 56

No, Azure SQL Database does not support server-side transactions in the same way as traditional SQL Server instances. However, it does support transactions within the database itself, allowing you to manage and execute transactions using T-SQL commands.

Answer 57

Yes, Azure SQL Managed Instance supports server-side transactions. This means you can manage transactions directly on the server, ensuring data integrity and consistency across operations.

Answer 58

Dynamic Data Masking in Azure Managed Instance and Azure SQL Database is a security feature that automatically obscures sensitive data in query results. It does not alter the actual data stored in the database. Instead, it applies masking rules to the data when it is retrieved, ensuring that users without the necessary permissions see only masked data. Users with the appropriate permissions can access and interact with the unmasked, original data.

Answer 59

To achieve this, use Dynamic Data Masking in Azure SQL Managed Instance. Configure the database to apply a mask to the credit card numbers by default. Then, grant User A the `UNMASK` permission, allowing them to see the unmasked data, while User B will see the masked data by default.

Answer 60

Yes, both Azure SQL Managed Instance and Azure SQL Database support dynamic data masking.

Answer 61

1. **Active Geo-Replication**: Allows you to create up to four readable secondary databases in different Azure regions, providing high availability and disaster recovery. 2. **Auto-Failover Groups**: Enables automatic failover of multiple databases in a group to a secondary server in a different region, simplifying the management of DR for multiple databases. 3. **Point-in-Time Restore**: Allows you to restore a database to any point within the retention period, providing protection against accidental data loss or corruption. 4. **Geo-Restore**: Enables you to restore a database from geo-redundant backups to any Azure region, ensuring data recovery in case of a regional outage. 5. **Zone Redundant Configuration**: Distributes database replicas across multiple availability zones within a region, enhancing resilience against zone-level failures. 6. **Geo-Redundant Backups**: Automatically stores backups in a secondary region, ensuring data availability and recovery in the event of a regional disaster.

Answer 62

To create read-only replicas of an Azure SQL Database in a different region, you can use the "Active Geo-Replication" feature. This allows you to configure up to four readable secondary databases in different regions, providing high availability and disaster recovery.

Answer 63

No, Failover Groups and Active Geo-Replication are separate features in Azure SQL Database. They both provide disaster recovery and high availability across regions, but they are designed to be used independently. You can choose one based on your specific requirements, but they are not meant to be used together.

Answer 64

Yes, you can manually failover an Azure SQL Database with a secondary read replica in a separate region by using the Azure portal, PowerShell, or the Azure CLI. This is typically done by initiating a failover of the geo-replication relationship to promote the secondary database to the primary role.

Answer 65

Yes, the DNS name used to connect to the database remains the same. Azure SQL Database automatically updates the DNS to point to the new primary database after a failover.

Answer 66

Auto-Failover Groups: Auto-Failover Groups enable automatic failover for geo-replicated Azure SQL Databases, ensuring continuous availability during regional outages without manual intervention. They support automatic failover, maintaining read-write access to the database after a failover event. You can manage multiple databases seamlessly and configure policies for either automatic or manual failover between primary and secondary regions.

Answer 67

Azure SQL Database Point-in-Time Restore allows you to recover a database to any point within the backup retention period, which can be up to 35 days for Standard and Premium tiers. This feature is useful for recovering from accidental data loss, corruption, or malicious activity. It enables you to restore databases within the same region and also across regions if geo-redundant backups are configured.

Answer 68

1. Azure SQL Database Geo-Replication, specifically Active Geo-Replication, allows you to create up to four readable secondary replicas of your database in different Azure regions. 2. These replicas are synchronized asynchronously with the primary database, meaning they can serve as failover databases if the primary database becomes unavailable. 3. In the event of a failure, you can manually initiate a failover to a secondary replica to restore service, with minimal data loss depending on the replication lag. 4. The secondary replicas are available for read-only queries, which can improve availability and performance for global applications.

Answer 69

1. Auto-Failover Groups enable automatic failover for geo-replicated Azure SQL Databases, eliminating the need for manual intervention during a regional outage. 2. They ensure continuous availability by automatically switching to a secondary region if the primary region becomes unavailable. 3. This feature allows for seamless management of multiple databases, maintaining read-write access to the databases even after a failover event. 4. You can configure Auto-Failover Groups to handle failover automatically or manually, based on your specific requirements, between the primary and secondary regions.

Answer 70

Yes, you can use auto-failover groups with multiple databases. Auto-failover groups in Azure SQL Database allow you to manage the failover of a group of databases as a single unit, ensuring high availability and disaster recovery across different regions.

Answer 71

Azure SQL Database Point-in-Time Restore allows you to recover a database to any specific point within the backup retention period, which can be up to 35 days for Standard and Premium tiers. This feature is useful for recovering from accidental data loss, corruption, or malicious activity. It enables you to restore databases within the same region and also across regions if geo-redundant backups are enabled.

Answer 72

Geo-Restore in Azure SQL Database allows you to recover your database from a geo-replicated backup to any Azure region if there is a major regional outage or disaster. This feature ensures that even if your primary region is inaccessible, you can restore your database from backups stored in a secondary region. Geo-Restore uses geo-redundant backups, which are stored in different regions, to protect against region-wide failures. While the recovery time is longer compared to Active Geo-Replication or Failover Groups, Geo-Restore serves as a last-resort recovery option.

Answer 73

Azure SQL Database Zone Redundant Configuration is a feature available in the Premium and Business Critical tiers. It enhances high availability by replicating databases across multiple availability zones within the same region. This setup ensures that if one availability zone experiences a failure, the database remains accessible through replicas in other zones, thereby providing resilience against localized failures and maintaining continuous service availability.

Answer 74

Azure SQL Database Zone Geo-Redundant Backups are a feature that automatically stores your database backups in multiple geographic locations. By default, these backups are stored in both the primary region and a secondary region. This redundancy ensures that if the primary region experiences an outage, you can still restore your database from the backups stored in the secondary region, thereby maintaining data availability and minimizing downtime.

Answer 75

Azure SQL Database provides automatic performance tuning features, including automatic index management and query performance insights. However, you can also manually tune performance by using tools like Query Performance Insight, SQL Database Advisor, and by monitoring performance metrics.

Answer 76

Yes, performance tuning is available for Azure SQL Managed Instances. You can use various tools and features such as Query Store, Automatic Tuning, and Performance Recommendations to optimize and improve the performance of your SQL Managed Instances.

Answer 77

Answer: I recommend using Azure Cosmos DB for storing NoSQL data. It is a fully managed NoSQL database service that provides native support for various NoSQL data models, including document, key-value, graph, and column-family. It offers global distribution, scalability, and low-latency access, making it an ideal choice for applications requiring NoSQL data storage with minimal effort.

Answer 78

Answer: I recommend using Azure Cosmos DB, which is a fully managed NoSQL database service that supports multiple data models and provides a simple way to store and work with NoSQL data.

Answer 79

The Service Level Agreement (SLA) for Azure SQL Database guarantees 99.99% availability.

Answer 80

The default RPO (Recovery Point Objective) for Azure SQL Database is typically 5 minutes.

Answer 81

The default Recovery Time Objective (RTO) for Azure SQL Database is 1 hour.

Answer 82

Azure SQL Database provides protection against data corruption through features such as automated backups, geo-replication, and built-in data integrity checks. Automated backups ensure that you can restore your database to a previous state, while geo-replication provides redundancy and high availability. Data integrity checks help detect and correct data corruption issues.

Answer 83

The General Purpose tier in Azure SQL Database is primarily used for applications that require a balanced approach to cost and performance, making it suitable for most business workloads.

Answer 84

Yes, in the General Purpose tier of Azure SQL Database, compute and storage are separated. The compute layer is responsible for processing queries, while the storage layer is remote and handles data storage.

Answer 85

The I/O performance in the General Purpose tier of Azure is moderate, utilizing Azure Premium SSD-backed storage.

Answer 86

The maximum database size for the General Purpose tier in Azure SQL Database is 2 TB.

Answer 87

The General Purpose tier in Azure SQL Database provides high availability through a separation of compute and storage layers. It uses a failover group with automated backups and geo-replication for disaster recovery, but it does not use zone-redundant configurations or Always On availability groups. Instead, it relies on built-in data redundancy and automatic failover within the same region.

Answer 88

In the General Purpose tier of Azure SQL Database, automated backups are created and stored in geo-redundant storage. This allows for point-in-time restore, enabling you to restore the database to any point within the retention period, which is typically up to 35 days.

Answer 89

The typical failover time for the General Purpose tier in Azure SQL Database is 30 seconds to 60 seconds.

Answer 90

Answer: Azure Premium SSD with locally redundant storage.

Answer 91

The General Purpose tier in Azure handles scaling by providing balanced CPU-to-memory configurations and supporting both vertical and horizontal scaling. It allows you to adjust resources based on workload demands, ensuring cost-effectiveness while maintaining performance.

Answer 92

Answer: The General Purpose tier is most suitable for workloads that require a balanced mix of compute and memory resources, such as web servers, small to medium-sized databases, and application servers.

Answer 93

Answer: No, the General Purpose tier in Azure SQL Database does not offer read replicas.

Answer 94

Applications that require the highest level of availability, resilience to failures, and low-latency input/output operations.

Answer 95

No, in the Business-Critical tier of Azure SQL Database, compute and storage are not separated. This tier uses local SSD-based storage, which means that the storage is directly attached to the compute nodes.

Answer 96

The I/O performance in the Business-Critical tier of Azure SQL Database is high, as it utilizes local SSD storage with low latency for optimal performance.

Answer 97

The maximum database size for the Business Critical tier in Azure SQL Database is 5 TB.

Answer 98

The Business-Critical tier in Azure SQL Database provides high availability through zone-redundant configurations using Always On availability groups, with data stored on local SSDs.

Answer 99

In the Business-Critical tier of Azure SQL Database, backup and restore functionality operates as follows: 1. **Automated Backups**: The system automatically creates full, differential, and transaction log backups to ensure data protection and recovery. 2. **Point-in-Time Restore**: You can restore your database to any point in time within the retention period, which is typically up to 35 days. 3. **Geo-Redundant Backups**: Backups are stored in geo-redundant storage, providing additional protection by replicating data to a secondary region, ensuring availability even in the event of a regional outage.

Answer 100

The failover time for the Business-Critical tier in Azure SQL Database is typically 3-10 seconds, leveraging fast failover with SSD technology.

Answer 101

Answer: In the Business-Critical tier of Azure SQL Database, local SSD storage is used, providing fast local access and high performance.

Answer 102

The Business-Critical tier in Azure SQL Database provides high availability and performance with features like in-memory OLTP and faster failover. It supports scaling by allowing you to adjust the number of vCores and the amount of storage independently, enabling you to handle varying workloads efficiently. However, scaling may involve some downtime or performance impact during the scaling operation.

Answer 103

Answer: Workloads that require high performance, low-latency, high availability, and enhanced security, such as financial transactions, e-commerce platforms, and real-time data processing.

Answer 104

Up to 3 read replicas.

Answer 105

The primary use case for the Hyperscale tier in Azure SQL Database is to support applications that require high scalability, rapid scaling, and the ability to handle very large databases efficiently.

Answer 106

Yes, the Hyperscale tier in Azure SQL Database supports the separation of compute and storage, allowing for independent scaling of each to meet performance and capacity needs.

Answer 107

The I/O performance characteristic of the Hyperscale tier in Azure SQL Database is designed to provide high throughput and low latency, with the ability to scale storage and compute resources independently based on workload demand.

Answer 108

Up to 100 TB.

Answer 109

The Hyperscale tier provides high availability (HA) features such as rapid scale-out capabilities, automatic backups, and storage-level redundancy through a highly distributed architecture. This ensures that data is replicated across multiple nodes, providing resilience against hardware failures and enabling seamless scaling to accommodate workload demands.

Answer 110

In the Hyperscale tier of Azure SQL Database, the backup and restore process functions as follows: 1. **Automated Backups**: The system automatically takes full, differential, and transaction log backups. These backups are stored in Azure Blob Storage. 2. **Snapshot-Based Restores**: The Hyperscale architecture uses a snapshot-based approach for backups, which allows for fast and efficient restores. This means that instead of restoring from traditional backup files, the system uses snapshots of the data files, enabling quicker recovery times. 3. **Point-in-Time Restore**: You can restore the database to any point in time within the retention period, which can be configured up to 35 days. This approach ensures minimal downtime and efficient data recovery, leveraging the scalability and flexibility of the Hyperscale architecture.

Answer 111

The typical failover time for the Hyperscale tier in Azure SQL Database is generally within minutes, but it can vary based on the specific scaling requirements and the size of the database.

Answer 112

The Hyperscale tier in Azure utilizes highly scalable remote storage, specifically Azure Blob Storage, to store data files.

Answer 113

The Hyperscale tier in Azure SQL Database manages scaling by allowing rapid horizontal scaling of storage and compute resources independently, with minimal downtime. It uses a distributed architecture to support large databases and provides fast scaling capabilities to accommodate varying workloads efficiently.

Answer 114

The Hyperscale tier is most suitable for large-scale, rapidly growing workloads that require high read and write scalability, such as applications with unpredictable growth patterns and extensive data storage needs.

Answer 115

In the Hyperscale tier, you can create up to 30 read replicas for read scaling.

Answer 116

Hyperscale tier, as it supports up to 100TB of storage and allows for multiple read replicas to handle read-intensive workloads.

Answer 117

Azure SQL Database Hyperscale allows you to have up to 30 named replicas.

Answer 118

Scalable based on workload demand. Azure SQL Database Hyperscale automatically adjusts I/O performance to meet the needs of your workload, ensuring efficient resource utilization and optimal performance.

Answer 119

To optimize performance and cost for a web app using SQL accessed by 20 people during business hours, consider the following: 1. **Database Tier Selection**: Choose an appropriate SQL database tier that matches your usage pattern. For 20 users, a Basic or Standard tier might be sufficient, but monitor performance to ensure it meets your needs. 2. **Scaling**: Use Azure's scaling options to adjust resources based on demand. Consider scaling down during non-business hours to save costs. 3. **Connection Pooling**: Implement connection pooling to reduce the overhead of opening and closing database connections, which can improve performance. 4. **Query Optimization**: Ensure that your SQL queries are optimized. Use indexes where appropriate and avoid complex queries that can slow down performance. 5. **Caching**: Implement caching strategies to reduce the number of database queries. Use Azure Cache for Redis or in-memory caching to store frequently accessed data. 6. **Monitoring and Alerts**: Set up monitoring and alerts to track performance metrics and costs. Use Azure Monitor to identify and address performance bottlenecks. 7. **Data Archiving**: Archive old or infrequently accessed data to reduce the size of your active database, which can improve performance and reduce costs. 8. **Cost Management Tools**: Use Azure Cost Management tools to analyze and optimize your spending. Set budgets and alerts to avoid unexpected costs. By considering these factors, you can effectively balance performance and cost for your web app.

Answer 120

The Azure SQL Database Standard tier offers the following features and capabilities: 1. **Performance Levels**: Provides a balanced set of compute, memory, and storage resources suitable for most business workloads. It supports a range of performance levels to accommodate different application needs. 2. **Scalability**: Allows for easy scaling of resources up or down based on demand without downtime, ensuring flexibility and cost-efficiency. 3. **High Availability**: Includes built-in high availability with a 99.99% uptime SLA, ensuring your database is always accessible. 4. **Backup and Restore**: Automated backups with point-in-time restore capabilities for up to 35 days, providing data protection and recovery options. 5. **Security**: Offers advanced security features such as encryption at rest and in transit, threat detection, and auditing to protect your data. 6. **Geo-Replication**: Supports active geo-replication, allowing you to create readable replicas of your database in different regions for disaster recovery and global distribution. 7. **Intelligent Performance**: Includes features like automatic tuning, query performance insights, and adaptive query processing to optimize performance. 8. **Managed Service**: Fully managed database service that handles maintenance, patching, and updates, allowing you to focus on application development. 9. **Compatibility**: Supports a wide range of SQL Server features and is compatible with existing SQL Server tools and applications. These features make the Standard tier a versatile and reliable choice for many business applications requiring robust performance and availability.

Answer 121

Yes, Azure SQL Database supports both partitioning and sharding. Partitioning can be achieved using partitioned tables and indexes within a single database to improve performance and manageability. Sharding, or horizontal partitioning, can be implemented using Elastic Database tools to distribute data across multiple databases.

Answer 122

An Azure SQL Server-level Firewall is a security feature that controls access to an Azure SQL Database server. It allows you to define IP address ranges that are permitted to connect to the server. Any connection attempts from IP addresses outside these specified ranges will be blocked. This firewall operates at the server level, meaning it applies to all databases hosted on that server.

Answer 123

An Azure SQL Database-level Firewall is a security feature that controls access to an Azure SQL Database by allowing only specified IP addresses to connect. It helps protect the database by blocking unauthorized access from other IP addresses.

Answer 124

No, by default, the Azure SQL Database-level firewall does not block traffic. It relies on server-level firewall rules to manage access.

Answer 125

To securely write Azure SQL audit logs to a storage account protected by a VNet and firewall, follow these steps: 1. **Configure Azure SQL Auditing**: Set up auditing on your Azure SQL database or server to send logs to a storage account. 2. **Restrict Storage Account Access**: Configure the storage account to allow access only from specific virtual networks and IP addresses by setting up VNet service endpoints or private endpoints. 3. **Set Up Firewall Rules**: Implement firewall rules on the storage account to restrict access to trusted IP ranges and virtual networks. 4. **Use Managed Identity**: Assign a managed identity to your Azure SQL database or server. Grant this identity the necessary permissions (e.g., Blob Contributor) on the storage account to securely write audit logs. 5. **Verify Configuration**: Ensure that the storage account is correctly configured to accept connections only from the specified networks and that the managed identity has the appropriate permissions. This setup ensures that audit logs are securely stored within a controlled network environment, enhancing data protection.

Answer 126

Azure SQL Database Advanced Threat Protection is a security feature that helps safeguard your databases by detecting unusual and potentially harmful activities. It identifies threats such as SQL injection attempts, access from unfamiliar locations or data centers, access by unfamiliar users or potentially harmful applications, and brute force attempts to guess SQL credentials. This feature provides alerts for these suspicious activities, enabling you to take timely action to protect your data.

Answer 127

Dynamic data masking is a security feature that helps protect sensitive data in a database by controlling how much of the data is exposed to unauthorized users. It allows you to define masking rules that obfuscate sensitive information in the query results, without altering the actual data stored in the database. For instance, in a call center scenario, a service representative might need to verify a caller's identity using part of their email address. Dynamic data masking can be configured to show only certain characters of the email address, ensuring that the full email address remains hidden from the representative. Similarly, masking rules can be applied to personal data, allowing developers to access production environments for troubleshooting without exposing sensitive information, thereby maintaining compliance with data protection regulations.

Answer 128

Yes, Azure Policies can be used with Azure SQL Managed Instance and Azure SQL Database to enforce regulatory compliance. Azure provides built-in policy definitions that help ensure compliance with various standards and regulations. These policies can be assigned to your SQL resources to automatically audit and enforce compliance requirements.

Answer 129

The security baseline for Azure SQL is implemented using Azure Policy by applying the guidelines from the Microsoft Cloud Security Benchmark. This involves creating and assigning policies that ensure Azure SQL resources comply with best practices for security, such as access control, data protection, and threat management. Azure Policy helps automate compliance by continuously evaluating resources and providing insights and remediation steps for any deviations from the established security baseline.

Answer 130

Azure SQL Always Encrypted is crucial for data security because it ensures that sensitive data is encrypted on the client side before being stored in the database. This means that the data remains encrypted while at rest and in transit, and only authorized clients with the correct encryption keys can decrypt and access the data. This feature prevents unauthorized access, including by database administrators, thereby safeguarding confidential information such as social security numbers and credit card details.

Answer 131

Azure Always Encrypted with secure enclaves enhances data security by allowing computations on sensitive data while it remains encrypted. Secure enclaves are isolated, hardware-protected memory regions that enable this process, ensuring that data is not exposed during query execution. This feature provides an additional layer of security, minimizing the risk of data exposure even to administrators with elevated privileges.

Answer 132

Data Discovery & Classification in Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics offers tools to identify, categorize, label, and report sensitive data within your databases.

Answer 133

Transparent Data Encryption (TDE) helps protect Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics by encrypting data at rest, safeguarding against malicious offline activities. It automatically encrypts and decrypts the database, associated backups, and transaction log files in real-time without requiring any changes to the application. By default, TDE is enabled for all newly deployed Azure SQL Databases. For Azure SQL Managed Instance, TDE is enabled at the instance level for newly created databases. In Azure Synapse Analytics, TDE must be manually enabled.

Answer 134

Yes, you can use your own key, known as a customer-managed key, for implementing Transparent Data Encryption (TDE) in Azure SQL Database or SQL Managed Instance. This allows you to have greater control over the encryption keys used to protect your data.

Answer 135

An Always On availability group in the context of Azure SQL on a virtual machine (VM) is a high availability and disaster recovery solution that allows you to group one or more databases for replication. It supports up to eight secondary replicas for each primary database, providing redundancy and failover capabilities. This setup ensures that your databases remain available and protected against failures, serving as an alternative to database mirroring.

Answer 136

No, you cannot write to the secondary databases in an Always On Availability Group when using Azure SQL on a VM. The secondary databases are read-only.

Answer 137

Yes, secondary databases in an Always On Availability Group can be configured for read access. This allows you to offload read-only workloads to the secondary replicas, improving performance and availability.

Answer 138

No, a secondary database in an Always On Availability Group is not considered a backup. It is a replica used for high availability and disaster recovery, but it does not replace the need for regular backups. In a disaster scenario, issues affecting the primary database could also impact the secondary database, so maintaining separate backups is essential.

Answer 139

Always Encrypted is a feature in SQL databases that ensures sensitive data is encrypted both at rest and in transit. It works by using client-side encryption keys to encrypt data before it is stored in the database. The encryption and decryption processes occur on the client side, meaning that the database server never has access to the encryption keys or the unencrypted data. This ensures that sensitive information remains protected even if the database is compromised.

Answer 140

The database data for an Azure SQL Managed Instance is stored on Azure Premium Disk Storage.

Answer 141

When using Transparent Data Encryption (TDE) in Azure, the key type options available are: 1. **Azure Managed Keys**: These are encryption keys managed by Azure, which simplifies the management process as Azure handles key rotation and security. 2. **Customer Managed Keys**: These allow customers to manage their own encryption keys using Azure Key Vault, providing greater control over key rotation, access policies, and auditing.

Answer 142

The database data for Azure SQL Managed Instance is stored using Geo-Redundant Storage (GRS).

Answer 143

Transparent Data Encryption (TDE) encrypts the entire database, including data and log files, at rest. It is designed to protect data by performing real-time I/O encryption and decryption of the database, backups, and transaction log files without requiring changes to applications. Always Encrypted, on the other hand, is designed to protect sensitive data, such as credit card numbers or social security numbers, by encrypting it on the client side before it is sent to the database. This ensures that the data remains encrypted not only at rest but also in transit and during processing, with the encryption keys managed by the client application.

Answer 144

Yes, in Azure SQL Database, administrators with the necessary permissions, such as the SQL Server admin or members of the *db_owner* role, can see unmasked data even if dynamic data masking is applied. Dynamic data masking is designed to limit access to sensitive information for non-privileged users by hiding it in query results. However, it does not prevent administrators or users with elevated privileges from viewing the full data.

Answer 145

Dynamic Data Masking in Azure SQL Database limits access to sensitive data by automatically masking it at the database level. This feature provides obfuscated data to users who do not have the necessary permissions, while allowing users with the appropriate permissions to view the data in its original form.

Answer 146

Dynamic Data Masking in Azure SQL Database provides real-time obfuscation of query results by masking sensitive data based on user roles and permissions. This ensures that the actual data stored in the database remains unchanged and secure.

Answer 147

The key types of data masking provided by Azure SQL Database Dynamic Data Masking are: 1. **Default Masking**: Masks the entire value with a default mask, such as replacing characters with 'X' or numbers with '0'. 2. **Email Masking**: Masks email addresses by exposing only the first letter and the domain, such as "aXXX@domain.com". 3. **Random Masking**: Masks numeric values by replacing them with a random number within a specified range. 4. **Custom String Masking**: Masks data using a custom pattern, allowing you to specify which parts of the data to expose and which to mask, such as "XXXX-XX-1234".

Answer 148

Yes, administrators can customize Azure SQL Database Dynamic Data Masking to allow specific user roles access to unmasked data. This is done by granting the "UNMASK" permission to those roles, providing greater control over who can view sensitive information.

Answer 149

To enable Dynamic Data Masking in Azure SQL Database, follow these steps: 1. **Azure Portal**: - Navigate to your Azure SQL Database in the Azure portal. - Under the "Security" section, select "Dynamic Data Masking." - Click on "Add Mask" to configure masking rules for sensitive columns. - Choose the columns you want to mask and select the appropriate masking type (e.g., Default, Email, Custom String, or Random Number). 2. **PowerShell**: - Use the `Set-AzSqlDatabaseDataMaskingPolicy` cmdlet to enable Dynamic Data Masking. - Define masking rules using the `New-AzSqlDatabaseDataMaskingRule` cmdlet for each sensitive column. 3. **T-SQL Commands**: - Connect to your database using a tool like SQL Server Management Studio (SSMS). - Use the `ALTER TABLE` statement to add masking rules. For example: ```sql ALTER TABLE [TableName] ALTER COLUMN [ColumnName] ADD MASKED WITH (FUNCTION = 'maskingFunction'); ``` - Replace `maskingFunction` with the desired masking function, such as `default()`, `email()`, `partial()`, or `random()`. Ensure that you have the necessary permissions to configure Dynamic Data Masking and that you carefully select the columns and masking types to protect sensitive data effectively.

Answer 150

1. **vCore-Based Purchasing Model**: This model offers flexibility by allowing you to select the number of virtual cores (vCores), memory, and storage independently, aligning resources with your specific workload needs. The vCore-based model includes the following service tiers: - **General Purpose**: Designed for most business workloads, offering balanced and scalable compute and storage options at an affordable price point. - **Business Critical**: Tailored for applications requiring low-latency responses and high resilience to failures, utilizing high-performance local SSD storage. - **Hyperscale**: Ideal for applications with highly scalable storage and read-scale requirements, supporting rapid scaling up to 100 TB of storage. Within the vCore-based model, you can choose between two compute tiers: - **Provisioned Compute**: Resources are allocated continuously, suitable for workloads with consistent usage patterns. - **Serverless Compute**: Resources auto-scale based on workload demand, optimizing cost for intermittent or unpredictable usage patterns. 2. **DTU-Based Purchasing Model**: The Database Transaction Unit (DTU) model offers pre-configured bundles of compute, storage, and I/O resources, simplifying the selection process for common workloads. The DTU-based model includes the following service tiers: - **Basic**: Suitable for small databases with light workloads, providing up to 5 DTUs and 2 GB of storage. - **Standard**: Designed for moderate workloads, offering a range of DTUs (from 10 to 3,000) and up to 1 TB of storage. - **Premium**: Intended for high-performance workloads, providing between 125 and 4,000 DTUs and up to 4 TB of storage.

Answer 151

vCore-Based Purchasing Model: General Purpose Tier: - Max vCores: 80 - Max Storage: 4 TB - Max Concurrent Workers: 1,600 - Max Concurrent Sessions: 32,767 Business Critical Tier: - Max vCores: 80 - Max Storage: 16 TB - Max Concurrent Workers: 1,600 - Max Concurrent Sessions: 32,767 Hyperscale Tier: - Max vCores: 80 - Max Storage: 100 TB - Max Concurrent Workers: 1,600 - Max Concurrent Sessions: 32,767

Answer 152

Azure SQL Database does not support the creation or execution of user-defined Common Language Runtime (CLR) assemblies. Although the `clr enabled` configuration option exists and is set to 1 by default, it is intended for internal functionalities that use CLR and does not allow user-defined CLR integration. For scenarios that require CLR integration, Azure SQL Managed Instance supports CLR assemblies, enabling you to create stored procedures, triggers, user-defined functions, user-defined types, and user-defined aggregates using managed code. If you are migrating an application that uses CLR assemblies to Azure SQL Database, you will need to refactor the application to eliminate CLR dependencies or consider using other Azure services that support CLR integration.

Answer 153

No, Azure SQL Database on a Virtual Machine (VM) does not support the Common Language Runtime (CLR). CLR integration is available in SQL Server instances running on Azure VMs, but not in the Azure SQL Database managed service.

Answer 154

Yes, Azure SQL Managed Instance supports Common Language Runtime (CLR) integration. This allows you to create and execute user-defined CLR assemblies, including stored procedures, triggers, user-defined functions, user-defined types, and user-defined aggregates in managed code. To enable CLR integration in Azure SQL Managed Instance, you need to set the `clr enabled` option to 1 using the `sp_configure` stored procedure. Here is how you can do it: ```sql EXEC sp_configure 'clr enabled', 1; RECONFIGURE; ``` Make sure you have the necessary permissions to execute these commands.

Answer 155

No In Azure SQL Database, In-Memory OLTP is not available in the General Purpose or Standard service tiers. This feature is supported in the Premium (DTU) and Business Critical (vCore) service tiers. The Hyperscale service tier supports some In-Memory OLTP objects but does not include memory-optimized tables. If your workload requires In-Memory OLTP capabilities, consider using the Premium or Business Critical service tiers. These tiers are optimized for high-performance transaction processing workloads and provide the necessary support for In-Memory OLTP features.

Answer 156

The read scale-out feature is unavailable in Azure SQL Database's General Purpose service tier. This feature, which allows offloading read-only workloads to secondary replicas, is available only in the Premium, Business Critical, and Hyperscale service tiers. Therefore, you cannot scale out read nodes in the General Purpose tier. For scenarios requiring read scale-out capabilities, consider upgrading to one of the supported service tiers: - **Premium/Business Critical**: These tiers provide high availability with multiple replicas and support read scale-out by redirecting read-only queries to secondary replicas. - **Hyperscale**: This tier offers rapid scale-out by provisioning additional read replicas as needed, supporting up to four high-availability replicas and up to 30 named replicas for read workloads. By selecting an appropriate service tier, you can effectively manage and scale your read workloads in Azure SQL Database.

Answer 157

To maintain high availability during a regional outage, Azure SQL Database in the General Purpose tier requires additional disaster recovery strategies beyond its default configuration. Here are the recommended options: 1. **Active Geo-Replication**: This feature allows you to create continuously synchronized readable secondary databases in different regions. In the event of a regional outage, you can manually fail over to a secondary database to maintain availability. 2. **Auto-Failover Groups**: This feature enables automatic failover of multiple databases to a secondary region. It provides consistent read-write and read-only listener endpoints, which remain unchanged during failover, simplifying application connectivity. By implementing these strategies, you can ensure that your Azure SQL Database remains highly available even during regional outages.

Answer 158

Azure SQL Database's Business Critical service tier provides high availability within a single region by maintaining multiple replicas of your database. However, this setup alone does not guarantee availability during a regional outage. To ensure resilience against regional failures, it is advisable to implement disaster recovery strategies like active geo-replication or failover groups. These strategies replicate your database to a secondary region, allowing for quick recovery and continuity of service during regional disruptions.

Answer 159

The recommended solution is B: Set up SQL Server Always On availability groups with a secondary replica in a different Azure region. SQL Server Always On availability groups are optimized for maintaining near real-time data replication, which aligns well with the requirements of a 5-minute RPO and a 10-minute RTO. They provide application-level consistency and ensure transactional integrity, which is crucial for databases with strict recovery objectives. While Azure Site Recovery can replicate entire virtual machines, it may not consistently meet the 5-minute RPO for high-transactional databases and lacks application-level awareness. Additionally, Always On availability groups focus on replicating only the data changes, making them a more cost-effective and efficient solution for SQL Server disaster recovery compared to replicating the entire VM state.

Answer 160

The Always On feature in SQL Server on an Azure virtual machine (VM) is a high-availability and disaster recovery solution that enhances the reliability and resilience of SQL databases. It utilizes Availability Groups or Failover Cluster Instances to provide redundancy and failover support. Here's a detailed explanation: **Always On Availability Groups (AG):** This feature allows you to group multiple databases and synchronize them across different SQL Server instances on separate VMs. Each Availability Group consists of a primary replica and multiple secondary replicas, offering: - **High Availability:** Automatic failover to a secondary replica if the primary fails. - **Disaster Recovery:** Deployment of replicas across different regions or zones for enhanced resilience. - **Read Scale-Out:** Offloading read-only queries to secondary replicas to improve performance. **Always On Failover Cluster Instances (FCI):** This feature uses shared storage across multiple nodes in a failover cluster. It ensures SQL Server availability by failing over to another VM if the primary instance fails. FCI often utilizes Azure Premium File Shares or Azure Shared Disks for storage, enabling failover without the need for data replication. **Load Balancer:** In Azure VMs, an Azure Load Balancer can be configured to direct traffic to the active SQL instance, particularly during failovers, ensuring seamless connectivity. **Benefits of Always On in Azure VMs:** - **Enhanced Availability:** Increases uptime and resilience for mission-critical databases. - **Geo-Disaster Recovery:** Supports scenarios with geographically distributed replicas for improved disaster recovery. - **Cost Optimization:** Allows running active replicas in less expensive regions while maintaining failover capabilities. In summary, SQL Always On for Azure VMs is an ideal solution for applications requiring high uptime and disaster recovery, offering flexibility in managing costs and resources across different regions.

Answer 161

For a large-scale Oracle database migration that requires high-performance OLTP workloads with automatic failover to a secondary region, the Business Critical service tier in Azure SQL Database is the recommended choice. Here’s why: 1. **High Performance**: The Business Critical tier provides high IOPS and low-latency I/O, essential for handling high-performance OLTP (Online Transaction Processing) workloads. 2. **Automatic Failover**: This tier offers geo-replication capabilities, enabling a secondary replica in a different region. In the event of a disaster, failover to this secondary region is automatic, ensuring robust disaster recovery. 3. **High Availability and Redundancy**: It uses a Premium Availability model with multiple replicas and automatic failover, providing built-in high availability within the primary region, enhancing reliability and durability for mission-critical applications. 4. **Read Scale-Out**: The Business Critical tier supports read scale-out to additional replicas, allowing you to offload read operations, which optimizes performance.

Answer 162

Azure SQL Database, as a fully managed Platform as a Service (PaaS) offering, provides high availability and disaster recovery features without requiring the Always On feature used in SQL Server on virtual machines. By default, Azure SQL Database ensures availability through local redundancy, keeping your database accessible during maintenance operations and local hardware failures. For enhanced resilience, Azure SQL Database offers zone-redundant configurations, which protect against datacenter-level failures by replicating data across multiple availability zones within a region. This setup provides higher availability and fault tolerance compared to traditional Always On configurations. In summary, Azure SQL Database does not use the Always On feature as implemented in SQL Server on VMs, but it delivers equivalent or superior high availability and disaster recovery capabilities through its built-in redundancy options.