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

پوشش دقیق حوزه‌های آزمون

• معماری AEM و مفاهیم اصلی (۲۰٪)

  • مباحث:پردازش درخواست‌های Apache Sling، چارچوب OSGi و چرخه حیات کامپوننت‌ها، مشخصات Java Content Repository (JCR)، لایه‌های ذخیره‌سازی Apache Jackrabbit Oak (TarMK/MongoMK) و پیاده‌سازی AEM Core Components.

• توسعه و پیاده‌سازی AEM (۲۵٪)

  • مباحث:طراحی آرکیتایپ ساختار پروژه AEM، پروفایل‌های بیلد Maven، مدل‌های Sling و انوتیشن‌ها، سرویس‌های OSGi و قوانین پیکربندی Apache HTTP Server Dispatcher.

• بهینه‌سازی عملکرد و عیب‌یابی (۱۵٪)

  • مباحث:پیکربندی تحلیل‌گر لاگ، مدیریت متمرکز خطاها، ابزارهای بنچ‌مارک عملکرد، استراتژی‌های کشینگ چندسطحی و ایندکس‌گذاری سفارشی Oak (Lucene/Property).

• امنیت و کنترل دسترسی (۱۰٪)

  • مباحث:APIهای رمزنگاری و کریپتوگرافی، معماری مدیریت کاربران و گروه‌ها، ترتیب ارزیابی لیست‌های کنترل دسترسی (ACLs) و متدهای کدنویسی امن در برابر XSS/CSRF.

• یکپارچه‌سازی و مهاجرت (۱۰٪)

  • مباحث:معماری AEM as a Cloud Service، ابزارهای مهاجرت از On-Premise به Cloud (BPA/CAM)، یکپارچه‌سازی با REST/GraphQL شخص ثالث، اتصال به Adobe Target/Analytics و مهاجرت داده‌ها با CRX2Oak.

• بهترین روش‌ها و الگوهای طراحی (۱۰٪)

  • مباحث:پیکربندی‌های Context-Aware در Sling، سیستم‌های بیلد فرانت‌اند ماژولار، پارادایم‌های بازاستفاده از محتوا (Experience Fragments/Content Fragments) و مقیاس‌پذیری سازمانی.

• استقرار ابری و هیبریدی AEM (۵٪)

  • مباحث:مدیریت خط لوله (Pipeline) سرویس ابری، گیت‌های کیفی Cloud Manager، تحویل محتوای Headless هیبریدی و معماری میکروسرویس‌ها.

• استراتژی‌های بازیابی از فاجعه و پشتیبان‌گیری (۵٪)

  • مباحث:پاک‌سازی نسخه‌های آنلاین/آفلاین، الگوهای پشتیبان‌گیری و بازیابی مخزن، توپولوژی‌های تکثیر چندمنطقه‌ای (Multi-region) و اعتبارسنجی Failover.

توضیحات دوره

موفقیت در مصاحبه فنی Adobe Experience Manager (AEM) بسیار فراتر از حفظ کردن اصطلاحات ابتدایی است. تیم‌های سازمانی مدرن به دنبال مهندسانی هستند که دقیقاً بدانند وقتی یک درخواست به Dispatcher می‌رسد چه اتفاقی می‌افتد، Apache Sling چگونه اسکریپت‌ها را Resolve می‌کند و چگونه Thread Lockهای پیچیده یا کوئری‌های کند JCR را در محیط عملیاتی عیب‌یابی کنند.

من این بانک سوالات تمرینی را طراحی کردم تا شکاف بین آموزش‌های توسعه ابتدایی و تصمیمات معماری سطح بالا در سناریوهای واقعی را پر کنم. با ۵۵۰ سوال دقیق، این منبع دقیقاً عمق، ساختار سناریو-محور و سخت‌گیری فنی مصاحبه‌های توسعه‌دهندگان Mid-to-Senior، لیدهای فنی و معماران راهکار را شبیه‌سازی می‌کند.

