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

پوشش جامع حوزه‌های آزمون

این ماتریس تمرینی جامع بر اساس حوزه‌های کلیدی و پرتکرار که در مصاحبه‌های مهندسی Cloud و DevOps در سطح سازمانی مورد پرسش قرار می‌گیرند، سازماندهی شده است.

• یکپارچه‌سازی و تحویل مداوم (CI/CD) (۲۰%): ساختاربندی پایپ‌لاین‌های Declarative در Jenkins، مدیریت Runnerهای چند مرحله‌ای در GitLab CI/CD، پیکربندی جریان‌های کاری قابل استفاده مجدد با GitHub Actions، اتوماسیون استقرار GitOps با استفاده از ArgoCD و تسلط بر استراتژی‌های Rollback.

• کانتینرسازی و ارکستراسیون (۱۸%): طراحی Dockerfileهای بهینه چند مرحله‌ای، مدیریت لایه‌های Image، شبکه کلاستر، مسیریابی سرویس، تعریف منابع سفارشی (CRD)، سیاست‌های چرخه حیات Pod و مسیریابی Ingress Controller در Kubernetes.

• زیرساخت به عنوان کد (IaC) و مدیریت پیکربندی (۱۵%): نوشتن وضعیت‌های ماژولار و بهینه در Terraform، مدیریت قفل وضعیت (State Locking)، ساختاربندی Stackهای AWS CloudFormation، پیکربندی‌های Inventory پویا و ارکستراسیون خودکار نودها از طریق Ansible Playbooks.

• مانیتورینگ، لاگینگ و مشاهده‌پذیری (۱۲%): ابزارگذاری متریک‌های اپلیکیشن با Prometheus، ایجاد پنل‌های مانیتورینگ پیشرفته PromQL در Grafana، مدیریت چرخه حیات ایندکس‌های متمرکز در ELK Stack و پیکربندی قوانین هشدار.

• رایانش ابری و معماری (۱۰%): طراحی معماری‌های با دسترسی بالا در ارائه‌دهندگان بزرگ (AWS, Azure, GCP)، پیکربندی Landing Zones، الگوهای بهینه‌سازی هزینه و استانداردهای امنیتی مدرن ابری.

• امنیت و انطباق (۸%): ادغام اسکن خودکار آسیب‌پذیری در مرحله Build (DevSecOps)، مدیریت متمرکز مجوزهای مدیریت هویت و دسترسی (IAM)، نقشه‌برداری کنترل دسترسی و برآورده کردن الزامات انطباق قانونی.

• شبکه‌سازی و توزیع بار (۵%): ایجاد بخش‌بندی‌های شبکه ایزوله، جداول مسیریابی VPC Peering، پیکربندی راهکارهای Load Balancing چند لایه و طراحی پیکربندی‌های پیش‌دستانه Auto Scaling.

• اسکریپت‌نویسی و اتوماسیون (۱۲%): نوشتن اسکریپت‌های تولیدی مستحکم و دفاعی با استفاده از Bash و Python، تجزیه پیکربندی‌های بدون ساختار، تعامل با ابزارهای CLI بومی ابری و اتوماسیون روتین‌های نگهداری سیستم.

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

موفقیت در مصاحبه DevOps یا مهندسی ابر، نیازمند چیزی فراتر از حفظ کردن تعاریف نام ابزارها است. مصاحبه‌کنندگان فنی به دنبال توانایی حل مسئله سیستماتیک، آگاهی معماری و درک روشن از بازیابی خطاهای زمان اجرا هستند. اگر مصاحبه‌کننده از شما بپرسد چگونه تداخل‌های State Lock را در یک پایپ‌لاین CI همزمان مدیریت کنید، یا چگونه یک Crash Loop Back-off را در یک کلاستر تولیدی Kubernetes ایزوله کنید، به سطحی از عمق عملی نیاز دارید که تئوری‌های انتزاعی نمی‌توانند ارائه دهند.

