נבדק לאחרונה: מאי 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן TF-PRO בודק. קראו מלמעלה למטה, או דלגו לסעיף.
משאב זקוק למספר משתנה של בלוקים מקוננים זהים (לדוגמה, כללי ingress) המונעים על ידי רשימה/מפה.
השתמש בבלוק `dynamic` שה-`for_each` שלו מבצע איטרציה על האוסף; התייחס לכל אלמנט דרך איטרטור הבלוק (שם ברירת מחדל = תווית בלוק) בתוך `content {}`.
למה: בלוקים דינמיים מייצרים בלוקים מקוננים חוזרים ללא העתק-הדבק; האיטרטור שומר כל בלוק שנוצר מקושר לאלמנט המקור שלו.
צור משאב אחד עבור כל כניסה במפה של אובייקטים, עם מפתח יציב כך ששינוי סדר לעולם לא יכפה החלפה.
הגדר `for_each = var.objects` (מפה). השתמש ב-`each.key` עבור המפתח היציב וב-`each.value.<attr>` עבור שדות. הימנע מ-`count` כאן – שינויי אינדקס גורמים לתנודתיות.
למה: מפתחות מפה הם זהויות יציבות במצב; אינדקסי רשימה הם עמדות וזזים כאשר אלמנטים מתווספים/מוסרים.
החלט בין `count` לבין `for_each` עבור מספר מופעים.
השתמש ב-`for_each` כאשר למופעים יש זהויות מובחנות (סט/מפה); השתמש ב-`count` רק עבור N עותקים זהים, שאינם רגישים לסדר. העדף `for_each` לכל דבר שעשוי לגדול/להתכווץ.
למה: `for_each` מתייחס לפי מפתח (resource["key"]); `count` מתייחס לפי אינדקס (resource[0]) אשר משנה את הסדר בהוספות/מחיקות.
משתנה קלט הוא אובייקט שבו חלק מהתכונות הן אופציונליות וזקוקות לערכי ברירת מחדל.
הגדר את הטיפוס שלו כ-`object({ name = string, size = optional(number, 10) })`. `optional(type, default)` מספק את ערך ברירת המחדל כאשר הקורא משמיט את התכונה.
למה: `optional()` עם ערך ברירת מחדל שומר על קוד קצר עבור הקוראים תוך הבטחת ערך קונקרטי בהמשך הזרם – ללא טיפול ב-null בכל מקום.
אמת הנחה לגבי משאב לפני יישום, או הבטח תוצאה לאחר מכן.
השתמש ב-`lifecycle { precondition { ... } }` כדי לאמת קלטים לפני יצירה/עדכון, וב-`postcondition` כדי לאמת פלטים לאחר מכן. שניהם מקבלים `condition` + `error_message`.
למה: תנאים מותאמים אישית נכשלים במהירות עם הודעה ברורה במקום לייצר יישום שבור או שגיאה מבלבלת בהמשך הזרם.
משאב חייב להיווצר מחדש בכל פעם שמשאב או תכונה אחרים משתנים.
הוסף `lifecycle { replace_triggered_by = [aws_x.y.id] }`. כאשר הערך המוצלב משתנה, Terraform כופה החלפה של משאב זה.
למה: מבטא תלות החלפה באופן הצהרתי, ונמנע משימוש ידני ב-`-replace` על כל שינוי קשור.
החלפת משאב גורמת להשבתה מכיוון שהישן מושמד לפני שהחדש נוצר.
הגדר `lifecycle { create_before_destroy = true }` כך ש-Terraform יספק את ההחלפה תחילה, ואז ישמיד את הישן. וודא שמות ייחודיים/ללא התנגשויות קשות.
למה: החלפה ללא השבתה; אך היזהר מהתנגשויות שמות וממגבלות מכסה כאשר שניהם קיימים לזמן קצר.
דחה ערכי קלט לא חוקיים מוקדם (לדוגמה, סביבה שאינה dev/stage/prod).
הוסף בלוק `validation { condition = contains(["dev","stage","prod"], var.env), error_message = "..." }` למשתנה.
למה: תופס קלט שגוי בזמן התכנון עם הודעה קריאה במקום להיכשל עמוק בתוך קריאת ספק.
התייחס לערך שאולי לא קיים מבלי לקרוס את התוכנית.
השתמש ב-`try(local.maybe.value, "default")` כדי לחזור לערך ברירת מחדל במקרה של שגיאות, או ב-`can(expr)` כדי לקבל ערך בוליאני אם ביטוי מצליח.
למה: טיפול חינני בנתונים אופציונליים/בעלי צורה משתנה; מונע "Error: Unsupported attribute" על מפתחות חסרים.
המר רשימה למפה, או סנן/עצב אוסף עבור ארגומנט משאב.
השתמש בביטוי `for`: `{ for u in var.users : u.name => u.role if u.active }` (מפה) או `[for x in list : upper(x)]` (רשימה).
למה: ביטויי `for` הם הדרך המקובלת לעצב מחדש נתונים; סעיף ה-`if` מסנן, וצורת `k => v` בונה מפות.
משתנה או פלט מכילים סוד שאין להדפיס בפלט של תוכנית/יישום.
סמן את המשתנה `sensitive = true` (וגם פלטים). Terraform מסתיר אותו בפלט ה-CLI, אם כי הוא עדיין נשמר במצב.
למה: מונע חשיפה מקרית ביומנים/פלט CI; המצב עצמו עדיין חייב להיות מוגן (backend מוצפן, בקרת גישה).
נהל משאבים בשני אזורים/חשבונות בתוך תצורה אחת.
הצהר על ספקים עם כינויים (`provider "aws" { alias = "west" region = "us-west-2" }`) והגדר `provider = aws.west` על משאבים או העבר למודולים.
למה: כינויים מאפשרים לתצורה אחת למקד מופעי ספק מרובים; מודולים מקבלים אותם במפורש באמצעות ארגומנט ה-`providers`א.
תלות נסתרת (שאינה מבוטאת באמצעות הפניות) גורמת לבעיות סדר.
הוסף `depends_on = [aws_iam_role_policy.x]` כדי לכפות סדר. השתמש בזה במשורה – העדף תלויות עקיפות באמצעות הפניות לתכונות.
למה: `depends_on` מפורש מטפל בתלויות שהגרף אינו יכול להסיק, אך שימוש יתר יוצר תוכניות שמרניות ואיטיות יותר.
רנדר קובץ תצורה/נתוני משתמש מתבנית עם משתנים מובנים.
השתמש ב-`templatefile("${path.module}/tpl.tftpl", { items = local.items })`; התבנית משתמשת באינטרפולציה `%{ for }` / `${}`.
למה: `templatefile` שומר על עיבוד טהור/בזמן התכנון (בניגוד לספק התבניות המיושן) ותומך בלולאות/תנאים.
בנה רשימה שטוחה של כל שילוב (subnet, rule) כדי להזין ל-`for_each` יחיד.
השתמש ב-`setproduct(var.subnets, var.rules)` עבור המכפלה הקרטזית, או ב-`flatten([for ...])` כדי לקפל רשימות מקוננות לאחת.
למה: פונקציות אלו הופכות נתונים מקוננים לאוסף השטוח ובעל המפתחות הייחודיים הנדרש על ידי `for_each`.
מודול רישום משתנה ומשנה באופן בלתי צפוי תשתית באתחול הבא.
קבע גרסה עם `version = "~> 4.2"` (מודולי רישום בלבד). עבור מקורות Git, קבע תגית `?ref=v4.2.0`. הפעל `terraform init -upgrade` במכוון כדי להזיז קביעות גרסה.
למה: מודולים לא קבועים צפים לגרסה העדכנית ביותר; קיבוע גרסאות הופך שדרוגים למכוונים וניתנים לבדיקה.
מודול שורש זקוק לערך שנוצר עמוק בתוך מודול ילד.
חשוף אותו כ-`output` בילד, ואז התייחס ל-`module.child.output_name`. ערכים שאינם פלט אינם נגישים לקוראים.
למה: מודולים הם ארוזים; פלטים הם הדרך היחידה שבה נתונים עוברים את גבול המודול כלפי מעלה.
צור מופע של אותו מודול פעם אחת עבור כל צוות/סביבה ממפה.
הגדר `for_each` על בלוק המודול: `module "env" { for_each = var.envs; source = "./env"; name = each.key }`. התייחס ל-`module.env["prod"]`.
למה: `for_each` על מודולים מרחיב תבנית ללא העתק-הדבק של בלוקים; מפתחות מספקים כתובות יציבות.
מודול ילד חייב ליצור משאבים בספק שאינו ברירת מחדל (כינוי).
העבר ספקים במפורש: `module "x" { providers = { aws = aws.west } }`. הילד מצהיר על הספק ב-`required_providers` עם `configuration_aliases`.
למה: מודולים אינם יורשים ספקים עם כינויים באופן עקיף; מפת הספקים מחברת את כינוי ההורה לילד.
שינוי שם משאב או העברתו למודול יגרמו בדרך כלל להשמדתו וליצירתו מחדש.
הוסף בלוק `moved { from = aws_instance.old; to = module.compute.aws_instance.new }`. Terraform מעדכן כתובות מצב ללא השמדה.
למה: בלוקי `moved` הופכים ריפקטורים לבטוחים וניתנים לבדיקה בקוד, ומחליפים `terraform state mv` ידני.
מודול מונוליטי הפך מסורבל ומערבב דאגות רשת, מחשוב ונתונים.
פרק למודולי ילד ממוקדים וארגן אותם במודול שורש, תוך העברת פלטים של אחד כקלטים לשני. שמור על מודולים בעלי מטרה יחידה.
למה: קומפוזיציה משפרת שימוש חוזר ובדיקות; מודולים בעלי היקף מצומצם מתעדכנים ומתפתחים באופן עצמאי.
צרכנים מעבירים שילובי קלטים לא חוקיים למודול משותף.
הוסף בלוקי `validation` ו-`precondition` בתוך המודול כדי לאכוף חוזים, ותעד קלטים עם `description`.
למה: מודול הוא הבעלים של החוזה שלו; אימות פנימי מגן על כל קורא, לא רק על תצורת שורש אחת.
מודולים מקוננים עמוק מקשים על מעקב אחר זרימת נתונים והעברת ספקים.
שמור על קינון רדוד (1-2 רמות). העבר ספקים וקלטי מפתח במפורש בכל רמה; הימנע מהסתמכות על ירושה עקיפה עמוקה.
למה: עצים רדודים קלים יותר להבנה; קינון עמוק מגביר את מורכבות העברת הספקים וניפוק הפלטים.
פרסם מודול לשימוש חוזר ברישום הפרטי ופתח אותו מבלי לשבור קוראים.
תייג גרסאות עם semver (`v1.2.0`); שינויים שוברים בקלט/פלט מעלים את גרסת המייג׳ור. קוראים מקבעים עם אילוצי `~>`.
למה: גירסא סמנטית מאפשרת לצרכנים לאמץ תיקונים/תכונות בבטחה ולבחור באופן מכוון בשינויים שוברים.
בחר מאיפה לקבל מודול עבור רמת בשלות נתונה.
נתיבים מקומיים (`./modules/x`) עבור מודולים בתוך המאגר, Git (`git::...?ref=tag`) עבור מודולים משותפים אך לא מפורסמים, רישום (`namespace/name/provider`) עבור מודולים עם גרסאות/מפורסמים.
למה: סוג המקור תואם להיקף השיתוף; רק מקורות רישום תומכים בארגומנט `version` ופתרון אילוצים.
פלט מודול נושא סוד הנצרך על ידי השורש.
סמן את פלט המודול כ-`sensitive = true`. צריכתו בהקשר לא רגיש תגרום לשגיאה עד שתטפל בו גם כרגיש.
למה: רגישות מתפשטת על פני גבול המודול, ומונעת דליפה מקרית בפלט השורש.
סט משאבים קיים מבוסס `count` צריך להפוך ל-`for_each` מבלי להשמיד מופעים.
הוסף בלוקי `moved` הממפים כל אינדקס `resource[0]` לכתובת `resource["key"]` החדשה, ולאחר מכן עבור ל-`for_each`.
למה: בלוקי `moved` משנים את מפתח המצב מכתובות מבוססות מיקום לכתובות מבוססות זהות, ובכך נמנעים מהשמדה/יצירה מחדש.
שינית את שם המשאב בתצורה; התוכנית רוצה כעת להשמיד את הישן וליצור חדש.
העדף בלוק `moved` בתצורה. לתיקונים אד-הוק/CLI, השתמש ב-`terraform state mv aws_x.old aws_x.new` כדי להפנות מחדש את האובייקט הקיים.
למה: שניהם מעדכנים את כתובת המצב כך ש-Terraform רואה את האובייקט הקיים כמשאב ששונה שמו – ללא השמדה.
הכנס משאב קיים, שנוצר ידנית, לניהול תחת Terraform.
הוסף בלוק `import { to = aws_x.y; id = "i-123" }` והרץ `terraform plan -generate-config-out=gen.tf` כדי ליצור שלד תצורה, ולאחר מכן ערוך ויישם.
למה: ייבוא מונע תצורה ניתן לבדיקה ומייצר תצורת התחלה, בניגוד ל-`terraform import` האימפרטיבי הישן יותר.
הפסק לנהל משאב באמצעות Terraform אך השאר אותו פועל בענן.
הפעל `terraform state rm aws_x.y`. Terraform שוכח את האובייקט; הוא אינו מושמד. הסר גם את התצורה שלו כדי למנוע תוכנית יצירה מחדש.
למה: `state rm` מנתק מבלי למחוק – שימושי בעת העברת משאב לכלי/צוות אחר.
העבר מצב מ-backend מקומי ל-S3 (או ל-HCP Terraform).
הוסף/החלף את בלוק ה-`backend`/`cloud`, הפעל `terraform init` – Terraform מזהה את השינוי ומבקש להעביר מצב קיים ל-backend החדש.
למה: `init` מתזמר את ההעתקה; תשובה חיובית מעבירה את המצב בבטחה במקום להתחיל מריק.
שני מהנדסים מריצים apply על אותו מצב מרוחק בו-זמנית.
השתמש ב-backend התומך נעילה (S3+DynamoDB, HCP Terraform וכו'). Terraform רוכש נעילה לכל פעולה; ההרצה השנייה ממתינה או נכשלת.
למה: נעילה מונעת כתיבות מקבילות שעלולות להשחית את המצב. לעולם אל תבטל אותה סתם כך.
יישום שקרס השאיר נעילה ישנה ועכשיו כל הרצה חסומה.
וודא שאף פעולה לא פועלת בפועל, ואז `terraform force-unlock <LOCK_ID>`. השתמש במזהה מהודעת השגיאה.
למה: `force-unlock` מנקה נעילה יתומה; ביצועה בזמן שפעולה אמיתית פועלת מסכן את שחיתות המצב.
זהה סחף בין התצורה/מצב לתשתית האמיתית מבלי להציע שינויים.
הרץ `terraform plan -refresh-only` (או `apply -refresh-only` כדי לעדכן מצב). הוא מדווח על הבדלים מבלי לתכנן שינויים במשאבים.
למה: מפריד זיהוי סחף מתכנון שינויים – אתה רואה מה השתנה בענן לפני שתחליט ליישב.
משאב מתנהג בצורה לא תקינה ואתה רוצה ליצור אותו מחדש מבלי לערוך את התצורה.
הרץ `terraform apply -replace="aws_instance.web"`. זוהי ההחלפה המודרנית ל-`terraform taint` המיושן.
למה: `-replace` כופה על משאב אחד להיות מושמד וליצור מחדש ביישום הבא, באופן הצהרתי ב-CLI.
אתה מתפתה להשתמש ב-`-target` באופן שגרתי כדי להאיץ יישומים.
השתמש ב-`-target` רק להתאוששות משגיאות או תיקונים כירורגיים. הימנע ממנו כזרימת עבודה רגילה – הוא מייצר יישומים חלקיים ויכול לדלג על תלויות.
למה: מיקוד שגרתי מסתיר בעיות תלות ומניב מצב לא שלם; HashiCorp מתעד אותו ככלי יוצא דופן.
ספק העביר מרחבי שמות (לדוגמה, hashicorp/aws למזלג) והמצב מפנה לכתובת הישנה.
הרץ `terraform state replace-provider registry.terraform.io/hashicorp/aws registry.example.com/org/aws`.
למה: כותב מחדש הפניות לספקים במצב כך ש-init/plan יפתרו את המקור החדש מבלי ליצור מחדש משאבים.
תצורה אחת זקוקה לפלטים שנוצרו על ידי תצורה/מרחב עבודה אחר.
השתמש במקור הנתונים `terraform_remote_state` (או בפלטי הרצה של HCP Terraform) כדי לקרוא את פלטי מצב אחר במצב קריאה בלבד.
למה: משתף ערכים על פני גבולות מצב מבלי לשכפל משאבים; רק פלטים מיוצאים ניתנים לקריאה.
הגדרות backend (bucket, key) שונות לכל סביבה ואין לקודד אותן באופן קבוע.
השאר אותם מחוץ לבלוק `backend` והעבר אותם באתחול: `terraform init -backend-config=prod.hcl` (או `-backend-config="key=..."`).
למה: תצורה חלקית שומרת על תצורה אחת ניתנת לשימוש חוזר על פני סביבות תוך אספקת ערכי backend ספציפיים לסביבה באתחול.
אתה זקוק למצב נפרד עבור dev/stage/prod מתצורה אחת.
השתמש במרחבי עבודה של CLI (`terraform workspace new prod`) לבידוד קל משקל, או בתצורות שורש נפרדות/מרחבי עבודה של HCP לבידוד חזק יותר.
למה: לכל מרחב עבודה יש מצב משלו; התייחס ל-`terraform.workspace` כדי לשנות שמות/גדלים. לבידוד חזק, העדף backends/מרחבי עבודה נפרדים.
הימנע מאחסון מפתחות ענן ארוכי טווח במשתני מרחב העבודה של HCP Terraform.
הגדר אישורי ספק דינמיים: HCP Terraform משתמש ב-OIDC/זהות עומס עבודה כדי להשיג אישורים קצרי טווח מ-AWS/Azure/GCP/Vault לכל הרצה.
למה: מבטל סודות סטטיים; אישורים נוצרים בזמן אמת ופגים, ומצמצמים את רדיוס הפיצוץ.
אותם משתנים (תצורת ספק, תגיות) נחוצים על פני מרחבי עבודה רבים.
הגדר סט משתנים ויישם אותו על פרויקט או על מרחבי עבודה נבחרים. משתנים ברמת מרחב העבודה עוקפים ערכי סט משתנים.
למה: סטי משתנים מונעים שכפול תצורה משותפת; עדיפות (מרחב עבודה > סט) מאפשרת למרחב עבודה לעקוף בעת הצורך.
אכוף מעקות בטיחות (ללא S3 ציבורי, תגיות נדרשות) בכל הרצה.
צרף סט מדיניות Sentinel או OPA. הגדר רמת אכיפה: ייעוצית (אזהרה), חובה רכה (עקיפה באישור), או חובה קשה (חסימה).
למה: מדיניות כקוד שומרת על הרצות באופן מרכזי; רמות אכיפה מאזנות קפדנות מול גמישות תפעולית.
שלב בדיקה חיצונית (אומדן עלות, סריקת אבטחה) לתוך צינור ההרצה.
הגדר משימת הרצה בשלב (טרום-תכנון, לאחר-תכנון, טרום-יישום). HCP Terraform קורא לשירות החיצוני ומגביל את ההרצה על פי תוצאתה.
למה: משימות הרצה מרחיבות את הצינור עם בדיקות צד שלישי ללא צורך בהגדרת CI מותאמת אישית.
בחר כיצד מופעלות הרצות עבור מרחב עבודה.
מונע VCS (קומית/PR מפעיל תוכנית), מונע CLI (`terraform plan/apply` מול המרוחק), או מונע API (תצורה שהועלתה). בחר לפי זרימת עבודה של הצוות.
למה: מונע VCS מתאים ל-GitOps; מונע CLI מתאים לאיטרציה מקומית; מונע API מתאים לצינורות מותאמים אישית. הם מוציאים זה את זה לכל מרחב עבודה.
הענק לצוות גישת כתיבה למרחבי עבודה של staging אך גישת קריאה בלבד לייצור.
הגדר היקף הרשאות ברמת הארגון/פרויקט/מרחב עבודה: הקצה גישת צוות (קריאה/תכנון/כתיבה/אדמין) לכל פרויקט או מרחב עבודה; השתמש בקיבוץ פרויקטים לניהול בקנה מידה.
למה: הרשאות גרנולריות ומוגדרות היקף אוכפות את עקרון הפריבילגיה המינימלית; הענקות ברמת הפרויקט מפחיתות את הניהול לכל מרחב עבודה.
יישום של מרחב עבודה של רשת צריך להוסיף באופן אוטומטי הרצה לתור במרחבי עבודה תלויים של יישומים.
הגדר טריגר הרצה: מרחב העבודה במורד הזרם נרשם למרחב העבודה במעלה הזרם; יישום מוצלח מוסיף את ההרצה במורד הזרם לתור.
למה: טריגרי הרצה משרישרים מרחבי עבודה תלויים כך ששינויי תשתית משותפים מתפשטים בסדר.
אפשר למשתמשים שאינם Terraform לספק תשתית סטנדרטית באמצעות טופס.
פרסם מודול ללא קוד ברישום הפרטי; משתמשים יוצרים מופע שלו דרך ממשק המשתמש, ומספקים רק קלטים – ללא כתיבת HCL.
למה: מודולים ללא קוד ממשיכים את הדמוקרטיזציה של אספקת שירות עצמי תוך שמירה על התצורה הבסיסית מנוהלת ומסופקת בגרסאות.
שתף מודולים וספקים מאושרים ברחבי הארגון.
פרסם לרישום הפרטי של HCP Terraform; צרכנים מתייחסים ל-`app.terraform.io/org/name/provider` עם אילוצי גרסה.
למה: רישום פרטי מרכז גילוי, גרסאות וניהול של מודולים פנימיים.
ארגן עשרות מרחבי עבודה לפי צוות/יישום עבור הרשאות וסטי משתנים.
קבוץ מרחבי עבודה לפרויקטים; יישם הרשאות צוות וסטי משתנים ברמת הפרויקט.
למה: פרויקטים מרחיבים את הניהול – אתה מנהל גישה ותצורה משותפת לכל פרויקט במקום לכל מרחב עבודה.
זהה באופן רציף מתי הייצור סוטה מהמצב המוגדר.
הפעל הערכות תקינות (זיהוי סחף / אימות רציף) במרחב העבודה; HCP Terraform מרענן ומדווח מעת לעת על סחף ועל אימותים שנכשלו.
למה: הערכות אוטומטיות חושפות סחף ותנאים שלא התקיימו בין יישומים, לפני שהם גורמים לתקלות.
HCP Terraform חייב להגיע לתשתית בתוך רשת פרטית ללא כניסה ציבורית.
פרוס סוכני HCP Terraform ברשת הפרטית והקצה את מרחב העבודה למאגר סוכנים; הרצות יבוצעו דרך הסוכן.
למה: סוכנים מאפשרים ל-HCP Terraform לפעול מול סביבות פרטיות/מבודדות אוויר מבלי לחשוף אותן לציבור.
יישום שגוי השחית את המצב ואתה צריך לשחזר.
HCP Terraform שומר מצב עם גרסאות; חזור לגרסת מצב קודמת מממשק המשתמש/API של מרחב העבודה ותכנן מחדש.
למה: גירסאות מצב מובנות מספקות נקודות שחזור מבלי שתצטרך לנהל בעצמך את תצלומי ה-backend.