پوشش جامع حوزههای آزمون
این بانک سوالات جامع به طور سیستماتیک با ساختار دقیق حوزههای موجود در مصاحبههای فنی حرفهای AWS، بررسیهای معماری و گواهینامههای پیشرفته ابری مطابقت دارد:
سرویسهای اصلی AWS (۲۰٪)
مباحث پوشش داده شده:انواع Instanceهای Elastic Compute Cloud (EC2) و گروههای جایگذاری، کلاسهای ذخیرهسازی و سیاستهای چرخه عمر Simple Storage Service (S3)، زیرشبکههای Virtual Private Cloud (VPC)، سیاستهای مدیریت هویت و دسترسی (IAM) و توپولوژیهای استقرار Relational Database Service (RDS).
امنیت و انطباق (۱۸٪)
مباحث پوشش داده شده:نقشهای cross-account در IAM، بازرسی stateful در Security Groups، فیلترینگ stateless در Network Access Control Lists (NACLs)، Route 53 DNSSEC و تجمیع لاگهای امنیتی CloudWatch.
شبکه و اتصال (۱۵٪)
مباحث پوشش داده شده:محدودیتهای VPC Peering، گزینههای مسیریابی AWS Direct Connect، failover در AWS Site-to-Site VPN، معماریهای مسیریابی متمرکز Transit Gateway و Interface Endpoints در AWS PrivateLink.
پایگاه داده و ذخیرهسازی (۱۲٪)
مباحث پوشش داده شده:مقایسه RDS multi-AZ در مقابل read replicas، کلیدهای پارتیشن و جداول جهانی DynamoDB، بهینهسازی عملکرد S3، ویژگیهای عملکرد Volume در Elastic Block Store (EBS) (io2 در مقابل gp3) و مونت کردن Elastic File System (EFS).
سرویسهای اپلیکیشن و استقرار (۱۰٪)
مباحث پوشش داده شده:تعریف تسکها در Elastic Container Service (ECS)، شبکه در Elastic Kubernetes Service (EKS)، محیطهای اجرای AWS Lambda و محدودیتهای همزمانی، یکپارچهسازی API Gateway و پارامتریسازی زیرساخت به عنوان کد (IaC) در CloudFormation.
مانیتورینگ و عیبیابی (۸٪)
مباحث پوشش داده شده:هشدارها و فیلترهای متریک CloudWatch، حسابرسی API در CloudTrail، ردیابی توزیع شده AWS X-Ray و گردش کارهای اصلاح Drift در CloudFormation.
بهینهسازی و مدیریت هزینهها (۷٪)
مباحث پوشش داده شده:تحلیل AWS Cost Explorer، بررسیهای بهینهسازی Trusted Advisor، مقایسه Savings Plans در مقابل Reserved Instances، مدیریت پایان Spot Instances و استراتژیهای تخصیص گروه Auto Scaling.
معماری و طراحی (۱۰٪)
مباحث پوشش داده شده:ستونهای چارچوب Well-Architected AWS، طراحی برای در دسترس بودن بالا و دوام، جداسازی بارهای کاری Monolithic برای مقیاسپذیری، و استراتژیهای بازیابی فاجعه (DR) چند منطقهای (Pilot Light, Warm Standby).
توضیحات دوره
موفقیت در مصاحبه مهندسی ابر یا معماری AWS نیازمند چیزی بسیار بیشتر از شناخت سطحی نام سرویسهاست. مصاحبهکنندگان فنی به دنبال مهندسانی هستند که توازنهای عمیق معماری، پیامدهای امنیتی، الگوهای جداسازی شبکه و مرزهای هزینه را درک کنند. من این بانک سوالات تمرینی هدفمند را به عنوان یک منبع مطالعاتی سختگیرانه و سناریومحور ایجاد کردهام که دقیقاً محیطهای حل مسئلهای را بازسازی میکند که در طول مصاحبههای فنی واقعی با آنها مواجه خواهید شد.
با کتابخانهای عظیم از سوالات بسیار دقیق و متمرکز بر سناریو، این دوره تمرکز شما را از حفظ کردن مطالب ساده به سمت منطق واقعی معماری تغییر میدهد. شما با چالشهای عملیاتی پیچیدهای مانند محدودههای IP همپوشان، تأخیر در تکثیر پایگاه داده، امنیت سختگیرانه محیط داده و جهشهای ناگهانی ترافیک اپلیکیشن روبرو خواهید شد.
هر سوال شامل یک توضیح جامع است که مکانیسمهای ابری پشت پاسخ درست را شفاف کرده و دلیل رد شدن پنج گزینه جایگزین را در شرایط واقعی توضیح میدهد. با کار روی این سناریوهای کاربردی، شما غریزه طراحی سیستم لازم برای عبور از غربالگریهای فنی در اولین تلاش را میسازید و میتوانید با اطمینان تصمیمات مهندسی خود را برای مصاحبهکنندگان ارشد توجیه کنید.
پیشنمایش نمونه سوالات تمرینی
سوال ۱: شبکه و اتصال
شرکت شما نیاز دارد تا یک اتصال امن و خصوصی بین VPC شرکتی خود و یک اپلیکیشن تحلیلی تامینکننده شخص ثالث که در یک حساب AWS مجزا میزبانی میشود، برقرار کند. تیم زیرساخت شرکت تاکید دارد که ترافیک هرگز نباید از اینترنت عمومی عبور کند. علاوه بر این، VPC تامینکننده از یک بلوک CIDR همپوشان (10.0.0.0/16) با VPC شرکت شما استفاده میکند. کدام رویکرد معماری این الزامات امنیتی و مسیریابی را برآورده میکند؟
A) ایجاد یک اتصال VPC Peering استاندارد بین VPC شما و VPC تامینکننده، و سپس بهروزرسانی جداول مسیریابی مربوطه.
چرا نادرست است:VPC Peering به شدت نیازمند بلوکهای CIDR غیرهمپوشان است. چون هر دو VPC از محدوده 10.0.0.0/16 استفاده میکنند، اتصال peering نمیتواند به درستی مقداردهی یا مسیریابی شود.
B) استقرار یک Network Load Balancer (NLB) رو به اینترنت در حساب تامینکننده و مسیریابی ترافیک از طریق AWS Site-to-Site VPN روی اینترنت عمومی.
چرا نادرست است:این معماری دستور امنیتی اصلی را که ترافیک هرگز نباید از اینترنت عمومی عبور کند نقض میکند، حتی اگر از طریق VPN رمزنگاری شده باشد و همچنین باعث قرار گرفتن غیرضروری در معرض اینترنت از طریق NLB میشود.
C) تخصیص یک اتصال AWS Direct Connect که منحصراً به حساب تامینکننده اختصاص یافته و پیکربندی یک Private Virtual Interface (VIF).
چرا نادرست است:AWS Direct Connect برای اتصال مراکز داده On-premises به محیطهای AWS طراحی شده است. این سرویس به طور بومی اتصالات بین حسابی VPC با زیرشبکههای همپوشان را بدون مسیریابیهای پیچیده و هزینهبر در محیط On-premises حل نمیکند.
D) دستور به تامینکننده برای ایجاد یک سرویس endpoint AWS PrivateLink که توسط Network Load Balancer پشتیبانی میشود و تخصیص یک Interface VPC Endpoint در VPC شرکتی شما.
چرا درست است:AWS PrivateLink به شما اجازه میدهد تا VPC خود را به صورت خصوصی به سرویسهای پشتیبانی شده بدون عبور از اینترنت متصل کنید. چون این سرویس با قرار دادن یک Elastic Network Interface (ENI) با یک IP خصوصی خاص در زیرشبکه شما عمل میکند، کاملاً محدودیتهای بلوکهای CIDR همپوشان در سطح VPC را دور میزند و مواجهه با اینترنت را حذف میکند.
E) اتصال هر دو VPC به یک AWS Transit Gateway (TGW) متمرکز و جداسازی آنها با استفاده از TGW Route Tableهای متمایز.
چرا نادرست است:اگرچه Transit Gateway شبکه چند VPC را ساده میکند، اما متصل کردن دو VPC با بلوکهای CIDR یکسان و همپوشان به یک TGW، در صورتی که این VPCها نیاز به ارتباط مستقیم با یکدیگر داشته باشند، همچنان باعث تداخل مسیریابی IP میشود.
F) راهاندازی یک AWS Client VPN endpoint در VPC شما و پیکربندی سیستمهای بکاند تامینکننده برای احراز هویت به عنوان نودهای کلاینت خارجی.
چرا نادرست است:Client VPN برای کاربران راه دور طراحی شده است که به صورت امن از دستگاههای محلی خود به محیط AWS متصل میشوند. این یک مکانیسم سازمانی و منطبق بر معماری برای یکپارچهسازی سرویسهای VPC به صورت ماشین-به-ماشین نیست.
سوال ۲: پایگاه داده و ذخیرهسازی
یک سیستم تجارت الکترونیک تراکنشی حیاتی به یک معماری پایگاه داده رابطهای با در دسترس بودن بالا نیاز دارد. سیستم باید از خواندن با تأخیر کم (کمتر از ۱ ثانیه) برای میکروسرویسهای Read-heavy که در مناطق اصلی آمریکای شمالی و مناطق ثانویه اروپا مستقر شدهاند، پشتیبانی کند. در صورت خرابی کامل منطقه اصلی، هدف نقطه بازیابی (RPO) باید زیر ۱ دقیقه و هدف زمان بازیابی (RTO) باید زیر ۱۵ دقیقه باشد. کدام پیکربندی موتور پایگاه داده این الزامات را با کمترین سربار عملیاتی به طور بومی برآورده میکند؟
A) استقرار یک Instance استاندارد Amazon RDS PostgreSQL با Read Replicaهای Cross-region پیکربندی شده در اروپا.
چرا نادرست است:Read Replicaهای استاندارد RDS در مناطق مختلف از تکثیر asynchronous در سطح موتور استفاده میکنند که میتواند تحت بار زیاد دچار تأخیر قابل توجهی شود و RPO یک دقیقهای را به خطر بیندازد. علاوه بر این، ارتقای یک replica به instance اصلی نیازمند مداخله دستی یا اسکریپتهای سفارشی پیچیده است که تضمین RTO ۱۵ دقیقهای سختگیرانه را در هنگام فاجعه دشوار میکند.
B) تخصیص یک Amazon Aurora Global Database با کلاستر اصلی در آمریکای شمالی و کلاستر ثانویه در اروپا، با استفاده از failoverهای برنامهریزی شده مدیریت شده.
چرا درست است:Amazon Aurora Global Database از تکثیر مبتنی بر ذخیرهسازی اختصاصی استفاده میکند که مستقل از لایه compute موتور پایگاه داده عمل میکند و معمولاً به تأخیر تکثیری کمتر از ۱ ثانیه دست مییابد. این سرویس از failoverهای سریع بین منطقهای پشتیبانی میکند که میتواند در عرض چند دقیقه اجرا شود (برآورده کردن RTO ۱۵ دقیقهای) و در شرایط مدیریت شده بدون از دست رفتن داده عمل کند و کاملاً RPO یک دقیقهای را برآورده سازد.
C) پیادهسازی Amazon DynamoDB با فعال کردن Global Tables در هر دو منطقه آمریکای شمالی و اروپا.
چرا نادرست است:DynamoDB یک پایگاه داده NoSQL کلید-مقدار است. الزامات اپلیکیشن صراحتاً بر نیاز به معماری پایگاه داده رابطهای برای حفظ تضمینهای تراکنشی SQL و Schemaها تأکید کرده است.
D) استفاده از استقرار Amazon RDS Multi-AZ در سه Availability Zone در منطقه اصلی آمریکای شمالی.
چرا نادرست است:استقرار Multi-AZ تکثیر synchronous و در دسترس بودن بالا را در یک منطقه واحدفراهم میکند. این روش خواندنهای محلی با تأخیر کم یا قابلیتهای بازیابی فاجعه برای کاربرانی که در منطقه اروپا هستند را ارائه نمیدهد.
E) پیکربندی Amazon ElastiCache for Redis با یک کلاستر Global Datastore برای کش کردن تمام فعالیتهای نوشتن رابطهای در سطح جهانی.
چرا نادرست است:ElastiCache for Redis یک لایه کشینگ در حافظه (in-memory) است، نه یک راهکار پایگاه داده رابطهای اصلی و پایدار که قادر به مدیریت امن جداول تراکنشی پیچیده مطابق با استانداردهای ACID باشد.
F) ذخیره تمام رکوردهای تراکنشی به صورت اشیاء flat در Amazon S3، با استفاده از Cross-Region Replication (CRR) و پرسوجو از طریق Amazon Athena.
چرا نادرست است:ترکیب Amazon S3 و Athena یک الگوی پرسوجوی تحلیلی مبتنی بر شیء است. این روش فاقد ایندکسگذاری با تأخیر کم، قفلگذاری در سطح ردیف (row-level locking) و قابلیتهای نوشتن با همزمانی بالا است که برای یک پایگاه داده تراکنشی زنده تجارت الکترونیک مورد نیاز است.
سوال ۳: سرویسهای اپلیکیشن و بهینهسازی هزینه
یک اپلیکیشن که روی Amazon ECS و با قدرت AWS Fargate اجرا میشود، پیامها را از یک صف Amazon SQS پردازش میکند. حجم کاری ورودی در طول روز دچار جهشهای عظیم و غیرقابل پیشبینی در ترافیک میشود. مدیریت میخواهد هزینههای عملیاتی را بهینه کند و در عین حال تضمین کند که پیامها بیش از ۱۵ دقیقه پردازش نشده در صف باقی نمانند. کدام استراتژی مقیاسبندی و قیمتگذاری این هدف را به موثرترین شکل محقق میکند؟
A) پیکربندی سیاست ECS Service Auto Scaling بر اساس Average CPU Utilization با استفاده از ۱۰۰٪ On-Demand Capacity Providers.
چرا نادرست است:بهرهوری CPU لزوماً با اندازه بکلاگ صف مرتبط نیست؛ تسکها ممکن است در انتظار I/O شبکه بیکار باشند در حالی که پیامها در صف انباشته میشوند. علاوه بر این، تکیه کامل بر ظرفیت On-Demand مقرونبهصرفهترین راهکار برای Workerهای بدون وضعیت (stateless) و صفمحور نیست.
B) پیکربندی سیاست ECS Service Auto Scaling بر اساس متریک ApproximateNumberOfMessagesVisible به ازای هر تسک، با استفاده از ترکیبی از Fargate On-Demand و Fargate Spot Capacity Providers و اولویت دادن به Spot.
چرا درست است:مقیاسبندی بر اساس اندازه بکلاگ صف به ازای هر تسک، مستقیماً SLA عملکرد (پردازش ظرف ۱۵ دقیقه) را هدف قرار میدهد. استفاده از Fargate Spot برای مصرفکنندگان صف بدون وضعیت و تحملپذیر در برابر خطا، تا ۷۰٪ کاهش هزینه نسبت به قیمت On-Demand ایجاد میکند، در حالی که داشتن یک خط پایه از On-Demand در دسترس بودن را در صورت عدم دسترسی موقت به ظرفیت Spot تضمین میکند.
C) خرید All Upfront EC2 Reserved Instances برای اجرای یک کلاستر اختصاصی ECS EC2 که به طور مداوم برای پاسخگویی به حداکثر ظرفیت پیک تاریخی مقیاسبندی شده است.
چرا نادرست است:اجرای Instanceها در ظرفیت پیک به طور مداوم، باعث اتلاف شدید منابع در دورههای ترافیک کم میشود. این کار مزایای مالی مقیاسپذیری الاستیک ابری را کاملاً از بین میبرد.
D) نگه داشتن تعداد ثابتی از تسکهای ECS Fargate به صورت مداوم، که کاملاً توسط Compute Savings Plan پوشش داده شده تا قیمت ثابت و قابل پیشبینی تضمین شود.
چرا نادرست است:تعداد تسکهای ثابت نمیتواند با جهشهای غیرقابل پیشبینی ترافیک سازگار شود. در طول فورانهای ترافیکی عظیم، استخر استاتیک Workerها عقب میافتد و محدودیت عملیاتی پردازش پیامها ظرف ۱۵ دقیقه را نقض میکند.
E) زمانبندی تعداد تسکهای ECS Fargate با استفاده از اکشنهای مقیاسبندی cron مبتنی بر زمان برای افزایش مقیاس منحصراً در ساعات کاری با استفاده از ۱۰۰٪ Spot instances.
چرا نادرست است:مقیاسبندی زمانبندی شده فرض میکند که الگوهای ترافیکی قابل پیشبینی هستند. چون در صورت سوال ذکر شده که جهشها غیرقابل پیشبینی هستند، مقیاسبندی مبتنی بر cron باعث انباشت پیامهای پردازش نشده در خارج از پنجرههای زمانبندی شده میشود.
F) راهاندازی یک EC2 Auto Scaling group با استفاده از instanceهای بهینه شده برای Amazon EBS، که برای مقیاسبندی پویا بر اساس متریکهای بهرهوری حافظه (memory utilization) پیکربندی شده است.
چرا نادرست است:بهرهوری حافظه شاخص ضعیفی برای حجم صف SQS است. علاوه بر این، مدیریت دستی کلاسترهای EC2 زیرین در مقایسه با Fargate سربار عملیاتی غیرضروری ایجاد میکند و instanceهای خام EC2 در هنگام جهشهای ناگهانی ترافیک دیرتر مقیاس میگیرند.
به تستهای سوالات مصاحبه خوش آمدید تا شما را برای آزمون تمرینی سوالات مصاحبه AWS آماده کنیم.
شما میتوانید هر تعداد بار که بخواهید در آزمونها شرکت کنید
این یک بانک سوالات عظیم و اورجینال است
در صورت داشتن هرگونه سوال، از پشتیبانی مدرسان بهرهمند میشوید
هر سوال دارای یک توضیح دقیق است
سازگار با موبایل از طریق اپلیکیشن Udemy
امیدوارم تا الان متقاعد شده باشید! و سوالات بسیار بیشتری در داخل دوره وجود دارد.
Interview Questions Tests
مربی در Udemy
نمایش نظرات