Microsoft AZ-204: Azure API Yönetimi — Çalışma kılavuzu

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Şunun bir parçası: Microsoft Azure Developer Associate AZ-204 — Ç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 API Management (APIM), çeşitli arka uç hizmetleri üzerinde birleşik bir arayüz sunarak yüksek performanslı bir ağ geçidini yapılandırılabilir bir ilke motoru, geliştirici katılımı ve tam bir yönetim düzlemi ile birleştirir. REST, SOAP ve GraphQL arka uçlarında tutarlı güvenlik, kısıtlama, dönüşüm, gözlemlenebilirlik ve yaşam döngüsü denetimleri sağlar. APIM, hem trafik için bir çalışma zamanı ağ geçidi hem de Azure portalı, ARM/Bicep/CLI veya CI/CD aracılığıyla yönettiğiniz yapılandırma odaklı bir sistemdir. İstek işlem hattını, ilke yeteneklerini, sürüm oluşturma/revizyonları, abonelik modelini ve katman özelliklerini anlamak, büyük ölçekte sağlam ve güvenli API’ler oluşturmanın temelini oluşturur.

Mimari, Katmanlar ve Temel Bileşenler

Ağ geçidi, veri düzlemidir. İstemci bağlantılarını sonlandırır, ilkeleri belirli bir sırada uygular, arka uçlara yönlendirme yapar ve yanıtları döndürür. Yerleşik önbelleğe alma, JWT doğrulaması, karşılıklı TLS ve tam hızda içerik dönüşümünü destekler. Ağ geçitleri, bölge başına Microsoft tarafından barındırılabilir veya merkezi olarak yönetilmeye devam ederken şirket içi ya da uç iş yüklerine daha yakın çalışmak için kendi kendine barındırılabilir (konteynerize edilmiş). Ağ geçidi, izleme ve metrikleri kullanıma sunar ve dağıtılmış telemetri için Application Insights ile entegre olur.

Geliştirici portalı; keşif, dokümantasyon ve abonelik yönetimi için tüketiciye yönelik bir deneyimdir. OpenAPI/GraphQL dokümantasyonunu oluşturur, etkileşimli “deneyin” konsolları sağlar, tarayıcı içinde OAuth 2.0 akışlarını yönetir ve özel markalamayı ve kimlik sağlayıcılarını destekler. Geliştiriciler, ürün aboneliklerini kendi kendilerine yönetir ve anahtarlarını buradan değiştirir.

Yönetim düzlemi, yapılandırma ve yönetişim yüzeyidir. API’leri, işlemleri, ilkeleri, ürünleri, kullanıcıları/grupları, arka uçları, sertifikaları ve tanılama ayarlarını depolar. Azure portalı, ARM/Bicep/CLI/PowerShell, Management REST API ve Git tabanlı yapılandırma senkronizasyonu aracılığıyla erişilebilir. Bu düzlem; dağıtımları, sürüm oluşturmayı, revizyonları ve RBAC’yi düzenler.

APIM katmanları; ölçeği, özellikleri ve ağ yeteneklerini belirler:

Consumption (Tüketim) katmanı sunucusuzdur ve çağrı başına faturalandırılır. Otomatik olarak ölçeklenir, düzensiz/düşük işlem hacimli senaryolar için idealdir ve çoğu temel ilkeyi destekler. Yerleşik yanıt önbelleğe alma özelliğini içermez ve gelişmiş ağ ile çok bölgeli özelliklerden yoksundur.
Developer (Geliştirici) katmanı üretim dışı ortamlar içindir. SLA olmadan ve üretim ölçeğinde işlem hacmi sunmadan neredeyse tam özellik işlevselliği sunar.
Basic ve Standard, öngörülebilir işlem hacmi, ölçek genişletme birimleri ve yerleşik yanıt önbelleğe alma özelliklerine sahip, tek bölgeli, adanmış üretim katmanlarıdır. Çok bölgeli veya gelişmiş ağ özellikleri gerektirmeyen birçok kurumsal iş yükü için uygundurlar.
Premium; çok bölgeli dağıtım, gelişmiş ağ özellikleri (VNet entegrasyonu dahil), daha yüksek ölçek, desteklenen bölgelerde kullanılabilirlik alanları ve kendi kendine barındırılan ağ geçidi lisanslaması ekler. Küresel, kritik görev dağıtımları ve özel ağ bağlantıları için Premium’u seçin.

İlkeler ve İstek İşlem Hattı

APIM ilkeleri, dört bölümde katı bir sırayla yürütülen bildirimsel ifadelerdir: inbound, backend, outbound ve on-error.

