آموزش بیش از ۵۰۰ سوال مصاحبه Terraform همراه با پاسخ‌ها ۲۰۲۶ - آخرین آپدیت

در اینجا یک توضیحات دوره بهینه‌شده و نوشته شده توسط انسان آورده شده است که برای رتبه بندی مناسب در جستجوی گوگل و یودمی برای آمادگی مصاحبه Terraform طراحی شده است. لحن آن طبیعی، حرفه‌ای و به دور از کلیشه‌های AI است.

پوشش تفصیلی دامنه‌های آزمون

این مخزن تست‌های تمرینی دقیقاً به گونه‌ای ساختار یافته است که سناریوهای معماری، عملیاتی و اتوماسیونی موجود در محیط‌های عملیاتی (Production) و مصاحبه‌های فنی سخت‌گیرانه DevOps را منعکس کند.

• دانش هسته‌ای Terraform (۲۰٪): تسلط بر سینتکس زبان پیکربندی HashiCorp (HCL)، تعریف Providerها، بلوک‌های Declarative Resource، متغیرهای ورودی/خروجی، مقادیر Local و کالبد ساختاری فایل‌های State.

• ماژول‌های Terraform و مدیریت State (۱۸٪): طراحی اجزای زیرساختی قابل استفاده مجدد از طریق ماژول‌ها، پیکربندی Backendهای ذخیره‌سازی State از راه دور (S3, Azure Blob, GCS)، دینامیک‌های قفل State و مدیریت Drift با دستورات State.

• اتوماسیون زیرساخت و CI/CD (۱۵٪): بررسی عمیق مکانیسم‌های عملیاتی Execution Planها، جریان‌های کاری اتوماسیون، ادغام IaC در خط لوله‌های GitOps (GitHub Actions, GitLab CI, Jenkins) و مدیریت Concurrency در اجراهای خودکار.

• تدارک و استقرار ابری (۱۲٪): ارکستراسیون منابع در هایپراسکالرهای بزرگ (AWS, Azure, Google Cloud)، مدیریت چیدمان‌های چندمنطقه‌ای (Multi-region)، وابستگی‌های بین-ابری و ساخت انتزاع‌های مستقل از Provider.

• امنیت و مدیریت دسترسی (۱۰٪): مقاوم‌سازی استقرارهای IaC، اعمال کنترل‌های دسترسی Least-Privilege، پیکربندی نقش‌های IAM برای محیط‌های زمان اجرا، مدیریت دینامیک Secretها (HashiCorp Vault, AWS Secrets Manager) و جابجایی امن State.

• مفاهیم پیشرفته Terraform (۸٪): استفاده از Meta-arguments پیشرفته (lifecycle blocks, depends_on, for_each, count)، خواندن محیط‌های دینامیک با Data Sources و اعمال Compliance به عنوان کد با استفاده از Sentinel یا Open Policy Agent (OPA).

• ابزارها و یکپارچه‌سازهای Terraform (۷٪): مقیاس‌بندی همکاری با Terraform Cloud و Terraform Enterprise، تنظیم Triggerهای سیستم کنترل نسخه (VCS)، محیط‌های کاری تیمی (Workspaces)، رجیستری‌های خصوصی ماژول و ابزارهای GitOps مانند Atlantis.

• عیب‌یابی و بهینه‌سازی (۱۰٪): تکنیک‌های پیشرفته دیباگ (TF_LOG)، ایزوله کردن مشکلات Concurrency، بهینه‌سازی عملکرد (Parallelism, Targeting)، ابزارهای تخمین هزینه و پاک‌سازی منابع رها شده.

درباره این دوره

به دست آوردن نقش DevOps، معماری ابری یا SRE نیازمند درک عمیق از مکانیسم‌های اجرای زیرساخت به عنوان کد (IaC) است. زیرساخت‌های در حال رشد نیازمند تنظیماتی هستند که پیش‌بینی‌پذیر، ایمن، قابل استفاده مجدد و امن باشند. من این بانک سوالات جامع را برای پر کردن شکاف بین اجرای دستورات پایه زیرساختی به صورت محلی و پاسخ به چالش‌های معماری سطح بالا و عملیاتی که در مصاحبه‌های فنی نخبه مطرح می‌شود، ایجاد کرده‌ام.

