SQL SERVER – Azure Interview Questions and Answers – Guest Post by Paras Doshi – Day 25 of 31

These Azure interview questions and answers were contributed by Paras Doshi for Day 25 of our July 2011 series. They provide a useful record of SQL Azure at that time. Start with the introductory post and the complete interview series.

About this edition: The guest answers below have been lightly cleaned up for readability and remain explicitly historical. Product limits, editions, tools and recovery options have changed since July 2011. The current editorial context is separate from Paras Doshi’s contribution.

Current editorial context

Azure SQL Database is a managed database service. It should not be treated as identical to either Azure SQL Managed Instance or SQL Server installed on an Azure virtual machine. Identify the service before answering a modern interview question.

• Azure SQL Database now provides automated backups and point-in-time restore within the applicable retention period. The 2011 recovery answer is not current guidance.
• Authentication includes Microsoft Entra ID as well as SQL authentication. IP firewall rules are only one part of controlling access.
• Purchasing models include vCore and DTU options. Current limits and costs depend on the selected offering; the old Web/Business edition figures are historical.
• High-availability architecture varies by service tier. Do not repeat the old three-replica description as a universal explanation of today’s service.

These notes are an editorial update, not new answers or opinions attributed to Paras Doshi. For a present-day deployment, check the chosen service and its current documentation before using any old limit or tool name.

Guest questions and answers from July 2011

1. What is SQL Azure?

SQL Azure was described as a cloud-based relational database service from Microsoft. A useful starting point was to think of SQL Server technology delivered as a cloud service.

2. What is cloud computing?

The National Institute of Standards and Technology describes cloud computing in terms of convenient, on-demand access to shared computing resources that can be provisioned and released with little management effort. The original memory aid, credited to Dave Nielsen, was OSSM: on demand, scalable, self-service and measurable, pronounced like “awesome.”

3. How is SQL Azure different from SQL Server?

The service offered on-demand provisioning, high availability, reduced management overhead and scalability. It also hid some implementation details from the subscriber. Whether that abstraction helped depended on the requirements.

4. How many replicas were maintained for each database?

The 2011 answer described three replicas: one primary handling reads and writes, with the others kept synchronized. If the primary failed, another replica could be promoted behind the scenes.

5. How could a database be migrated?

The tools discussed were BCP or SSIS for data, the Generate Scripts wizard for schema, and the SQL Azure Migration Wizard.

6. Which management tools were available?

The answer named SQL Server Management Studio 2008 R2 and a Silverlight application in the Azure management portal.

7. What security features did SQL Azure provide?

The service used IP-address firewall rules, SQL authentication and encrypted connections. The original answer used the term SSL for connection encryption.

8. What was the SQL Azure firewall?

It restricted requests according to IP address.

9. How did Web and Business editions differ?

The July 2011 answer listed a 5 GB maximum for Web edition and 50 GB for Business edition. It described size changes in 1 GB increments for Web and 10 GB increments for Business.

10. How could on-premises SQL Server and SQL Azure be synchronized?

The options discussed were SQL Azure Data Sync, then in community technology preview, and custom solutions using Sync Framework.

11. How could SQL Azure data be backed up?

The original answer distinguished hardware redundancy from recovery after user mistakes. It discussed database copies and data exports using tools such as BCP or SSIS, and said point-in-time recovery was not supported at that time.

12. What was the pricing model?

The answer described charges based on database size and data transfer. These are historical pricing notes, not a current cost estimate.

13. What was the database size limit?

The maximum listed in this July 2011 article was 50 GB.

14. How could a dataset larger than 50 GB be handled?

The answer discussed splitting data across multiple databases through application logic. It also mentioned the then-announced SQL Azure Federations feature.

15. What happened when a database reached its maximum size?

The original answer said reads could continue while create, insert and update operations were restricted. Deleting, dropping or truncating data could free space.

16. How many databases could be created on one server?

The limit quoted in the original answer was 150 databases, including master.

17. How many servers could be created in one subscription?

The original answer quoted six servers per subscription.

18. How could performance be improved?

The answer recommended examining execution plans, query statistics and dynamic management views. It also noted the effect of network latency and bandwidth.

19. What was code-near application topology?

It meant placing the application and its SQL Azure database in the same Azure datacenter. The contrasting code-far arrangement connected from outside that datacenter.

20. Which updates were new at the time?

The article highlighted multiple servers per subscription, co-administrator support and firewall-rule creation with IP detection.

21. When could a workload be throttled?

The answer described storage limits and resource-sharing policies. It distinguished soft throttling after a safety threshold from hard throttling when a machine lacked resources, and suggested examining the reason codes.

The original contribution also reminded readers that SQL Server knowledge remains relevant, while supported features can change quickly. That is still a useful way to approach an interview: understand the concept, then establish the product and version being discussed.

Continue with the Interview Questions and Answers Series or browse the interview question archive.

A historical answer is not a current product specification, it is a starting point for understanding what changed.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.