Microsoft AZ-900: Depolama ve Veritabanları — Çalışma kılavuzu

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Şunun bir parçası: Microsoft Azure AZ-900 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Microsoft sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Azure, entegre dayanıklılık, güvenlik ve maliyet kontrolleri ile yapılandırılmamış ve yapılandırılmış verileri küresel ölçekte depolamak için geniş bir temel sağlar. Doğru depolama temelini, yedeklilik modelini, erişim katmanını ve veritabanı hizmetini anlamak, sanal makinelerden küresel olarak dağıtılmış web ve mobil platformlara kadar güvenilir ve performanslı uygulamaların önünü açar.

Azure Depolama hizmetleri ve yönetilen diskler

Azure Blob Storage, yapılandırılmamış veriler için temel taştır. Block bloblar, verimli akış ve paralel yükleme, anlık görüntüler, sürüm oluşturma ve katmanlandırma ile büyük nesneleri işler. Page bloblar, 512 baytlık sayfalarda rastgele okuma/yazma G/Ç’si için optimize edilmiştir ve sanal sabit diskleri destekler; disklerin ve tutarlı düşük gecikmeli IOPS gerektiren senaryoların altında yer alırlar. Append bloblar, yeni blokların verimli bir şekilde sona eklendiği uygulama günlükleri gibi yazma ağırlıklı ekleme senaryoları için özel olarak tasarlanmıştır. Azure Files, SMB veya NFS üzerinden erişilebilen, NTFS ACL’leri, dizin entegrasyonu seçenekleri ve Windows Sunucularındaki sık erişilen verileri önbelleğe almak için Azure File Sync özelliklerine sahip tam yönetilen dosya paylaşımları sunar. Queue Storage, bileşenleri en az bir kez teslim semantiği ile ayrıştırmak için hafif, dayanıklı uygulama mesajlaşması sağlar. Table Storage, ölçek ve maliyet verimliliği için bölüm ve satır anahtarlarını kontrol ettiğiniz geniş, bölümlenmiş veri kümeleri için şemasız bir anahtar/öznitelik deposu sunar. Yönetilen diskler, depolama hesaplarını veya page blobları doğrudan yönetmeye gerek kalmadan Azure Sanal Makineleri için dayanıklı, kalıcı blok depolama sağlar. Maliyet açısından optimize edilmiş aktarım hızı iş yükleri için Standard HDD, dengeli performans için Standard SSD, düşük gecikmeli yüksek IOPS için Premium SSD ve Premium SSD v2 ve yapılandırılabilir IOPS ve aktarım hızına sahip en zorlu işlemsel iş yükleri için Ultra Disk arasından seçim yapın. Yönetilen diskler, anlık görüntüleri, artımlı yedeklemeleri, disk şifrelemesini ve VM SLA’larınızla uyumlu kullanılabilirlik seçeneklerini destekler.

• Blob – Block blob
  • Veri modeli veya G/Ç modeli: Büyük nesne, sıralı G/Ç
  • Temel yetenekler: Katmanlandırma, anlık görüntüler, sürüm oluşturma, yaşam döngüsü ilkeleri
  • Tipik kullanım örnekleri: Görüntüler, video, yedeklemeler, büyük veri hazırlık bölgeleri
  • Önemli sınırlar/notlar: Tek bir blob ~190 TiB’a kadar; rastgele G/Ç için optimize edilmemiştir
• Blob – Page blob
  • Veri modeli veya G/Ç modeli: 512 baytlık sayfalarda rastgele G/Ç
  • Temel yetenekler: Düşük gecikmeli okuma/yazma, VHD desteği
  • Tipik kullanım örnekleri: Diskler ve rastgele erişim gerektiren senaryolar için temel depolama
  • Önemli sınırlar/notlar: Page blob boyutu 8 TiB’a kadar; yönetilen diskler bunu soyutlar
• Blob – Append blob
  • Veri modeli veya G/Ç modeli: Yalnızca ekleme (append-only) yazmaları
  • Temel yetenekler: Verimli günlük eklemeleri, değiştirilemezlik seçenekleri
  • Tipik kullanım örnekleri: Telemetri ve uygulama günlükleri
  • Önemli sınırlar/notlar: Yerinde güncelleme desteklenmez; blok sayısı sınırları geçerlidir