به جای سوالات کویزی معمولی، با سناریوهایی مواجه می‌شوید که به شکست‌های ایندکس Oak، بن‌بست‌های وابستگی Bundle در OSGi، چالش‌های مهاجرت به ابر و پیچیدگی‌های ابطال کش Dispatcher می‌پردازند. هر سوال شامل یک تحلیل جامع است که اصل مهندسی پشت گزینه صحیح و دلایل رد گزینه‌های جایگزین یا الگوهای ضد-معماری (Anti-patterns) را توضیح می‌دهد. این رویکرد، یک ابزار تست ساده را به یک راهنمای مطالعه جامع تبدیل می‌کند.

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

سوال ۱: تحلیل اسکریپت و Overlays

وقتی یک درخواست HTTP یک Resource Type خاص را در AEM هدف قرار می‌دهد، اگر نام‌های اسکریپت یکسانی در هر دو مسیر /apps و /libs وجود داشته باشد، Apache Sling چگونه تعیین می‌کند که کدام اسکریپت رندرینگ اجرا شود؟

• A) هدرهای درخواست ورودی را ارزیابی می‌کند تا بر اساس یک قانون خاص Dispatcher، تصمیم بگیرد از /apps یا /libs استفاده کند.

• B) ابتدا /apps را بر اساس پیکربندی مسیر جستجو در Resource Resolver Factory بررسی می‌کند که امکان سفارشی‌سازی یا Overlay کامپوننت‌های نیتیو را فراهم می‌کند.

• C) ابتدا /libs را جستجو می‌کند و تنها در صورت بروز خطای کامپایل یا ۴۰۴ به /apps باز می‌گردد.

• D) هر دو اسکریپت را به صورت پویا در زمان اجرا با استفاده از OSGi fragment bundles ادغام می‌کند تا منطق سفارشی و هسته را ترکیب کند.

• E) اولویت را به /libs می‌دهد مگر اینکه تعریف کامپوننت شامل یک ویژگی صریح sling:resourceSuperType باشد که به /apps اشاره کند.

• F) از Event Listenerهای JCR استفاده می‌کند تا هر دو اسکریپت را در یک درخت اجرای بهینه در /var/classes پیش-کامپایل کرده و جدیدترین زمان (Timestamp) را انتخاب کند.

پاسخ صحیح:B

تحلیل دقیق:

• چرا گزینه B صحیح است:Apache Sling از یک پیکربندی مسیر جستجوی ساختاریافته (که معمولاً پیش‌فرض آن [/apps, /libs] است) استفاده می‌کند که توسط Resource Resolver Factory مدیریت می‌شود. هنگام Resolve کردن یک اسکریپت، Sling این مسیرها را به ترتیب بررسی می‌کند. چون /apps در ابتدای آرایه قرار دارد، هر اسکریپتی که در آنجا یافت شود، بلافاصله اسکریپت مربوطه در /libs را بازنویسی (یا Overlay) می‌کند. این مکانیسم بنیادی برای گسترش قابلیت‌های Out-of-the-box در AEM بدون تغییر در کد هسته است.

• چرا گزینه A غلط است:تحلیل اسکریپت کاملاً در موتور Apache Sling در داخل نمونه Publish/Author در AEM اتفاق می‌افتد. Dispatcher بازنویسی URL و کشینگ را در لایه وب‌سرور مدیریت می‌کند اما هیچ دیدی نسبت به مسیرهای داخلی Resolve اسکریپت‌های JCR ندارد.

• چرا گزینه C غلط است:این دقیقاً برعکس نحوه عملکرد Resolve اسکریپت است. اگر ابتدا /libs جستجو می‌شد، توسعه‌دهندگان هرگز نمی‌توانستند ویژگی‌های پیش‌فرض را Overlay کنند و بازنویسی‌های سفارشی بی‌اثر می‌شد.

• چرا گزینه D غلط است:OSGi fragment bundles برای متصل کردن کلاس‌های جاوا کامپایل شده یا فایل‌های پیکربندی به یک Host Bundle در سطح زمان اجرای سیستم استفاده می‌شوند. آن‌ها اسکریپت‌های تفسیری یا دارایی‌های متنی موجود در مخزن JCR را ادغام نمی‌کنند.

• چرا گزینه E غلط است:ویژگی sling:resourceSuperType ارث‌بری شیءگرا بین کامپوننت‌ها را مدیریت می‌کند، اما مکانیسم مسیر جستجو به طور خودکار /apps را بر /libs ارزیابی می‌کند، حتی بدون تعریف صریح supertype.

