Microsoft AZ-305: Yüksek Erişilebilirlik, Felaket Kurtarma ve İş Sürekliliği — Çalışma kılavuzu
Şunun bir parçası: Microsoft Azure Solutions Architect Expert AZ-305 — Ç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.
Genel Bakış
Azure’da yüksek kullanılabilirlik (HA), olağanüstü durum kurtarma (DR) ve iş sürekliliği (BC), işlem, veri ve ağ katmanlarında bilinçli bir tasarım gerektirir. Dayanıklılık, net kurtarma süresi hedefi (RTO) ve kurtarma noktası hedefi (RPO) hedefleriyle başlar, ardından platform yeteneklerini (Kullanılabilirlik Alanları, küresel yönlendirme, veri çoğaltma, yedekleme ve yük devretme orkestrasyonu) test edilmiş, otomatik bir stratejiye dönüştürür. Azure, maliyeti ve operasyonel karmaşıklığı kontrol altında tutarken sıkı hedefleri karşılamak için alan ve bölge hata yalıtımı, DNS ve anycast tabanlı küresel dağıtım, çok bölgeli veri dayanıklılığı ve ilke tabanlı yedekleme/geri yükleme sağlar.
RTO/RPO Odaklı Mimari ve Alansal/Küresel Dayanıklılık
Tasarım, RTO ve RPO ile başlar. RTO, bir arızadan sonra hizmetin ne kadar hızlı bir şekilde devam etmesi gerektiğini belirtir; RPO, kabul edilebilir maksimum veri kaybını belirtir. Düşük RTO’yu karşılamak, otomatik yük devretme ve önceden sağlanan kapasite gerektirir; düşük RPO’yu karşılamak, zaman uyumlu veya zaman uyumluya yakın çoğaltma ve sık, tutarlı kurtarma noktaları gerektirir.
Kullanılabilirlik Alanları, bir bölge içindeki bağımsız veri merkezi hata etki alanlarıdır. Alana özgü hizmetler (örneğin, Virtual Machines, yönetilen diskler, Standard genel IP’ler) tek bir alana sabitlenmiştir. Alanlar arası yedekli hizmetler (örneğin, Azure Load Balancer Standard alanlar arası yedekli ön uçları, alanlar arası yedekli depolama teklifleri ve alanlar arası yedekli Azure SQL katmanları) alanları otomatik olarak kapsar. Tipik bir dayanıklı model, en az iki alanda alana özgü VM’ler dağıtır, bunları tek bir sanal ağa yerleştirir ve alanlar arası yedekli bir yük dengeleme ön ucu sunar. Bu, tek bir alan arızasının kesinti nedeni olmasını ortadan kaldırır.
Küresel uçta, DNS tabanlı ve anycast-proxy yük dağıtımı arasında seçim yapın:
- Azure Traffic Manager, DNS tabanlıdır. İstemcileri yönlendirme yöntemlerini kullanarak uç noktalara yönlendirir: Performans (en düşük gecikme süresi), Ağırlıklı (A/B testi ve kademeli trafik kaydırmaları), Öncelik (aktif/pasif yük devretme), Coğrafi (kullanıcılara bölgesel olarak uyumlu uç noktalardan hizmet verme), Çok Değerli (basit istemciler için birden çok sağlıklı IPv4/IPv6 kaydı döndürür) ve Alt Ağ (istemci IP aralıklarını belirli uç noktalara eşleme). DNS tabanlı olduğu için Traffic Manager, içeriği hızlandırmaz veya trafiğe proxy’lik yapmaz; istemciler seçilen uç noktaya doğrudan bağlanır ve yerel DNS önbelleğe alma davranışına uyar.
- Azure Front Door (Standard/Premium), akıllı yönlendirme, TLS sonlandırma ve entegre web uygulaması güvenlik duvarı (WAF) özelliklerine sahip küresel bir anycast HTTP/HTTPS ters proxy’sidir. Yönlendirme kuralları etki alanı, yol, yöntem ve başlıklara göre eşleşir, ardından kaynak gruplarına yönlendirir; kural altyapısı eylemleri URL’leri/başlıkları yeniden yazabilir ve yeniden yönlendirmeleri zorunlu kılabilir. Sistem durumu yoklamaları, yapılandırılabilir bir yol ve protokolde kaynak durumunu sürekli olarak değerlendirir; sağlıksız kaynaklar rotasyondan çıkarılır. Kaynak grupları, bölgeler arasında öncelikli (aktif/pasif) ve ağırlıklı dağıtımı destekler. WAF ilkeleri, yönetilen kural kümeleri, özel kurallar ve OWASP tehditlerini ve kötü niyetli istemcileri azaltmak için hız sınırlama ile uç noktaya veya rotaya eklenir. Hızlandırma, uç nokta güvenliği ve uygulamaya duyarlı yük devretme özelliklerine sahip küresel yük dengelemeye ihtiyacınız olduğunda Front Door’u kullanın; yalnızca HTTP olmayan uç noktalara veya DNS düzeyinde kontrole ihtiyacınız olduğunda Traffic Manager ile birleştirin.
Katman 4’te, Azure Load Balancer, TCP/UDP için ultra düşük gecikmeli yük dağıtımı sağlar. Standard Load Balancer, alana özgü ve alanlar arası yedekli ön uçları, HA bağlantı noktalarını, giden kurallarını ve varsayılan olarak güvenli davranışı (açık NSG ve arka uç havuzu yapılandırması) destekler. Sistem durumu yoklamaları (TCP/HTTP), arka uç durumunu belirler; arızalanan örnekler rotasyondan çıkarılır. Basic Load Balancer, alan farkındalığı, gelişmiş özellikler ve bir SLA’dan yoksundur—üretim ortamları için kaçının. Cross-region Load Balancer, bölgesel Standard yük dengeleyiciler arasında dengeleme yapan küresel bir anycast ön ucu ekleyerek, HTTP olmayan iş yükleri için aktif/aktif çok bölgeli tasarımları mümkün kılar ve sistem durumuna dayalı hızlı bölgesel yük devretme sağlar.
Veri Koruma ve Olağanüstü Durum Kurtarma: Azure Backup ve Site Recovery
Azure Backup belirli bir noktaya kurtarma (point-in-time recovery) sağlar; Azure Site Recovery (ASR) ise iş yükü replikasyonu ve düzenlenmiş (orchestrated) yük devretme sunar. Bu iki hizmet birbirini tamamlayan ihtiyaçları karşılar ve genellikle birlikte kullanılır.
Azure Backup kasa seçenekleri:
- Recovery Services kasası, Azure VM’lerini, Azure VM’lerindeki SQL Server’ı, Azure VM’lerindeki SAP HANA’yı, Azure Files’ı ve MARS/MABS aracılarını korur. Desteklendiği durumlarda zamanlamaları, saklama sürelerini ve uygulama tutarlı (application-consistent) yedeklemeleri tanımlayan Yedekleme ilkeleri (Backup policies) ile entegre olur.
- Backup kasası, Azure Disks yedeklemesi ve Azure Blobs yedeklemesi gibi daha yeni iş yükleri için modernize edilmiş kasadır ve desteklenen bölgelerde ayrıntılı RBAC (granular RBAC) ve bölge yedekli (zone-redundant) kasa depolaması sunar. Kasa türünü, iş yükü ve yönetişim modelinizle uyumlu olacak şekilde seçin.
Yedekleme ilkeleri (Backup policies), yedeklemelerin ne zaman çalışacağını, saklama katmanlarını (günlük/haftalık/aylık/yıllık) ve tutarlılık ayarlarını yönetir. Geçici silme (Soft delete), silinmiş yedekleme öğelerinin geri alınabileceği bir güvenlik penceresi ekleyerek yanlışlıkla veya kötü niyetli silmelere karşı koruma sağlar. Bölgeler arası geri yükleme (Cross-region restore), kasa depolaması coğrafi olarak yedekli (geo-redundant) seçenekler kullandığında ikincil bölgeden geri yükleme yapılmasına olanak tanır; bu özelliğin etkinleştirilmesi gerekir ve bölgesel özellik desteğine ve veri düzlemi (data-plane) hazır olma durumuna tabidir.
Azure Site Recovery, iş yüklerini bölgeler (zone) veya coğrafi bölgeler (region) arasında çoğaltır ve uçtan uca ODK’yı (DR) düzenler:
- Replikasyon ilkeleri (Replication policies), anlık görüntü (snapshot) sıklığını, kurtarma noktalarının (recovery points) saklama süresini, uygulama tutarlı (app-consistent) anlık görüntü temposunu ve RPO uyarı eşiklerini tanımlar. İlkeler, replikasyon bant genişliği, depolama maliyetleri ve kurtarma hassasiyeti arasında bir denge kurar.
- Kurtarma planları (Recovery plans), çok katmanlı uygulamaların gruplar (ör. veritabanı, API, web), ön/son adımlar ve Azure Automation runbook’ları, betikler veya manuel eylemler aracılığıyla otomasyon ile sıralı bir şekilde yük devretmesini sağlar. DNS değişikliklerini, Traffic Manager/Front Door uç nokta güncellemelerini ve uygulama yapılandırmasını plana entegre edin.
- Yük devretme testi (Test failover), üretime veya replikasyona etki etmeden runbook’ları, önyükleme sırasını (boot order) ve uygulama sağlığını doğrulamak için üretim dışı bir VNet veya bir test ağı kullanarak yalıtılmış bir kurtarma işlemi çalıştırır. RTO’yu doğrulamak için düzenli testler yapmak esastır.
- Geriye yük devretme (Failback), sağlıklı olduğunda iş yüklerini orijinal siteye veya bölgeye geri döndürür. Yük devretmeden sonra, iş yükünü yeni birincil yönde yeniden koruyun, değişiklikleri senkronize edin, planlı bir geriye yük devretme penceresi zamanlayın ve geriye yük devretme sonrası replikasyonu doğrulayın. Azure’dan Azure’a senaryolar için, genellikle eşleştirilmiş bölgeler (paired regions) arasında yük devredilir ve hazır olduğunda orijinal topolojiyi geri yüklemek için replikasyon tersine çevrilir.
Veri Katmanı Sürekliliği: Azure SQL, Depolama Replikasyonu ve Cosmos DB
Her veri hizmeti, uygulama tutarlılığı gereksinimleriyle uyumlu olması gereken farklı dayanıklılık ve yük devretme semantikleri sunar.
Azure SQL Database ve Azure SQL Managed Instance:
- Aktif coğrafi replikasyon (Active geo-replication), tek veritabanları veya elastik havuzlar için en fazla dört okunabilir ikincil kopya oluşturur. Okuma ölçeklendirme (read-scale) ve ODK (DR) sağlayan, manuel veya API güdümlü yük devretme ile veritabanı düzeyinde replikasyon sunar. Veritabanı başına kontrol ve özel düzenleme (orchestration) gerektiğinde uygundur.
- Otomatik yük devretme grupları (Auto-failover groups), bir dinleyici uç noktası (listener endpoint) ile birlikte yük devreden bir veritabanı grubu (veya tüm bir yönetilen örnek) oluşturur. Bölgeler arası yük devretmeyi ve bağlantı dizesi (connection string) yönetimini basitleştirir ve bir bekleme süresinden sonra otomatik yük devretmeyi destekler. Yük devretme gruplarını, koordineli yük devretme ve basitleştirilmiş istemci bağlantısı gerektiren çoklu veritabanı uygulamaları için kullanın.
- Bölge yedekliliği (Zone redundancy), bölgeler arası kurtarma olmaksızın bölgesel (zonal) arızalardan kurtulmak için kopyaları bir coğrafi bölge (region) içindeki bölgelere (zone) yerleştirir. Gecikme profillerini değiştirmeden yerel kullanılabilirliği artırmak için bunu destekleyen katmanlarda etkinleştirin.
Azure Storage replikasyon seçenekleri:
- GRS (coğrafi olarak yedekli depolama), verileri birincil bölgeden (üç kopya) eşleştirilmiş bir ikincil bölgeye (üç kopya) zaman uyumsuz olarak çoğaltır. Normal çalışma sırasında, okuma ve yazma işlemleri birincil bölgeyi hedefler.
- RA-GRS, birincil bölgenin performansı düştüğünde acil durum raporlaması veya analiz gibi senaryolar için ikincil uç noktaya okuma erişimi ekler.
- GZRS (coğrafi bölge yedekli depolama), hem yerel hem de bölgesel dayanıklılığı artırmak için birincil bölgedeki ZRS’yi (bölgesel dayanıklılık için) ikincil bölgeye zaman uyumsuz replikasyon ile birleştirir.
- RA-GZRS, GZRS hesapları için ikincil bölgeye okuma erişimi ekler. Birincil bölge kurtarılamaz durumdaysa, ikincil bölgeye bir hesap yük devretme (account failover) başlatabilirsiniz. Yük devretmeden sonra, depolama hesabı ikincil bölgede birincil hale gelir ve genellikle (siz yeniden yapılandırana kadar) yerel olarak yedekli (locally redundant) duruma geri döner. Bir miktar RPO (zaman uyumsuz replikasyon nedeniyle) bekleyin; uygulamalar yük devretmeden sonra tekrarlanabilirlik (idempotency) ve mutabakat (reconciliation) işlemlerini yönetmelidir.
Azure Cosmos DB:
- Çok bölgeli yazmalar (Multi-region writes), çakışma çözümleme ilkeleriyle (belirlenmiş bir özellik aracılığıyla son yazan kazanır, özel veya çoklu ana (multi-master) stratejiler) yapılandırılmış herhangi bir bölgeye yazma yapılmasına olanak tanır. Bu, yazma gecikmesini azaltır ve kullanılabilirliği artırır.
- Otomatik yük devretme, bir kesinti durumunda yeni bir yazma bölgesini yükseltmek için önceliklendirilmiş bir bölge listesi kullanır. Seçilen tutarlılık seviyeleriyle (Güçlü’den Nihai’ye kadar - Strong to Eventual) birleştirildiğinde, kullanılabilirlik-tutarlılık arasındaki dengeyi (trade-off) yönetirsiniz.
- SLA’lar kullanılabilirliği, aktarım hızını (throughput), gecikmeyi ve tutarlılığı kapsar. Çok bölgeli yazmalarla (multi-region writes), doğru çok bölgeli yapılandırma varsayılarak, Cosmos DB hem okuma hem de yazma işlemleri için %99,999’a varan kullanılabilirlik sunar. Bu garantilerden tam olarak yararlanmak için istemcileri, uç nokta keşfi (endpoint discovery) ve yeniden denemeler (retries) özelliklerine sahip SDK’yı kullanarak tasarlayın.
Hepsini Bir Araya Getirme: Belirli Kurtarma Hedeflerini Karşılama
Her katmanı, RTO/RPO ve hata etki alanları rehberliğinde kendi süreklilik mekanizmasıyla eşleştirin:
- Bölge içi kullanılabilirlik: Availability Zones kullanın. Zonal işlem kaynaklarını en az iki zone’a dağıtın; zone-redundant ön uçlar (Standard Load Balancer, zone-redundancy özellikli Application Gateway v2 veya edge’de Front Door) kullanın. Desteklendiği yerlerde SQL zone redundancy özelliğini etkinleştirin ve hem zonal hem de bölgesel dayanıklılığa ihtiyaç duyan depolama için GZRS kullanın.
- Bölgeler arası DR: Durum bilgisi tutan (stateful) katmanlar için, düşük RPO elde etmek amacıyla yerel coğrafi replikasyonu (SQL auto-failover groups, Cosmos DB multi-region accounts, Storage GRS/GZRS) tercih edin. Yerel replikasyonu olmayan durum bilgisi tutan IaaS veya iş yükleri için, iyi ayarlanmış replikasyon ilkeleri ve kurtarma planları ile Azure Site Recovery kullanın. Geçici (ephemeral) işlem kaynakları için, Infrastructure as Code kullanarak imajlardan veya VM Scale Sets’ten yeniden oluşturun.
- Global yönlendirme ve yük devretme: HTTP/S için, Azure Front Door sistem durumu yoklaması (health-probe) odaklı, uygulamaya duyarlı yük devretme ve WAF koruması sağlar. HTTP olmayan veya karma protokoller için, uygun şekilde Traffic Manager (DNS) veya Cross-region Load Balancer (L4 anycast) ekleyin. Katı aktif/pasif RTO hedefleri için öncelik tabanlı yönlendirme (priority routing) kullanın; aşamalı dağıtımlar (staged rollouts) için ağırlıklı (weighted) ve en düşük gecikmeli kullanıcı deneyimleri için performans (performance) yönlendirmesini kullanın.
- Son savunma hattı olarak yedeklemeler: Replikasyon olsa bile, uyumluluk gereksinimlerini karşılayan saklama ilkeleriyle (retention policies) Azure Backup’ı sürdürün, kalıcı silme (purge) olaylarına karşı koruma sağlamak için geçici silmeyi (soft delete) etkinleştirin ve coğrafi olarak yedekli depolama kullanan kasalar (vaults) için bölgeler arası geri yüklemeyi (cross-region restore) yapılandırın. Yedeklemeler, replikasyonun yayabileceği riskler olan mantıksal bozulma, fidye yazılımı (ransomware) ve operatör hatalarına karşı koruma sağlar.
Test yapmak tartışılamaz bir zorunluluktur. Düzenli ASR test yük devretmeleri planlayın, Front Door/Traffic Manager sistem durumu tatbikat testleri yapın, yük altında SQL failover group davranışını doğrulayın ve bir sanal alanda (sandbox) depolama yük devretme simülasyonları gerçekleştirin. RTO ölçümlerini araçlarla izleyin ve geri alma/geri dönme (rollback/failback) işlemlerini runbook’lar ile otomatikleştirin. Nöbetçi müdahale ekiplerinin (on-call responders) baskı altında tutarlı bir şekilde çalışabilmesi için operasyonel runbook’ları belgeleyin ve provalarını yapın.
Pratik Problem Senaryosu
Expedia Group, ana rezervasyon işlemleri için RTO ≤ 15 dakika ve RPO ≤ 5 dakika hedeflerini karşılamak üzere global seyahat rezervasyon platformunu modernize etmeli ve aynı zamanda önemli seyahat dönemlerindeki 10 katlık trafik artışlarını sürdürebilmelidir. Platform, dünya çapındaki web ve mobil istemcilere karma HTTP ve HTTP olmayan iş yükleriyle hizmet vermektedir.
- Birincil bölgede zonal dayanıklılık oluşturma
- Durum bilgisi tutmayan (stateless) mikroservisleri, Standard Load Balancer zone-redundant ön uçları ile iki veya daha fazla Availability Zone’a yayılan zonal VM Scale Sets olarak dağıtın. Bu, tek bir zone’un arızalanması riskini ortadan kaldırır ve bölge içinde düşük gecikmeli trafik sağlar.
- Otomatik yük devretme grupları (auto-failover groups) ve zone redundancy etkinleştirilmiş Azure SQL Database kullanın. Otomatik yük devretme grupları, koordine veritabanı yük devretmesi ve kararlı bir dinleyici (listener) sağlayarak 15 dakikalık RTO hedefini minimum operasyonel yük ile karşılar.
- Zonal dayanıklılığı asenkron bölgesel koruma ile birleştirmek için oturum yapıtlarını (session artifacts) ve imajları GZRS depolama hesaplarında saklayın. Bu, uygulama tarafı etkisizliği (idempotency) ile eşleştirildiğinde 5 dakikalık RPO hedefini karşılar.
- Aktif/aktif okumalarla bölgeler arası DR ekleme
- Rezervasyon web/API kaynaklarını (origins) iki eşleştirilmiş bölgede Azure Front Door Standard arkasında yapılandırın. Sistem durumu yoklamaları ve öncelik tabanlı yönlendirme, uygulama sağlığına bağlı olarak hızlı yük devretme sağlarken, anycast kullanıcı trafiğini hızlandırır. Yönetilen kural setleri (managed rulesets) ve hız sınırlaması (rate limiting) içeren WAF ilkeleri, trafik artışları sırasında kritik olan hacimsel (volumetric) ve uygulama katmanı saldırılarına karşı koruma sağlar.
- Global kullanıcılar için yazma gecikmesini azaltmak ve %99.999 kullanılabilirlik sağlamak amacıyla seyahat planı ve kişiselleştirme servisleri için Cosmos DB çok bölgeli yazmaları (multi-region writes) etkinleştirin. Otomatik yük devretme, ikincil bölgeye öncelik vererek manuel müdahale olmadan düşük RTO’yu korur.
- İşlemsel rezervasyonlar için aynı iki bölge arasında SQL auto-failover groups kullanın; bu, raporlama için ikincil sunucularda okuma ölçeklendirmesi (read-scale) sağlarken hızlı ve koordine bir yük devretme temin eder.
- Durumu koruma ve bozulmadan kurtarmayı destekleme
- Eski bileşenler kaldıysa, Azure VM yedeklemeleri (desteklendiği yerlerde uygulama tutarlı - app-consistent) ve VM içi SQL için Recovery Services vaults kullanın. Katmanlı saklama (tiered retention) özellikli yedekleme ilkeleri uygulayın ve kazara veya kötü niyetli silmelere karşı koruma sağlamak için geçici silmeyi (soft delete) etkinleştirin.
- Özelleştirilmiş iş yüklerini barındıran Azure Disks için, konuk işletim sistemi ajanlarından (guest OS agents) bağımsız olarak artımlı anlık görüntüler (incremental snapshots) yakalamak üzere Backup vault tabanlı Azure Disk Backup ekleyin. Bu, kurtarma seçeneklerini çeşitlendirir.
- Coğrafi olarak yedekli depolama kullanan kasalarda (vaults) bölgeler arası geri yüklemeyi (cross-region restore) etkinleştirin; bu, kısmi kontrol düzlemi (control-plane) kesintileri sırasında ikincil bölgeden veri düzlemi (data-plane) geri yüklemelerine olanak tanır.
- DR’ı düzenleme ve RTO’yu doğrulama
- Yerel olarak replike edilmeyen tüm hizmetler (ör. eski Windows servisleri) için Azure Site Recovery’yi yapılandırın. Önce veritabanı hazırlığını, ardından API’yi, sonra da web’i sıralayan kurtarma planları oluşturun ve Key Vault referanslarını güncellemek, Front Door kuralları aracılığıyla CDN önbelleklerini temizlemek ve HTTP olmayan uç noktalar için Traffic Manager önceliğini değiştirmek üzere Azure Automation runbook’larını dahil edin.
- Runbook’ları doğrulamak, gerçek yük devretme süresini ölçmek ve kapasite rezervasyonlarını iyileştirmek için maskelenmiş veriler kullanarak yalıtılmış VNet’lere üç ayda bir test yük devretmeleri planlayın. Testlerden sonra, yapıtları temizleyin ve metrikleri 15 dakikalık RTO hedefine göre gözden geçirin.
- Karma protokoller için global yönlendirme
- HTTP/S için, Front Door sistem durumu odaklı yük devretmeyi ve edge güvenliğini yönetir. HTTP olmayan protokoller (ör. iş ortağı TCP entegrasyonları) için, alt uç noktalar (child endpoints) olarak bölgesel Standard Load Balancer’lar ile Cross-region Load Balancer dağıtın. Sistem durumu yoklamaları, arızalı bölgeleri anında kaldırarak DNS TTL bağımlılıkları olmadan bağlantıyı sürdürür. DNS düzeyinde coğrafi sınırlamanın (geofencing) gerekli olduğu yerlerde (yasal düzenlemelere tabi uç noktalar), bölgeye özgü uç noktaların önüne Azure Traffic Manager Coğrafi (Geographic) yönlendirme katmanı ekleyin.
Neden bu hizmetler Availability Zones ve zone-redundant ön uçlar, minimum gecikme etkisiyle tek bir zone’daki arızaları ortadan kaldırır. Azure SQL failover groups, bağlantı yönetimini soyutlar ve yük devretmeyi otomatikleştirerek 15 dakikalık RTO ile uyum sağlar. Cosmos DB çok bölgeli yazmaları (multi-region writes), global olarak ultra yüksek kullanılabilirlik ve düşük gecikmeli yazma gereksinimlerini karşılar. GZRS ve RA seçenekleri, kontrollü RPO ödünleşimleri ile zonal artı bölgesel dayanıklılık sağlar. Front Door, global hızlandırma, uygulamaya duyarlı yük devretme ve edge’de WAF sunar. Cross-region Load Balancer ve Traffic Manager, HTTP olmayan ve coğrafi yönlendirme ihtiyaçlarını karşılar. Azure Backup ve ASR, belirli bir noktaya geri yüklemeden (point-in-time restores) tam yığın yük devretmeye (full-stack failover) kadar bağımsız kurtarma yolları sunarak platformun hem altyapı arızalarından hem de mantıksal veri bozulmasından kurtulabilmesini sağlar.
← Ağ ve Bağlanabilirlik · Tüm alanlar · Güvenlik Mimarisi ve Zero Trust →
Bu soruları çözün → · ExamRoll.io’da süreli pratik →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Sınavınızı geçin →