Google PCA: DevOps, Teslimat Mühendisliği ve Kod Olarak Altyapı — Çalışma kılavuzu

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Genel Bakış

Google Cloud’da DevOps, Teslimat Mühendisliği ve Kod Olarak Altyapı (IaC), güçlü izlenebilirlik, otomasyon ve güvenlikle sürekli olarak güvenilir değişiklikler sunmaya odaklanır. Mimariler, kısa geri bildirim döngüleri, tekrarlanabilir dağıtımlar, değiştirilemez altyapı ve kuruluşla birlikte ölçeklenen koruma mekanizmaları (guardrails) için optimize edilmelidir. Google Cloud’da bu genellikle şunları birleştirir: kaynak kontrolü en iyi uygulamaları; Cloud Build ile CI; Artifact Registry ile yapıt (artifact) yönetimi; Cloud Deploy ile CD; manifest’ler, Helm veya Kustomize kullanan GKE ile Kubernetes; yapılandırma sapması (configuration drift) kontrolü için GitOps; ve Terraform veya Google Cloud dağıtım şablonları ile IaC. Operasyonel mükemmellik, aşamalı teslimatı (blue-green, canary, trafik bölme ve özellik bayrakları), yazılım tedarik zinciri kontrollerini (tarama, kaynak (provenance), imzalama), test ve dağıtım kapılarını (gates) ve hız, güvenlik, denetlenebilirlik ve sahipliği dengeleyen bir yönetişimi gerektirir.

CI/CD, kaynak kontrolü ve sürüm orkestrasyonu

CI/CD ilkeleri
- master/main dalını her zaman yayınlanabilir durumda tutun; kısa ömürlü özellik dalları (feature branch) ile trunk tabanlı geliştirmeyi (trunk-based development) uygulayın.
- Her değişiklikte derleme (build), test, tarama ve paketleme işlemlerini otomatikleştirin; zorunlu onaylar ve durum kontrolleri (status checks) ile kod incelemesi (code review) gerektirin.
- commit → build → yapıt özeti (artifact digest) → ortam sürümü (environment release) arasında tam izlenebilirliği koruyun; commit SHA’larını ve derleme meta verilerini imajlara ve dağıtım notlarına (deployment annotations) gömün.
- Hata modları: uzun ömürlü dallar, manuel devirler, kararsız (flaky) testler, tekrarlanamayan derlemeler ve yapıtların değiştirilemezliğinin (artifact immutability) olmaması, geç fark edilen sürprizlere ve geri almalara (rollback) yol açar.
Kaynak kontrolü, dallanma (branching), pull request’ler, kod incelemesi ve izlenebilirlik
- Korumalı dallar (protected branches), zorunlu incelemeler ve commit imzalama kullanın. Sürümleri etiketleyin (tag) ve birleştirme commit’lerinden (merge commit) oluşturulan bir değişiklik günlüğü (changelog) tutun.
- Alan sorumluluğunu (domain stewardship) zorunlu kılmak için CODEOWNERS ve hizmet sahipliği meta verilerini uygulayın.
- Commit’leri görevlere (issue) ve dağıtımlara bağlayın; denetim ve DORA metrikleri için CI/CD günlüklerini ve meta verilerini Cloud Logging ve BigQuery’ye aktarın.
Cloud Build
- Tetikleyiciler (Triggers): Git olaylarında (dal, etiket, PR), manuel çağrılarda veya Pub/Sub üzerinde tetiklenir. Pipeline’ları DRY (Don’t Repeat Yourself) tutmak için sürüm, ortam ve özellik bayrakları için değişkenlerle (substitutions) parametrelendirin.
- Derleme adımları (Build steps): Resmi derleyicileri (builder) veya tanımladığınız container’ları çalıştırın; gecikmeyi azaltmak için bağımsız adımları paralel kullanın; derlemeleri hızlandırmak için dil bağımlılıkları için önbellekleri (cache) kullanın.
- Yapıtlar (Artifacts): İmajları, değiştirilemez etiketler (immutable tags) ve özetlerle (digest) Artifact Registry’ye push’layın; SBOM’ları ve derleme günlüklerini saklayın; test raporlarını derleme yapıtları olarak yayınlayın.
- Güvenli derleme kimlikleri: Cloud Build’u en az ayrıcalığa (least privilege) sahip özel bir hizmet hesabıyla (service account) ve mümkün olan yerlerde depo başına Workload Identity Federation ile çalıştırın. Özel ağlar için veya dışa trafikten (egress) kaçınmak için Private Pools kullanın. Hizmet hesabı anahtarlarını sınırlayın; kısa ömürlü token’ları tercih edin.
- Örnek (kısaltılmış):

