Microsoft AZ-900: Azure Mimarisi ve Küresel Altyapı — Ç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’ın küresel mimarisi, ölçeklenebilir, dayanıklı, performanslı ve uyumlu bulut hizmetleri sunmak üzere tasarlanmıştır. Coğrafyaların, bölgelerin ve kullanılabilirlik alanlarının fiziksel düzenini ve yönetim grupları, abonelikler, kaynak grupları ve kaynakların mantıksal hiyerarşisini anlamak, güvenilir tasarım ve yönetişimin temelini oluşturur. Azure Resource Manager tarafından sağlanan kontrol düzlemi, bildirimsel şablonlarla birleştiğinde, kurumsal politika ve güvenlik gereksinimleriyle uyumlu, tutarlı ve tekrarlanabilir dağıtımlar sağlar. Bu alandaki tasarım kararları, kullanılabilirlik hedeflerini, veri yerleşimi yükümlülüklerini ve dünya çapındaki kullanıcı deneyimini doğrudan etkiler. Doğru yedeklilik modelini seçmek, bileşik SLA’ları hesaplamak ve Azure Front Door, Traffic Manager ve Azure CDN gibi küresel yönlendirme hizmetlerini tercih etmek; iş sürekliliği, uyumluluk ve performans hedeflerine ulaşmanın merkezinde yer alır.

Coğrafyalar, Bölgeler, Kullanılabilirlik Alanları ve Bölge Çiftleri

Azure coğrafyaları, veri yerleşimi ve uyumluluk sınırlarını koruyan, tanımlanmış bölge kümeleridir. Örnekler arasında Amerika Birleşik Devletleri, Avrupa, Birleşik Krallık, Avustralya ve Kanada’nın yanı sıra farklı uyumluluk ve bağlantı modellerine sahip egemen bulutlar (sovereign clouds) bulunur. Belirli bir yargı alanı içinde kalması gereken iş yükleri, yasal düzenlemelere uyum ve veri yerleşimini sağlamak için hedef coğrafyaya ait bölgelere dağıtılmalıdır. Bir bölge, gecikme süresiyle tanımlanmış bir çevre içinde dağıtılan ve özel, düşük gecikmeli bir ağ üzerinden bağlanan bir veri merkezi kümesidir. Her hizmet veya özellik her bölgede mevcut değildir, bu nedenle kapasite ve özellik kullanılabilirliği planlamanın erken aşamalarında doğrulanmalıdır. Kullanılabilirlik Alanlarını (Availability Zones) destekleyen bölgeler, bağımsız güç, soğutma ve ağ bağlantılarına sahip, fiziksel olarak ayrı üç veya daha fazla veri merkezi alanı sağlar. Alanlar arası yedekli hizmetler (Zone-redundant services - ZRS) ve alanlar arasında mimari oluşturmak, bölge içinde düşük gecikmeli erişimi korurken veri merkezi düzeyindeki arızalara karşı koruma sağlar. Her Azure bölgesi, bir bölge çifti oluşturmak için aynı coğrafya içindeki başka bir bölgeyle eşleştirilir (örneğin, North Europe ile West Europe, East US ile West US). Bölge çiftleri, geniş çaplı kesintiler sırasında öncelikli kurtarmayı, kademeli platform güncellemelerini ve belirli hizmetler için veri replikasyonunu mümkün kılar. Azure Storage’ın coğrafi olarak yedekli seçenekleri (GRS/GZRS), verileri eşleştirilmiş bölgeye zaman uyumsuz olarak çoğaltır; ikincil bölgeye okuma erişimi gerektiğinde, bir kesinti veya planlı yük devretme sırasında ikincil uç noktadan okumalara izin vermek için RA-GRS veya RA-GZRS kullanılır. Hem bölge içi yüksek kullanılabilirlik hem de bölgeler arası olağanüstü durum kurtarma gerektiren görev açısından kritik iş yükleri için, alanlar arası yedekliliği bölge çifti replikasyonuyla birleştirin. Gecikme, dayanıklılık ve uyumluluğu dengelemek yaygın bir desene yol açar: aktif iş yüklerini birincil bir bölgedeki alanlara dağıtın ve verileri çoğaltıp eşleştirilmiş bölgeye yük devretme yolları sağlayarak bölgesel felaketlere karşı koruma sağlayın. Kurtarma hedeflerinin karşılandığından emin olmak için yük devretme runbook’larını ve DNS veya ön uç yönlendirme davranışını düzenli olarak doğrulayın.