• Azure Files
  • Veri modeli veya G/Ç modeli: POSIX/SMB/NFS dosya semantiği
  • Temel yetenekler: SMB/NFS erişimi, NTFS ACL’leri, AD DS/Azure AD DS entegrasyonu, File Sync
  • Tipik kullanım örnekleri: “Lift-and-shift” dosya paylaşımları, uygulama yapılandırması, kullanıcı ev dizinleri
  • Önemli sınırlar/notlar: Standard ve Premium katmanları; büyük dosya paylaşımları 100 TiB’a kadar
• Queue Storage
  • Veri modeli veya G/Ç modeli: Mesaj kuyruğu
  • Temel yetenekler: En az bir kez teslim, görünürlük zaman aşımları, zehirli mesaj işleme
  • Tipik kullanım örnekleri: Arka plan işlemleri, ayrıştırılmış mikro hizmetler
  • Önemli sınırlar/notlar: Mesaj boyutu 64 KB’a kadar (daha büyük/gelişmiş desenler için Service Bus kullanın)
• Table Storage
  • Veri modeli veya G/Ç modeli: Anahtar/öznitelik NoSQL
  • Temel yetenekler: Devasa ölçek, PartitionKey’e göre bölümleme, düşük maliyet
  • Tipik kullanım örnekleri: Telemetri, kataloglar, kullanıcı profilleri
  • Önemli sınırlar/notlar: Join veya ikincil dizinler yok; küresel ihtiyaçlar için Cosmos DB Table API
• Managed disks
  • Veri modeli veya G/Ç modeli: VM’ler için blok depolama
  • Temel yetenekler: Standard/Premium/Ultra SKU’ları, anlık görüntüler, ölçeklendirme, disk şifrelemesi
  • Tipik kullanım örnekleri: VM’ler için işletim sistemi/veri diskleri, veritabanları, iş kolu uygulamaları
  • Önemli sınırlar/notlar: Disk başına 32 TiB’a kadar; belirli SKU’lar için ZRS mevcuttur

Yedeklilik ve dayanıklılık seçenekleri

Yedeklilik modelleri, Azure’un verileriniz için nerede ve kaç tane senkron ve asenkron kopya tuttuğunu tanımlar. Yerel olarak yedekli depolama (LRS), tek bir bölgedeki tek bir veri merkezi içinde üç kopya tutarak en düşük maliyetle sürücü ve raf arızalarına karşı koruma sağlar. Bölgesel olarak yedekli depolama (ZRS), bir bölgedeki ayrı kullanılabilirlik alanlarına üç senkron kopya yayarak uygulama düzeyinde yük devretme olmadan alansal bir kesintiye karşı dayanıklılık sağlar. Coğrafi olarak yedekli depolama (GRS), verilerinizi eşleştirilmiş bölgeye asenkron olarak çoğaltarak LRS’yi genişletir ve iki bölge arasında toplam altı kopya oluşturur; Microsoft hesap yük devretme işlemini başlattıktan sonra ikincil bölge yeni birincil bölge olur. Okuma erişimli coğrafi olarak yedekli depolama (RA‑GRS), uygulamaların yük devretmeden önce bile ikincil bölgeden okuma yapabilmesi için canlı, salt okunur bir ikincil uç nokta ekleyerek küresel okuma dağıtımını ve analiz yükünün boşaltılmasını sağlar. Coğrafi-bölgesel olarak yedekli depolama (GZRS), birincil bölgedeki ZRS’yi eşleştirilmiş bölgedeki LRS’ye asenkron çoğaltma ile birleştirerek hem alansal hem de bölgesel arızalara karşı koruma sağlar; okuma erişimli bir varyantı (RA‑GZRS) ikincil bölgede okuma uç noktaları sunar. Seçim; kurtarma hedefleri, gecikme süresi beklentileri ve bütçeye göre yapılır. Bir bölge içinde ZRS, yazma gecikmesini düşük tutarken alan arızalarına karşı koruma sağlar. Bölgeler arasında GRS/RA‑GRS ve GZRS, olağanüstü durum kurtarma ve bölgeler arası okuma senaryoları için tercih edilir. Coğrafi seçeneklerde ikincil bölgeye veri tutarlılığı tasarım gereği asenkrondur, bu nedenle uygulamaların bir yük devretme tamamlanana kadar nihai tutarlılığı tolere etmesi gerekir.

