Introduction

Imagine this situation.

It is 10:30 AM. Your application team reports that an important query that normally takes 200 milliseconds is suddenly taking 8 seconds.

You check the application. Nothing changed.

You check the database server. CPU looks normal.

You check blocking. Nothing obvious.

Then you open Query Store and discover something interesting:

The query started using a different execution plan at 2:15 AM.

This is a classic query plan regression.

Traditionally, a DBA would investigate the plans, identify the better plan, force it, monitor the result, and later decide whether the forced plan should remain.

Azure SQL can automate much of this process through Automatic Tuning.

But automatic tuning does not mean:

“Turn it on and forget about performance.”

A DBA still needs to understand what Azure is changing, why it is changing it, when it should be enabled, and when it should not be trusted blindly.

This article explains Automatic Tuning in Azure SQL in simple terms, with T-SQL examples and real-world scenarios.

What is Automatic Tuning in Azure SQL?

Automatic Tuning is a managed performance capability that continuously monitors database workload behavior and can identify performance problems, recommend corrective actions, and when configured to do so apply selected changes automatically.

For Azure SQL Database, the major automatic tuning capabilities are:

1. FORCE_LAST_GOOD_PLAN
2. CREATE_INDEX
3. DROP_INDEX

Azure SQL Managed Instance currently supports FORCE_LAST_GOOD_PLAN for Automatic Tuning; the automatic index-management options described for Azure SQL Database aren’t available there through Automatic Tuning. (Microsoft Learn)

That distinction is important.

When someone says:

“Automatic Tuning is available in Azure SQL.”

The next question should always be:

“Which Azure SQL service are you talking about?”

Azure SQL Database and Azure SQL Managed Instance do not have identical Automatic Tuning capabilities.

Why Do We Need Automatic Tuning?

Database workloads are not static.

Today’s workload may look like this:

9 AM       → Normal OLTP traffic
12 PM      → Reporting workload increases
2 PM       → New application release
6 PM       → Batch processing
11 PM      → ETL workload
2 AM       → Maintenance jobs

The database engine may choose different execution plans as data, statistics, parameters, indexes, and workload patterns change.

A plan that was excellent yesterday may become inefficient tomorrow.

For example:

Yesterday

Query
  ↓
Index Seek
  ↓
Nested Loops
  ↓
200 ms

After a plan change:

Same Query
     ↓
Table Scan
     ↓
Hash Join
     ↓
8 seconds

The query itself didn’t change.

The execution plan changed.

This is where Automatic Tuning can help.

The Three Important Automatic Tuning Options

Think of the three Azure SQL Database options like this:

Option	Main Problem It Addresses
FORCE_LAST_GOOD_PLAN	Query became slower because of a plan regression
CREATE_INDEX	A missing index may improve workload performance
DROP_INDEX	An unused or duplicate index is creating unnecessary overhead

Let’s look at each one.

1. FORCE_LAST_GOOD_PLAN

This is probably the easiest Automatic Tuning feature to understand.

Suppose Query Store has recorded these plans:

Query 125

Plan 10 → 200 ms
Plan 15 → 250 ms
Plan 21 → 8,000 ms

Plan 10 was previously performing well.

Plan 21 is significantly slower.

Automatic plan correction can identify the regression and force the query to use the last known good plan instead of the regressed plan.

Microsoft documents this as automatic plan correction based on Query Store. (Microsoft Learn)

Real-world scenario

Imagine an e-commerce application.

The following query runs thousands of times per hour:

SELECT OrderID,
       CustomerID,
       OrderDate,
       OrderAmount
FROM dbo.Orders
WHERE CustomerID = @CustomerID;

For months, SQL Server uses an efficient plan.

Then data distribution changes.

The optimizer chooses a different plan.

Performance changes from:

Average duration: 180 ms

to:

Average duration: 7,500 ms

The application team reports:

“The order-history page is suddenly very slow.”

Instead of immediately rewriting the query, you investigate Query Store.

You discover a plan regression.

If Automatic Tuning is enabled and the query is eligible, Azure SQL can automatically force the previous good plan.

That can restore performance while you continue investigating the underlying reason for the regression.

Automatic Tuning Does Not Magically Fix Every Slow Query

This is one of the most important points to understand.

Automatic plan correction primarily addresses plan-choice regressions.

It is not a replacement for complete performance tuning.

For example, suppose a query has always been slow:

Average duration:
Monday     15 seconds
Tuesday    14 seconds
Wednesday  16 seconds
Thursday   15 seconds
Friday     15 seconds

There may be no meaningful plan regression.

The query may simply have:

• Poor indexing
• Excessive logical reads
• Bad joins
• Non-SARGable predicates
• Excessive data volume
• Inefficient application design

Automatic plan correction is not a magic solution for all of these problems.

A DBA still needs to diagnose the workload.

2. CREATE_INDEX

The second major capability is automatic index creation.

Azure SQL Database continuously analyzes workload behavior and can identify indexes that may improve query performance. When confidence is high enough, it can create a recommendation and, if automatic index creation is enabled, apply it. (Microsoft Learn)

For example, suppose you have:

CREATE TABLE dbo.Sales
(
    SalesID       bigint,
    CustomerID    int,
    SalesDate     date,
    Amount        decimal(18,2)
);

And your application frequently executes:

SELECT SalesID,
       SalesDate,
       Amount
FROM dbo.Sales
WHERE CustomerID = @CustomerID;

But there is no useful index on CustomerID.

The query may scan a large portion of the table.

Azure SQL can identify that an index could improve the workload and generate a recommendation.

Conceptually, the recommendation might look like:

CREATE INDEX ...
ON dbo.Sales(CustomerID)
INCLUDE (SalesDate, Amount);

The exact index definition should come from the recommendation rather than being blindly copied from a generic example.

Azure Does Not Simply Create Every Missing Index

This is an important distinction.

The existence of a missing-index suggestion does not automatically mean:

“Create this index.”

Azure’s automatic indexing system considers workload benefit and resource conditions.

For example, Microsoft documents safeguards around resource utilization and available storage. Create-index operations can be postponed when CPU, Data IO, or Log IO utilization is high, and recommendations can be affected by available storage. (Microsoft Learn)

This is good because creating an index itself consumes resources.

An index has costs:

CREATE INDEX
     ↓
More storage
     ↓
More maintenance
     ↓
More INSERT cost
     ↓
More UPDATE cost
     ↓
More DELETE cost

So the real question is not:

“Will this index make one SELECT faster?”

It is:

“Does the overall workload benefit enough to justify the cost of this index?”

That is a much better DBA question.

Real-World Scenario: Reporting Query

Imagine a Power BI dashboard starts using a new query against a 100-million-row table.

Before the dashboard:

Query execution
→ 15 seconds
→ Runs 10 times/day

After the dashboard:

Query execution
→ 15 seconds
→ Runs 10,000 times/day

Suddenly the database is under serious pressure.

Automatic indexing may recognize that a particular index could significantly improve the workload.

The new index might change the query from:

Table Scan
     ↓
100 million rows examined

to:

Index Seek
     ↓
Small number of rows examined

That can dramatically reduce resource consumption.

But the DBA should still examine:

• How frequently the query executes
• Index size
• Write workload
• Existing indexes
• Storage availability
• Whether another index already covers the query

Automatic Index Validation

One of the strongest aspects of Azure SQL automatic tuning is that it isn’t simply:

Recommendation
     ↓
CREATE INDEX
     ↓
Done

Azure SQL can validate whether an automatically applied recommendation actually improves workload performance.

For automatic index recommendations, Azure compares workload behavior with the baseline and can revert a change when the expected performance benefit isn’t realized. (Microsoft Learn)

This is one reason automatic tuning can be useful in environments where workload behavior changes frequently.

3. DROP_INDEX

Now we reach the option that often makes DBAs nervous.

DROP_INDEX.

Creating an index sounds easy.

Dropping one from production is a different conversation.

Every index has a maintenance cost.

Suppose a table has:

14 indexes

But workload analysis shows:

Index A → 2,000,000 seeks
Index B → 500,000 seeks
Index C → 100 seeks
Index D → 0 seeks
Index E → 0 seeks

Meanwhile, the table receives:

5 million UPDATE operations

Every index that must be maintained during writes adds overhead.

Azure SQL Database Automatic Tuning can identify unused or duplicate indexes. Microsoft documents the DROP_INDEX behavior as targeting indexes unused over the previous 90 days and duplicate indexes; unique indexes, including those supporting primary-key and unique constraints, aren’t dropped. (Microsoft Learn)

There are also important limitations. For example, DROP_INDEX can be disabled when the workload uses index hints or partition switching, and behavior differs by service tier. (Microsoft Learn)