• چرا گزینه F غلط است:اگرچه اسکریپت‌ها برای عملکرد بهتر در /var/classes کامپایل و کش می‌شوند، اما منطق انتخاب قبلاز کامپایل و بر اساس مسیر جستجو اتفاق می‌افتد، نه بر اساس Timestamp تغییرات یا نوتیفیکیشن‌های JCR.

سوال ۲: عملکرد مخزن و ایندکس‌گذاری

یک نمونه AEM Author به دلیل یک کوئری سفارشی JCR که مکرراً هشدار TraversalIndex را در لاگ‌ها برمی‌گرداند، با مصرف شدید CPU مواجه شده است. موثرترین روش برای حذف این هشدار و بازگرداندن عملکرد چیست؟

• A) افزایش اندازه Thread Pool در پیکربندی LuceneIndexProviderService برای اجازه دادن به Traversal همزمان سریع‌تر.

• B) پاکسازی کامل کش AEM Dispatcher برای اطمینان از اینکه نتایج کوئری در لایه وب‌سرور کش شوند به جای اینکه به Oak ضربه بزنند.

• C) تغییر رشته کوئری برای استفاده انحصاری از ویژگی jcr:path تا به طور خودکار به B-tree گره‌های مرتب شده ارجاع دهد.

• D) تعریف یک ایندکس سفارشی Oak Lucene تحت /oak:index که صراحتاً ویژگی‌های استفاده شده در بندهای WHERE کوئری را شامل شود.

• E) ایندکس مجدد کل /oak:index/nodetype پیش‌فرض برای مجبور کردن Jackrabbit Oak به به‌روزرسانی با ویژگی‌های جدید ایجاد شده.

• F) ری‌استارت سرویس مخزن Oak برای تخلیه بافرهای حافظه گذرا که گره‌های ورک‌اسپیس ایندکس نشده را نگه داشته‌اند.

پاسخ صحیح:D

تحلیل دقیق:

• چرا گزینه D صحیح است:وقتی کوئری بدون ایندکس مناسب اجرا می‌شود، موتور کوئری Apache Jackrabbit Oak مجبور است گره‌های مخزن JCR را گره به گره پیمایش کند (عملیات Traversal). اگر تعداد گره‌ها از حد آستانه تعیین شده بیشتر شود، عملکرد افت کرده و یک هشدار/خطا ثبت می‌شود. ایجاد یک تعریف ایندکس Lucene خاص تحت /oak:index که ویژگی‌های معیارهای فیلتر کوئری شما را هدف قرار دهد، به Oak اجازه می‌دهد یک جدول جستجوی بسیار بهینه بسازد و پیمایش گره‌ها را کاملاً حذف کند.

• چرا گزینه A غلط است:افزایش اندازه Thread Pool صرفاً اجازه می‌دهد رشته‌های بیشتری عملیات ناکارآمد Traversal را به صورت همزمان انجام دهند، که این امر به جای رفع نقص ایندکس، باعث تشدید مصرف CPU می‌شود.

• چرا گزینه B غلط است:Dispatcher پاسخ‌های HTTP را برای نمونه Publish کش می‌کند. این ابزار کوئری‌های API JCR که در محیط Author اجرا می‌شوند را کش نمی‌کند، بنابراین هیچ کمکی به رفع گلوگاه‌های کوئری در محیط Authoring نمی‌کند.

• چرا گزینه C غلط است:محدود کردن کوئری به یک مسیر خاص به محدود کردن دامنه کمک می‌کند، اما اگر ویژگی‌های داخل آن مسیر ایندکس نشده باشند، Oak همچنان باید تک تک گره‌های فرزند زیر آن مسیر را پیمایش کند.

• چرا گزینه E غلط است:ایندکس پیش‌فرض nodetype کوئری‌هایی را بهینه می‌کند که به دنبال دسته‌های خاص گره (مانند cq:Page) هستند. این ایندکس ویژگی‌های سفارشی اپلیکیشن را که توسط تیم توسعه اضافه شده‌اند، به طور پویا ایندکس نمی‌کند.

• چرا گزینه F غلط است:ری‌استارت کردن نمونه، کش‌های حافظه گذرا را پاک می‌کند اما ساختارهای ایندکس لازم را ایجاد نمی‌کند. در اولین باری که کوئری مجدداً اجرا شود، رفتار Traversal بلافاصله باز می‌گردد.

