BrainyBeeBrainyBee
ExploreBlogStart Studying
HomeDesigning Microsoft Azure Infrastructure Solutions (AZ-305)Quick Note — Recommend a Solution for Database Scalability
LO Quick Note801 words

Quick Note — Recommend a Solution for Database Scalability

AZ-305 › Unit 2 › Design data storage for relational data › Recommend a solution for database scalability

Quick Note — Recommend a Solution for Database Scalability

Reference: Designing Microsoft Azure Infrastructure Solutions (AZ-305) — the attached exam study guide is the source material for this lesson.

Retrieval target

Objective
Recommend a Solution for Database Scalability
Mode
Closed-book recall
Target time
5 minutes
Escalation
Open the full lesson after a miss

Decision anchors

PromptCompact answer
Vertical vs horizontal scalingVertical (scale-up/down) — change the size of one resource (e.g., 2 → 8 vCores on one DB). Requires a restart on most resources; not used for autoscaling. Horizontal (scale-out/in) — add or remove instances behind a router/load balancer. No downtime, the basis for all Azure autoscale. Relational engines combine both: tier up for write capacity, replicas out for read capacity.
Read scale-out (Azure SQL)A read-only secondary replica usable by clients that pass ApplicationIntent=ReadOnly in the connection string — the gateway routes those connections to the replica; default ReadWrite goes to the primary. Available in Business Critical and Hyperscale tiers; General Purpose doesn't have it. Replica lag is small but non-zero — applications must tolerate eventual-consistency reads.
Sharding (database)Horizontally partition data across many databases (shards), each holding a slice keyed by a sharding key (tenant ID, customer ID, region). A separate shard map manager database records which key maps to which shard; the app library reads this map to route each request. Pattern of choice for SaaS multi-tenant scale beyond a single DB's limits.
Elastic PoolA fixed pool of vCores or DTUs shared by multiple SQL DBs on the same server. Per-DB min/max caps bound noisy neighbors. Cost is the pool's, not per DB — best for many low-utilization DBs with occasional spikes. Adding / removing a DB to a pool is online. Cannot mix DTU and vCore models in one pool, cannot span servers.

Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.

Turn recall into an architecture answer

For recommend a solution for database scalability, state: choose X because constraints A and B apply; reject Y because it fails C; validate with evidence D.

Ninety-second explanation

Without notes, explain:

  1. What requirement signals this learning objective rather than a neighbouring one?
  2. Which two solution families are most likely to be compared?
  3. Which hard constraint eliminates the strongest distractor?
  4. What identity, network, data, or failure boundary must appear in the design?
  5. Which operational test would prove the recommendation works?

Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.

Loading flashcards…

When to open the full lesson

Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.

Source and freshness

Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.

All Designing Microsoft Azure Infrastructure Solutions (AZ-305) Study Resources

Related Notes

  • Recommend a Solution for Database Scalability — Lesson5,400 words
  • AZ-305 Exam Map and Design Decision Playbook652 words
  • Unit 1 Capstone — Design identity, governance, and monitoring solutions668 words
  • Unit 1 Roadmap — Design identity, governance, and monitoring solutions639 words
  • Cram Sheet — Design authentication and authorization solutions632 words
  • Design Authentication and Authorization Solutions — Lesson4,263 words
  • Design Studio — Design authentication and authorization solutions734 words
  • Quick Note — Recommend an Authentication Solution758 words
  • Recommend an Authentication Solution — Lesson4,868 words
  • Quick Note — Recommend an Identity Management Solution796 words
  • Recommend an Identity Management Solution — Lesson5,982 words
  • Quick Note — Recommend a Solution for Authorizing Access to Azure Resources745 words

Ready to study Designing Microsoft Azure Infrastructure Solutions (AZ-305)?

Practice tests, flashcards, and all study notes — free, no sign-up.

Start Studying

Ready to study Designing Microsoft Azure Infrastructure Solutions (AZ-305)?