Real-World Scenario: Too Many Indexes

Imagine an OLTP table:

dbo.CustomerTransactions

It has:

17 indexes

Developers added indexes over several years.

The application now has:

Heavy INSERT workload
Heavy UPDATE workload
Moderate SELECT workload

The DBA notices:

INSERT latency increasing
Transaction log usage increasing
Write CPU increasing

Investigation shows several indexes provide little or no read benefit.

Automatic index management may identify duplicate or unused indexes.

But this is exactly where a DBA should still understand the business workload.

For example:

“We haven’t used this index in the last 90 days.”

doesn’t necessarily mean:

“We will never use this index.”

A month-end report might run only once every quarter.

So automatic recommendations should be reviewed in the context of the business workload.

The Most Important Rule: Automatic Does Not Mean Unsupervised

This is the mindset I recommend:

Let Azure automate repetitive performance decisions, but don’t outsource your database architecture to automation.

Automatic tuning is excellent at continuously observing workload patterns.

But it doesn’t know everything about your organization.

It doesn’t necessarily know:

• A quarterly report runs next week
• A migration is scheduled tonight
• A new application release is coming tomorrow
• An index is required for a special workload
• A business process intentionally uses a particular access path
• A reporting workload is seasonal

That’s where DBA judgment remains important.

How to Check Automatic Tuning Configuration

You don’t need to open the Azure portal every time.

You can inspect the configuration using T-SQL.

Check Automatic Tuning Mode

SELECT
    desired_state_desc,
    actual_state_desc
FROM sys.database_automatic_tuning_mode;

This tells you whether the database’s desired and actual Automatic Tuning modes match.

The view requires VIEW DATABASE STATE. (Microsoft Learn)

Check Individual Automatic Tuning Options

SELECT
    name,
    desired_state_desc,
    actual_state_desc,
    reason_desc
FROM sys.database_automatic_tuning_options;

This is one of the most useful checks because it can show situations such as:

CREATE_INDEX
Desired: ON
Actual:  OFF
Reason: QUERY_STORE_OFF

That immediately tells you:

“I enabled the feature, but Azure isn’t actually able to use it because Query Store isn’t available in the required state.”

Microsoft documents VIEW DATABASE STATE as the required permission for this view. (Microsoft Learn)

Why Query Store Matters

Automatic plan correction depends on Query Store.

If Query Store is:

OFF

or:

READ_ONLY

Automatic Tuning may not be able to perform the expected action.

The Automatic Tuning configuration view can expose reasons such as:

QUERY_STORE_OFF
QUERY_STORE_READ_ONLY
NOT_SUPPORTED
DISABLED

Microsoft specifically identifies Query Store being disabled or read-only as common causes of automated recommendation management being unavailable. (Microsoft Learn)

So when troubleshooting Automatic Tuning, don’t start by blaming Automatic Tuning.

Check Query Store first.

Check Automatic Tuning Recommendations

One of the most useful DMVs is:

sys.dm_db_tuning_recommendations

For example:

SELECT
    name,
    type,
    state,
    details
FROM sys.dm_db_tuning_recommendations;

This DMV returns information about Automatic Tuning recommendations. It can contain recommendations such as:

FORCE_LAST_GOOD_PLAN
CREATE_INDEX
DROP_INDEX

The state column contains JSON describing the recommendation state and reason. Microsoft documents states such as Active, Verifying, Success, Reverted, and Expired. (Microsoft Learn)

A More Useful Recommendation Query

You can extract the current state and reason from the JSON:

SELECT
    name,
    type,
    JSON_VALUE(state, '$.currentValue') AS recommendation_state,
    JSON_VALUE(state, '$.reason') AS reason,
    details
FROM sys.dm_db_tuning_recommendations
ORDER BY name;

This is useful when you’re troubleshooting:

“What is Azure Automatic Tuning doing right now?”

Important Limitation of sys.dm_db_tuning_recommendations

There is an important point many articles miss.

The recommendations exposed by:

sys.dm_db_tuning_recommendations

are not persisted indefinitely.

Microsoft documents that this DMV is updated as the engine identifies potential regressions and the recommendations aren’t persisted across database-engine restarts. (Microsoft Learn)

So if you want a historical record of tuning activity, don’t rely exclusively on this DMV.