این منبع با دارای ۵۵۰ سوال سناریویی سخت‌گیرانه و اورجینال، از جستجوهای ساده تعاریف پرهیز کرده است. در عوض، شما را در دل تنگناهای عملیاتی قرار می‌دهد: فایل‌های State خراب، Race Conditionها در خط لوله‌های CI/CD، ساختارهای پیچیده ماژول، بلوک‌های شبکه چند-ابری و محدودیت‌های سختگیرانه Policy-as-code. هر سوال با یک تحلیل جامع همراه است که منطق دقیق پشت رویکرد صحیح و دلیل ناکافی بودن گزینه‌های دیگر در محیط‌های سازمانی را توضیح می‌دهد. اگر می‌خواهید غرایز عملیاتی خود را اصلاح کنید، از زیرساخت در برابر Drift محافظت کنید یا استراتژی‌های استقرار چند-ابری خود را برای قبولی در اولین تلاش در مصاحبه فنی تایید کنید، این مخزن تمرین واقع‌گرایانه لازم را به شما می‌دهد.

پیش‌نمایش نمونه سوالات تمرینی

برای ارزیابی عمق مهندسی و شفافیت ساختاری این مطالب تمرینی، این سه نمونه سوال متمرکز بر محیط عملیاتی را بررسی کنید.

سوال ۱: حل تداخلات پیچیده Concurrency و بازنویسی State در Backendهای مشترک از راه دور

یک تیم پلتفرم از Backend آمازون S3 با پیکربندی صریح جدول DynamoDB برای مدیریت State از راه دور استفاده می‌کند. در طول یک استقرار خودکار با فرکانس بالا، یک GitOps runner به طور غیرمنتظره در اواسط اجرای مرحله تغییر منبع شکست می‌خورد. تغییرات دستی بعدی بلافاصله با خطایی مواجه می‌شوند که نشان می‌دهد فایل State قفل شده است. کدام مرحله عملیاتی این مشکل را بدون قرار دادن State در معرض فساد داده‌ها یا بازنویسی‌های همزمان حل می‌کند؟

• الف) فایل .terraform.lock.hcl را از مخزن محلی حذف کرده و یک مقداردهی اولیه فوری اجبار کنید.

• ب) دستور terraform force-unlock را با ارائه Lock ID منحصربه‌فرد استخراج شده از خروجی خطا اجرا کنید.

• ج) مستقیماً به کنسول AWS DynamoDB دسترسی پیدا کرده و تمام پارتیشن‌های رکورد حاوی تعاریف ارجاع به مسیر S3 هدف را پاک کنید.

• د) فلگ lock=false- را مستقیماً به آرگومان‌های اجرا در توالی apply بعدی اضافه کنید تا قفل فعال را به صورت ایمن نادیده بگیرید.

• ه) فایل پیکربندی محلی را تغییر دهید تا ارجاع مسیر backend را تغییر داده و مقداردهی اولیه یک پارتیشن State جایگزین و تمیز را اجبار کنید.

• و) مرحله تنظیمات اولیه را با استفاده از فلگ اجرای migrate-state- مجدداً اجرا کنید تا قفل‌های فعال سمت سرور به طور خودکار پاک شوند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل صحت: هنگام استفاده از S3 همراه با DynamoDB، Terraform یک رکورد قفل در جدول پایگاه داده می‌نویسد تا از تغییرات همزمان جلوگیری کند. اگر فرآیندی قبل از اتمام کار خود کرش کند، قفل فعال می‌ماند. اجرای terraform force-unlock <LOCK_ID> این قفل را پس از تایید اینکه هیچ runner خودکار دیگری فعالانه در حال تغییر آن زیرساخت نیست، به صورت ایمن حذف می‌کند.