• Coğrafya
  • Kapsam: Çok bölgeli sınır
  • Temel Fayda: Veri yerleşimi ve uyumluluk
  • Tipik Kullanım: Yasal düzenlemelere uyum (ör. AB verileri)
• Bölge
  • Kapsam: Tek bir metropol alanı
  • Temel Fayda: Hizmetlere düşük gecikmeli erişim
  • Tipik Kullanım: Birincil dağıtım konumu
• Kullanılabilirlik Alanı
  • Kapsam: Bir bölge içindeki farklı veri merkezleri
  • Temel Fayda: Veri merkezi düzeyinde hata yalıtımı
  • Tipik Kullanım: Bölge içi yüksek kullanılabilirlik
• Bölge Çifti
  • Kapsam: Aynı coğrafyadaki iki bölge
  • Temel Fayda: Koordineli kurtarma ve güncellemeler
  • Tipik Kullanım: Bölgeler arası olağanüstü durum kurtarma

Kaynak Organizasyonu ve Yönetişim: Yönetim Grupları, Abonelikler, Kaynak Grupları ve Kaynaklar

Azure’nin yönetim hiyerarşisi, ölçekli bir şekilde ilke, erişim ve maliyet kontrolü sağlar. Yönetim grupları, aboneliklerin üzerinde yer alır ve Azure Policy ile rol tabanlı erişim kontrolünü (RBAC) merkezi olarak uygulamanıza olanak tanır; bu uygulama, alt yönetim gruplarına ve aboneliklere kalıtım yoluyla aktarılır. Bu yapı, şirket bölümleri, ortam katmanları (üretim, üretim dışı) veya yasal sınırlar bazında segmentasyon yapmak ve aynı zamanda tek tip koruma mekanizmalarını (guardrails) sürdürmek için doğru bir yaklaşımdır. Abonelikler, idari, faturalandırma ve kota sınırını oluşturur. İş birimleri, ortamlar veya uygulamalar için maliyet ve erişimi izole etmek amacıyla oldukça uygundurlar. Üretim ortamını üretim dışı ortamdan ayırmak, limitleri ve bütçeleri zorunlu kılmak için tutarlı bir abonelik tasarımı kullanın. Birden çok bölümü ve merkezi olmayan yönetimi olan kuruluşlar için, her bölüme bir veya daha fazla abonelik atayın ve temiz bir ilke ve RBAC kalıtımı için bunları bölüme özgü yönetim gruplarının altına yerleştirin. Kaynak grupları, aynı yaşam döngüsünü paylaşan kaynaklar için mantıksal kapsayıcılardır. Atomik dağıtımları, tutarlı etiketlemeyi ve silme veya kilitleme gibi yaşam döngüsü operasyonlarını mümkün kılarlar. Bir web katmanı ve onun izleme bileşenleri gibi birlikte dağıtılan, güncellenen ve kullanımdan kaldırılan kaynakları gruplayın. Kaynaklar ve gruplar genelinde geri ödeme/maliyet dökümü (chargeback/showback), sahiplik, ortam ve uyumluluk niteliklerini yönetmek için etiketleri kullanın. Kilitler (ReadOnly, CanNotDelete), kaynak veya grup kapsamında yanlışlıkla silinmeye karşı koruma ekler. Kaynaklar, dağıtılan hizmet örnekleridir (VM’ler, App Service planları, depolama hesapları). RBAC kapsamları (yönetim grubu, abonelik, kaynak grubu, kaynak), en az ayrıcalıklı erişimin tam olarak ihtiyaç duyulan yerde verilmesine olanak tanır. Çok bölümlü dağıtımlar için, birden çok tenant gerektiren güçlü bir uyumluluk veya özerklik zorunluluğu olmadıkça tek bir Microsoft Entra ID tenant’ı kullanın; abonelikler ve yönetim grupları genellikle çok daha az idari yük ile yeterli ayrımı sağlar.

• Yönetim Grubu
  • Temel Amaç: Kurum çapında yönetişim
  • Uygulanan Kontroller: RBAC, Policy, Blueprints (Policy + şablonlar aracılığıyla)
  • Yaygın Desenler: Bölüm/yasal düzenleme segmentasyonu