Azure SQL Database retains Automatic Tuning history for 21 days in the service experience, and longer-term retention can be achieved through AutomaticTuning diagnostic settings. (Microsoft Learn)

Enabling Automatic Tuning

There are two common approaches:

1. Azure Portal
2. T-SQL

Azure SQL Database supports configuration at the server and database level. Microsoft recommends managing the settings at the server level and allowing databases to inherit them when you want consistent behavior across databases. (Microsoft Learn)

Option 1: Inherit Server Configuration

ALTER DATABASE CURRENT
SET AUTOMATIC_TUNING = INHERIT;

This means the database follows the Automatic Tuning configuration of its parent logical server. (Microsoft Learn)

This is a good approach when you have many databases and want centralized configuration.

Option 2: Use Azure Defaults

ALTER DATABASE CURRENT
SET AUTOMATIC_TUNING = AUTO;

Azure’s documented defaults are:

FORCE_LAST_GOOD_PLAN = ON
CREATE_INDEX         = OFF
DROP_INDEX           = OFF

So don’t assume that “Automatic Tuning enabled” means all three options are automatically enabled. (Microsoft Learn)

Option 3: Configure Individual Features

For example:

ALTER DATABASE CURRENT
SET AUTOMATIC_TUNING
(
    FORCE_LAST_GOOD_PLAN = ON,
    CREATE_INDEX = ON,
    DROP_INDEX = OFF
);

This configuration says:

Automatic plan correction → ON
Automatic index creation  → ON
Automatic index dropping   → OFF

This can be a sensible starting point for organizations that want automated plan correction and index recommendations but aren’t yet comfortable with automatic index removal.

My Recommended Starting Strategy

I would not recommend that every organization immediately turn everything ON.

A safer approach is:

Step 1
Enable FORCE_LAST_GOOD_PLAN
        ↓
Step 2
Monitor recommendations
        ↓
Step 3
Understand CREATE_INDEX recommendations
        ↓
Step 4
Enable CREATE_INDEX where appropriate
        ↓
Step 5
Review DROP_INDEX carefully
        ↓
Step 6
Automate progressively

Why?

Because risk isn’t the same for every automatic action.

A plan correction is fundamentally different from changing the physical indexing strategy of a busy OLTP database.

Real-World Scenario: Production Plan Regression

Let’s walk through a realistic incident.

8:00 AM

Application performance is normal.

Query duration = 250 ms

11:00 AM

A deployment happens.

11:15 AM

Users report:

“The customer search screen is slow.”

DBA Investigation

First, check resource pressure.

SELECT
    end_time,
    avg_cpu_percent,
    avg_data_io_percent,
    avg_log_write_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;

CPU is only:

32%

So scaling the database probably isn’t the first answer.

Next, check Query Store.

You discover:

Before:
Plan 101 → 250 ms

After:
Plan 145 → 6,500 ms

Now you have a strong hypothesis:

Plan regression.

If Automatic Tuning identifies the regression and forces the previous good plan, the query may return to the better execution plan while you investigate why the optimizer changed plans.

This is a good example of where Automatic Tuning acts as a safety net rather than replacing DBA troubleshooting.

Real-World Scenario: Automatic Index Creation

A SaaS application launches a new reporting feature.

Before launch:

Orders table
50 million rows

After launch:

New report
Runs every 30 seconds

The query repeatedly filters and joins on a column that isn’t supported by an appropriate index.

Database resource consumption increases.

Azure SQL identifies that a new index could provide a significant workload benefit.

If CREATE_INDEX is enabled, Azure can create the index and validate whether the workload improves. Microsoft documents that automatic index operations consider workload/resource conditions and validate the resulting performance. (Microsoft Learn)

The important part is not simply:

“Azure created an index.”

The important part is:

“Azure created an index because workload evidence indicated that it could help, and the service then evaluated the result.”

Real-World Scenario: Automatic Index Removal

Now consider a different database.

Over several years:

Indexes = 30

But application behavior has changed.

Some indexes are no longer useful.

The write workload has increased.

The DBA sees:

High write CPU
Large index maintenance cost
Increasing transaction log activity

DROP_INDEX may identify duplicate or unused indexes.

But before enabling it, ask:

Question 1

Do we have seasonal workloads?

Question 2

Do we have quarterly reports?

Question 3

Do we use index hints?

Question 4

Do we use partition switching?

Question 5

Are some indexes required for a workload that doesn’t run frequently?