undefined

Cloud Deploy
- Sürümler (Releases) ve hedefler (targets): Hedefler arasında yükseltme (promotion) içeren bir teslimat pipeline’ı modelleyin (ör. dev → staging → prod). Bir sürüm, değiştirilemez bir yapıt referansını ve dağıtım yapılandırmasını yakalar.
- Onaylar ve yükseltme (promotion): Rol tabanlı kontrol ile manuel veya otomatik onaylar gerektirin. Yapıt ve manifest’ler değişmediği için yükseltme, hızlı ve düşük riskli bir eylem olmalıdır.
- Canary dağıtımı (rollout) ve geri alma (rollback): Aşamalı sunum (progressive exposure), sağlık kontrolleri ve SLO hatalarında otomatik geri alma için stratejiler tanımlayın. Denetim için her yükseltmeyi, onaylayanı ve doğrulama sonucunu kaydedin.
- Hata modları: Ortamlar arasında değiştirilebilir yapıtlar, üretimde manuel kubectl kullanımı veya dağıtım öncesi doğrulamaların atlanması, sapmaya (drift) ve izlenemeyen kesintilere neden olur.

Kod Olarak Altyapı ve yapılandırma yönetimi

Terraform
- Modüller: yeniden kullanılabilir kalıpları (ör. VPC’ler, GKE kümeleri, hizmet hesapları, IAM bağlamaları) yakalayın. Modül sürümlerini versiyonlayın ve sabitleyin; dahili modül kayıt defterleri yayınlayın.
- Uzak durum (remote state): Cloud Storage’da sürüm oluşturma, saklama politikası ve CMEK ile saklayın; kilitlemeyi etkinleştirin; IAM ve tek tip bucket düzeyinde erişim (uniform bucket-level access) aracılığıyla erişimi kısıtlayın; durumu yedekleyin.
- Planlar ve politika kontrolleri: CI’da

undefined

komutlarını çalıştırın; planın insan tarafından incelenmesini zorunlu kılın; ihlalleri (ör. herkese açık bucket’lar, geniş kapsamlı IAM bağlamaları) engellemek için kod olarak politika (OPA/Conftest, Sentinel veya Policy Controller) uygulayın.

Ortam yükseltme (promotion): her ortam için ayrı çalışma alanları (workspaces) veya ayrı durum/arka uçlar (state/backends) kullanın; değişiklikleri aynı modül sürümleri ve değişkenler aracılığıyla yükseltin; bulut kaynaklarını asla elle düzenlemeyin. Hassas girdiler Secret Manager’dan veya otomasyondan gelmelidir, asla kodda sabitlenmemelidir.
Hata modları: sırların duruma (state) sızması, kilitleme olmadan eşzamanlı değişiklikler, bant dışı düzenlemelerden kaynaklanan sapma (drift) ve yok etme/değiştirme (destroy/replace) işlemlerini bozan örtük bağımlılıklar.
Google Cloud dağıtım şablonları ve bildirimsel yapılandırma
- İstenen durumu tanımlamak için zorunlu adımlardan oluşan betikler yerine bildirimsel araçlar (Terraform, Google Cloud Deployment Manager veya Kubernetes Configuration as Code) kullanın.
- Değişmez altyapıyı (immutable infrastructure) tercih edin: örnek şablonlarını (instance templates) değiştirin ve MIG’leri güncelleyin (roll); pod’ları yerinde yamamak yerine yeni GKE Deployment’ları kullanıma sunun. Değişmez kalıplar, geri almayı (rollback) ve denetimi basitleştirir.
- Deployment Manager, Google Cloud kaynakları için Jinja/Python şablonlarını destekler ancak yalnızca Google Cloud ile sınırlıdır; Terraform daha geniş bir ekosistem ve politika araçları sunar. Kurumsal standardizasyon ve yetenek setlerine göre seçim yapın.
Kubernetes manifestoları, Helm, Kustomize ve GitOps
- Manifestolar: temel şablonları ortam katmanlarıyla (environment overlays) birlikte tutun; yalnızca ortama göre değişmesi gerekenleri (ör. replikalar, limitler, uç noktalar) parametrelendirin.
- Helm: hizmetleri chart’lar ile paketleyin, şablonlayın ve versiyonlayın; bağımlılıkları kilitleyin; imaj özetlerini (image digests) sabitleyin. Hata modu: aşırı şablonlama, amacı gizler ve incelemeyi karmaşıklaştırır.
- Kustomize: katmanları (temel + ortam yamaları) yönetin; yalnızca Kubernetes yeterli olduğunda Helm’den daha basittir.
- GitOps: bir denetleyici (ör. Config Sync, Argo CD, Flux), kümeleri Git’teki istenen durumla sürekli olarak uzlaştırır; her değişiklik, inceleme ve denetim izi içeren bir PR’dır. Sapmayı (drift) otomatik olarak tespit edin ve düzeltin.