• Abonelik
  • Temel Amaç: Faturalandırma ve kota sınırı
  • Uygulanan Kontroller: Bütçeler, RBAC, Policy
  • Yaygın Desenler: İş birimi veya ortam başına izolasyon
• Kaynak Grubu
  • Temel Amaç: Yaşam döngüsü sınırı
  • Uygulanan Kontroller: Kilitler, Etiketler, RBAC
  • Yaygın Desenler: Uygulama veya iş yükü birimi başına
• Kaynak
  • Temel Amaç: Hizmet örneği
  • Uygulanan Kontroller: Örnek düzeyinde RBAC, Etiketler
  • Yaygın Desenler: Bireysel hizmet bileşenleri

Azure Resource Manager ve Şablonlar

Azure Resource Manager (ARM), tutarlı bir API ve rol tabanlı model aracılığıyla Azure kaynaklarını dağıtmak, güncellemek ve silmek için kullanılan kontrol düzlemidir (control plane). ARM, dağıtım zamanında bir kez etkili (idempotent) operasyonlar, bağımlılık yönetimi, etiketleme ve ilke zorunluluğu sağlayarak platform yönetişiminin her değişikliğe dahil edilmesini mümkün kılar. Bildirimsel (declarative) ARM şablonları, ortamınızın istenen durumunu JSON formatında tanımlar ve parametreleri, değişkenleri, koşulları ve modüler bağlantılı şablonları destekler. Ortamlar ve abonelikler arasında tekrarlanabilir, sürüm kontrollü dağıtımları mümkün kılarlar. Daha akıcı bir yazma deneyimi için Bicep, aynı dağıtım motorunu ve avantajları korurken ARM şablonlarına dönüşen (transpile) daha öz bir sözdizimi sunar. Sapmasız (drift-free) ve denetlenebilir altyapı değişiklikleri sağlamak için şablonları kaynak kontrolünde saklayın, paylaşım için template specs olarak paketleyin ve CI/CD işlem hatlarına entegre edin. Yönetici parolaları veya bağlantı dizeleri gibi hassas değerler asla şablonların içine gömülmemelidir. ARM’in dağıtım sırasında gizli bilgileri loglarda ifşa etmeden alabilmesi için Key Vault referansları ile secureString/secureObject parametrelerini kullanın. Otomasyondaki sabit kodlanmış kimlik bilgilerini ortadan kaldırmak için şablonları yönetilen kimliklerle (managed identities) birleştirin. Bu yaklaşım, büyük ölçekli, çoklu abonelikli dağıtımlar için tam otomasyonu korurken riski azaltır.

• Bir kez etkili (Idempotent) dağıtımlar
  • ARM/Şablon Desteği: Evet
  • Sonuç: Güvenli, tekrarlanabilir değişiklikler
• Dağıtım sırasında ilke zorunluluğu
  • ARM/Şablon Desteği: Evet
  • Sonuç: İşlem hatlarına entegre edilmiş koruma mekanizmaları
• Modüler kompozisyon
  • ARM/Şablon Desteği: Bağlantılı modüller / Bicep modülleri
  • Sonuç: Yeniden kullanılabilirlik ve standardizasyon
• Gizli bilgi yönetimi
  • ARM/Şablon Desteği: Key Vault referansları
  • Sonuç: Kodda veya loglarda gizli bilgi bulunmaz

Kullanılabilirlik, SLA’lar, Bileşik SLA’lar ve Hizmet Yaşam Döngüsü