• LRS
  • Çoğaltma düzeni: Tek bir veri merkezinde (bölge) 3 kopya
  • İkincil kopyaya okuma erişimi: Yok
  • Bölgesel/alansal tolerans: Yerel donanım/raf arızalarına karşı korur
  • Yaygın iş yükleri: Geliştirme/test, düşük maliyetli depolama, kritik olmayan veriler
• ZRS
  • Çoğaltma düzeni: 3 kullanılabilirlik alanına (bölge) senkron olarak 3 kopya
  • İkincil kopyaya okuma erişimi: Yok
  • Bölgesel/alansal tolerans: Uygulama düzeyinde yük devretme olmadan alansal kesintilerden etkilenmez
  • Yaygın iş yükleri: Yüksek bölgesel kullanılabilirlik gerektiren üretim web/uygulama içeriği
• GRS
  • Çoğaltma düzeni: Birincil bölgede LRS + eşleştirilmiş bölgede asenkron LRS (toplam ~6 kopya)
  • İkincil kopyaya okuma erişimi: Yok
  • Bölgesel/alansal tolerans: Hesap yük devretme yoluyla bölgesel olağanüstü durum kurtarma; birincil bölgede alansal koruma yok
  • Yaygın iş yükleri: Bölgesel olağanüstü durum kurtarma duruşuna sahip yedekleme/arşivleme
• RA‑GRS
  • Çoğaltma düzeni: GRS + ikincil bölgede okuma uç noktası
  • İkincil kopyaya okuma erişimi: Var
  • Bölgesel/alansal tolerans: GRS ile aynı; küresel okuma dağıtımını sağlar
  • Yaygın iş yükleri: Küresel içerik okumaları, ikincil bölgeden analiz/raporlama
• GZRS
  • Çoğaltma düzeni: Birincil bölgede ZRS + eşleştirilmiş bölgede asenkron LRS
  • İkincil kopyaya okuma erişimi: Yok (RA‑GZRS kullanın)
  • Bölgesel/alansal tolerans: Alansal arızalara ve bölgesel felaketlere karşı korur
  • Yaygın iş yükleri: Alan + coğrafi dayanıklılık gerektiren görev açısından kritik uygulamalar

Erişim katmanları ve yaşam döngüsü yönetimi

Blob erişim katmanları, depolama maliyetini erişim düzenleriyle uyumlu hale getirir. Hot katmanı, daha yüksek GB başına depolama fiyatına karşılık en düşük okuma ve yazma işlem maliyetleriyle sık erişim için optimize edilmiştir. Cool katmanı, GB başına depolama fiyatını düşürür ve işlem ile erken silme maliyetlerini artırır; bu da onu aylık raporlar veya kısa süreli yedeklemeler gibi seyrek erişilen veri kümeleri için uygun hale getirir. Archive katmanı en düşük depolama maliyetini sunar ancak erişimden önce yeniden canlandırma gerektirir ve en yüksek erişim ile erken silme ücretlerine sahiptir; uzun süreli saklama ve uyumluluk senaryoları için tasarlanmıştır. Yaşam döngüsü yönetimi ilkeleri, kapsayıcı veya hesap düzeyinde katmanlandırmayı ve saklamayı otomatikleştirir. Kurallar, son değiştirilme zamanına, son erişim zamanına veya blob dizin etiketlerine göre blobları Hot, Cool ve Archive arasında taşıyabilir; ve tanımlanmış bir yaştan sonra sürümleri, anlık görüntüleri veya temel blobları silebilir. İlkeler, soğuk verileri Hot depolamadan taşıyarak ve eski verileri manuel müdahale olmadan kullanımdan kaldırarak toplam sahip olma maliyetini düşürmeye yardımcı olur. Yaşam döngüsü yönetimi, genel amaçlı v2 ve Blob depolama hesapları için mevcuttur ve blok ve ekleme blobları üzerinde çalışır; premium blok blobu depolama için geçerli değildir. Arşivden yeniden canlandırma, maliyet karşılığında hız takası sunan standart ve yüksek öncelikli seçenekleri destekler. Standart yeniden canlandırma için saatlerle ölçülen ve daha küçük nesneler için yüksek öncelikli canlandırmada dakikalar ile saatler arasında değişen geri getirme pencereleri için plan yapın. Uyumluluk için, kapsayıcı veya blob düzeyinde bir kez yaz, çok kez oku (WORM) garantilerini uygulamak üzere Archive katmanını değişmezlik ilkeleriyle (zamana dayalı saklama veya yasal tutma) eşleştirin.