سوال ۳: مدیریت کش HTTP از طریق Dispatcher

در یک معماری سازمانی AEM، پیکربندی ویژگی /statfileslevel در ماژول Dispatcher چه تأثیری بر عملکرد تحویل محتوا هنگام فعال‌سازی (Activation) محتوا دارد؟

• A) حداکثر عمق پوشه مسیر URL را که می‌تواند کش شود محدود می‌کند و مسیرهای عمیق‌تر را مجبور می‌کند مستقیماً از نمونه Publish سرو شوند.

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

• C) تعداد Agentهای تکثیر همزمان مجاز برای ارسال درخواست‌های ابطال به یک نمونه Dispatcher را تعریف می‌کند.

• D) آستانه پاسخ‌های HTTP 200 مورد نیاز را مشخص می‌کند تا Dispatcher فایل‌های کش Memory-mapped خود را تخلیه کند.

• E) حداکثر عمق تو در تو دایرکتوری‌هایی را تنظیم می‌کند که Dispatcher به صورت بازگشتی اسکن کرده و پس از دریافت دستور Flush، به صورت فیزیکی حذف می‌کند.

• F) سطح فشرده‌سازی gzip اعمال شده بر فایل‌های .stat را کنترل می‌کند تا رفت‌وبرگشت‌های شبکه بین نمونه Publish و وب‌سرور بهینه شود.

پاسخ صحیح:B

تحلیل دقیق:

• چرا گزینه B صحیح است:به طور پیش‌فرض، یک فایل .stat واحد در ریشه ساختار دایرکتوری کش Dispatcher قرار دارد. وقتی هر صفحه‌ای منتشر می‌شود، Timestamp این فایل به‌روز شده و تمامصفحات کش شده در کل سایت باطل می‌شوند. با تنظیم /statfileslevel روی یک عمق خاص (مثلاً ۳)، Dispatcher فایل‌های .stat را تا آن سطح از دایرکتوری ایجاد می‌کند. هنگام تغییر محتوا، تنها فایل .stat در آن زیرشاخه خاص به‌روز می‌شود و کش برای بخش‌های نامرتبط سایت حفظ شده و نرخ Cache Hit به شدت بهبود می‌یابد.

• چرا گزینه A غلط است:ویژگی /statfileslevel منطق ابطال (Invalidation)کش را مدیریت می‌کند، نه واجد شرایط بودن (Eligibility)کش را. این ویژگی مانع از نوشته شدن مسیرهای عمیق در کش نمی‌شود.

• چرا گزینه C غلط است:همزمانی Agent تکثیر کاملاً در تنظیمات OSGi author/publish در AEM و پیکربندی‌های صف تکثیر تنظیم می‌شود و کاملاً مستقل از ویژگی‌های ماژول وب‌سرور است.

• چرا گزینه D غلط است:Dispatcher از آستانه تعداد پاسخ‌ها برای تعیین عمر کش استفاده نمی‌کند؛ ابطال صرفاً رویداد-محور است و توسط درخواست‌های Replication Flush یا انقضای TTL تحریک می‌شود.

• چرا گزینه E غلط است:Dispatcher هنگام ابطال محتوا، اسکن حذف فایل گسترده‌ای انجام نمی‌دهد. در عوض، Timestamp فایل .stat را به‌روز می‌کند. وقتی درخواست بعدی می‌رسد، وب‌سرور سن فایل کش شده را با سن فایل .stat مقایسه می‌کند تا تصمیم بگیرد آیا نیاز به دریافت نسخه جدید هست یا خیر.

• چرا گزینه F غلط است:یک فایل .stat یک فایل متنی بسیار کوچک یا صفر بایت است که فقط شامل یک معیار Timestamp است. این فایل هرگز در شبکه عمومی منتقل یا فشرده نمی‌شود؛ بلکه صرفاً یک مکانیسم ردیابی سیستم فایل داخلی برای ماژول وب‌سرور است.

• به تست‌های سوالات مصاحبه خوش آمدید تا شما را در آمادگی برای مصاحبه توسعه‌دهنده و معمار AEM (Adobe Experience Manager) کمک کنیم.

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

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

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

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

• با اپلیکیشن Udemy کاملاً با موبایل سازگار است.

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