Inbound (gelen) ilkeleri, istek arka uca iletilmeden önce çalışır. Tipik görevler arasında abonelik anahtarlarını zorunlu kılma veya doğrulama, JWT’leri doğrulama (issuer, audience, signature zorunluluğu), istemci IP’lerini kontrol etme, hız limitleri ve kotalar uygulama, başlıkları normalleştirme, URI’leri yeniden yazma ve payload’u dönüştürme yer alır. Koşullu olarak farklı arka uçlara yönlendirme yapabilir ve sonraki aşamalar için değişkenler ayarlayabilirsiniz.

Backend bölümü, yukarı akış hizmetine (upstream service) yapılan çağrıyı yapılandırır ve değiştirir. Bu bölümü bir arka uç varlığı seçmek, istemci kimlik bilgilerini eklemek (Basic auth, istemci sertifikaları veya Azure AD korumalı arka uçlar için yönetilen kimlik aracılığıyla alınan token’lar), zaman aşımlarını ayarlamak, yeniden denemeleri etkinleştirmek ve devre kesici uygulamak için kullanın. Arka uca karşılıklı TLS (Mutual TLS), ağ geçidinin sunacağı bir istemci sertifikası ilişkilendirilerek burada yapılandırılır.

Outbound (giden) ilkeleri, arka uç yanıtı alındıktan sonra çalışır. Genellikle yanıt dönüşümleri (ör. JSON’dan XML’e veya tam tersi), başlıkların yeniden yazılması, veri şekillendirme, dahili ayrıntıları maskeleme ve yanıt önbelleğe alma gibi işlemleri gerçekleştirirler. Burası aynı zamanda içerik anlaşması (content negotiation) dönüşümlerini uygulamak veya durum kodlarını normalleştirmek için de kullanılır.

On-error (hata durumunda) ilkeleri, arka uç çağrısı da dahil olmak üzere önceki bölümlerden herhangi birinde bir istisna oluşursa yürütülür. Bu bölümü arka uç hatalarını standartlaştırılmış API hata şekilleriyle eşleştirmek, uygun durum kodlarını ayarlamak, hassas mesajları gizlemek, korelasyon kimlikleri eklemek veya yedek yanıtlar sağlamak için kullanın.

Yaygın ilke kalıpları:

Hız sınırlama (Rate limiting), anlık işlem hacmini kontrol eder ve arka uçları korur. rate-limit-by-key, abonelik anahtarı, JWT claim’i veya IP adresi gibi bir anahtar kullanarak kimlik başına bir kısıtlama uygular. Daha uzun zaman aralıkları için, günlük veya aylık kullanımı sınırlamak üzere quota-by-key ile birleştirin.
IP filtreleme (ip-filter kullanarak), maliyeti ve riski en aza indirmek için genellikle inbound bölümünün başlarında konumlandırılarak istemci IP’sine veya CIDR aralıklarına göre trafiği engeller veya trafiğe izin verir.
validate-jwt ile JWT doğrulaması, OpenID Connect parametrelerini zorunlu kılar. OpenID yapılandırma URL’sini veya issuer’ı yapılandırın, kabul edilen audience/scope’ları tanımlayın, gerekli claim’leri seçin ve saat sapması (clock skew) ile token ömrü kontrollerini ayarlayın. Anonim çağrılara izin verilmeyen tüm işlemler için geçerli bir token gerektirerek anonim erişimi reddedin.
Dönüşüm; rewrite-uri, set-header, set-query-parameter, set-body ve find-and-replace ilkelerini içerir. Kod değiştirmeden uyumsuz istemci/arka uç formatları arasında köprü kurmak için xml-to-json veya json-to-xml kullanın.
Önbelleğe alma, yol, sorgu, başlıklar ve JWT claim’lerini içerebilen anahtarlara dayalı olarak tüm yanıtları önbelleğe almak için cache-lookup ve cache-store ilkelerinden yararlanır. Token’ları önbelleğe almak gibi, ilkeler içinde anahtar/değer (key/value) önbelleğe alma için cache-lookup-value/cache-store-value kullanın. Yerleşik yanıt önbelleğe almanın Consumption (Tüketim) katmanında mevcut olmadığını unutmayın.

Güvenlik, Kimlik ve Abonelikler

Hem ön uç istemci-ağ geçidi güvenliği hem de arka uç ağ geçidi-hizmet güvenliği ele alınmalıdır.