• دلیل نادرست بودن گزینه‌های دیگر:

  • گزینه الف نادرست است: فایل .terraform.lock.hcl صرفاً نسخه‌های Provider و هش‌های وابستگی را مدیریت می‌کند و کنترلی روی فلگ‌های قفل State در زمان اجرا ندارد.

  • گزینه ج نادرست است: پاک‌سازی دستی جداول ریسک حذف تنظیمات حیاتی Schema یا پاک کردن قفل‌های فعال غیرمرتبط متعلق به سیستم‌های دیگر را دارد.

  • گزینه د نادرست است: استفاده از lock=false- به سیستم می‌گوید بررسی‌های ایمنی را کاملاً نادیده بگیرد، که در صورت اجرای فرآیند دیگر، ریسک شدید فساد State را ایجاد می‌کند.

  • گزینه ه نادرست است: تغییر مسیر State باعث تقسیم ردیابی محیط شما شده و منابع رها شده‌ای ایجاد می‌کند که همچنان در حساب‌های ابری شما در حال اجرا هستند.

  • گزینه و نادرست است: فلگ مهاجرت داده‌های ردیابی موجود را بین Backendهای مختلف جابجا می‌کند و قفل‌های فعال یک نشست خراب را حذف نمی‌کند.

سوال ۲: تعریف منابع دینامیک پیشرفته و فیلتر کردن مجموعه‌های ماژول

یک معمار نیاز دارد آرایه‌ای از نمونه‌های Compute را در چندین محیط مستقر کند. پیکربندی ورودی به صورت یک Map پیچیده از اشیاء شامل پیکربندی‌های مختلف است. منبع باید به طور انتخابی نمونه‌هایی را که در آن‌ها ویژگی صریح محیط با مقدار "development" مطابقت دارد، حذف کند. کدام ترکیب از ویژگی‌های HCL این هدف را به صورت تمیز و در عین حال با حفظ آدرس‌دهی شفاف منابع برآورده می‌کند؟

• الف) از meta-argument استاندارد count که مستقیماً به طول آرایه متغیر متصل شده است به همراه یک بلوک شرطی ternary صریح استفاده کنید.

• ب) از یک عبارت for_each برای ارزیابی یک Map Projection فیلتر شده استفاده کنید که یک عبارت شرطی if را مستقیماً در بلوک منبع به کار می‌برد.

• ج) از یک تعریف بلوک dynamic حاوی یک فیلتر داده داخلی استفاده کنید که رکوردهای هدف را در مرحله تولید اولیه حذف می‌کند.

• د) یک ساختار حلقه تو در تو در یک بلوک local values با استفاده از چندین Map متغیر مستقل تعریف کنید تا ایندکس آرایه را از ابتدا بازسازی کند.

• ه) بلوک منبع را در یک پیکربندی lifecycle خارجی با استفاده از آرگومان precondition قرار دهید تا رندرینگ در طول ارزیابی نادیده گرفته شود.

• و) برای هر کلاس پیکربندی مجزا، Provider Aliasهای جداگانه مستقر کنید تا منابع توسعه را کاملاً جدا کنید.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل صحت: استفاده از for_each همراه با یک عبارت Map فیلتر شده ({ for k, v in var.instances : k => v if v.environment != "development" }) راهی تمیز برای ساخت دینامیک منابع فراهم می‌کند. این روش موارد unwanted را قبل از شروع استقرار حذف کرده و آدرس‌های منابع را به جای ایندکس‌های عددی شکننده، به کلیدهای رشته‌ای شفاف متصل نگه می‌دارد.

• دلیل نادرست بودن گزینه‌های دیگر:

  • گزینه الف نادرست است: استفاده از count باعث ایجاد مسیرهای منبع با ایندکس عددی می‌شود (مانند [0], [1]). اگر بعداً عنصری را از وسط آرایه حذف کنید، Terraform شماره ایندکس‌ها را جابجا می‌کند و باعث تخریب و بازسازی ناخواسته منابع غیرمرتبط می‌شود.

  • گزینه ج نادرست است: بلوک‌های Dynamic برای تولید بلوک‌های ساختاری تو در تو در داخل یک منبع واحد استفاده می‌شوند؛ آن‌ها نمی‌توانند تعداد ایجاد در سطح بالای خود منبع را کنترل کنند.

  • گزینه د نادرست است: پردازش Mapها در local values کار می‌کند، اما در مقایسه با نوشتن یک فیلتر inline تمیز مستقیماً در بلوک منبع، سربار ساختاری آشفته‌ای ایجاد می‌کند.

  • گزینه ه نادرست است: یک بلوک precondition در صورت عدم برآورده شدن معیارها، خطای اجرای سخت (Hard Error) می‌دهد؛ نمی‌توان از آن برای نادیده گرفتن نرم عناصر خاص در یک حلقه منبع استفاده کرد.

  • گزینه و نادرست است: Provider Aliasها نقاط انتهایی ابری و مرزهای احراز هویت مجزا را مدیریت می‌کنند و برای فیلتر کردن Mapهای ورودی ساختاری در نظر گرفته نشده‌اند.