• Hot
  • Depolama maliyeti: En yüksek
  • Erişim/işlem maliyeti: En düşük
  • Minimum saklama süresi: Yok
  • Geri getirme gecikmesi: Milisaniyeler (çevrimiçi)
  • Tipik veri: Aktif içerik, sık okunan/yazılan veriler
• Cool
  • Depolama maliyeti: Hot’tan daha düşük
  • Erişim/işlem maliyeti: Hot’tan daha yüksek; erken silme ücreti uygulanır
  • Minimum saklama süresi: 30 gün
  • Geri getirme gecikmesi: Milisaniyeler (çevrimiçi)
  • Tipik veri: Seyrek erişilen veriler, kısa süreli yedeklemeler
• Archive
  • Depolama maliyeti: En düşük
  • Erişim/işlem maliyeti: En yüksek; erken silme ücreti uygulanır
  • Minimum saklama süresi: 180 gün
  • Geri getirme gecikmesi: Saatler (yeniden canlandırma gerekir)
  • Tipik veri: Uzun süreli saklama, uyumluluk arşivleri, nadiren erişilen yedeklemeler

Güvenlik, şifreleme ve erişim denetimi

Bekleme durumundaki verilerin şifrelenmesi (Encryption at rest), Depolama Hizmeti Şifrelemesi (Storage Service Encryption - SSE) aracılığıyla varsayılan olarak etkindir. Varsayılan olarak, Microsoft tarafından yönetilen anahtarlar verileri şeffaf bir şekilde korur. Daha sıkı denetim ve görev ayrılığı için, müşteri tarafından yönetilen anahtarlar (CMK), Azure Key Vault veya Managed HSM’deki anahtarlar kullanılarak depolama hesabı başına yapılandırılabilir ve anahtar rotasyonu ile iptal iş akışlarını destekler. Hassas iş yükleri için çift şifreleme ve gizli bilgi işlem (confidential computing) seçenekleri, veri sızıntısı risklerini daha da azaltır. Aktarım sırasında (In transit), tüm veri düzlemi (data-plane) işlemleri için TLS ile HTTPS zorunlu kılınmalıdır. Erişim denetimi, kimlik tabanlı yetkilendirmeyi ve kapsamı belirlenmiş belirteçleri (scoped tokens) kapsar. Azure RBAC, kullanıcılara, gruplara ve yönetilen kimliklere (managed identities) Storage Blob Data Reader/Contributor gibi en az ayrıcalıklı (least-privilege) veri düzlemi erişimi vermek için Microsoft Entra ID ile entegre olur. RBAC, paylaşılan gizli anahtarları (shared secrets) ortadan kaldırır ve koşullu erişimi (conditional access), Privileged Identity Management’i ve denetlemeyi (auditing) destekler. Shared Access Signatures (SAS), bir kimliğe sahip olmayabilecek istemcilere zaman ve izin kapsamlı erişim yetkisi verir; SAS, hesap anahtarlarının açığa çıkmasını önlemek için hesap anahtarlarıyla veya Microsoft Entra kimlik bilgileri kullanılarak kullanıcı delegasyonu (user delegation) ile imzalanabilir. Hizmetten hizmete (service-to-service) ve yönetimsel erişim için RBAC’yi, geçici istemci erişim akışları için SAS ile birleştirin. Hesap anahtarlarını koruyun ve düzenli olarak döndürün; mümkün olduğunda kullanıcı delegasyonu SAS’ı (user delegation SAS) tercih edin. Private Endpoints veya hizmet uç noktaları (service endpoints) ile ağ yalıtımı, güvenlik duvarı kuralları ve değiştirilemez depolama (immutable storage) ilkeleri, depolama hesapları için derinlemesine savunma (defense-in-depth) duruşunu tamamlar.

