فيس كويز?فيس كويز
ابحث عن اختبار
الوظيفة:
دعم فني IT
المستوى:
خبير
عدد الأسئلة:
١٢ سؤالاً
الزمن:
٦ دقائق

أسئلة مقابلة مدير IT ومسؤول شبكات خبير

قرارات ومواقف صعبة يُسأل عنها الخبراء في مقابلات وظيفة دعم فني IT: DNS وDHCP، وWindows وإدارة المستخدمين، وأساسيات أمن المعلومات، وأساسيات الشبكات، والتعامل مع المستخدمين وتذاكر الدعم، وتشخيص الأعطال. في آخرها تقرير بنقاط ضعفك.

المهارات: DNS وDHCP، Windows وإدارة المستخدمين، تشخيص الأعطال، أساسيات أمن المعلومات، أساسيات الشبكات، التعامل مع المستخدمين وتذاكر الدعم

تعليمات: لكل سؤال إجابة صحيحة واحدة. إن لم تعرف الإجابة فاختر «لا أعرف»، وسيدلّك التقرير على ما تراجعه.

السؤال الأول: ستنقل الموقع الإلكتروني العام للشركة إلى خادم بعنوان IP جديد يوم الخميس، وقيمة TTL لسجل A الخاص به حالياً 86400 ثانية، أي يوم كامل. تريد أن يصل الزوار إلى العنوان الجديد بأسرع وقت ممكن بعد التغيير. ما الإجراء الصحيح؟

اختر إجابتك لتبدأ الاختبار

كل الأسئلة مع الإجابات (١٢ سؤالاً)