Azure, genel kullanıma sunulmuş (GA) hizmetler için finansal olarak desteklenen hizmet seviyesi anlaşmaları (SLA’lar) yayınlar. Sanal makineler için kullanılabilirlik, dağıtım topolojisine bağlıdır: Premium SSD depolamaya sahip tek bir sanal makine %99,9 SLA’ya sahiptir; bir kullanılabilirlik setindeki (availability set) iki veya daha fazla sanal makine %99,95 SLA’ya sahiptir; ve kullanılabilirlik bölgelerine (availability zones) dağıtılmış iki veya daha fazla sanal makine %99,99 SLA’ya ulaşır. Platform hizmetlerinin (örneğin, Azure SQL Database veya App Service) katmana veya yedeklilik seçeneğine göre değişebilen kendi SLA’ları vardır. Uygun yedeklilik modelini ve hizmet katmanlarını seçerek mimariyi hedef SLA ile uyumlu hale getirin. Bir çözüm birden çok hizmete bağlı olduğunda, uygulamanın çalışması için tüm bileşenler gerekliyse, bileşik SLA bireysel SLA’ların çarpımıdır. Örneğin, bir web uygulaması (%99,95) bir veritabanına (%99,99) bağlıysa, bileşik kullanılabilirlik yaklaşık olarak 0,9995 × 0,9999 = %99,94 olur. Bölgeler arasında dağıtım yapmak, bir yük dengeleyicinin arkasına birden çok örnek eklemek veya coğrafi olarak yedekli veri depoları kullanmak gibi herhangi bir katmanda yedekliliği artırmak, etkin kullanılabilirliği iyileştirir. Tersine, seri bağımlılıklar eklemek bileşik SLA’yı düşürür ve net bir işlevsel değerle gerekçelendirilmelidir. Hizmet yaşam döngüsü durumu, güvenilirlik garantilerini etkiler. Herkese açık önizleme (public preview) özellikleri geri bildirim toplamak için sunulur ve belirli bölgelerle sınırlı olabilir veya özellik eksiklikleri içerebilir; genellikle bir SLA taşımazlar ve üretim açısından kritik yollar için önerilmezler. GA (genel kullanıma sunum) özellikleri üretime hazırdır ve bir SLA kapsamındadır. Özellikle uyumluluk açısından hassas ortamlarda, üretim tasarımlarında yanlışlıkla önizleme özelliklerine güvenmekten kaçınmak için yol haritaları ve bölge dağıtım takvimleri takip edilmelidir. RPO ve RTO gibi felaket kurtarma hedefleri, SLA’ları tamamlar ve bölgeler arası veya çapraz bölge çoğaltma, yedekleme sıklığı ve yük devretme (failover) orkestrasyonu gibi tasarım seçimlerine rehberlik eder. Ölçülen kurtarma performansının iş hedefleriyle uyumlu olduğundan ve DNS, sertifikalar ve kimlik bağımlılıklarının da beklendiği gibi kurtarıldığından emin olmak için yük devretme prosedürlerini düzenli olarak doğrulayın.

• Tek Sanal Makine (Premium SSD)
  • Gösterge SLA: %99,9
  • Notlar: Kritik olmayan iş yükleri veya toleranslı uygulamalar için kullanın
• Kullanılabilirlik Setinde 2+ Sanal Makine
  • Gösterge SLA: %99,95
  • Notlar: Raf/hata etki alanı (fault domain) arızalarına karşı korur
• Kullanılabilirlik Bölgelerinde 2+ Sanal Makine
  • Gösterge SLA: %99,99
  • Notlar: Veri merkezi düzeyindeki arızalara karşı korur
• Herkese Açık Önizleme (Public Preview) özelliği
  • Gösterge SLA: Finansal SLA yok
  • Notlar: Değerlendirin; kritik yollarda kullanmaktan kaçının
• GA özelliği (hizmet katmanına bağlı)
  • Gösterge SLA: SLA destekli
  • Notlar: Katmana ve bölgeye özgü SLA’ları kontrol edin

Global Yönlendirme ve İçerik Dağıtımı: Azure Front Door, Traffic Manager ve Azure CDN