This is exactly where DBA knowledge + Automatic Tuning is stronger than either one alone.

Automatic Tuning vs Manual DBA Tuning

This isn’t an “Azure vs DBA” competition.

Think about it this way:

Automatic Tuning	DBA
Continuously monitors workload	Understands business workload
Detects patterns	Understands architecture
Can apply selected changes	Evaluates broader impact
Can validate automated changes	Investigates root cause
Works continuously	Handles unusual scenarios
Scales across many databases	Makes architectural decisions

The strongest approach is:

Automation handles repetitive optimization; DBAs handle judgment, architecture, and exceptions.

What About SQL Server?

Automatic Tuning is not exclusively an Azure concept.

Automatic Tuning was introduced in SQL Server 2017 and later versions.

However, the capabilities differ.

For SQL Server, automatic plan correction focuses on execution-plan regressions.

Azure SQL Database adds automatic index management capabilities such as CREATE_INDEX and DROP_INDEX. (Microsoft Learn)

So don’t write a single generic statement like:

“SQL Server Automatic Tuning automatically creates and drops indexes.”

That is not accurate across all SQL Server environments.

Always specify the platform.

Azure SQL Database vs Azure SQL Managed Instance

This distinction is particularly important for Azure DBAs.

Capability	Azure SQL Database	Azure SQL Managed Instance
FORCE_LAST_GOOD_PLAN	YES	YES
CREATE_INDEX Automatic Tuning	YES	NO
DROP_INDEX Automatic Tuning	YES	NO
Portal-based Automatic Tuning configuration	YES	Not for the MI-supported option
T-SQL configuration	YES	YES

Azure SQL Managed Instance’s Automatic Tuning support is currently limited to FORCE_LAST_GOOD_PLAN, configured through T-SQL. (Microsoft Learn)

This is one of the most common Azure SQL distinctions worth remembering for both production work and DP-300-style interview questions.

Automatic Tuning and Permissions

If you’re monitoring Automatic Tuning through T-SQL, permissions matter.

For example:

sys.database_automatic_tuning_options

requires:

VIEW DATABASE STATE

as documented by Microsoft. (Microsoft Learn)

To manage Automatic Tuning through the Azure portal, PowerShell, or REST API, Azure RBAC is involved; Microsoft documents SQL Database Contributor as the minimum Azure RBAC role for managing Automatic Tuning in Azure SQL Database. T-SQL configuration follows the permissions required for ALTER DATABASE. (Microsoft Learn)

For an operational monitoring account, don’t automatically give broad administrative rights just because it needs to inspect tuning information.

Common Mistakes with Automatic Tuning

Mistake 1: Turning Everything ON Immediately

Don’t assume:

More automation = better performance

Start gradually.

Mistake 2: Thinking Automatic Tuning Replaces Query Store

It doesn’t.

Query Store is an important foundation for plan regression detection.

If Query Store is unavailable or read-only, Automatic Tuning behavior can be affected. (Microsoft Learn)

Mistake 3: Blindly Trusting CREATE INDEX

A new index isn’t free.

It can increase:

• Storage
• INSERT cost
• UPDATE cost
• DELETE cost
• Index maintenance

Always understand the workload.

Mistake 4: Treating DROP INDEX as “Clean Up Everything”

An index that isn’t heavily used today may still be required for:

• Monthly reporting
• Quarterly processing
• Rare but critical business operations

Look at the business cycle.

Mistake 5: Applying Recommendations Manually and Assuming Azure Will Validate Them

This is a particularly important distinction.

If you manually apply a recommendation using the T-SQL supplied by Azure, the automatic performance validation and reversal mechanism isn’t available in the same way as when the service autonomously applies the recommendation. Microsoft notes that manually applied recommendations remain visible for 24–48 hours before being automatically withdrawn from the recommendation list. (Microsoft Learn)

So:

Azure automatically applies
        ↓
Azure validates
        ↓
Azure can revert

is different from:

DBA manually runs script
        ↓
DBA owns validation

That difference is critical.

A Practical DBA Workflow

Here’s the workflow I recommend when using Automatic Tuning.

                 Production Issue
                       ↓
             Check Resource Pressure
                       ↓
              Check Query Store
                       ↓
             Check Plan Regression
                       ↓
         ┌─────────────┴─────────────┐
         ↓                           ↓
   Plan Regression              No Regression
         ↓                           ↓