Ön uç güvenliği için Azure AD ile OAuth 2.0 baskın modeldir. İstemciler Azure AD’den token’ları alır ve bunları ağ geçidine sunar. APIM, Azure AD OpenID Connect meta verilerine (kiracının well-known endpoint’i) referans veren validate-jwt kullanarak token gereksinimlerini zorunlu kılar. İlkeler, token’ın doğru API’yi hedeflediğinden emin olmak için audience denetimlerini, arayanların uygun izinlere sahip olduğundan emin olmak için scope taleplerini ve app roles gibi isteğe bağlı talepleri zorunlu kılabilir. Anonim çağrıları ortadan kaldırmak için validate-jwt tüm operasyonlara uygulanmalıdır. Geliştirici portalı, test sırasında token alımını basitleştirmek için Azure AD ile yapılandırılabilir.

İstemci sertifikaları ve mutual TLS için APIM, arayanlardan gelen istemci sertifikalarını isteyebilir ve validate-client-certificate kullanarak veren/konu/sona erme (issuer/subject/expiry) ve isteğe bağlı olarak CRL/OCSP durumunu doğrulayabilir. Bu, B2B ve yüksek güvenceli entegrasyonlar için uygundur. Ağ geçidinden arka uca mTLS için, APIM’e bir istemci sertifikası yükleyin, bunu bir arka uç varlığıyla (backend entity) veya set-backend-service ile ilişkilendirin; APIM, arka uçta kimlik doğrulaması yapmak için TLS el sıkışması sırasında bu sertifikayı sunacaktır. Bu yaklaşım genellikle güvenli hale getirilmiş App Service veya sertifika kimlik doğrulamasını zorunlu kılan özel hizmetler tarafından istenir.

Azure AD korumalı arka uçlar için, APIM’in sistem tarafından atanan veya kullanıcı tarafından atanan yönetilen kimliği (system-assigned or user-assigned managed identity) ile bir erişim token’ı almak üzere arka uç bölümünde authentication-managed-identity kullanın. İlke, arka uç çağrısı için Authorization başlığını ekler. Bu, gizli bilgilerin (secret) saklanmasını önler ve modern sıfır güven (zero-trust) gereksinimlerini karşılar.

Abonelikler, genel hatlarıyla bir erişim ve para kazanma modeli sağlar. Ürünler; şartlar, onay ve kullanım limitleri tarafından yönetilen API paketleridir. Geliştiriciler, Ocp-Apim-Subscription-Key başlığı veya bir sorgu parametresi aracılığıyla kullanılan abonelik anahtarlarını (birincil ve ikincil) elde etmek için ürünlere abone olurlar. Çift anahtar sayesinde anahtarlar kesinti olmadan döndürülebilir (rotate). Abonelik kapsamı, anahtarların nerede geçerli olacağını belirler: tüm API’ler, tek bir API veya belirli bir ürün. Abonelik tabanlı erişim, OAuth 2.0’ı tamamlayıcı niteliktedir; kimlik doğrulama token’lara dayanırken ayrı kısıtlama/hesaplama (throttling/accounting) sağlamak için her ikisi de zorunlu kılınabilir. Ürünler, operasyon başına ilkelere bağlı olmaksızın abonelik başına kotalar ve hız limitleri uygulayarak katmanlı koruma ve yönetişim sağlayabilir.

Arka Uçlar, Dayanıklılık, Versiyonlama ve Revizyonlar

APIM’deki arka uçlar (backend’ler), hedef hizmetin temel URL’sini, protokolünü, kimlik bilgilerini, TLS ayarlarını, başlık şablonlarını ve proxy yapılandırmasını kapsayan birinci sınıf, yeniden kullanılabilir varlıklardır. API’leri ve operasyonları arka uçlarla ilişkilendirmek, yönlendirmeyi ilkelerden ayırır ve bağlantı ayrıntılarını merkezileştirir. URL’leri koda gömmek yerine istekleri yönlendirmek için ilkelerde arka uç kimliğine göre

undefined

kullanın; bu, geliştirme (dev), test ve üretim (prod) ortamları arasında geçişi basitleştirir.

Dayanıklılık, yeniden denemeler ve devre kesici (circuit breaking) ile sağlanır. Üstel geri çekilmeli (exponential backoff) yeniden denemeler, geçici hataları azaltabilir; etki artışını önlemek için bu denemeler idempotent operasyonlarla sınırlandırılmalı ve makul zaman aşımları ile kısıtlanmalıdır. Bir devre kesici ilkesi, bir örnekleme penceresi içinde hata oranı, ardışık hatalar veya gecikme süresi yapılandırılmış eşikleri aştığında açılır ve tanımlanmış bir kesinti süresi boyunca istekleri kısa devre yapar. Açık durumdayken, ilke hemen bir geri dönüş (fallback) yanıtı döndürebilir veya yedek (standby) bir arka uca yönlendirebilir. Yarı açık (half-open) durumdayken, sınırlı sayıda deneme isteği, devreyi kapatmadan önce arka ucun sağlığını kontrol eder. Bu, arka uçları korur, istemci deneyimini iyileştirir ve kısmi hata durumlarında sistemleri stabilize eder.