• Azure RBAC (Microsoft Entra ID)
  • Kapsam: Depolama veri düzlemi ve yönetim düzleminde kimlik tabanlı roller
  • En uygun olduğu durumlar: Yöneticiler, hizmetler ve yönetilen kimliklere sahip uygulamalar
  • Temel özellikler: En az ayrıcalık, koşullu erişim, denetlenebilirlik, paylaşılan gizli anahtar yok
  • Risk değerlendirmeleri: Kimlik entegrasyonu gerektirir; iptal rol değişiklikleri yoluyla yapılır
• Shared Access Signature (SAS)
  • Kapsam: Belirli kaynaklar üzerinde zaman ve izin kapsamlı belirteçler
  • En uygun olduğu durumlar: İstemcilere/iş ortaklarına sınırlı erişim yetkisi vermek
  • Temel özellikler: Ayrıntılı izinler, IP/zaman kısıtlamaları; kullanıcı delegasyonu SAS (user-delegation SAS) hesap anahtarlarını kullanmaktan kaçınır
  • Risk değerlendirmeleri: Belirtecin sızması, süresi dolana kadar erişim sağlar; dağıtımı koruyun ve kısa geçerlilik süreleri belirleyin

İlişkisel PaaS ve küresel olarak dağıtılmış NoSQL

Azure SQL Database; otomatik yama uygulama, yerleşik yüksek erişilebilirlik, yedeklemeler ve ölçeklendirme özelliklerine sahip, yönetilen bir ilişkisel altyapı sunar. Değişken iş yüklerini birleştirmek için tek veritabanları (single databases) veya elastik havuzlar (elastic pools) dağıtın. Hizmet, bir bölge içinde birden çok kopya (replica) tutar ve alanlar arası yedekliliği (zone redundancy) destekler; Şeffaf Veri Şifrelemesi (Transparent Data Encryption - TDE) varsayılan olarak açıktır. Otomatik yedeklemeler, genellikle 7–35 gün için belirli bir zamana geri yüklemeyi (point‑in‑time restore) mümkün kılar ve Azure depolama alanında yıllara varan isteğe bağlı uzun süreli saklama (long‑term retention) seçeneği sunar. Çok bölgeli dayanıklılık ve düşük gecikmeli okumalar için aktif coğrafi çoğaltmayı (active geo‑replication) (en fazla dört okunabilir ikincil sunucu) veya ölçekte koordineli olağanüstü durum kurtarma (DR) için Otomatik Yük Devretme gruplarını (Auto‑failover groups) kullanın. Azure SQL Managed Instance; SQL Agent, veritabanları arası sorgular, Service Broker ve CLR gibi örnek (instance) düzeyindeki özellikler için %100’e yakın SQL Server altyapı uyumluluğu sunarak, şirket içinden (on-premises) yeniden düzenleme (refactoring) yapmadan kolayca modernizasyon sağlar. Aynı yönetilen yüksek erişilebilirlik (HA) mimarisini, çevrimiçi yama uygulamayı, otomatik yedeklemeleri, varsayılan TDE’yi paylaşır ve bölgeler arasında otomatik yük devretme gruplarını (auto‑failover groups) destekler. Özel uç noktalar (private endpoints) ile ağ yalıtımı ve veritabanı veya örnek başına işlem/depolama ölçeklendirmesi, öngörülebilir performans zarfları (performance envelopes) sağlar. Azure Cosmos DB, anahtar teslim küresel dağıtım ve çok bölgeli yazma (multi‑region writes) özelliklerine sahip, tam olarak yönetilen, çok modelli (multi‑model) bir NoSQL veritabanı sağlar. Bir bölge içinde 99. yüzdelik dilimde tek haneli milisaniye gecikme sürelerini garanti eder ve bölgeler arasında performans ile doğruluğu dengelemek için ayarlanabilir beş tutarlılık seviyesi (consistency levels) sunar. RU/s cinsinden iş hacmi (throughput) sağlayın veya otomatik ölçeklendirme (autoscale) kullanın, kesinti olmadan bölge ekleyip çıkarın ve otomatik yük devretmeyi (automatic failover) yapılandırın. API’ler arasında Core (SQL), MongoDB, Cassandra, Gremlin ve Table bulunur; bu da çeşitli uygulama yığınları arasında geçişi ve entegrasyonu basitleştirir.

