מה באמת יש בבחינת GCP Cloud DevOps Engineer (PCDOE)
PCDOE בוחן עקרונות SRE ו-DevOps ב-GCP — Cloud Build, Cloud Deploy, צינורות GKE, תכנון SLO, תגובה לאירועים. הנה מה לצפות וכיצד הוא משתווה ל-AZ-400 ול-DOP-C02.
PCDOE — Professional Cloud DevOps Engineer — הוא אישור ה-DevOps של גוגל בטעם SRE. 200$, שעתיים, בסביבות 50 שאלות, תקפות לשנתיים. אם ניגשתם לבחינה מקצועית של גוגל, זו הצורה הסטנדרטית. מה שלא סטנדרטי זו צפיפות מקרי המבחן (case-study). ל-PCDOE יש מוניטין של אחת מבחינות המקצועיות הקשות יותר של גוגל לעבור בניסיון הראשון, והסיבה היא כמעט כולה שהשאלות ארוכות, עשירות בתרחישים, ומניחות שבאמת הפעלתם שירות בייצור (production).
שיעורי המעבר אינם מפורסמים — גוגל גם לא מפרסמת ציונים מספריים, רק עבר/נכשל — אבל שיעור הניסיון הראשון האנקדוטי משרשורי קבוצות לימוד יושב באופן ניכר מתחת ל-ACE וקצת מתחת ל-PCA. קחו את זה עם גרגיר המלח הרגיל. שיעורי מעבר מדווחים-עצמית נוטים להטות כלפי אנשים שנכשלו ורוצים לפרוק.
מה הבחינה באמת מכסה
המדריך הרשמי מחלק את PCDOE לחמישה תחומים. המשקל משתנה כל שנתיים, אבל הצורה עקבית:
- יישום עקרונות Site Reliability Engineering. תכנון SLO ו-SLI, תקציבי שגיאות (error budgets), הפחתת טרחה (toil reduction), פוסטמורטמים ללא האשמה (blameless postmortems). לקיחה ישירה מספר ה-SRE של גוגל — קראו לפחות את הפרקים על SLOs, התראות (alerting) ותגובה לאירועים (incident response) אם לא עשיתם זאת.
- בנייה ויישום של צינורות CI/CD. Cloud Build, Artifact Registry, Cloud Deploy, Skaffold עבור תהליכי עבודה מקומיים לאשכול (local-to-cluster workflows), אינטגרציה עם GitHub / GitLab. סריקת קונטיינרים (Container scanning) עם Artifact Analysis. Binary Authorization עבור תמונות חתומות (signed images).
- יישום אסטרטגיות ניטור שירותים. Cloud Monitoring, Cloud Logging, Cloud Trace, Cloud Profiler, Error Reporting. כל חבילת "Cloud Operations" (לשעבר Stackdriver — התיעוד עדיין אומר "Cloud Ops" אבל מגייסים ומהנדסים ותיקים ישתמשו בשני השמות לסירוגין).
- אופטימיזציה של ביצועי שירותים. כוונון עומסי עבודה של GKE (GKE workload tuning), קנה מידה אוטומטי (autoscaling) (HPA, VPA, cluster autoscaler), אופטימיזציית עלויות, תכנון קיבולת.
- ניהול אירועי שירות. רוטציות כוננות (On-call rotations), פיקוד על אירועים (incident command), ספרי הפעלה (runbooks), כתיבת פוסטמורטמים (postmortem writeups). כן, הם שואלים שאלות על תהליכים, לא רק שאלות על כלים.
שאלות מקרה המבחן הן החלק הקשה. תקבלו תרחיש המתאר חברה פיקטיבית — הארכיטקטורה שלה, נקודות הכאב הנוכחיות שלה, מבנה הצוות שלה — ושלוש או ארבע שאלות שידרשו מכם להחזיק את כל זה בראש בו זמנית. קריאה חפוזה (Skim-reading) היא הסיבה שאנשים נכשלים. השאלות מתוכננות כך שהתשובה הברורה הופכת לשגויה ברגע שאתם קוראים מחדש את התרחיש בזהירות.
מה שאתם באמת צריכים לדעת
לא כל שירות GCP מופיע. הנה רשימת הפגיעות הגסה (rough hit list), משוקללת לפי תדירות הופעת הנושאים בדוחות לימוד:
| שירות / נושא | משקל בבחינה |
|---|---|
| Cloud Build, Cloud Deploy, Artifact Registry | כבד |
| פעולות GKE, קנה מידה אוטומטי, זהות עומס עבודה (workload identity) | כבד |
| מתמטיקת SLO / SLI / תקציב שגיאות | כבד |
| Cloud Monitoring, מדיניות התראות (alerting policies), לוחות מחוונים (dashboards) | כבד |
| Cloud Logging, מדדים מבוססי יומן (log-based metrics), ניתוב יומנים (log routing) | בינוני |
| Binary Authorization, סריקת קונטיינרים | בינוני |
| Cloud Trace, Profiler, Error Reporting | בינוני |
| יסודות Terraform / Config Connector | בינוני |
| Anthos / ריבוי אשכולות (multi-cluster) (קל יותר מבעבר) | קל |
| Pub/Sub, Cloud Tasks עבור תבניות אסינכרוניות (async patterns) | קל |
אתם לא צריכים לשנן כל מפתח YAML של Cloud Build. אתם צריכים לזהות מתי Cloud Build היא התשובה הנכונה לעומת Cloud Deploy לעומת CI של צד שלישי בתוספת Cloud Deploy. הבחינה אוהבת את הניסוח "חברה X משתמשת ב-Y, מה עליהם לעשות הלאה".
איך הוא משתווה ל-AZ-400 ול-DOP-C02
שלושת האישורים מכסים שטח דומה ברמה הרעיונית — צינורות, ניטור, תגובה לאירועים, IaC, אבטחה — אך עם דגשים שונים.
| PCDOE | AZ-400 | DOP-C02 | |
|---|---|---|---|
| עלות | $200 | $165 | $300 |
| אורך | ~שעתיים, ~50 ש' | ~150 דקות, ~50 ש' | ~3 שעות, ~75 ש' |
| תוקף | שנתיים | שנה, חידוש חינם | 3 שנים |
| עומק SRE / SLO | כבד | קל | בינוני |
| התמקדות ב-CI/CD מקורי | Cloud Build / Deploy | Azure DevOps + GitHub | CodePipeline / CodeBuild |
| התמקדות ב-IaC | Terraform, Config Connector | Bicep, ARM, Terraform | CloudFormation, CDK |
| החלק הקשה ביותר | צפיפות מקרי מבחן | רוחב Azure DevOps | שאלות מילוליות של DOP-C02 |
PCDOE נשען הכי הרבה על מושגי SRE — SLOs, תקציבי שגיאות, טרחה — מכיוון שגוגל המציאה את אוצר המילים הזה. AZ-400 נשען על Azure DevOps (המוצר) ואינטגרציית GitHub Actions. DOP-C02 מכסה את שטח הפנים הרחב ביותר אך בעומק תרחישים רדוד יותר מאשר PCDOE.
אם אתם עובדים ב-GCP, PCDOE הוא הבחירה הברורה. אם אתם עובדים ב-Azure, אז AZ-400. אם אתם עובדים ב-AWS, אז DOP-C02. הכישורים חופפים מאוד והצינורות נראים כמעט זהים ברגע שאתם ממצמצים מעבר לשמות השירותים. קניות אישורים בין עננים עבור DevOps היא לעיתים רחוקות המהלך הנכון — האישור שמתאים לעבודה היומית שלכם יהיה זה שתוכלו באמת ללמוד עבורו באמצעות עבודתכם האמיתית.
למי זה מיועד
בכנות, לשלוש קבוצות:
מהנדסי SRE / DevOps בכירים שכבר עובדים ב-GCP. זהו קהל היעד של הבחינה. אם הייתם בכוננות עבור שירות הפועל ב-GKE לפחות שנה, השאלות ירגישו כמו הרחבות של ויכוחים שכבר קיימתם בצוות שלכם. שלושה עד שישה שבועות של הכנה ממוקדת בדרך כלל מספיקים.
מהנדסי פלטפורמה עוברים מ-AWS או Azure. מושגי ה-SRE עוברים אחד לאחד. שמות השירותים לא. צפו ל-2-3 חודשי לימוד כדי למפות את הידע הקיים שלכם ל-Cloud Build, Cloud Deploy, וחבילת ה-Cloud Ops. בנו פרויקט קטן שעושה CI דרך Cloud Build, פורס ל-GKE באמצעות Cloud Deploy, ופולט SLOs ל-Cloud Monitoring. הפרויקט הבודד הזה מכסה אולי 40% מהבחינה.
מחליפי קריירה הרודפים אחר תואר DevOps. בכנות, זו מטרה מאתגרת. PCDOE מניח שעברתם אירועי ייצור (production incidents) אמיתיים. אם לא, שאלות מקרה המבחן ייראו לא מוכרות באופן שאף כמות של קורסי וידאו לא תתקן. עשו CKA או KCNA קודם, עבדו בתפקיד פלטפורמה במשך שנה, ואז חזרו ל-PCDOE.
הערות לימוד מהשטח
כמה דברים שבאופן עקבי מכשילים אנשים:
ספר ה-SRE הוא קריאת חובה, לא אופציונלית. הספרים Site Reliability Engineering ו-The Site Reliability Workbook של גוגל זמינים שניהם בחינם באינטרנט. פרקי ה-SLO / תקציב שגיאות ניתנים לבחינה ישירה. דילוג עליהם והסתמכות על חומרי קורסים היא הסיבה הנפוצה ביותר לכך שמהנדסים חכמים נכשלים בזה.
Cloud Deploy חדש יותר ומקבל משקל בלתי פרופורציונלי. הוא הפך לזמין כללית (GA) ב-2022. מדריכי לימוד מוקדמים יותר מכסים אותו פחות. בלו סוף שבוע בביצוע המדריך המהיר הרשמי של Cloud Deploy מקצה לקצה עם שתי סביבות והשקה הדרגתית (canary rollout) — זה מתאים ישירות לשאלות בחינה מרובות.
דעו את ההבדל בין מאגרי Cloud Build פרטיים לבריכות ברירת מחדל (default pools). כאשר שאלות כוללות build-ים פנימיים ב-VPC, מאגרי פרטיים הם בדרך כלל התשובה. שאלות כלליות כמו "אנחנו רוצים build-ים מהירים יותר" הן בדרך כלל על סוג מכונה (machine type) או גודל מאגר עובדים (worker pool size).
Binary Authorization מופיע יותר ממה שהייתם מצפים. התרחיש "אנחנו צריכים לאכוף תמונות חתומות בייצור" (enforce signed images in prod) כמעט מובטח להופיע בצורה כלשהי.
בשורה התחתונה
PCDOE הוא אישור מקצועי מוצק אם אתם באמת עובדים ב-DevOps על GCP. הוא משלם בערך באותו טווח כמו PCA בשווקים דומים — בסיס של 150-200 אלף דולר עבור תפקידי DevOps / SRE בכירים במטרופולינים הגדולים בארה"ב, עם פיצוי כולל ב-FAANG ו-ad-tech שדוחף ל-250 אלף דולר+ ברגע שהון עצמי (equity) נערם. האישור אינו מכפיל שכר בפני עצמו; ניסיון ה-SRE הבסיסי הוא כן. PCDOE פשוט הופך את הניסיון לקריא למגייסים.
אם אתם לומדים, עיינו במאגר השאלות של PCDOE ב-CertLabPro או התחילו בחינה מתוזמנת. שאלות מקרה המבחן במאגר הן ההתאמה הקרובה ביותר לצורת הבחינה האמיתית — השלכת שאלות זכירה ישרות לא מכינה אתכם למה שבאמת מופיע.
אם אתם מחליטים אם לטרוח: האם אתם כותבים פוסטמורטמים בעבודה? אם כן, האישור הזה ירגיש מובן מאליו. אם לא, עברו אירוע אמיתי אחד או שניים קודם, ואז חזרו.