Global kullanıcı deneyimi, akıllı yönlendirmeye, içeriğe yakınlığa ve hızlı yük devretmeye (failover) bağlıdır. Azure Front Door, Web Application Firewall (WAF), TLS sonlandırma, URL/yol tabanlı yönlendirme, oturum benzeşimi (session affinity) ve uç noktalardan (edge) sağlık denetimleri (health probes) özelliklerine sahip global, anycast bir Katman 7 ters proxy’dir. Split-TCP ve protokol optimizasyonları aracılığıyla dinamik içeriği hızlandırır ve kaynaklar (origin) arasında neredeyse anında yük devretme sağlar. Front Door, hem performansa hem de uç noktada merkezi güvenliğe ihtiyaç duyduğunuz aktif-aktif veya aktif-pasif çok bölgeli web uygulamaları ve API’ler için idealdir. Azure Traffic Manager, öncelik, ağırlıklı, performans (gecikme), coğrafi, alt ağ veya çok değerli gibi politikaları kullanarak istemcileri en iyi uç noktaya yönlendiren DNS tabanlı bir trafik dağıtım hizmetidir. DNS seviyesinde çalıştığı için HTTP olmayan uç noktaları (ör. TCP hizmetleri) ve hibrit senaryoları destekler, ancak yük devretme hızı DNS TTL ve istemci önbelleklemesi ile sınırlıdır. Traffic Manager trafiği proxy’lemez veya içeriği hızlandırmaz; sadece seçilen uç nokta ile DNS’e yanıt verir. Azure CDN, gecikmeyi azaltmak ve kaynakların (origin) yükünü hafifletmek için statik içeriği uç varlık noktalarında (edge points of presence) önbelleğe alır. Görüntüler, videolar, betikler ve indirmeler gibi büyük statik varlıklar için çok uygundur. CDN, önbelleğe alınabilir içerik için gidiş-dönüş sürelerini azaltsa da, dinamik kaynaklar için sağlık durumunu bilen bir global yük dengeleyici değildir; çok kaynaklı yük devretme veya dinamik yönlendirme mantığı için Front Door veya Traffic Manager ile birleştirin. Birçok mimari, aynı uygulamanın önüne statik varlık önbelleklemesi için CDN’yi ve dinamik trafik ile güvenlik için Front Door’u yerleştirir.

• Azure Front Door (Std/Prm)
  • Katman/Mekanizma: Katman 7 anycast proxy
  • Birincil Kullanım Alanları: Global yük dengeleme, uç nokta güvenliği, hızlandırma
  • Yönlendirme Yöntemleri: Öncelik, ağırlıklı; yol/ana bilgisayar tabanlı kurallar
  • Sağlık Denetimi: Uç POP denetimleri
  • Yük Devretme Hızı: Saniyeler (neredeyse anında)
  • Dinamik Hızlandırma: Evet
  • Statik Önbellekleme: Evet (kural tabanlı)
  • WAF Mevcut: Evet (entegre)
  • Tipik Model: Çok bölgeli web uygulamalarının/API’lerinin önünde Front Door
• Azure Traffic Manager
  • Katman/Mekanizma: DNS tabanlı politika
  • Birincil Kullanım Alanları: Bölgeler arası DNS yönlendirme; HTTP olmayan uç noktalar
  • Yönlendirme Yöntemleri: Öncelik, ağırlıklı, performans, coğrafi, alt ağ, çok değerli
  • Sağlık Denetimi: Global uç nokta denetimleri
  • Yük Devretme Hızı: TTL’ye bağlı (on saniyelerden dakikalara kadar)
  • Dinamik Hızlandırma: Hayır
  • Statik Önbellekleme: Hayır
  • WAF Mevcut: Yok
  • Tipik Model: HTTP ve HTTP olmayan hizmetler için DNS yönlendirmesi
• Azure CDN
  • Katman/Mekanizma: Uç önbellekleme ağı
  • Birincil Kullanım Alanları: Statik içerik yükünü boşaltma ve gecikmeyi azaltma
  • Yönlendirme Yöntemleri: Yok (önbellek kuralları)
  • Sağlık Denetimi: Yok (isteğe bağlı kaynak grubu yük devretme)
  • Yük Devretme Hızı: Yok (önbellek tabanlı)
  • Dinamik Hızlandırma: Hayır (önbellek ötesinde)
  • Statik Önbellekleme: Evet
  • WAF Mevcut: Front Door Premium veya ayrı bir WAF aracılığıyla
  • Tipik Model: Varlıklar için CDN + kaynaklar için Front Door/Traffic Manager

Uygulamalı Problem: IronPeak Manufacturing için Yüksek Erişilebilirliğe Sahip, Uyumlu ve Global Olarak Performanslı bir Web Platformu Tasarlama

Senaryo: IronPeak Manufacturing, Avrupa ve Kuzey Amerika’da faaliyet göstermektedir ve müşteri ile iş ortağı portallarını Azure üzerinde birleştirmektedir. Platform, web katmanı için %99,99 erişilebilirlik sağlamalı, AB müşteri verilerini AB içinde tutmalı, bölgeler arasında hızlı yük devretme (failover) sunmalı ve dünya çapında hızlı sayfa yüklemeleri sağlamalıdır. Ekip, kodda veya loglarda düz metin (plaintext) olarak saklanan gizli bilgiler olmadan, tamamen otomatikleştirilmiş dağıtımlar istemektedir.