Practice tests, flashcards, and all study notes — free, no sign-up needed.

Start Studying — Free
Designing Microsoft Azure Infrastructure Solutions (AZ-305) ResourcesExplore All HivesBlogHome

© 2026 BrainyBee. Free AI-powered exam prep.

Recommend a Solution for Database Scalability — quick retrieval

Card 1 of 4

Front of flashcard 1 of 4

Vertical vs horizontal scaling

easy

Vertical (scale-up/down) — change the size of one resource (e.g., 222 → 888 vCores on one DB). Requires a restart on most resources; not used for autoscaling. Horizontal (scale-out/in) — add or remove instances behind a router/load balancer. No downtime, the basis for all Azure autoscale. Relational engines combine both: tier up for write capacity, replicas out for read capacity.

scalingverticalhorizontal

Recommend a Solution for Database Scalability — quick retrieval

Card 1

Front

Vertical vs horizontal scaling

Back

Vertical (scale-up/down) — change the size of one resource (e.g., 222 → 888 vCores on one DB). Requires a restart on most resources; not used for autoscaling. Horizontal (scale-out/in) — add or remove instances behind a router/load balancer. No downtime, the basis for all Azure autoscale. Relational engines combine both: tier up for write capacity, replicas out for read capacity.

Card 2

Front

Read scale-out (Azure SQL)

Back

A read-only secondary replica usable by clients that pass ApplicationIntent=ReadOnly in the connection string — the gateway routes those connections to the replica; default ReadWrite goes to the primary. Available in Business Critical and Hyperscale tiers; General Purpose doesn't have it. Replica lag is small but non-zero — applications must tolerate eventual-consistency reads.

Card 3

Front

Sharding (database)

Back

Horizontally partition data across many databases (shards), each holding a slice keyed by a sharding key (tenant ID, customer ID, region). A separate shard map manager database records which key maps to which shard; the app library reads this map to route each request. Pattern of choice for SaaS multi-tenant scale beyond a single DB's limits.

Card 4

Front

Elastic Pool

Back

A fixed pool of vCores or DTUs shared by multiple SQL DBs on the same server. Per-DB min/max caps bound noisy neighbors. Cost is the pool's, not per DB — best for many low-utilization DBs with occasional spikes. Adding / removing a DB to a pool is online. Cannot mix DTU and vCore models in one pool, cannot span servers.

Recommend a Solution for Database Scalability — quick retrieval

Card 1

Front

Vertical vs horizontal scaling

Back

Vertical (scale-up/down) — change the size of one resource (e.g., 222 → 888 vCores on one DB). Requires a restart on most resources; not used for autoscaling. Horizontal (scale-out/in) — add or remove instances behind a router/load balancer. No downtime, the basis for all Azure autoscale. Relational engines combine both: tier up for write capacity, replicas out for read capacity.

Card 2

Front

Read scale-out (Azure SQL)

Back

A read-only secondary replica usable by clients that pass ApplicationIntent=ReadOnly in the connection string — the gateway routes those connections to the replica; default ReadWrite goes to the primary. Available in Business Critical and Hyperscale tiers; General Purpose doesn't have it. Replica lag is small but non-zero — applications must tolerate eventual-consistency reads.

Card 3

Front

Sharding (database)

Back

Horizontally partition data across many databases (shards), each holding a slice keyed by a sharding key (tenant ID, customer ID, region). A separate shard map manager database records which key maps to which shard; the app library reads this map to route each request. Pattern of choice for SaaS multi-tenant scale beyond a single DB's limits.

Card 4

Front

Elastic Pool

Back

A fixed pool of vCores or DTUs shared by multiple SQL DBs on the same server. Per-DB min/max caps bound noisy neighbors. Cost is the pool's, not per DB — best for many low-utilization DBs with occasional spikes. Adding / removing a DB to a pool is online. Cannot mix DTU and vCore models in one pool, cannot span servers.