अंतिम समीक्षा: मई 2026
साधारण Terraform के साथ PCDE परीक्षा के AWS संसाधनों को बनाएं — एक समय में एक ब्लॉक, प्रत्येक परीक्षा डोमेन से जुड़ा हुआ। यही कोड OpenTofu पर भी काम करता है।
इस लैब के अंत तक आप, प्लेन टेराफ़ॉर्म के साथ, एक PCDE-आकार का CI/CD + ऑब्ज़र्वेबिलिटी सबस्ट्रेट प्रोविज़न कर चुके होंगे — निर्मित इमेज के लिए एक आर्टिफैक्ट रजिस्ट्री रेपो, एक स्टब गिटहब स्रोत को देखने वाला एक क्लाउड बिल्ड ट्रिगर, दो क्लाउड रन लक्ष्यों (स्टेजिंग + प्रोड) के साथ एक क्लाउड डिप्लॉय डिलीवरी पाइपलाइन, और प्रोड लक्ष्य पर एक क्लाउड मॉनिटरिंग SLO + अलर्ट नीति। पाँच ब्लॉक; कमिट → बिल्ड → डिप्लॉय → ऑब्ज़र्व लूप जिसका PCDE परीक्षण करता है।
स्निपेट्स को एक ही main.tf में डालें, terraform init चलाएँ, फिर terraform apply को स्टेप-बाय-स्टेप चलाएँ।
>= 1.5 या ओपनटोफू >= 1.6।your-project-id (और वैकल्पिक रूप से स्टेप 3 में github-owner / github-repo) को बदलें।लैब के दायरे में मुफ्त या लगभग मुफ्त:
min_instances = 0 वाले क्लाउड रन लक्ष्य: निष्क्रिय होने पर $0।लैब वॉल्यूम पर ~$0/माह।
क्लाउड बिल्ड, क्लाउड डिप्लॉय, क्लाउड रन, आर्टिफैक्ट रजिस्ट्री, और क्लाउड मॉनिटरिंग APIs सक्षम करें।
terraform {
required_version = ">= 1.5"
required_providers {
google = { source = "hashicorp/google", version = "~> 6.0" }
}
}
provider "google" {
project = "your-project-id" # REPLACE
region = "us-central1"
}
locals {
labels = {
project = "certlabpro-pcde"
managed_by = "terraform"
}
}
resource "google_project_service" "cloudbuild" {
service = "cloudbuild.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "clouddeploy" {
service = "clouddeploy.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "run" {
service = "run.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "artifactregistry" {
service = "artifactregistry.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "monitoring" {
service = "monitoring.googleapis.com"
disable_on_destroy = false
}PCDE-कैनोनिकल CI/CD आकार: क्लाउड बिल्ड, आर्टिफैक्ट रजिस्ट्री में इमेज आउटपुट करता है; क्लाउड डिप्लॉय, समान इमेज SHA को वातावरणों के माध्यम से प्रचारित करता है। रेपो सभी वातावरणों में सच्चाई का एकल स्रोत है — अपरिवर्तनीय इमेज, परिवर्तनीय टैग।
resource "google_artifact_registry_repository" "images" {
repository_id = "certlabpro-pcde-images"
location = "us-central1"
format = "DOCKER"
labels = local.labels
depends_on = [google_project_service.artifactregistry]
}क्लाउड बिल्ड ट्रिगर PCDE की कमिट-टू-बिल्ड प्रिमिटिव हैं। हम एक गिटहब रेपो की main ब्रांच पर एक ट्रिगर परिभाषित करते हैं — प्रत्येक पुश रेपो रूट पर cloudbuild.yaml चलाता है, जो स्टेप 2 से आर्टिफैक्ट रजिस्ट्री में docker build + docker push करेगा।
github-owner और github-repo को अपने वास्तविक रेपो से बदलें। ट्रिगर प्रोविज़न हो जाएगा लेकिन तब तक सक्रिय नहीं होगा जब तक कि रेपो पर गिटहब क्लाउड बिल्ड ऐप इंस्टॉल न हो जाए (मैन्युअल वन-टाइम कंसोल स्टेप)।
resource "google_cloudbuild_trigger" "main_push" {
name = "certlabpro-pcde-main-push"
description = "Build on push to main"
filename = "cloudbuild.yaml"
github {
owner = "github-owner" # REPLACE
name = "github-repo" # REPLACE
push {
branch = "^main$"
}
}
depends_on = [google_project_service.cloudbuild]
}क्लाउड डिप्लॉय GCP की प्रबंधित CD सेवा है — यह एक रिलीज़ को क्रमबद्ध चरणों (आमतौर पर देव → स्टेजिंग → प्रोड) के माध्यम से बढ़ावा देती है, प्रत्येक एक लक्ष्य (क्लाउड रन सेवा, GKE क्लस्टर, या एंथोस क्लस्टर) द्वारा समर्थित होता है। PCDE परीक्षा इस एक बार रिलीज़ करें, कई बार प्रचारित करें आकार का व्यापक रूप से परीक्षण करती है।
हम दो क्लाउड रन लक्ष्य सेवाएँ (एक स्टेजिंग के लिए, एक प्रोड के लिए, दोनों स्केल-टू-ज़ीरो) + उन्हें जोड़ने वाली एक डिलीवरी पाइपलाइन परिभाषित करते हैं। एक वास्तविक रिलीज़ एक सफल क्लाउड बिल्ड रन के बाद gcloud deploy releases create के माध्यम से ट्रिगर होगी; लैब एक रिलीज़ को सक्रिय किए बिना सबस्ट्रेट प्रोविज़न करती है।
resource "google_cloud_run_v2_service" "staging" {
name = "certlabpro-pcde-staging"
location = "us-central1"
template {
scaling { max_instance_count = 5 }
containers {
image = "us-docker.pkg.dev/cloudrun/container/hello"
}
}
labels = local.labels
depends_on = [google_project_service.run]
}
resource "google_cloud_run_v2_service" "prod" {
name = "certlabpro-pcde-prod"
location = "us-central1"
template {
scaling { max_instance_count = 10 }
containers {
image = "us-docker.pkg.dev/cloudrun/container/hello"
}
}
labels = local.labels
depends_on = [google_project_service.run]
}
resource "google_clouddeploy_target" "staging" {
name = "staging"
location = "us-central1"
run {
location = "projects/${data.google_project.current.project_id}/locations/us-central1"
}
depends_on = [google_project_service.clouddeploy]
}
resource "google_clouddeploy_target" "prod" {
name = "prod"
location = "us-central1"
run {
location = "projects/${data.google_project.current.project_id}/locations/us-central1"
}
require_approval = true # promotion to prod needs manual approval
depends_on = [google_project_service.clouddeploy]
}
data "google_project" "current" {}
resource "google_clouddeploy_delivery_pipeline" "main" {
name = "certlabpro-pcde-pipeline"
location = "us-central1"
serial_pipeline {
stages {
target_id = google_clouddeploy_target.staging.name
}
stages {
target_id = google_clouddeploy_target.prod.name
}
}
depends_on = [google_project_service.clouddeploy]
}PCDE की SLO / SLI / त्रुटि बजट शब्दावली लोड-बियरिंग ऑब्ज़र्वेबिलिटी आकार है — साइट विश्वसनीयता टैग वाला प्रत्येक PCDE परीक्षा प्रश्न इसका परीक्षण करता है। हम एक सेवा-स्तर का उद्देश्य परिभाषित करते हैं: "प्रोड सेवा के लिए 99% HTTP अनुरोध 28-दिवसीय रोलिंग विंडो पर 2xx लौटाने चाहिए।" फिर एक क्लाउड मॉनिटरिंग अलर्ट सक्रिय होता है जब बर्न रेट यह इंगित करता है कि बजट बहुत तेजी से उपभोग किया जा रहा है।
पाँच ब्लॉकों के स्थान पर (आर्टिफैक्ट रजिस्ट्री, क्लाउड बिल्ड ट्रिगर, दो क्लाउड रन लक्ष्य, क्लाउड डिप्लॉय पाइपलाइन, प्रोड SLO + अलर्ट), PCDE का कमिट → बिल्ड → डिप्लॉय → ऑब्ज़र्व लूप एंड-टू-एंड प्रोविज़न किया गया है।
resource "google_monitoring_service" "prod" {
service_id = "certlabpro-pcde-prod-svc"
display_name = "PCDE prod Cloud Run service"
basic_service {
service_type = "CLOUD_RUN"
service_labels = {
service_name = google_cloud_run_v2_service.prod.name
location = google_cloud_run_v2_service.prod.location
}
}
depends_on = [google_project_service.monitoring]
}
resource "google_monitoring_slo" "prod_availability" {
service = google_monitoring_service.prod.service_id
slo_id = "certlabpro-pcde-prod-availability"
display_name = "99% requests return 2xx (28-day rolling)"
goal = 0.99
rolling_period_days = 28
basic_sli {
availability {
enabled = true
}
}
}
resource "google_monitoring_alert_policy" "prod_budget_burn" {
display_name = "PCDE prod — fast budget burn"
combiner = "OR"
conditions {
display_name = "1-hour burn rate > 14.4 (fast burn)"
condition_threshold {
filter = "select_slo_burn_rate(\"${google_monitoring_slo.prod_availability.name}\", \"3600s\")"
duration = "0s"
comparison = "COMPARISON_GT"
threshold_value = 14.4 # consumes 2% of monthly budget in 1 hour
}
}
}terraform destroy सब कुछ हटा देता है। क्लाउड डिप्लॉय पाइपलाइन + लक्ष्य साफ-सुथरे ढंग से नष्ट हो जाते हैं (कोई भी इन-फ्लाइट रिलीज़ ब्लॉक नहीं होती)। दो क्लाउड रन सेवाएँ नष्ट हो जाती हैं (min_instances = 0 → वैसे भी लैब के दौरान कोई निष्क्रिय बिलिंग नहीं होती)। क्लाउड बिल्ड ट्रिगर अलग हो जाता है। SLO + अलर्ट + मॉनिटरिंग सेवा साफ-सुथरे ढंग से नष्ट हो जाती है।
PCDE में कई ऐसे क्षेत्र शामिल हैं जिन्हें यह लैब फिट नहीं कर सकती — क्लाउड लॉगिंग डीप डाइव (लॉग रूटिंग, लॉग सिंक, लॉग बकेट, लॉग एनालिटिक्स ↔ बिगक्वेरी एकीकरण), क्लाउड ट्रेस + क्लाउड प्रोफाइलर + क्लाउड डीबगर (ऐप प्रदर्शन), एरर रिपोर्टिंग, क्लाउड मॉनिटरिंग डैशबोर्ड + कस्टम मेट्रिक्स + अपटाइम चेक, क्लाउड बिल्ड प्राइवेट वर्कर पूल, क्लाउड बिल्ड अनुमोदन नियम, क्लाउड डिप्लॉय कैनरी + ब्लू-ग्रीन रणनीतियाँ, क्लाउड डिप्लॉय कस्टम रेंडर / सत्यापित करें स्टेप्स, स्काफ़ोल्ड-आधारित क्लाउड डिप्लॉय रेंडर पाइपलाइन, इमेज-एटेस्टेशन प्रवर्तन के लिए बाइनरी ऑथोराइज़ेशन, कंटेनर थ्रेट डिटेक्शन, वेब ऐप और API प्रोटेक्शन (WAAP) / क्लाउड आर्मर, एंथोस कॉन्फिग मैनेजमेंट + पॉलिसी कंट्रोलर, GKE बैकअप, संपूर्ण Google SRE बुक / SRE वर्कबुक प्रथाएँ जिनका PCDE परीक्षा अक्सर संदर्भ देती है।
हम आर्टिफैक्ट रजिस्ट्री + क्लाउड बिल्ड + क्लाउड डिप्लॉय + क्लाउड रन + SLO/अलर्ट प्रिमिटिव्स पर टिके रहते हैं क्योंकि वे PCDE-कैनोनिकल CI/CD/ऑपरेट लूप हैं। लॉगिंग / ट्रेस / प्रोफाइलर / डीबगर / एरर रिपोर्टिंग सभी एक ही प्रोड लक्ष्य सेवा में प्लग होते हैं। बाइनरी ऑथोराइज़ेशन क्लाउड डिप्लॉय प्रमोशन स्टेप को गेट करता है। क्लाउड मॉनिटरिंग SLOs लोड-बियरिंग विश्वसनीयता प्रिमिटिव हैं — आकार को सही करें; जैसे-जैसे आर्किटेक्चर परिपक्व होता है, अधिक टेलीमेट्री सतहों को जोड़ें।
सेवा-दर-सेवा अवधारणात्मक कवरेज के लिए, इस प्रमाणपत्र पृष्ठ के ब्राउज़, मार्गदर्शिका, और Editorial अनुभाग देखें।