Zorluk: AB’de veri yerleşikliğini (data residency) sağlayarak bölge içi yüksek erişilebilirlik ve bölgeler arası olağanüstü durum kurtarma elde etmek, dinamik trafik için global hızlandırma ve yük devretme sağlamak ve abonelikler arasında tekrarlanabilir, güvenli dağıtımlar gerçekleştirmek.

Önerilen Yaklaşım:

1. Avrupa coğrafyasını seçin ve birincil iş yükünü, Availability Zones bulunan bir bölgede (örneğin, West Europe), bölgelere dağıtılmış iki veya daha fazla VM scale set örneği veya App Service örneği kullanarak dağıtın.
2. Eşleştirilmiş bölgeye (North Europe) bölgeler arası olağanüstü durum kurtarmayı, servislerin yerel replikasyonunu kullanarak etkinleştirin: Storage için RA-GZRS ve mevcut olan veritabanları için coğrafi replikasyon (geo-replication) kullanın; otomatikleştirilmiş yük devretme (failover) runbook’ları yapılandırın.
3. Uygulamanın önüne, global HTTPS sonlandırma, WAF, uç sistem sağlık denetimleri (edge health probes), West Europe (birincil) ve North Europe (ikincil) arasında öncelik tabanlı yük devretme ve yol tabanlı yönlendirme (path-based routing) kuralları için Azure Front Door Standard/Premium’u konumlandırın.
4. Gecikmeyi azaltmak ve trafiği boşaltmak için statik varlıkları (görseller, betikler, indirilen dosyalar) aynı kaynaklarla (origin) entegre edilmiş Azure CDN kullanarak önbelleğe alın; önbellek kurallarını ve TTL’leri doğrulayın.
5. AB ve KA (Kuzey Amerika) bölümleri için yönetim grupları (management groups) tanımlayın; her birinin altına üretim ve üretim dışı abonelikleri yerleştirin ve veri yerleşkliği, etiketleme ve izin verilen konumlar için Azure Policy uygulayın.
6. Kaynak kontrolünde saklanan ve şablon özellikleri (template specs) olarak yayınlanan ARM/Bicep şablonları uygulayın; bölgeleri, SKU’ları ve ölçeklendirmeyi parametreleştirin; dağıtımlar için yönetilen kimlikleri (managed identities) kullanarak Azure Key Vault’taki gizli bilgilere referans verin.
7. SLA’ları belirleyin ve bileşik erişilebilirliği test edin: Front Door arkasındaki bölgeye dağıtılmış iki örnek, uygulama katmanı için %99,99’u hedefler; uçtan uca yük devretme tatbikatlarını, DNS, sertifikaları ve kimlik bağımlılıklarını üç ayda bir doğrulayın.
8. Platformu Application Insights ve Azure Monitor ile izleyin (instrument); Front Door sağlık denetimlerini ve uyarıları yapılandırın; telemetri verilerine dayanarak otomatik ölçeklendirme (autoscale) ve önbellekleme politikalarını ayarlayın.

Azure Gerekçesi: Bu tasarım, Availability Zones aracılığıyla bölge içi hata yalıtımı ve eşleştirilmiş bölgeye bölgeler arası olağanüstü durum kurtarma sağlarken, AB verilerini Avrupa coğrafyası içinde tutar. Azure Front Door, dinamik trafik için global hızlandırma ve sağlık durumuna duyarlı yük devretme sağlarken, Azure CDN performans için statik içeriği boşaltır. Key Vault referanslarına sahip ARM/Bicep şablonları, abonelikler ve bölgeler arasında tekrarlanabilir, güvenli dağıtımlar sağlar. Seçilen topolojiler, web katmanı için %99,99 hedefini karşılamak üzere yayınlanmış SLA’larla uyumludur ve yönetim grubu ile abonelik seviyelerindeki ilke (policy), minimum operasyonel yük ile yönetişimi zorunlu kılar.

← Bulut Kavramları · Tüm alanlar · İşlem ve Uygulama Hizmetleri →

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

Microsoft'a göz atın →