سوال ۳: اعمال متریک‌های ایمنی استقرار و تغییرناپذیری از طریق پیکربندی‌های Lifecycle

یک مهندس DevOps می‌خواهد پیکربندی یک کلاستر دیتابیس Production را به‌روزرسانی کند. به دلیل محدودیت‌های API ابری، این تغییر مستلزم تخریب و بازسازی مجدد بلوک منبع است. مهندس باید اطمینان حاصل کند که کلاستر دیتابیس جدید کاملاً بالا آمده، فعال و پذیرای ترافیک است، پیش از آنکه کلاستر دیتابیس قدیمی تخریب شود. کدام انتخاب طراحی این الگو را به صورت ایمن اجرا می‌کند؟

• الف) یک آرایه depends_on سفارشی را در تعریف ماژول تزریق کنید که به یک منبع تایمر تأخیری ارجاع می‌دهد.

• ب) یک بلوک lifecycle در پیکربندی منبع اضافه کنید که حاوی قانون create_before_destroy = true باشد.

• ج) یک آرایه خارجی ignore_changes تعریف کنید که مستقیماً به ویژگی‌های خاصی که بازسازی منبع را اجبار می‌کنند اشاره کند.

• د) یک قانون Sentinel policy پیکربندی کنید که موتور اجرا را مجبور کند بین مرحله plan و apply متوقف شود.

• ه) plan را با استفاده از فلگ صریح target- اجرا کنید که ابتدا منحصراً روی عناصر منبع جدید تعریف شده متمرکز باشد.

• و) متغیر TF_LOG را روی حالت هشدار تعاملی تنظیم کنید تا وظایف حذف را به صورت دستی متوقف کنید.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل صحت: به طور پیش‌فرض، وقتی تغییری باعث بازسازی می‌شود، Terraform ابتدا منبع را تخریب کرده و سپس جایگزین آن را می‌سازد. اضافه کردن create_before_destroy = true در بلوک lifecycle این ترتیب را برعکس می‌کند و تضمین می‌کند که منبع جدید با موفقیت ساخته شود پیش از آنکه منبع قدیمی حذف گردد، که از قطعی سرویس (Downtime) جلوگیری می‌کند.

• دلیل نادرست بودن گزینه‌های دیگر:

  • گزینه الف نادرست است: meta-argument {depends_on} ترتیب اجرا را بین منابع مختلف تعیین می‌کند؛ نمی‌تواند رفتار چرخه عمر داخلی یک منبع واحد را تغییر دهد.

  • گزینه ج نادرست است: استفاده از ignore_changes ردیابی تغییرات را کاملاً متوقف می‌کند، به این معنی که به‌روزرسانی‌های پیکربندی دیتابیس هرگز مستقر نخواهند شد.

  • گزینه د نادرست است: سیاست‌های Sentinel قوانین انطباق را با plan شما بررسی می‌کنند؛ آن‌ها نمی‌توانند توالی اجرای زمان واقعی مراحل چرخه عمر منبع را تنظیم کنند.

  • گزینه ه نادرست است: استفاده از target- منابع خاصی را برای دیباگ ایزوله می‌کند اما برای استفاده عمومی به شدت توصیه نمی‌شود زیرا می‌تواند وابستگی‌ها را بشکند و فایل‌های State را ناسازگار کند.

  • گزینه و نادرست است: متغیر TF_LOG فقط سطح جزئیات خروجی لاگ‌ها را مدیریت می‌کند و هیچ کنترل عملیاتی روی مراحل ایجاد منبع ندارد.

آنچه انتظار داشته باشید

• به تست‌های سوالات مصاحبه خوش آمدید تا به شما در آمادگی برای آزمون تمرینی سوالات مصاحبه Terraform کمک کنیم.

• می‌توانید هر تعداد بار که بخواهید در آزمون‌ها شرکت کنید.

• این یک بانک سوالات اورجینال و عظیم است.

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح دقیق است.

• سازگار با موبایل از طریق اپلیکیشن یودمی.

امیدواریم تا الان متقاعد شده باشید! و سوالات بسیار بیشتری در داخل دوره وجود دارد.