Yük dengeleme ve yönlendirme, ilke katmanında uygulanabilir.

undefined

ile koşullu yönlendirme, trafiği kullanıcı segmentine, coğrafyaya, istek içeriğine veya sağlık sinyallerine göre yönlendirebilir. Ağırlıklı yönlendirme, istenen ağırlıklara göre rastlantısal olarak bir arka uç seçen ilke ifadeleriyle gerçekleştirilebilir; bu da kanarya sürümlerini (canary release) ve aşamalı dağıtımları mümkün kılar. Bölgeler arası aktif-aktif arka uçlar, Premium katmanındaki çok bölgeli APIM dağıtımı ile en yakın sağlıklı bölgeye koşullu yönlendirmenin birleştirilmesiyle ele alınabilir; alternatif olarak, APIM kimlik doğrulama ve dönüşüm işlemlerini yürütürken küresel katman 7 yük dengelemesi için Azure Front Door ile entegre olunabilir.

Versiyonlama ve revizyonlar, API yaşam döngüsünü yönetir. Versiyon setleri, yol (path), sorgu dizesi (query string) veya başlık (header) gibi bir versiyonlama şeması kullanarak birden çok API versiyonunun istemcilere nasıl sunulacağını tanımlar. Kırıcı değişiklikler (breaking changes) için versiyonları kullanın; her versiyon, aynı versiyon setiyle ilişkili ayrı bir API varlığıdır. Kırıcı olmayan, yinelemeli değişiklikler revizyon olarak uygulanır. Bir revizyon, bir önceki revizyon mevcut üretim revizyonu olarak kalırken test için açıkça (revizyon son eki aracılığıyla) çağrılabilen, bir API’nin değiştirilebilir bir anlık görüntüsüdür. Doğrulandıktan sonra, versiyon tanımlayıcısını değiştirmeden yeni revizyonu mevcut (current) olarak yükseltin. Bu ayrım, güvenli ve aşamalı teslimatı mümkün kılar: kırıcı olmayan güncellemeler için revizyonlar; geliştirici portalında net keşif ve dokümantasyon aracılığıyla sunulan kırıcı değişiklikler için versiyonlar.

Son olarak, gözlemleyin ve yönetin. Uçtan uca görünürlük için izlemeyi (tracing) etkinleştirin, korelasyon kimlikleri (correlation ID) belirleyin ve tanılama verilerini Application Insights’a aktarın. Tekrarlanabilir dağıtımlar elde etmek için yapılandırmayı ARM/Bicep veya APIM DevOps Resource Kit aracılığıyla yönetin ve API yazarları, yayıncıları ve operatörleri için görevleri ayırmak üzere yönetim düzleminde RBAC uygulayın.

Pratik Problem Senaryosu

Starbucks, iki Azure bölgesindeki mikro servisleri bir araya getiren mobil sipariş için birleşik bir genel API sunmalıdır. API, anonim erişimi engellemeli, kötü niyetli istemcileri kısıtlamalı, bölgesel arka uçları zincirleme arızalardan korumalı ve v1 istemcilerini bozmadan v2 sipariş şemasının aşamalı olarak dağıtılmasına izin vermelidir.

İki bölgede bir APIM Premium örneği oluşturun ve çok bölgeli dağıtımı etkinleştirin. Premium, çok bölgeli ağ geçidi varlığı, gelişmiş ağ özellikleri ve kurumsal ölçek için seçilmiştir. Bölgesel ağ geçitleri, mobil istemciler için gecikmeyi azaltır ve aktif-aktif dayanıklılık sağlar.
Her iki bölgedeki App Service örnekleri de dahil olmak üzere arka uç hizmetlerini APIM arka uç (backend) varlıkları olarak içeri aktarın. Arka uç varlıkları, temel URL’leri, TLS’i ve kimlik bilgisi ayarlarını merkezileştirerek temiz yönlendirme ilkeleri ve ortam taşınabilirliği sağlar.
İstemci-ağ geçidi arasını Azure AD OAuth 2.0 ile güvence altına alın ve inbound bölümünde

undefined

kullanarak token’ları zorunlu kılın. Azure AD, merkezi kimlik, koşullu erişim ve güçlü token doğrulaması sağlar.