من این مخزن ۵۵۰ سوالی را دقیقاً برای بازسازی سناریوهای چالش‌برانگیزی طراحی کرده‌ام که در جلسات فنی زنده و ارزیابی‌های طراحی سیستم رخ می‌دهد. به جای سوالات ساده صحیح/غلط، تمرکز من کاملاً بر عیب‌یابی عملی، رفتار پیچیده اسکریپت‌ها، تحلیل خطاهای پیکربندی و گلوگاه‌های طراحی است. هر سوال تمرینی دارای یک توضیح معماری جامع است که جزئیات دلیل موفقیت یک انتخاب مهندسی خاص و دلیل شکست گزینه‌های دیگر را شرح می‌دهد. چه در حال بهینه کردن رزومه خود برای نقش Senior DevOps Engineer باشید، چه برای ارزیابی پلتفرم Release Manager آماده شوید و یا به دنبال منابع باکیفیت برای گذراندن مراحل معماری ابری در اولین تلاش باشید، این مجموعه جامع، سخت‌گیری عملی لازم برای قبولی آسان را فراهم می‌کند.

نمونه سوالات تمرینی

برای درک عمق و سبک توضیحات ارائه شده در این بانک سوالات، این سه نمونه پیش‌نمایش را بررسی کنید.

سوال ۱: کنترل ترافیک Kubernetes و مکانیسم‌های انتخاب Pod

یک مدیر کلاستر سرویس جدیدی را برای نمایش مجموعه‌ای از Workloadهای پردازش پس‌زمینه مستقر می‌کند. مانیفست Kubernetes Service بدون خطا ایجاد می‌شود، اما ترافیک اجرا هنگام انتقال به Endpoint به طور مداوم هشدارهای Network Timeout می‌دهد. بررسی سریع نشان می‌دهد که Podهای هدف سالم هستند، فعال‌اند و تست‌های Readiness Probe را کاملاً پاس می‌کنند. محتمل‌ترین علت ساختاری این رفتار چیست؟

• الف) مانیفست سرویس از پروتکل نسخه API قدیمی استفاده می‌کند که در آخرین اجرای کنترل‌کننده کلاستر منسوخ شده است.

• ب) تعریف Podها از یک قانون nodeSelector صریح استفاده می‌کند که اجرا را به نمونه‌های Worker فاقد رابط‌های شبکه مجبور می‌کند.

• ج) Label Selectorهای تعریف شده در سرویس، دقیقاً با برچسب‌های کلید-مقدار اختصاص یافته به متادیتای Podهای زیرین مطابقت ندارند.

• د) پادهای پس‌زمینه هدف با یک ویژگی clusterIP فعال پیکربندی شده‌اند که مستقیماً با پیکربندی‌های Gateway خارجی تداخل دارد.

• هـ) سیستم استقرار نتوانست در زمان اجرای اولیه، یک پیکربندی hostPort صریح را به مرز Runtime کانتینر متصل کند.

• و) سرویس به عنوان Headless Service پیکربندی شده است که مکانیسم‌های کشف مسیر DNS داخلی کلاستر را کاملاً متوقف می‌کند.

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

• پاسخ صحیح: ج

• دلیل صحیح بودن: سرویس‌های Kubernetes، بک‌اندهای Workload هدف خود را از طریق مطابقت Label Selector شناسایی می‌کنند. اگر حتی یک تفاوت تایپی کوچک بین بلوک‌های Selector در مانیفست سرویس و بلوک Labelهای تعریف شده در متادیتای استقرار Pod وجود داشته باشد، سرویس در نقشه‌برداری لیست Endpointها شکست می‌خورد و منجر به Timeoutهای فوری در اتصال می‌شود، در حالی که پادها کاملاً عملیاتی و سالم هستند.

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

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

  • گزینه ب نادرست است: اگر nodeSelector مشکل‌دار بود، پادها در وضعیت Pending باقی می‌ماندند، نه اینکه فعال باشند و تست‌های Readiness را پاس کنند.

  • گزینه د نادرست است: تخصیص clusterIP مکانیسم استاندارد و صحیح برای دسترسی داخلی سرویس است و تداخل مسیریابی ایجاد نمی‌کند.

  • گزینه هـ نادرست است: اتصال به hostPort در پلتفرم‌های کانتینری توصیه نمی‌شود و برای مسیرهای استاندارد Load Balancing بین سرویس و پاد ضروری نیست.

  • گزینه و نادرست است: سرویس‌های Headless رفتار مسیریابی را با بازگرداندن مستقیم بردارهای IP پاد از طریق DNS تغییر می‌دهند، اما اگر تعاریف درست باشند، باعث Timeout مسیریابی نمی‌شوند.