Aşamalı teslimat, tedarik zinciri, test ve doğrulama

Özellik bayrakları (feature flags) ve trafik yönetimi
- Özellik bayrakları, dağıtımı (deploy) sürümden (release) ayırır; kademeli kullanıma sunma, A/B testleri ve acil durum kapatma anahtarları (kill switches) için kullanın. Bayrak durumlarının versiyonlandığından ve denetlenebilir olduğundan emin olun; eski bayrakları kullanımdan kaldırın.
- Trafik bölme: Cloud Run’da revizyonlar arasında yüzde tabanlı yönlendirme kullanın; GKE’de ağırlıklı yönlendirmeyi destekleyen service mesh veya ingress denetleyicileri kullanın. Tek bir ana makine adı/TLS altındaki API’ler için, HTTP(S) Load Balancer’ın arkasında her yol (path) için ayrı arka uç hizmetleri tutun; yol tabanlı yönlendirme (path routing), tek bir URL’yi ve sertifikayı korurken eski/yeni sürümleri temiz bir şekilde ayırır.
- Mavi-yeşil (Blue-green): üretime hazır iki yığın çalıştırın; trafiği yük dengeleyici, hizmet seçicileri (service selectors) veya Cloud Run revizyon trafiği aracılığıyla atomik olarak değiştirin. Anında geri almayı (rollback) sağlar ancak kararlı durum maliyetini iki katına çıkarır.
- Kanarya (Canary) ve aşamalı kullanıma sunma: altın sinyalleri (golden signals) ve iş KPI’larını ölçerken trafiği küçük bir dilimden başlayarak kademeli olarak artırın; gerileme durumunda geri almayı otomatikleştirin.
Yazılım tedarik zinciri kontrolleri
- İmaj tarama: Artifact Analysis güvenlik açığı taramasını etkinleştirin; kritik güvenlik açıkları veya bilinen kötü temel imajlar için derlemeleri (builds) başarısız kılın; bir yama takvimi tutun.
- Menşe (Provenance) ve imzalama: Cloud Build’da SLSA uyumlu derleme menşei oluşturun; yapıtları (artifacts) Cosign ile imzalayın; dağıtımdan önce kanıt (attestations) gerektiren Binary Authorization politikalarını uygulayın.
- Bağımlılık yönetimi: sürümleri ve özetleri (digests) sabitleyin, SBOM’ları koruyun, kritik bağımlılıkları kendi bünyenizde barındırın (vendor) ve sağlama toplamlarını (checksums) doğrulayın. Hata modları arasında geçişli bağımlılık sapması (transitive dependency drift) ve güvenliği ihlal edilmiş kayıt defterleri (registries) bulunur.
Test piramidi, dağıtım kapıları ve dağıtım sonrası doğrulama
- Piramit: hızlı birim testlerine (unit tests) vurgu yapın; entegrasyon ve sözleşme testleri (contract tests) ekleyin; hedeflenmiş uçtan uca testler (end-to-end tests) çalıştırın. Test verilerini gerçekçi ve kimliği gizlenmiş halde tutun (PII’yi kaldırmak için Cloud DLP kullanın).
- Dağıtım kapıları: yükseltmeden (promotion) önce test geçme oranı, güvenlik açığı durumu, politika uyumluluğu ve kod incelemesi için eşikleri zorunlu kılın; risk yüksek olduğunda üretim için manuel onay isteyin.
- Dağıtım sonrası doğrulama: Cloud Monitoring, Error Reporting ve Trace kullanarak duman testleri (smoke tests), sentetik kontroller ve kanarya analizi (canary analysis) çalıştırın. KPI’lar kötüleşirse, otomatik bir geri almayı tetikleyin ve yakalanan bağlamla bir olay (incident) açın.
- Operasyonel tanılama: Gereken yerlere Cloud Logging aracısını dağıtın ve hizmetleri Trace ve Debugger için enstrümante edin. Güvenli düzeltme işlemleri için runbook’lar tutun (ör. kalıcı bir diski çevrimiçi olarak yeniden boyutlandırma ve minimum kesintiyle

undefined

çalıştırma).