undefined

, yalnızca doğru kitle/kapsam (audience/scope) bilgisine sahip kimliği doğrulanmış arayanların API’yi çağırabilmesini sağlar.

Ürün aboneliklerini zorunlu kılın ve her iş ortağı uygulaması için abonelik anahtarları (subscription key) verin. Bu, OAuth’tan bağımsız bir yönetişim ve ölçüm katmanı ekler ve iş ortağı başına kotalara, kolay anahtar rotasyonuna ve portal tabanlı self servis katılıma olanak tanır.
Inbound bölümünde, abonelik anahtarına göre anahtarlanmış

undefined

ilkelerini yapılandırın. Kısıtlama (throttling), arka uçları ani yük artışlarından korur ve iş ortakları için farklılaştırılmış SLA’lar sağlar. Ayırt edici olarak abonelik anahtarlarını kullanmak, yaptırımı iş sözleşmeleriyle uyumlu hale getirir.

Bilinen kötü amaçlı aralıkları engellemek ve yönetim için Starbucks’a ait kurumsal aralıklara izin vermek üzere IP filtrelemesi uygulayın.

undefined

, işlem hattının başlarında saldırı yüzeyini azaltır ve alt sistem kaynaklarından tasarruf sağlar.

Hassas hizmetler için istemci sertifikalarını APIM’e yükleyerek ve bunları ilgili arka uç varlıklarına bağlayarak arka uç karşılıklı TLS (mTLS) yapılandırın. mTLS, arka uçların sertifika gerektirdiği durumlarda güçlü hizmetten hizmete kimlik doğrulaması sağlar ve dahili güvenlik politikalarını karşılar.
Azure AD korumalı hizmetler için backend bölümüne

undefined

ekleyin. APIM’in yönetilen kimliği (managed identity), arka uç için erişim token’ları alarak gizli bilgileri (secret) ortadan kaldırır ve Azure RBAC ve koşullu erişim ile entegre olur.

Backend bölümünde yeniden deneme (retry) ve geri dönüş (fallback) özellikli bir devre kesici (circuit-breaker) uygulayın. Bir zaman penceresi içinde tekrarlanan hatalarda devreyi açın ve istekleri sağlıklı bölgesel arka uca yönlendirin; her ikisi de çalışmıyorsa, standartlaştırılmış, önbelleğe alınmış bir geri dönüş yanıtı döndürün. Bu, performansı düşen hizmetleri korur ve hata durumunda öngörülebilir davranış sağlar.
Okuma işlemlerini en yakın bölgeye yük dengelemesi yapmak ve sağlık sinyallerine göre yük devretmek (fail over) için koşullu yönlendirme kullanın. İlke ifadeleri, özel bir başlığı veya IP coğrafi konumunu inceleyerek yerel bölgeyi seçer; sağlık denetimleri (health probe), yönlendirme kararları için değişkenleri doldurur. Bu, bölgesel olaylar sırasında düşük gecikme ve süreklilik sağlar.
Siparişler (Orders) API’si için yol tabanlı versiyonlama (/v1, /v2) ile bir versiyon seti oluşturun. Test için v2’nin yeni bir revizyonunu oluşturun, revizyona özgü URL’yi çağırarak belirli istemcilerle doğrulayın, ardından mevcut (current) olarak yükseltin. Versiyon setleri kırıcı değişiklikleri net bir şekilde iletirken, revizyonlar güvenli, kırıcı olmayan yinelemeyi mümkün kılar.
Okuma yoğunluklu uç noktalar (menü/katalog) için outbound bölümünde, yerel ayara ve cihaz türüne göre değişen

undefined

ile yanıt önbelleğe almayı etkinleştirin. Önbelleğe alma, arka uçlardan tekrarlanan veri çekme yükünü azaltır ve mobil performansı artırır; Premium bu özellikleri büyük ölçekte destekler.

Bu tasarım, kimliği doğrulanmış, kısıtlanmış, dayanıklı ve geliştirilebilir API’ler sunar. APIM Premium, küresel ve güvenli ağ geçidini sağlar; ilkeler kimlik, kısıtlama, dönüşüm ve dayanıklılığı uygular; arka uç varlıkları ve yönetilen kimlikler bağlantıları güvence altına alır ve birbirinden ayırır; versiyon setleri ve revizyonlar, istemcilerde kesinti olmadan sürekli teslimat için disiplinli bir yaşam döngüsü sağlar.

← Azure Kimlik Doğrulama · Tüm alanlar · Azure Olay Tabanlı ve Mesaj Çözümleri →

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