FORCE_LAST_GOOD_PLAN          Investigate Root Cause
                                     ↓
                           Index / Query / Blocking /
                           Statistics / Architecture

Automatic Tuning should be part of this workflow—not the entire workflow.

My Recommended Configuration for a New Azure SQL Database

For many production environments, I would start conservatively:

ALTER DATABASE CURRENT
SET AUTOMATIC_TUNING
(
    FORCE_LAST_GOOD_PLAN = ON,
    CREATE_INDEX = OFF,
    DROP_INDEX = OFF
);

Then monitor.

Once the team understands the recommendations and operational impact, consider enabling CREATE_INDEX for suitable workloads.

DROP_INDEX deserves the most careful review because removing an index changes the physical access paths available to the workload.

This isn’t a universal configuration for every environment. The right settings depend on workload characteristics, governance requirements, and how much control your organization wants over schema/index changes.

A Useful Automatic Tuning Monitoring Script

For a DBA dashboard or daily health check, I would start with:

SELECT
    name,
    type,
    JSON_VALUE(state, '$.currentValue') AS recommendation_state,
    JSON_VALUE(state, '$.reason') AS reason,
    details
FROM sys.dm_db_tuning_recommendations
ORDER BY type, name;

And:

SELECT
    name,
    desired_state_desc,
    actual_state_desc,
    reason_desc
FROM sys.database_automatic_tuning_options;

Together, these answer two important questions:

1. Is Automatic Tuning configured correctly?

and

2. What recommendations is the engine currently identifying?

Remember that the recommendation DMV is not a permanent historical repository. If you need long-term auditing, use the Azure monitoring/diagnostic capabilities designed for Automatic Tuning history. (Microsoft Learn)

Automatic Tuning Is a Safety Net, Not a Substitute for DBA Skills

This is probably the most important takeaway from this article.

Imagine you have:

Automatic Tuning
        +
Query Store
        +
DMVs
        +
Execution Plans
        +
Extended Events
        +
DBA Experience

That’s a powerful combination.

But if you only have:

Automatic Tuning

you are missing the most important part:

understanding why the database is behaving the way it is.

A DBA should still know how to:

• Read execution plans
• Analyze Query Store
• Understand waits
• Investigate blocking
• Analyze indexes
• Check statistics
• Understand workload patterns
• Review resource pressure
• Evaluate application behavior

Automatic Tuning simply gives the DBA another tool.

Final Takeaways

If you remember only a few things from this article, remember these:

1. Automatic Tuning is powerful

It can continuously monitor workload behavior and automate selected performance improvements.

2. Azure SQL Database has three major options

FORCE_LAST_GOOD_PLAN
CREATE_INDEX
DROP_INDEX

3. Azure SQL Managed Instance is different

Automatic Tuning currently supports:

FORCE_LAST_GOOD_PLAN

not the Azure SQL Database automatic index-management options. (Microsoft Learn)

4. Query Store matters

Automatic plan correction depends on Query Store being available and in the appropriate operating mode.

5. Don’t blindly enable everything

Start with the least disruptive option and expand based on experience.

6. Automatic doesn’t mean uncontrolled

Understand what Azure is doing and monitor the results.

7. DBA judgment still matters

Azure can analyze workload behavior at enormous scale.

But it doesn’t understand your business requirements the way your DBA and architecture teams do.

The best strategy isn’t:

“Let Azure tune everything.”

It is:

“Let Azure automate what it is good at, while DBAs remain responsible for understanding the workload and making the architectural decisions.”

That is where Automatic Tuning becomes genuinely useful.

Quick Reference

If you see…	Investigate…	Automatic Tuning capability
Query suddenly becomes slow	Query Store plan regression	FORCE_LAST_GOOD_PLAN
Query repeatedly scans a large table	Missing index opportunity	CREATE_INDEX
Too many unused/duplicate indexes	Index usage and workload	DROP_INDEX
Automatic Tuning isn’t working	Query Store + tuning configuration	sys.database_automatic_tuning_options
Need current recommendations	Tuning DMV	sys.dm_db_tuning_recommendations
Need historical tuning activity	Azure portal/diagnostics	Automatic Tuning history

The goal isn’t to eliminate the DBA.

The goal is to give the DBA a system that can continuously watch the workload and handle certain repetitive tuning decisions—while the DBA focuses on the problems that require human judgment.

That is the real value of Automatic Tuning in Azure SQL.