سوال ۲: قفل وضعیت همزمان و کنترل همزمانی در Terraform

دو تسک اتوماسیون مهندسی به طور همزمان یک چرخه استقرار را روی یک Workspace ماژولار Terraform از راه دور اجرا می‌کنند. اولین اجرای پایپ‌لاین، جدول وضعیت S3/DynamoDB را به درستی قفل می‌کند. Runner دوم بلافاصله با خطای execution state lock شکست می‌خورد. این سناریو چگونه باید حل شود تا انعطاف‌پذیری پایپ‌لاین اتوماسیون حفظ شده و وضعیت سیستم فاسد نشود؟

• الف) پارامترهای Runner پشتیبان را تغییر دهید تا آرگومان force-copy- را مستقیماً در رشته پیکربندی مقداردهی اولیه Backend اعمال کند.

• ب) یک مرحله تلاش مجدد (Retry) خودکار با استفاده از ویژگی lock-timeout- پیاده‌سازی کنید تا پروسه دوم منتظر بماند تا قفل اولیه به درستی آزاد شود.

• ج) محیط Runner محلی CI را پیکربندی کنید تا فایل متادیتای قفل رهگیری از راه دور را با استفاده از Triggerهای سفارشی Workspace حذف کند.

• د) پیکربندی زیرساخت Backend را به استفاده از سیستم فایل محلی تغییر دهید تا از ارزیابی‌های قفل دیتابیس راه دور اجتناب شود.

• هـ) توالی استقرار را درون یک اسکریپت جهانی قرار دهید که قبل از هر بلوک اجرا، یک روتین کامل State Override را اجرا کند.

• و) واحدهای ظرفیت خواندن/نوشتن (RCU/WCU) دیتابیس رهگیری را افزایش دهید تا تغییرات همزمان در یک سطر مسیر وضعیت را مدیریت کند.

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

• پاسخ صحیح: ب

• دلیل صحیح بودن: فلگ lock-timeout=duration به Terraform دستور می‌دهد که به جای شکست فوری در مواجهه با یک قفل فعال، برای یک بازه زمانی مشخص برای به‌دست آوردن قفل وضعیت تلاش مجدد کند. این امر به حلقه‌های اتوماسیون همپوشان اجازه می‌دهد تا به طور طبیعی منتظر پایان تغییرات کوتاه‌مدت بمانند بدون اینکه کل مجموعه ارکستراسیون با خطا مواجه شود.

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

  • گزینه الف نادرست است: پارامتر force-copy- سیستم‌های رهگیری ذخیره‌سازی وضعیت را در طول توالی‌های مقداردهی اولیه تغییر می‌دهد و قفل‌های اجرای همزمان را مدیریت نمی‌کند.

  • گزینه ج نادرست است: حذف دستی قفل در حالی که یک حلقه اجرای اصلی هنوز در حال کار است، می‌تواند باعث فساد فاجعه‌بار فایل وضعیت (Split-brain) شود.

  • گزینه د نادرست است: انتقال به ذخیره‌سازی سیستم فایل محلی، همکاری تیمی را مختل می‌کند، کنترل‌های حسابرسی (Auditing) را حذف می‌کند و آسیب‌پذیری‌های شدید Race Condition را بازمی‌گرداند.

  • گزینه هـ نادرست است: اجرای State Overrideهای دلخواه، گارد‌های اعتبارسنجی زیرساخت را به خطر انداخته و ریسک حذف اجزای فعال ابری را دارد.

  • گزینه و نادرست است: تداخل‌های قفل به این دلیل رخ می‌دهند که مقدار رکورد برای حفظ سازگاری مسدود شده است؛ تغییر محدودیت‌های پردازشی دیتابیس این منطق را تغییر نمی‌دهد.