• Azure SQL Database
  • Model: İlişkisel PaaS (tek veritabanı/elastik havuz)
  • Uyumluluk: En son SQL özellikleri; uygulama düzeyinde uyumluluk
  • HA/DR: Yerleşik kopyalar, alanlar arası yedeklilik; aktif coğrafi çoğaltma; Otomatik Yük Devretme grupları
  • Yedeklemeler/TDE: Otomatik PITR 7–35 gün; yıllara kadar LTR; varsayılan olarak TDE açık
  • Coğrafi seçenekler: Bölgeler arasında okunabilir ikincil sunucular; koordineli yük devretme grupları
  • En uygun olduğu durumlar: SaaS/çok kiracılı (multi-tenant) uygulamalar, yeni bulut tabanlı (cloud-native) ilişkisel iş yükleri
• Azure SQL Managed Instance
  • Model: İlişkisel PaaS (örnek)
  • Uyumluluk: SQL Agent, veritabanları arası (cross-DB) sorgular dahil yüksek SQL Server özellik denkliği
  • HA/DR: Yerleşik HA; alanlar arası yedeklilik; Otomatik Yük Devretme grupları
  • Yedeklemeler/TDE: Otomatik PITR 7–35 gün; LTR; varsayılan olarak TDE açık; yerel geri yükleme (native restore) desteği
  • Coğrafi seçenekler: Yük devretme grupları ve okunabilir ikincil sunucular ile çok bölgeli
  • En uygun olduğu durumlar: Şirket içi SQL’in minimum değişiklikle olduğu gibi taşıma (lift‑and‑shift)
• Azure Cosmos DB
  • Model: NoSQL, çok modelli (Core, MongoDB, Cassandra, Gremlin, Table)
  • Uyumluluk: Popüler NoSQL yığınları için API düzeyinde uyumluluk
  • HA/DR: Çok bölgeli, çok ana sunuculu yazma (multi-master writes); %99,99 SLA’lar
  • Yedeklemeler/TDE: Otomatik ve sürekli yedekleme seçenekleri; bekleme durumunda şifreleme
  • Coğrafi seçenekler: Canlı olarak bölge ekleme/çıkarma; ayarlanabilir tutarlılık; otomatik yük devretme
  • En uygun olduğu durumlar: Küresel, düşük gecikmeli uygulamalar, IoT, kataloglar, kişiselleştirme

Uygulama Problemi: Tailwind Traders: Güvenli, maliyet açısından optimize edilmiş veri katmanları ile iki yakada dayanıklılık

Senaryo: Tailwind Traders, ana iş yükleri East US’te ve bir olağanüstü durum kurtarma varlığı West US’te olacak şekilde e-ticaret operasyonları yürütmektedir. Ürün resimleri ve günlükler nesne depolamada saklanırken, siparişler ve envanter yönetilen bir ilişkisel veritabanında çalışır. Bölgesel olaylar sırasında, kataloğun göz atılabilir kalması için işletmenin ikincil bölgeden ürün medyasına okuma erişimine ihtiyacı vardır. Veri yönetişimi, müşteri tarafından yönetilen anahtarlarla şifreleme ve denetim günlüklerinin zamana dayalı olarak saklanmasını gerektirir.