Yönetişim, güvenlik, denetlenebilirlik ve sahiplik

Güvenlikle birlikte hız
- Kısa ömürlü PR’lar ve zorunlu inceleme ile trunk tabanlı geliştirme, kaliteden ödün vermeden akışı sürdürür.
- Yaygın yığınlar (GKE + Helm, Cloud Run, Dataflow) için şablonlar içeren self servis pipeline’lar, ekipleri hızlandırır ve özel çözümlerin riskini azaltır.
Erişim, kimlik ve onaylar
- Her pipeline aşaması için en az ayrıcalık ilkesi ve Workload Identity Federation ile adanmış hizmet hesapları kullanın; statik anahtarlardan kaçının.
- Görevler ayrılığı: geliştiriciler geliştirir; sürüm yöneticileri production’a yükseltmeyi onaylar; çalışma zamanı operatörleri çalışma zamanı yapılandırmasına ve bütçelere sahiptir.
Denetlenebilirlik ve uyumluluk
- Cloud Build, Cloud Deploy ve Cloud Audit Logs’u BigQuery’ye aktarın. Kapsamı belirlenmiş denetim verilerini denetçilerle paylaşmak için veri kümesi görünümlerini ve IAM’i kullanın. Politikaya göre Cloud Storage’a veya BigQuery’ye aktararak metrikleri uzun vadeli saklayın.
- Artifact özetlerini (digest) dağıtım meta verilerine kaydedin. Her sürüm için uçtan uca SBOM ve köken bilgisini (provenance) koruyun.
Sahiplik ve SLO’lar
- Her servisin bir sahibi, nöbetçi (on-call) rotasyonu, SLO’ları ve sürümleri kontrol eden hata bütçeleri (error budget) vardır. Bütçe tükendiğinde değişikliklerin yayınlanmasını önlemek için dağıtım politikalarını SLO uyumluluğuna bağlayın.
Yaygın ödünleşimler ve tuzaklar
- Blue-green maliyeti ve geri alma (rollback) hızı arasındaki denge; canary güvenilirliği ve tam sürüme geçiş süresi arasındaki denge.
- GitOps tutarlılığı ve operasyonel esneklik arasındaki denge; loglama ve takip PR’ları ile kontrollü acil durum erişimine (break-glass) izin verin.
- Aşırı şablon kullanımı okunabilirliği azaltır; yapılandırmayı açık ve minimal tutun.
- Merkezi politika yanlış yapılandırmayı önler ancak ekipleri gereksiz yere engellememek için yinelemeli olarak kullanıma sunulmalıdır.

Pratik Problem Senaryosu

Şirket: Borealis Fintech

Zorluk: Borealis, v1 ve v2’yi aynı ana makine adı (hostname) ve TLS altında korurken GKE üzerinde yeni bir ödeme API’si başlatıyor. Uçtan uca izlenebilirlik, canary ve özellik bayrakları (feature flag) ile aşamalı teslimat, güçlü tedarik zinciri kontrolleri ve dev, staging ve prod ortamları arasında denetlenmiş yükseltmelere ihtiyaçları var. Ayrıca, cluster yapılandırması için GitOps ve platform kaynakları için Terraform istiyorlar.

Yaklaşım:

Kaynak kontrolü ve dallanma (branching) stratejisi oluşturma
- Servis dizinleri içeren bir mono-repo ve ayrı bir altyapı (infra) reposu oluşturun. Korumalı main branch’i, zorunlu PR incelemeleri, CODEOWNERS ve imzalı commit’leri zorunlu kılın. Gerekçe: net sahiplik ve denetime hazır bir geçmişe sahip trunk tabanlı akış.
Cloud Build ve Artifact Registry ile artifact’ler oluşturma
- $COMMIT_SHA ile etiketlenmiş ve SBOM ile köken bilgisi (provenance) ile notlandırılmış imajları build etmek ve push’lamak için bir cloudbuild.yaml tanımlayın. En az ayrıcalığa sahip adanmış bir Cloud Build hizmet hesabı ve bir Private Pool kullanın. Gerekçe: izlenebilir özetlere (digest) sahip, tekrarlanabilir ve izole build’ler.
- Örnek:
  - gcloud artifacts repositories create app –repository-format=docker –location=us