سوال ۳: بیلد‌های خراب Dockerfile و ناکارآمدی‌های معماری کشینگ

یک تیم پلتفرم از یک پایپ‌لاین CI مشترک برای بیلد کردن Image کانتینر یک اپلیکیشن وب سازمانی استفاده می‌کند. Dockerfile حاوی خطی است که یک Lock file را کپی می‌کند، نصب پکیج‌ها را اجرا می‌کند و سپس بقیه فایل‌های اپلیکیشن را کپی می‌کند. یک توسعه‌دهنده متوجه می‌شود که حتی وقتی تغییرات متنی کوچکی در فایل‌های مستندات اپلیکیشن ایجاد می‌شود، مرحله دانلود پکیج‌ها در هر تکرار بیلد، چندین دقیقه زمان می‌برد. راه حل ساختاری چیست؟

• الف) پیکربندی runtime ذخیره‌سازی پیش‌فرض را با ارسال یک فلگ جایگزین برای Overlay Network Storage تغییر دهید.

• ب) اطمینان حاصل کنید که مرحله کپی کردن لیست تعاریف پکیج و اجرای دستورات نصب، قبل از کپی کردن فایل‌های گسترده‌تر سورس اپلیکیشن اتفاق بیفتد.

• ج) تمام دستورات پیکربندی مجزا را در یک اسکریپت یکپارچه (Monolithic) که خارج از محیط Runtime بیلد کانتینر اجرا می‌شود، تجمیع کنید.

• د) یک فایل Wrapper برای Entrypoint اضافه کنید که در طول عملیات بوت سیستم، درخت‌های دایرکتوری لایه‌های داخلی را کاملاً پاک کند.

• هـ) محیط Daemon زمان بیلد را مجدداً پیکربندی کنید تا با استفاده از آرگومان‌های کامپایلر سفارشی، مقادیر بررسی مراحل میانی را نادیده بگیرد.

• و) لایه نصب پکیج را با استفاده از یک فلگ حساب با دسترسی Root تایید نشده اجرا کنید تا دانلودهای مستقیم پس‌زمینه اجباری شوند.

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

• پاسخ صحیح: ب

• دلیل صحیح بودن: داکر از یک سیستم کش لایه‌ای استفاده می‌کند که در آن هر دستور یک خط کش ایجاد می‌کند. اگر هر لایه‌ای تغییری در فایل شناس کند، آن لایه و تمام لایه‌های بعدی باید کاملاً مجدداً ارزیابی شوند. با کپی کردن تنها مانیفست‌های رهگیری پکیج (مانند package.json یا requirements.txt) و اجرای دستورات نصب قبل از کپی کردن سورس‌کد که مرتباً تغییر می‌کند، سیستم هر زمان که وابستگی‌ها بدون تغییر بمانند، از لایه‌های نصب کش شده مجدداً استفاده می‌کند.

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

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

  • گزینه ج نادرست است: انتقال نصب‌ها به یک اسکریپت خارجی، قابلیت جابجایی (Portability) کانتینر را از بین می‌برد و اهداف محیط‌های بازتولیدپذیر استاندارد را مختل می‌کند.

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

  • گزینه هـ نادرست است: غیرفعال کردن مکانیسم‌های کش لایه وضعیت را بدتر می‌کند زیرا هر خط را مجبور می‌کند هر بار از ابتدا بیلد شود.

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

آنچه در انتظار شماست

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

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

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

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

• هر سوال دارای یک توضیح مفصل است

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

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