Zorluk: Medya için bölgeler arası okuma erişimi sağlayan, günlükler için otomatik yaşam döngüsü ve saklama sunan, güçlü şifreleme ve en az ayrıcalıklı erişim sağlayan ve yerleşik yüksek kullanılabilirlik ve olağanüstü durum kurtarma özelliklerine sahip yönetilen bir ilişkisel arka uç sunan depolama ve veritabanı hizmetleri tasarlayın.

Önerilen Yaklaşım:

1. 1. Ürün medyası kapsayıcıları için East US’te RA-GRS (veya bölgesel dayanıklılık da gerekiyorsa RA-GZRS) ile genel amaçlı bir v2 depolama hesabı oluşturun.
2. 2. Yalnızca HTTPS’yi etkinleştirin, VNet’e bir özel uç nokta yapılandırın ve depolama hesabı için Azure Key Vault’tan müşteri tarafından yönetilen anahtarları entegre edin.
3. 3. Yaşam döngüsü ilkelerini tanımlayın: 30 gün boyunca erişilmeyen medyayı Cool’a ve 180 gün sonra Archive’e taşıyın; arşivlenmiş medyayı 5 yıl sonra silin.
4. 4. Yalnızca ekleme yapılan uygulama günlükleri için, değişmez (zamana dayalı) saklama ilkelerine sahip bir append-blob kapsayıcısı ve eski günlükleri Archive’e geçirmek için ayrı bir yaşam döngüsü kuralı kullanın.
5. 5. Yönetilen kimliklere Azure RBAC (Storage Blob Data Contributor) kullanarak uygulama erişimi verin; iş ortağı yüklemelerinin bir hazırlık kapsayıcısına yapılması için kısa ömürlü kullanıcı delegasyonu SAS’ları oluşturun.
6. 6. Siparişler ve envanter için Azure SQL Database (Business Critical veya bölgesel yedeklilik ile General Purpose) sağlayın; West US’e çoğaltma yapmak için Auto-failover gruplarını yapılandırın.
7. 7. Otomatik yedeklemeleri (PITR 7–35 gün) doğrulayın ve gerektiğinde uyumluluk veritabanları için uzun süreli saklamayı etkinleştirin.
8. 8. Transparent Data Encryption’ı (varsayılan olarak etkindir) uygulayın ve gerekirse SQL sunucusu kaynağı için kendi anahtarınızı getirin.
9. 9. Birincil bölgenin performansı düştüğünde ürün medyasını ikincil RA uç noktası üzerinden okuması için e-ticaret uygulamasını güncelleyin; yük devretme gerçekleşene kadar birincil SQL’e işlemsel yazmalara devam edin.
10. 10. Hem depolama (hesap yük devretme) hem de SQL (Auto-failover grubu) için yük devretme tatbikatları yapın ve RTO/RPO’yu iş hedeflerine göre belgeleyin.

Azure Gerekçesi: RA-GRS, birincil bölgede üç eşzamanlı kopya ve eşleştirilmiş bölgeye eşzamansız çoğaltma sağlar ve salt okunur bir ikincil uç nokta sunarak bölgesel bir kesinti sırasında katalog okumalarına hizmet etme gereksinimini karşılar. Yaşam döngüsü ilkeleri, seyrek erişilen medyayı Cool ve Archive katmanlarına taşıyarak ve günlükler için değişmezlik ile zamana dayalı saklamayı zorunlu kılarak depolama maliyetlerini erişim desenleriyle uyumlu hale getirir. Müşteri tarafından yönetilen anahtarlar ve özel uç noktalar güvenlik ve uyumluluğu güçlendirirken, Azure RBAC ve kullanıcı delegasyonu SAS en az ayrıcalık ilkesini ve güvenli yetki devrini zorunlu kılar. Azure SQL Database yerleşik HA, TDE ve otomatik yedeklemeler sunar; Auto-failover grupları, hizmet sürekliliğini sağlamak için işlemsel iş yükleri için kontrollü, test edilmiş bölgeler arası yük devretme sağlar.

← Ağ · Tüm alanlar · Kimlik →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Microsoft'a göz atın →