Yazılım tedarik zinciri kontrollerini uygulama
- Artifact Registry’de güvenlik açığı taramasını etkinleştirin. Cloud Build’in build sonrası adımlarında Cosign ile köken bilgisi (provenance) oluşturun ve imajları imzalayın. GKE dağıtımından önce imzaları ve taramanın başarılı olmasını gerektirecek şekilde Binary Authorization’ı yapılandırın. Gerekçe: güvenilmeyen veya güvenlik açığı bulunan artifact’leri zorlama anında engellemek.
Cloud Deploy ile teslimatı modelleme
- Dev, staging, prod hedefleri ve prod için bir canary stratejisi içeren bir teslimat pipeline’ı tanımlayın. Prod için rol tabanlı onaylayanlarla manuel onay gerektir. Gerekçe: değişmez (immutable) yükseltme ve denetlenebilir onaylar.
- clouddeploy.yaml (alıntı):
  - strategy:
    - canary:
      - canaryDeployment:
        percentages: [5, 25, 50, 100]
v1 ve v2 API’lerini aynı ana makine adı (hostname) altında yönlendirme
- Her biri ilgili GKE NEG’e işaret eden /v1 ve /v2 yolları için ayrı backend servislerine sahip bir harici HTTP(S) Load Balancer yapılandırın. Gerekçe: temiz yol tabanlı (path-based) izolasyon, aynı sertifika ve DNS, bağımsız dağıtılabilirlik.
- Örnek (alıntı):
  - gcloud compute url-maps add-path-matcher api-map –path-matcher-name api-pm –default-service v1-bes –path-rules="/v1/=v1-bes,/v2/=v2-bes"
Altyapıyı Terraform ile yönetme
- VPC, GKE, Artifact Registry, hizmet hesapları ve IAM için modüller oluşturun. Uzak state’i (remote state), sürüm oluşturma ve saklama ile CMEK korumalı bir Cloud Storage bucket’ında saklayın. Riskli değişiklikleri önlemek için CI’da OPA politikalarını zorunlu kılın. Gerekçe: yeniden kullanılabilir, incelenebilir ve yönetilen platform provizyonu.
- backend “gcs” { bucket = “borealis-tf-state” prefix = “prod” }
Kubernetes’i Helm/Kustomize ve GitOps ile yapılandırma
- API için temel manifest’leri ve Kustomize kullanarak ortam başına overlay’leri koruyun. Cluster’ları Git’teki durumla eşitlemek için Config Sync veya Argo CD kullanın. Gerekçe: bildirimsel (declarative), denetlenebilir ve sapmaya (drift) dayanıklı operasyonlar.
Canary ve özellik bayrakları (feature flag) ile aşamalı teslimat
- Prod için Cloud Deploy canary ve yeni mantığı kontrol etmek için bir özellik bayrağı SDK’sı (OpenFeature) kullanın. Trafiğin %5’i ile başlayın, sağlıklı SLO’larda otomatik olarak yükseltin; bozulma durumunda otomatik olarak geri alın (rollback) ve bayrağı bir acil durdurma anahtarı (kill switch) olarak kullanın. Gerekçe: etki alanını (blast radius) azaltmak ve dağıtımı (deploy) sürümden (release) ayırmak.
Kalite kapıları ve doğrulama
- Pipeline aşamaları: birim testleri → geçici ortama karşı entegrasyon testleri → container taraması → politika kontrolleri → staging uçtan uca testleri → otomatikleştirilmiş SLO tabanlı doğrulama (Cloud Monitoring, Error Reporting, Trace) ile prod canary. Gerekçe: erken aşamada hızlı geri bildirim, prod öncesi güçlü güvenlik ve dağıtım sonrası objektif sağlık kontrolleri.
Operasyonlar, loglama ve denetim
- Destekleyen VM’ler için Cloud Logging/Monitoring ajanlarını kurun ve GKE iş yükü log’larını/metriklerini etkinleştirin. CI/CD ve Audit Logs’u denetçiler için kapsamı belirlenmiş görünümlerle BigQuery’ye aktarın. Runbook’ları (güvenli geri alma ve acil durum DNS veya LB değiştirme prosedürleri dahil) koruyun. Gerekçe: hızlı çözüm için gözlemlenebilirlik ve uyumluluğa hazır kanıtlar.

Bu tasarım, trunk tabanlı akış ve otomatikleştirilmiş pipeline’lar ile hızı; canary, özellik bayrakları (feature flag) ve Binary Authorization ile güvenliği; değişmez (immutable) artifact’ler, onaylar ve merkezi log’lar ile denetlenebilirliği; ve CODEOWNERS ile GitOps kontrollü ortamlar aracılığıyla net sahipliği korur.

← Operasyonlar · Tüm alanlar · Maliyet →

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