נבדק לאחרונה: מאי 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן ACE בודק. קראו מלמעלה למטה, או דלגו לסעיף.
ריכוז חשבונות ואכיפת מדיניות תוך מתן אוטונומיה ניהולית ליחידות עסקיות.
השתמש בצומת Organization עם Folders עבור כל יחידה עסקית. צור פרויקטים בתוך ה-Folders. קשר את כל הפרויקטים לחשבון חיוב יחיד (Billing Account).
למה: Folders מספקים גבולות אדמיניסטרטיביים וירושת מדיניות. חשבון חיוב יחיד מרכז את ניהול העלויות ומאפשר הנחות ברמת הארגון.
הודע למחלקת הכספים כאשר הוצאות הפרויקט מגיעות לאחוזים מסוימים מהתקציב.
ב-Cloud Billing, צור תקציב (Budget) עבור הפרויקט. הגדר מספר כללי סף התראה (לדוגמה, 50%, 90%, 100%) ששולחים הודעות לנושא Pub/Sub או למייל.
למה: תקציבים מיועדים להתראות, לא לעצירת הוצאות. כדי להגביל הוצאות באופן אוטומטי, הודעת Pub/Sub חייבת להפעיל Cloud Function כדי להשבית חיובים או לכבות משאבים.
נתח עלויות ענן מפורטות ברמת המשאב ועקוב אחר הוצאות לפי מרכז עלות.
אפשר ייצוא חיובים מפורט ל-BigQuery dataset. החל תוויות (לדוגמה, `cost-center: "finance"`) על משאבים. בצע שאילתות לטבלת BigQuery וקבץ לפי תוויות לצורך ניתוח.
למה: ייצוא חיובים ל-BigQuery מספק את נתוני העלות המפורטים ביותר, כולל תוויות, וזה חיוני למודלי חיוב חוזר (chargeback) ותצוגת עלויות (showback) מותאמים אישית.
אכוף תקני אבטחה ותצורה על פני כל הפרויקטים בארגון (לדוגמה, הגבל מיקומי משאבים, דרוש גישה אחידה לדלי, השבת כתובות IP ציבוריות).
החל אילוצי Organization Policy ברמת ה-Organization או ה-Folder. דוגמאות: `gcp.resourceLocations` עבור מיקום נתונים, `storage.uniformBucketLevelAccess` עבור אבטחת GCS, `compute.vmExternalIpAccess` למניעת IP ציבוריים.
למה: מדיניות ארגונית עוברת בירושה ומספקת שליטה מונעת, וחוסמת פעולות שאינן תואמות לפני שהן מתרחשות. זה יעיל יותר מביקורת תגובתית.
מנע מחיקה מקרית של פרויקט ייצור קריטי.
הצב עיקול (lien) על הפרויקט באמצעות `gcloud alpha resource-manager liens create`.
למה: עיקול הוא מאפיין החוסם את מחיקת הפרויקט. יש להסירו במפורש על ידי משתמש בעל תפקיד `resourcemanager.lienModifier` לפני שניתן יהיה למחוק את הפרויקט.
עבור ביעילות בין פרויקטים וחשבונות משתמש שונים בעת שימוש ב-gcloud CLI.
השתמש ב-`gcloud config configurations create` כדי ליצור תצורות בעלות שם עבור כל פרויקט/חשבון. עבור ביניהן באמצעות `gcloud config configurations activate [CONFIG_NAME]`
למה: תצורות מאחסנות הגדרות כמו פרויקט, חשבון, אזור (region) ואזור זמינות (zone), ובכך מונעות את הצורך לציין אותן בכל פקודה.
הפעל microservice מבוסס HTTP, חסר מצב ומבוסס קונטיינרים עם תעבורה משתנה, תוך צמצום תקורה תפעולית ועלויות.
פרוס את הקונטיינר ל-Cloud Run.
למה: Cloud Run מנוהל במלואו, מתרחב לאפס (מבטל עלויות עבור תקופות סרק), ומתרחב אוטומטית בהתבסס על בקשות נכנסות. הוא אידיאלי לשירותי ווב חסרי מצב.
הפעל משימת עיבוד אצווה סובלנית לתקלות, גמישה בזמן, בעלות הנמוכה ביותר האפשרית.
השתמש ב-Spot VMs (לשעבר Preemptible VMs) בקבוצת מופעים מנוהלת (Managed Instance Group).
למה: Spot VMs מציעים הנחה של עד 91% בהשוואה למחירי on-demand. הם מתאימים לעומסי עבודה שניתן לעצור ולהתחיל מחדש, כמו רבות ממשימות עיבוד אצווה.
פרוס יישום ווב הדורש זמינות גבוהה (לדוגמה, 99.9%) והרחבה אוטומטית (autoscaling).
השתמש בקבוצת מופעים מנוהלת אזורית (Regional Managed Instance Group - MIG) עם מדיניות הרחבה אוטומטית, הפרוסה מאחורי מאזן עומסים חיצוני גלובלי (Global External HTTP(S) Load Balancer).
למה: MIG אזורי מפיץ מופעים אוטומטית על פני מספר אזורים לצורך סבילות לתקלות. הרחבה אוטומטית מתאימה את הקיבולת כדי לעמוד בביקוש, ומאזן העומסים מספק נקודת כניסה יחידה.
אחסן נתונים הנגישים לעיתים קרובות למשך 30 יום, ולאחר מכן לעיתים רחוקות למשך שנה, ואז בארכיון.
אחסן בדלי Cloud Storage מסוג Standard. צור כלל מחזור חיים (lifecycle rule) להעברת אובייקטים ל-Nearline/Coldline לאחר 30 יום ולארכיון לאחר 365 יום.
למה: כללי מחזור חיים מבצעים אופטימיזציה של עלויות באופן אוטומטי על ידי העברת נתונים לסוגי אחסון זולים יותר בהתבסס על גיל או תנאים אחרים, ללא התערבות ידנית.
יישום מבוזר גלובלית דורש מסד נתונים יחסי (relational database) עם סילומיות אופקית ועקביות חזקה.
השתמש ב-Cloud Spanner.
למה: Cloud Spanner הוא השירות היחיד המספק מסד נתונים יחסי מבוזר גלובלית, בעל עקביות חזקה, עם תמיכת SQL. Cloud SQL הוא אזורי.
יישום דורש מסד נתונים PostgreSQL או MySQL מנוהל עם SLA זמינות של 99.95% ו-failover אוטומטי.
השתמש ב-Cloud SQL עם תצורת High Availability (HA) מופעלת.
למה: תצורת HA יוצרת מופע ראשי ומופע גיבוי (standby instance) באזור זמינות אחר. הנתונים משוכפלים באופן סינכרוני, וה-failover הוא אוטומטי.
תכנן VPC עבור יישום בעל 3 שכבות (ווב, יישום, מסד נתונים) כאשר שכבת מסד הנתונים אינה נגישה מהאינטרנט.
צור VPC במצב מותאם אישית (custom-mode) עם תת-רשת נפרדת לכל שכבה. הקצה למופעי מסד הנתונים כתובות IP פרטיות בלבד בתת-הרשת הייעודית שלהם.
למה: בידוד שכבות בתת-רשתות נפרדות מאפשר כללי חומת אש גרנולריים. השמטת כתובות IP חיצוניות במופעי מסד נתונים היא הדרך הישירה ביותר למנוע גישה לאינטרנט.
פרוס יישום בעל מצב (stateful) (לדוגמה, מסד נתונים) ב-GKE הדורש מזהי רשת יציבים ואחסון מתמשך (persistent storage).
השתמש ב-StatefulSet עם תבנית PersistentVolumeClaim.
למה: StatefulSets מתוכננים לעומסי עבודה בעלי מצב, ומספקים שמות מארח יציבים (לדוגמה, `pod-0`, `pod-1`) ומקצים אוטומטית PersistentVolume ייחודי לכל רפליקה.
שירות Cloud Run הרגיש לזמן השהיה חייב למנוע "התחלות קרות" (cold starts) במהלך קפיצות תעבורה.
פרוס את השירות עם הדגל `--min-instances` מוגדר ל-1 או יותר.
למה: הגדרת מופעים מינימליים שומרת מספר מוגדר של קונטיינרים "חמים" ומוכנים לשרת בקשות, ובכך מבטלת את זמן ההשהיה הקשור להפעלת קונטיינר חדש.
בצע פונקציה serverless אוטומטית בכל פעם שקובץ חדש מועלה לדלי Cloud Storage.
פרוס Cloud Function (דור שני) עם טריגר Eventarc לאירוע `google.cloud.storage.object.v1.finalized` בדלי שצוין.
למה: Eventarc מספק ארכיטקטורה אחידה ומבוססת אירועים. טריגר ה-GCS הוא הדרך הסטנדרטית והמנוהלת לחיבור אירועי אחסון למחשוב serverless ללא polling.
פרוס גרסה חדשה של יישום App Engine לבדיקה מבלי לשלוח אליה מיד תעבורת ייצור.
פרוס את הגרסה החדשה באמצעות `gcloud app deploy --no-promote`.
למה: הדגל `--no-promote` יוצר את הגרסה החדשה אך אינו מעביר אליה תעבורה כלשהי. לאחר מכן תוכל לבדוק אותה באמצעות כתובת ה-URL הספציפית לגרסה ולהעביר תעבורה ידנית כשתהיה מוכן.
צור מאזן עומסים גלובלי מסוג HTTP(S) עבור יישום ווב הפועל על מופעי Compute Engine.
צור את הרכיבים הבאים לפי הסדר: Instance Group (עם VMs), Health Check, Backend Service (מצביע ל-IG ול-HC), URL Map, Target HTTP(S) Proxy, ו-Global Forwarding Rule (עם IP ציבורי).
למה: רצף זה בונה נכון את מאזן העומסים מהקצה האחורי (מופעים) לקצה הקדמי (כלל העברה). כל רכיב משרת מטרה ספציפית בניתוח ניתוב ובדיקת תקינות.
צוות צריך לנהל את מצב Terraform באופן שיתופי, תוך הבטחת אבטחה ומניעת שינויים מקבילים.
השתמש בדלי Cloud Storage כ-backend של Terraform. אפשר ניהול גרסאות אובייקטים (object versioning) להיסטוריה ושחזור. נעילת מצב מטופלת אוטומטית על ידי ה-backend של GCS.
למה: GCS backend מרוחק הוא הסטנדרט לשיתוף פעולה בצוות ב-GCP. הוא מספק נעילה למניעת שחיתות מצב וניהול גרסאות ליכולות שחזור.
קבל הודעה כאשר ניצולת ה-CPU בכל VM בקבוצה עולה על 80% לתקופה ממושכת (לדוגמה, 5 דקות).
ב-Cloud Monitoring, צור מדיניות התראה (Alerting Policy). הגדר את התנאי ל-`Metric: CPU utilization > 80%` עבור `Duration: 5 minutes`. הגדר ערוץ התראות (לדוגמה, אימייל, PagerDuty).
למה: Cloud Monitoring הוא השירות המקורי ליצירת התראות מבוססות מדדים. תנאי משך הזמן קריטי למניעת התראות "מתנדנדות" מקפיצות קצרות ונורמליות בניצולת.
שמור יומני ביקורת ספציפיים למשך 7 שנים לצורך תאימות, תוך שמירת יומנים אחרים למשך 30 יום.
צור log sink עם פילטר עבור יומני הביקורת. הגדר את ה-sink לייצא לדלי Cloud Storage. החל מדיניות שמירה של 7 שנים על הדלי.
למה: ל-Cloud Logging יש תקופת שמירה מוגבלת (מקסימום 400 ימים לפעילות ניהול). Sinks הם המנגנון לניתוב יומנים לאחסון לטווח ארוך וזול יותר כמו GCS או לניתוח ב-BigQuery.
קוד GKE נמצא במצב `CrashLoopBackOff`. עליך לצפות ביומנים מהקונטיינר רגע לפני שקרס.
השתמש בפקודה `kubectl logs [POD_NAME] --previous`.
למה: כאשר קונטיינר קורס ומופעל מחדש, `kubectl logs` מציג את יומני הקונטיינר *החדש*. הדגל `--previous` חיוני לצפייה ביומני המופע שהופסק כדי לאבחן את הקריסה.
קבוצת מופעים מנוהלת חייבת להחליף אוטומטית מופעים שמפסיקים להגיב.
הגדר בדיקת תקינות (לדוגמה, HTTP, TCP) והחל אותה על מדיניות הריפוי העצמי של קבוצת המופעים המנוהלת.
למה: ה-MIG בודק מופעים באופן תקופתי בהתבסס על בדיקת התקינות. אם מופע נכשל בבדיקות רצופות, ה-MIG מוחק ויוצר אותו מחדש אוטומטית מהתבנית, ומבטיח את זמינות היישום.
אירע אירוע שחיתות נתונים במסד נתונים של Cloud SQL. עליך לשחזר את מסד הנתונים למצב שבו היה 5 דקות לפני האירוע.
ודא ש-Point-in-Time Recovery (PITR) מופעל במופע מראש. בצע פעולת שחזור, תוך ציון חותמת הזמן המדויקת לשחזור.
למה: PITR מסתמך על הפעלת רישום בינארי (binary logging). הוא מאפשר שחזור גרנולרי לכל נקודת זמן בתוך חלון השמירה, וזה קריטי למזעור אובדן נתונים (RPO נמוך).
בצע גיבויים יומיים אוטומטיים של דיסק קשיח ב-Compute Engine ושמור אותם למשך 14 יום.
צור Resource Policy עבור תצלומי דיסק (disk snapshots). הגדר לוח זמנים יומי ומדיניות שמירה של 14 יום. צרף מדיניות זו לדיסק הקשיח היעד.
למה: לוחות זמנים של תצלומי מצב הם הדרך המנוהלת וה"הפעל ושכח" לאוטומציה של גיבויים ב-GCE. זה אמין יותר וקל יותר לתחזוקה מאשר שימוש בעבודות cron או סקריפטים מותאמים אישית.
מופע Compute Engine צריך לקרוא מדלי Cloud Storage ולכתוב לטבלת BigQuery. הענק את ההרשאות המינימליות הנדרשות.
צור חשבון שירות (service account) מותאם אישית. הענק לו את התפקידים `roles/storage.objectViewer` ו-`roles/bigquery.dataEditor`. צרף חשבון שירות זה למופע.
למה: שימוש בחשבון שירות מותאם אישית עם תפקידים ספציפיים ומוגדרים מראש מונע את האופי הפרוץ יתר על המידה של חשבון השירות המוגדר כברירת מחדל של Compute Engine, ובכך דבק בעקרון הפריבילגיה המינימלית.
הענק למשתמש הרשאות לניהול מופעי GCE אך לא למחיקתם.
צור תפקיד IAM מותאם אישית. התחל עם ההרשאות מהתפקיד `roles/compute.instanceAdmin.v1` והסר את ההרשאה `compute.instances.delete`.
למה: תפקידים מותאמים אישית מספקים את הגמישות להעניק קבוצת הרשאות מדויקת כאשר תפקידים מוגדרים מראש רחבים מדי או מגבילים מדי עבור פונקציית עבודה ספציפית.
מפתח צריך להתחבר ב-SSH למופע Compute Engine שאין לו כתובת IP חיצונית, בהתאם למדיניות האבטחה.
הענק למפתח את התפקיד `roles/iap.tunnelResourceAccessor`. לאחר מכן הוא יכול להתחבר באמצעות `gcloud compute ssh [INSTANCE_NAME] --tunnel-through-iap`.
למה: Identity-Aware Proxy (IAP) TCP forwarding מספק שיטה מאובטחת ומבוססת זהות לגישה למופעים פנימיים ללא מארחי בסיס (bastion hosts), VPNs או IP ציבוריים.
אפשר תעבורת SSH נכנסת (פורט 22) ל-VMs ספציפיים מטווח ה-IP של המשרד הארגוני בלבד.
צור כלל חומת אש של VPC עם `direction: INGRESS`, `action: ALLOW`, `protocol/ports: tcp:22`, `source ranges: [CORPORATE_IP_CIDR]`, ו-`target tags: [e.g., "allow-ssh"]`. החל את התג על ה-VMs המיועדים.
למה: שילוב טווחי מקור ותגי יעד מספק דרך מדויקת וסקלאבילית לשלוט בתעבורה. זה מגביל גם *מי* יכול להתחבר וגם *למה* הוא יכול להתחבר.
מנע העתקה או גישה לנתונים מפרויקט BigQuery רגיש מחוץ לגבול רשת מהימן, גם עם אישורים תקפים.
הגדר VPC Service Controls. צור היקף שירות (service perimeter) הכולל את הפרויקט הרגיש ומגביל את BigQuery API.
למה: VPC Service Controls יוצרים "היקף נתונים" וירטואלי השולט בגישה ברמת ה-API, ומספק הגנה חזקה מפני זליגת נתונים שכללי חומת אש אינם יכולים לספק.
ספק ליישום צד שלישי גישת קריאה זמנית ומוגבלת בזמן לאובייקט פרטי ספציפי בדלי Cloud Storage.
צור URL חתום עבור האובייקט עם זמן תפוגה קצר (לדוגמה, 15 דקות) באמצעות חשבון שירות עם הרשאות קריאה.
למה: כתובות URL חתומות מעניקות גישה זמנית, לפי אובייקט, ללא צורך שיהיה לצד השלישי חשבון Google או הרשאות IAM. זו השיטה המאובטחת ביותר למקרה שימוש זה.
קוד GKE צריך לגשת בצורה מאובטחת לממשקי API של Google Cloud (לדוגמה, Pub/Sub) ללא אחסון מפתחות חשבון שירות כסודות Kubernetes.
אפשר Workload Identity באשכול GKE. צור Google Service Account (GSA) ו-Kubernetes Service Account (KSA). קשור את ה-KSA ל-GSA באמצעות מדיניות IAM. הגדר את הקוד להשתמש ב-KSA.
למה: Workload Identity היא הדרך המומלצת וחסרת המפתחות עבור יישומי GKE לאימות לשירותי Google Cloud. היא ממפה זהויות KSA לזהויות GSA, וזה מאובטח יותר מניהול וסיבוב קבצי מפתח.
מדיניות ארגונית דורשת שכל הנתונים בדלי Cloud Storage יוצפנו באמצעות מפתח הצפנה שהארגון שולט בו.
צור מפתח קריפטוגרפי ב-Cloud KMS. בעת יצירת דלי Cloud Storage, ציין מפתח זה כמפתח הצפנה מנוהל על ידי הלקוח (CMEK).
למה: CMEK מעניק לך שליטה על המפתח המשמש להצפנה, כולל סיבוב וביטול, תוך ניצול תשתית ההצפנה המנוהלת של Google.
אפשר לעובדים להשתמש באישור ה-Active Directory הקיים שלהם מתוך ה-premises כדי לגשת למשאבי Google Cloud.
הגדר את Cloud Identity ל-federate עם Active Directory באמצעות SAML 2.0. משתמשים מאמתים עם AD, אשר מאשרת את זהותם ל-Google Cloud לצורך גישה.
למה: פדרציה מאפשרת Single Sign-On (SSO) ומרכזת את ניהול הזהויות ב-IdP הקיים (Active Directory), ובכך נמנעת הצורך לנהל סט נפרד של סיסמאות ב-Google Cloud.
הענק לקבלן חיצוני גישה זמנית לפרויקט, שאמורה לפוג אוטומטית לאחר 30 יום.
הוסף את הקבלן כחבר IAM עם התפקיד הנדרש. הוסף תנאי לקישור התפקיד עם חותמת זמן תפוגה (`request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`).
למה: IAM Conditions מספקים בקרת גישה מבוססת תכונות. תנאים מבוססי זמן מושלמים לגישה זמנית, מכיוון שהם מבטלים הרשאות באופן אוטומטי ללא צורך בניקוי ידני.