Google Cloud Professional Cloud DevOps Engineer
225 שאלות תרגול
נבדק לאחרונה: April 2026
הערות אישיות וקישורים למשאבים למסע הלמידה שלך
סנן לפי הסמכה
ההסמכה Google Cloud Professional Cloud DevOps Engineer (PCDOE) מאמתת את היכולת ליישם את עקרונות הנדסת אמינות אתרים (SRE) של גוגל לשירותי ייצור ב-Google Cloud. הבחינה משלבת תוכן DevOps קלאסי (CI/CD עם Cloud Build ו-Cloud Deploy, GitOps, Artifact Registry, IaC עם Terraform) עם מסגרת ה-SRE הייחודית של גוגל — SLOs, SLIs, תקציבי שגיאות, הפחתת עבודת כפיים (toil reduction), ותרבות postmortem. היא מכסה גם את כל חבילת Cloud Operations (Logging, Monitoring, Trace, Profiler, Error Reporting), פעולות יום-שני ב-GKE, ו-FinOps. PCDOE היא המקבילה ב-GCP ל-AWS DevOps Engineer Professional ול-Azure AZ-400 — קרובה יותר ברוחה לספר ה-SRE של גוגל מאשר להסמכת DevOps ממוקדת כלים.
היררכיית משאבים, מדיניות ארגונית, IAM בסיסי, קווי הגנה לרשת ולאבטחה, IaC עם Terraform ו-Cloud Foundation Toolkit. 20%.
התחום הגדול ביותר עם 23%. Cloud Build, Cloud Deploy, Skaffold, Artifact Registry, אסטרטגיות פריסה (כחול-ירוק, קנרי, מתגלגל), GitOps עם Config Sync. דגש רב על תרחישי תכנון צינורות (pipelines).
תחום שווה בגודלו לתחום הגדול ביותר עם 23%. תכנון SLI / SLO / תקציב שגיאות, זיהוי והפחתת עבודת כפיים (toil), תכנון קיבולת, נוהלי כוננות (on-call), postmortems. מבוסס ישירות על ספר ה-SRE של גוגל.
ניתוב ו-sinks של Cloud Logging, מדדים מבוססי יומנים, לוחות מחוונים והתראות של Cloud Monitoring, Cloud Trace, Cloud Profiler, Error Reporting. 22%.
התחום הקטן ביותר עם 12% אך בצפיפות גבוהה. התאמת גודל ב-GKE (rightsizing), משפחות מכונות ב-Compute Engine, FinOps עם Active Assist ו-Recommender, כוונון קנה מידה אוטומטי (autoscaling).
שירותים שתפגוש במבחן ומדוע כל אחד מהם חשוב.
שירות CI מנוהל שמריץ בניית תוכנה, בדיקות ותמונות קונטיינר על עובדים מתארחים של Google, מונע על ידי קובץ cloudbuild.yaml דקלרטיבי.
מדוע הוא במבחן: דומיין 2 (צינורות CI/CD) מציין את Cloud Build כרכיב בניית התוכנה הקנוני והמקומי של PCDOE — מצע לאפיית תמונות, אימות וטריגרים של צינורות.
שירות מסירה מתמשכת מנוהל שמקדם תמונות קונטיינר דרך יעדי GKE / Cloud Run מוגדרים מראש, עם אישורים ו-rollback.
מדוע הוא במבחן: דומיין 2 בוחן דפוסי מסירה מתקדמים (canary, blue/green) — Cloud Deploy הוא התשובה המקבילה ל-AWS CodeDeploy ב-GCP.
רישום מאוחד לחבילות Docker, Helm, Maven, npm, Python, Go וחבילות OS עם בידוד VPC-SC וסריקת פגיעויות.
מדוע הוא במבחן: דומיין 2 + דומיין 5 מדגישים מקוריות ארטיפקטים וסריקת פגיעויות — Artifact Registry הוא נקודת הקצה בשרשרת האספקה ומקור התמונה עבור Cloud Deploy.
אירוח Git מנוהל המשולב עם טריגרים של Cloud Build, Cloud Logging ו-Cloud Identity IAM עבור זרימות עבודה של בקרת מקור.
מדוע הוא במבחן: דומיין 2 מצפה למקור אמת משולב עבור טריגרים של Cloud Build ומהדורות של Cloud Deploy — CSR הוא המקבילה ל-AWS CodeCommit.
Kubernetes מנוהל עם מצבי Standard ו-Autopilot, מטוסי בקרה אזוריים, ingress מרובה אשכולות, ושדרוגי node-pool מנוהלים.
מדוע הוא במבחן: דומיין 3 (שיטות SRE) ודומיין 4 (תצפיתיות) נשענים על GKE — פריסת עומסים, autoscaling מודע ל-SLO, ושדרוגים מתגלגלים הם כולם ממוקדי GKE.
בקר תצורת GitOps שמסנכרן מצב אשכול דקלרטיבי (Kustomize, Helm, Config Sync) ואוכף אילוצי Policy Controller (OPA Gatekeeper) על פני צי כלים.
מדוע הוא במבחן: דומיין 1 (אתחול ארגון Google Cloud) ודומיין 3 (שיטות SRE) בוחנים GitOps ו-policy-as-code — ACM היא התשובה המוגדרת ב-GCP.
תוסף Kubernetes המנהל משאבי GCP (BigQuery datasets, Pub/Sub topics, IAM bindings) כ-CRDs מתואמים ממניפסטים של אשכול.
מדוע הוא במבחן: דומיין 1 בוחן תשתית דקלרטיבית בצורת GitOps — Config Connector מאפשר לצוותי פלטפורמה לשלוח הקצאת GCP יחד עם עומסי עבודה תחת אותו kubectl apply.
HashiCorp Terraform עם ספקי Google + google-beta הרשמיים, בתוספת מודולים של Cloud Foundation Toolkit וספריית המדיניות Terraform-validator.
מדוע הוא במבחן: דומיין 1 מציין את Terraform ככלי ה-IaC בפועל עבור landing zones, פרויקטים, רשתות ו-IAM — PCDOE מצפה לשליטה במבנה מודולים ואסטרטגיית מצב.
סביבת ריצת קונטיינרים serverless (מונעת על ידי בקשה או אירוע) עם פיצול תעבורה מבוסס גרסאות, sidecars, ו-mTLS מנוהל באמצעות Cloud Service Mesh.
מדוע הוא במבחן: דומיין 2 בוחן מסירה מתקדמת עבור שירותים חסרי מצב — גרסאות Cloud Run + פיצולי תעבורה הם הפרימיטיב הקנוני ל-canary.
מחשוב serverless מונחה-אירועים (טריגרים של HTTP ו-Eventarc) לדבק קל משקל בין Pub/Sub, Cloud Storage ו-Firestore.
מדוע הוא במבחן: דומיין 4 (תצפיתיות) מציין את Functions כמצע לאוטומציה של תגובה לאירועים ול-runbooks מונחי-אירועים.
תזמור serverless שמשרשר ממשקי API של Google Cloud ונקודות קצה של HTTP עם ניסיונות חוזרים, צעדים מקבילים וטיפול מובנה בשגיאות.
מדוע הוא במבחן: דומיין 4 מצפה לתיקון אוטומטי — Workflows הוא המקבילה ל-AWS Step Functions עבור תגובה לאירועים ו-playbooks ל-rollback רב-שירותי.
שירות תור משימות מנוהל במלואו עם הגבלת קצב, ביטול כפילויות, ויעדי HTTP / App Engine עבור עבודה אסינכרונית, בביצוע מדויק פעם אחת.
מדוע הוא במבחן: דומיין 5 (ביצועים ועלות) בוחן דפוסי הפחתת עומס — Cloud Tasks מנתק יצרנים תזזיתיים מצורכנים מוגבלי קצב וממתן עליות עלויות.
מצב פעולה של GKE שבו Google מנהלת צמתים, autoscaling, וגודל node-pool — מחויב לפי pod עם זמינות מגובה SLA.
מדוע הוא במבחן: דומיין 5 מציין את Autopilot כפשרה בין עלות / טרחה תפעולית עבור צוותים שרוצים אמינות ברמת SRE מבלי לנהל node pools.
קיבוץ לוגי של מספר אשכולות GKE על פני פרויקטים, אזורים ו-on-prem עם הפעלת תכונות כלל-צי (Config Sync, Policy Controller, Identity).
מדוע הוא במבחן: דומיין 1 + דומיין 3 בוחנים פעולות מרובות אשכולות — ציים הם יחידת הפצת המדיניות והזהות עבור צוותי פלטפורמה המנהלים אשכולות רבים.
פלטפורמת מסירה מתמשכת מרובת-עננים בקוד פתוח עם תמיכה מקורית ב-GKE / Cloud Run, שלבי שיפוט ידניים, וניתוח canary אוטומטי.
מדוע הוא במבחן: דומיין 2 משווה בין Cloud Deploy (מנוהל, מוטה) לבין Spinnaker (באירוח עצמי, מרובה-עננים) — הידיעה מתי כל אחד מתאים היא הבחנה חוזרת ב-PCDOE.
Google Cloud IAM עם כריכות מותנות, בתוספת Workload Identity המאחדת GKE / pods חיצוניים לחשבונות שירות של Google ללא מפתחות ארוכי טווח.
מדוע הוא במבחן: דומיין 1 + דומיין 3 נשענים על אימות ללא מפתח — Workload Identity היא הדרך הקנונית שבה צינורות ו-pods מניחים זהויות GCP תחת הרשאה מינימלית.
ערימת תצפיתיות משולבת — Cloud Logging לאיגום לוגים, Cloud Monitoring למדדים והתראות, Cloud Trace להשהיה, ו-Cloud Profiler לדגימת CPU/heap רציפה.
מדוע הוא במבחן: דומיין 4 (תצפיתיות ופתרון בעיות) הוא הסיבה כולה לקיום חבילה זו; PCDOE מצפה לשימוש שוטף ב-MQL, מדדים מבוססי לוגים, ובדיקות זמינות.
Error Reporting אוסף ומקבץ עקבות מחסנית מ-Cloud Logging לבעיות ניתנות לפעולה; Cloud Debugger לוכד מצב יישום מקוד ייצור פועל ללא פריסות מחדש.
מדוע הוא במבחן: דומיין 4 בוחן מיון אירועים חי — Error Reporting לוכד רגרסיות, Debugger בודק מצב מבלי לכפות rollback.
הגדרות SLO מקוריות ב-Service Monitoring עם התראות על קצב שריפת תקציב שגיאות מתגלגלות ומדיניות מהירות שחרור מונחית תקציב.
מדוע הוא במבחן: דומיין 3 (שיטות SRE) בנוי סביב SLIs/SLOs/תקציבי שגיאות — PCDOE מצפה ממועמדים לתרגם ציפיות משתמשים למדיניות התראה על קצב שריפה.
$135k–$185k–$280k USD שנתי
הטווח משקף מהנדסי SRE ו-DevOps בארה"ב שבהם GCP היא הפלטפורמה העיקרית. שכר כולל של מהנדסי SRE ב-FAANG L5 עולה על 300 אלף דולר+. תפקידי תפעול בלבד נוטים להיות נמוכים יותר; משרות מהנדס SRE בכיר / מהנדס ייצור בחברות דיגיטליות-מקוריות המשתמשות ב-GCP נוטות להיות גבוהות יותר. ההסמכה היא אות חזק אך משתלבת בצורה הטובה ביותר עם ניסיון מוכח בכוננות ייצור.
מקור: levels.fyi 2025–2026 (מהנדסי SRE L4–L5 בגוגל, מהנדסי פלטפורמה בכירים בחברות חד-קרן ו-FAANG המשתמשות ב-GCP), הלשכה האמריקאית לסטטיסטיקת עבודה BLS OEWS מאי 2024 (15-1244 מנהלי רשת ומערכות מחשב, 15-1252 מפתחי תוכנה). הנתונים משוערים; התגמול בפועל תלוי בתפקיד, באזור ובניסיון.
הביקוש ל-PCDOE גדל בהתמדה ככל שתרבות ה-SRE-first של GCP יוצאה ללקוחותיה. ביקוש גבוה בחברות דיגיטליות-מקוריות המשתמשות ב-GCP (Spotify, Snap, PayPal, כמה קמעונאים גדולים, אולפני משחקים) שבהן מודל ה-SRE כבר אומץ, ובשותפי Google Cloud הבונים שיטות עבודה לשירותים מנוהלים. ההסמכה משתלבת באופן טבעי עם Kubernetes CKA / CKAD ו-Terraform Associate ליצירת פרופיל SRE חזק מבוסס ענן. בעלי ההסמכה מדווחים באופן עקבי על תגובה חזקה מצד מגייסים לתפקידי SRE ומהנדס פלטפורמה בכיר. PCDOE מסמלת גם שליטה בספר ה-SRE של גוגל, שהוא עצמו אות גיוס בחברות שאימצו את מודל ה-SRE.
אין דרישות קדם רשמיות. גוגל ממליצה על שלוש שנות ניסיון בתעשייה או יותר, ושנה אחת או יותר בתכנון וניהול פתרונות ב-Google Cloud. בפועל, PCDOE אינה הסמכת GCP ראשונה אמינה — מועמדים מצליחים שלחו מערכות ייצור וביצעו תורנויות כוננות.
הסמכת Associate Cloud Engineer (ACE) היא אבן הדרך הנפוצה ביותר אך אינה נדרשת באופן מוחלט אם כבר אתם מנהלים סביבות ייצור ב-AWS או Azure. קריאת ספר ה-SRE של גוגל ("Site Reliability Engineering") וחוברת העבודה של SRE היא למעשה חלק מההכנה — שאלות רבות בבחינה מציגות פסקאות באופן ישיר. נדרשת נוחות עם Kubernetes (Deployments, Services, HPA, PodDisruptionBudgets), Terraform, ו-Cloud Build pipelines. נתיב הלמידה הרשמי של DevOps Engineer ב-Google Cloud Skills Boost (כ-40–60 שעות) מכסה את תוכנית הלימודים.
PCDOE מדורגת ברמה מקצועית ונחשבת קשה במידה מתונה — התוכן הספציפי ל-SRE (SLOs, תקציבי שגיאות, עבודת כפיים) מכשיל מועמדים ממוקדי תפעול מסורתיים יותר מאשר מהנדסי אמינות אתרים מנוסים. תכננו 80–130 שעות לימוד לאורך 8–12 שבועות אם PCDOE היא הסמכת GCP המקצועית הראשונה שלכם, או 40–70 שעות לאורך 4–6 שבועות אם כבר יש לכם ACE בתוספת ניסיון SRE בכוננות. הבחינה כוללת 50–60 שאלות רב-ברירה / בחירה מרובה ב-120 דקות, ומועברת דרך Pearson VUE (גוגל עברה מ-Kryterion / Webassessor בתחילת 2026).
המכשול הנפוץ ביותר הן שאלות פילוסופיית ה-SRE — התשובה המצופה מגוגל תלויה לעיתים קרובות בהבחנות דקות (מתי להוציא תקציב שגיאות לעומת מתי להקפיא פריסות, מתי הפחתת עבודת כפיים שווה אוטומציה לעומת קבלה). המכשול השני הוא תבניות ייצור ב-GKE, במיוחד תכנון node-pool, PodDisruptionBudgets ו-Workload Identity. גוגל אינה מפרסמת ציונים מספריים — רק עובר/נכשל. ההסמכה תקפה לשנתיים וחידוש דורש מעבר מחדש של הבחינה הנוכחית.
מדריך הבחינה הנוכחי עודכן בסוף 2023 כדי להוסיף כיסוי ל-Cloud Deploy, Config Sync / GitOps, ותרחישי GKE Autopilot מעודכנים. הורחב משקל תחום פילוסופיית ה-SRE.
עדכון משמעותי שהציג את Cloud Build כמשטח ה-CI העיקרי ויישר קו בין תוכן ה-SLO / תקציב השגיאות לחוברת העבודה של SRE.
PCDOE (Google Cloud Professional Cloud DevOps Engineer) הוא מבחן ברמת Professional מבחן מאתגר ועשיר בתרחישים הדורש ניסיון מעמיק ויכולת לקבל החלטות על פשרות אדריכליות. רוב המועמדים זקוקים ל-150–300 שעות לימוד הפרוסות על פני 3–6 חודשים עבור מבחני רמת מקצועי ומומחה. מבחנים אלו מצפים בדרך כלל למיומנות קודמת ברמת Associate. רוב המועמדים שמקבלים ציונים באופן עקבי מעל סף המעבר במבחני תרגול עוברים בניסיון הראשון.
רוב המועמדים זקוקים ל-150–300 שעות לימוד הפרוסות על פני 3–6 חודשים עבור מבחני רמת מקצועי ומומחה. מבחנים אלו מצפים בדרך כלל למיומנות קודמת ברמת Associate. משך הזמן למעבר משתנה מאוד בהתאם לניסיון קודם. מהנדסים בעלי ניסיון מעשי בסביבת ייצור בטכנולוגיה הבסיסית זקוקים בדרך כלל לפחות זמן; מועמדים חדשים לפלטפורמה צריכים לתכנן את לימודיהם לכיוון הקצה העליון של טווח זה.
PCDOE הוא אישור מוכר במערכת האקולוגית של GCP ומסמן ידע מאומת למעסיקים, מגייסים ולקוחות. האם זה שווה את הזמן והעמלה עבורך תלוי בתפקיד ובמטרות שלך – זה נוטה להשתלם ביותר עבור מהנדסי ענן, אדריכלים ויועצים שעובדים עם GCP על בסיס יומיומי או רוצים לעבור לתפקידים כאלה.
ציון המעבר עבור PCDOE הוא לא פורסם. המבחן מכיל 50 שאלות ונמשך 2 שע'.
עמלת מבחן ה-PCDOE היא $200 USD. העמלות נקבעות על ידי GCP ועשויות להשתנות לפי אזור; תמיד אשרו את המחיר הנוכחי בדף ההסמכה הרשמי של GCP לפני ההזמנה.
הסמכות Google Cloud Professional תקפות למשך שנתיים. ניתן לחדש הסמכה על ידי מעבר חוזר של הגרסה הנוכחית של המבחן.
כן. ניתן לגשת למבחן באופן מקוון (בפיקוח דרך הדפדפן המאובטח של הספק, זמין 24/7 ברוב האזורים) או במרכז בחינה פיזי של Pearson VUE בשעות הפעילות. שני הפורמטים משתמשים באותן שאלות, מגבלת זמן וציון מעבר.
CertLabPro מספק 15 מצבי לימוד על פני בנק השאלות לתרגול עבור PCDOE. מצב סימולציית המבחן משקף את המבחן האמיתי: 50 שאלות ב-2 שע', עם אותו סף מעבר של לא פורסם. מצב עיון מאפשר לך לקרוא כל שאלה ותשובה באופן סטטי.