جرّب المقابلة أولاً، ثم افتح الإجابات لتراجعها مع الشرح.

  1. ١. ستنقل الموقع الإلكتروني العام للشركة إلى خادم بعنوان IP جديد يوم الخميس، وقيمة TTL لسجل A الخاص به حالياً 86400 ثانية، أي يوم كامل. تريد أن يصل الزوار إلى العنوان الجديد بأسرع وقت ممكن بعد التغيير. ما الإجراء الصحيح؟

    • خفّض TTL إلى بضع دقائق قبل النقل بيوم على الأقل، ثم غيّر العنوان وأعِد TTL إلى قيمته لاحقاً
    • ارفع TTL إلى أسبوع، كي تستعلم الخوادم الوسيطة من الخادم الأصلي بتكرار أكبر بعد التغيير
    • خفّض TTL إلى بضع دقائق وغيّر العنوان في اللحظة نفسها يوم النقل، فيلتقط الجميع التغيير فوراً
    • غيّر العنوان يوم النقل، ثم امسح ذاكرة DNS المؤقتة على خوادم الشركة وجميع أجهزة موظفيها

    الشرح: الخوادم الوسيطة تحتفظ بالسجل طوال قيمة TTL التي استلمته بها، لذا يجب خفضها قبل التغيير بمدة لا تقل عن قيمتها القديمة. يخطئ كثيرون بخفضها لحظة التغيير، فتبقى النسخ المخزنة سابقاً صالحة يوماً كاملاً، ومسح ذاكرة أجهزة الشركة لا يؤثر في الزوار من الخارج.

  2. ٢. لديك خادما DHCP بنظام Windows Server في الموقع نفسه، وتريد أن يخدما النطاق scope نفسه بحيث تُزامَن عقود الإيجار leases بينهما، ويستطيع أي منهما خدمة جميع العملاء إذا توقف الآخر، دون استخدام تخزين مشترك. ما الحل المناسب؟

    • تفعيل DHCP Failover بين الخادمين بوضع Load Balance أو Hot Standby
    • إنشاء النطاق الكامل نفسه على كلا الخادمين بشكل مستقل مع تفعيل كشف التعارض conflict detection
    • تقسيم النطاق بين الخادمين بنسبة 80/20 split scope ليوزّع كل منهما جزءاً من العناوين
    • إضافة عنواني الخادمين إلى ip helper-address على الموجّه كي يتلقى كلاهما طلبات العملاء

    الشرح: ميزة DHCP Failover المتاحة منذ Windows Server 2012 تُزامن عقود الإيجار بين خادمين، فيتولى أحدهما النطاق كاملاً عند توقف الآخر. أما تقسيم النطاق 80/20 فلا يُزامن أي بيانات ويترك لكل خادم جزءاً من العناوين فقط، وتكرار النطاق نفسه دون مزامنة يعرّض الشبكة لتوزيع عناوين مكررة.

  3. ٣. أزلت موظفاً من مجموعة أمان تمنحه الوصول إلى مجلد مشترك على خادم ملفات، وتأكدت من وصول التغيير إلى جميع وحدات التحكم بالمجال. لكن الموظف ما زال يفتح المجلد بعد ساعات دون أن يسجّل خروجه من جهازه. ما السبب الأرجح؟

    • عضويته القديمة ما زالت في تذكرة Kerberos ورمز الوصول access token الصادرين عند تسجيل دخوله
    • خادم الملفات يقرأ قوائم ACL من القرص عند الإقلاع فقط، فيلزم إعادة تشغيله لتطبيق التغيير
    • تغيير عضوية المجموعات لا يُطبَّق إلا في دورة تحديث سياسات المجموعة Group Policy التالية على جهازه
    • صلاحيات المشاركة Share تتقدم على صلاحيات NTFS، فتبقى صلاحيته على المجلد المشترك سارية

    الشرح: يبني Windows رمز الوصول من المجموعات الواردة في تذكرة Kerberos عند تسجيل الدخول، وتصل صلاحية التذاكر افتراضياً إلى عشر ساعات، لذا يظهر التغيير عادةً بعد تسجيل الدخول من جديد. يربط كثيرون الأمر بتحديث Group Policy أو بتكرار AD، وكلاهما لا يغيّر رمزاً صدر مسبقاً.

  4. ٤. سياسة كلمات المرور في المجال تشترط 8 أحرف على الأقل، وطلبت الإدارة اشتراط 15 حرفاً لحسابات مسؤولي النظام فقط، دون تغيير السياسة لبقية الموظفين وضمن المجال نفسه. ما الطريقة الصحيحة؟

    • إنشاء GPO بسياسة كلمات مرور 15 حرفاً وربطه بالوحدة التنظيمية OU التي تضم حسابات المسؤولين
    • إنشاء سياسة كلمات مرور دقيقة Fine-Grained Password Policy وتطبيقها على مجموعة المسؤولين
    • ضبط سياسة الأمان المحلية Local Security Policy على أجهزة المسؤولين لتشترط 15 حرفاً
    • تعديل Default Domain Policy إلى 15 حرفاً وتفعيل Block Inheritance على وحدات الموظفين التنظيمية

    الشرح: سياسة كلمات المرور لحسابات المجال تُؤخذ من GPO المرتبط بالمجال فقط، ولا يغيّرها ربط GPO بوحدة تنظيمية أو حظر التوريث، لذا فالحل المخصص هو كائن PSO يُطبَّق على مستخدمين أو مجموعات. يقع كثيرون في خطأ ربط السياسة بالوحدة التنظيمية، فلا تؤثر إلا في الحسابات المحلية للأجهزة الموجودة فيها.

  5. ٥. اتصل بك موظف يقول إن ملفات جهازه والمجلد الشبكي الموصول به بدأت تتحول إلى امتداد غريب، وظهرت على الشاشة رسالة تطلب فدية. ما أول إجراء تتخذه؟

    • عزل الجهاز عن الشبكة فوراً مع إبقائه يعمل، وإبلاغ فريق الاستجابة للحوادث
    • استرجاع الملفات فوراً من آخر نسخة احتياطية إلى المجلد الشبكي لتقليل مدة توقف العمل
    • إطفاء الجهاز فوراً وإعادة تثبيت Windows عليه من الصفر، ثم إعادته إلى الموظف ليكمل عمله
    • إبقاء الجهاز متصلاً بالشبكة وتشغيل فحص كامل بمضاد الفيروسات بعد تحديث تعريفاته

    الشرح: الأولوية لإيقاف انتشار التشفير إلى المجلدات الشبكية والأجهزة الأخرى، وإبقاء الجهاز يعمل يحفظ أدلة الذاكرة اللازمة للتحقيق. الاسترجاع قبل العزل يجعل الملفات المسترجعة تُشفَّر من جديد، وإعادة التثبيت تمحو الأدلة قبل معرفة نطاق الهجوم.

  6. ٦. عُيّنت قائداً لفريق الدعم الفني، فوجدت أن جميع أعضاء المستوى الأول يستخدمون حسابات أعضاء في مجموعة Domain Admins، مع أن عملهم يقتصر على إعادة تعيين كلمات المرور وفك قفل الحسابات. ما أفضل إجراء؟

    • إبقاؤهم في Domain Admins مع فرض المصادقة متعددة العوامل MFA ومراجعة سجلات دخولهم أسبوعياً
    • نقلهم إلى المجموعة المدمجة Account Operators لأنها أقل صلاحية من Domain Admins وتكفي لهذه المهام
    • إزالتهم من Domain Admins وتفويض مجموعتهم بإعادة تعيين كلمات المرور وفك القفل على وحدات المستخدمين
    • إنشاء حساب مسؤول واحد مشترك للفريق بكلمة مرور قوية تتغير شهرياً وتُحفظ في نظام التذاكر

    الشرح: مبدأ أقل الصلاحيات يقتضي منح الفريق ما يحتاجه فقط عبر التفويض Delegate Control على الوحدات التنظيمية، فسرقة حساب واحد منهم حالياً تعني السيطرة على المجال كله. مجموعة Account Operators ما زالت شديدة الصلاحية وتوصي Microsoft بإبقائها فارغة، والحساب المشترك يُفقدك معرفة من نفّذ كل إجراء.

  7. ٧. فعّلت PortFast على منافذ المستخدمين في المحوّلات كي تعمل أجهزتهم فوراً دون انتظار تقارب STP. ما الميزة التي يجب تفعيلها معها على هذه المنافذ لتعطيل المنفذ تلقائياً إذا وصله إطار BPDU، كأن يوصل موظف محوّلاً صغيراً أو يتسبب في حلقة؟

    • BPDU Guard
    • Root Guard
    • BPDU Filter
    • Port Security

    الشرح: BPDU Guard ينقل المنفذ إلى حالة err-disabled فور استقبال أي BPDU، وهو المكمّل المعتاد لـPortFast على منافذ المستخدمين. أما BPDU Filter فيوقف تبادل هذه الإطارات فيُضعف الحماية من الحلقات، وRoot Guard لا يتدخل إلا عند وصول BPDU أفضل يحاول تغيير الجسر الجذر، وPort Security يعمل على عناوين MAC لا على BPDU.

  8. ٨. موظفو فرع يتصلون بالمقر الرئيسي عبر نفق VPN. ينجح ping إلى خوادم المقر وتفتح الصفحات الداخلية الخفيفة، لكن نسخ الملفات الكبيرة وبعض التطبيقات الداخلية تتوقف بعد بدء الاتصال مباشرة دون رسالة خطأ، ولا تظهر المشكلة لموظفي المقر. ما السبب الأرجح؟

    • خادم DNS في الفرع بطيء في الاستجابة، فتنتهي مهلة الاتصال بالتطبيقات قبل اكتمال التحميل
    • عرض النطاق الترددي للنفق غير كافٍ، فتتوقف الاتصالات الكبيرة عندما يمتلئ الخط بحركة الفرع
    • تعارض في عناوين IP بين بوابة الفرع وجهاز آخر، فتضيع بعض الحزم بشكل عشوائي أثناء النقل
    • الحزم الكبيرة تتجاوز MTU المسار بعد ترويسات النفق، ورسائل ICMP الخاصة بذلك محجوبة

    الشرح: نجاح الحزم الصغيرة وتوقف الكبيرة عبر النفق وحده علامة معروفة على مشكلة MTU، وتُؤكَّد بالأمر ping -f -l بأحجام متدرجة وتُحل بخفض MTU أو ضبط MSS على النفق. يتجه كثيرون إلى DNS أو السرعة، لكن الأسماء تُحل والصفحات الخفيفة تعمل، وضعف السرعة يسبب بطئاً لا توقفاً تاماً.

  9. ٩. بصفتك مشرفاً على فريق الدعم، لاحظت أن 30 تذكرة خلال الشهر عن تعطل تطبيق المبيعات أُغلقت كلها بإعادة تشغيل خدمة على الخادم، وجميعها حُلّت ضمن مستوى الخدمة المتفق عليه SLA. ما أفضل إجراء؟

    • جدولة إعادة تشغيل تلقائية للخدمة كل ليلة وإغلاق الموضوع نهائياً بعد توقف التذاكر
    • فتح سجل مشكلة Problem لتحليل السبب الجذري وربط التذاكر به، مع توثيق الحل المؤقت
    • دمج التذاكر الثلاثين في تذكرة واحدة وإغلاق البقية بوصفها مكررة لتحسين مؤشرات الفريق
    • الاستمرار في الطريقة الحالية، فالتذاكر تُحل بسرعة وضمن SLA والمستخدمون راضون عن الخدمة

    الشرح: تكرار الحادثة نفسها يعني وجود سبب جذري لم يُعالج، وإدارة المشكلات Problem Management تربط الحوادث وتبحث عن حل دائم مع إبقاء الحل المؤقت workaround موثقاً للفريق. الالتزام بـSLA يُغري بتجاهل التكرار، وإعادة التشغيل التلقائية تخفي العَرَض وتترك السبب قائماً.

  10. ١٠. توقف خادم البريد الإلكتروني للشركة كلها في التاسعة صباحاً، وبدأت عشرات المكالمات والتذاكر تصل إلى فريق الدعم. بصفتك قائد المناوبة، ما أفضل تصرف؟

    • توزيع التذاكر على الفنيين ليحقق كل منهم في تذكرته منفصلاً، فتُغلق جميعها بسرعة أكبر
    • تأجيل أي إعلان للموظفين حتى معرفة السبب الجذري بدقة، تجنباً لإعطاء معلومات غير مؤكدة
    • إرسال رسالة بريد إلكتروني عاجلة إلى جميع الموظفين تشرح العطل والوقت المتوقع لإصلاحه
    • إعلان حادثة كبرى وربط التذاكر بتذكرة رئيسية، ونشر تحديثات دورية عبر قناة بديلة

    الشرح: في الحادثة الكبرى يُنسَّق العمل من تذكرة رئيسية واحدة، وتُرسل تحديثات منتظمة حتى قبل معرفة السبب فتقل المكالمات المكررة. ويجب ألا تعتمد قناة التواصل على الخدمة المعطلة، فرسالة البريد هنا لن تصل إلى أحد.

  11. ١١. استُرجع جهاز موظف من صورة نسخ احتياطي أُخذت قبل ثلاثة أشهر. الدخول بالحساب المحلي يعمل، لكن الدخول بحساب المجال يعرض الرسالة The trust relationship between this workstation and the primary domain failed، مع أن الوقت مضبوط والشبكة سليمة. ما السبب والحل الأنسب؟

    • كلمة مرور الموظف في المجال انتهت صلاحيتها خلال الأشهر الثلاثة، فيجب إعادة تعيينها من Active Directory
    • ملف تعريف المستخدم user profile على الجهاز تالف، فيجب حذفه ليُنشأ ملف جديد عند الدخول
    • سجل الجهاز في DNS حُذف خلال تلك الفترة، فيجب تسجيله من جديد بالأمر ipconfig /registerdns
    • كلمة مرور حساب الجهاز في الصورة قديمة ولا تطابق AD، فتُصلح بالأمر Test-ComputerSecureChannel -Repair

    الشرح: يغيّر الجهاز كلمة مرور حسابه في المجال تلقائياً كل 30 يوماً افتراضياً، ولا يقبل المجال إلا الحالية والسابقة، لذا تفشل القناة الآمنة مع صورة أقدم من ذلك. الأمر Test-ComputerSecureChannel -Repair يعيد مزامنة كلمة المرور دون إعادة الانضمام إلى المجال، أما مشكلات كلمة مرور المستخدم أو DNS فتظهر برسائل مختلفة.

  12. ١٢. حصلت أجهزة في أحد الأقسام فجأة على عناوين من النطاق 192.168.0.0/24 مع بوابة افتراضية لا تتبع الشركة، بينما شبكة الشركة هي 10.20.0.0/16. تبيّن أن موظفاً وصل موجّهاً منزلياً بمنفذ الشبكة في مكتبه. ما الإجراء الذي يمنع تكرار ذلك على مستوى الشبكة؟

    • تفعيل DHCP Failover بين خادمين رسميين كي يسبق ردهما رد الموجّه الدخيل
    • تقصير مدة الإيجار في نطاق الشركة كي تعود الأجهزة بسرعة إلى خادم DHCP الرسمي
    • تفعيل DHCP Snooping على المحوّلات وجعل المنافذ المؤدية إلى خادم DHCP الرسمي وحدها موثوقة
    • تخويل خادم DHCP الرسمي في Active Directory كي ترفض الأجهزة العروض الواردة من أي خادم غير مخوّل

    الشرح: DHCP Snooping يُسقط رسائل DHCPOFFER وDHCPACK الواردة من أي منفذ غير موثوق، فلا يصل الخادم الدخيل إلى العملاء. أما التخويل في Active Directory فيمنع خوادم DHCP العاملة بنظام Windows Server فقط من العمل دون تخويل، ولا يؤثر في الموجّهات المنزلية ولا في سلوك العملاء.

مقابلات أخرى: دعم فني IT

المزيد