Ngân hàng đề — AWS Certified CloudOps Engineer Associate

🧩 Phân tích nội dung câu hỏi

Đề mô tả một SysOps Administrator quản lý đội EC2 instance dựng từ custom Linux AMI, muốn dùng AWS Systems Manager Session Manager để mở phiên SSH nhưng không tìm thấy instance trong console Session Manager. Câu hỏi yêu cầu chọn HAI hành động để xử lý.

Hai cụm từ quyết định đáp án:

• "custom Linux AMI" — AMI tự dựng gần như chắc chắn không có sẵn SSM Agent. Nhiều AMI chính thức của Amazon Linux có agent cài sẵn, nhưng ảnh tự tạo thì không có gì bảo đảm điều đó.
• "cannot find the target instance in the Session Manager console" — đây là triệu chứng của việc instance không đăng ký được làm managed instance, chứ không phải phiên kết nối bị chặn ở tầng mạng. Một máy không đăng ký được thì đơn giản là không hiện trong danh sách.

Một instance chỉ hiện trong Session Manager khi hội đủ hai điều kiện: có SSM Agent đang chạy, và agent đó có quyền IAM để gọi về Systems Manager. Đề hỏi hai đáp án vì đó chính là hai điều kiện này.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là A và D.

D — Install the Systems Manager agent (SSM Agent) on the instances. SSM Agent là phần mềm chạy trong instance, chủ động kết nối ra endpoint của Systems Manager để nhận lệnh. Không có agent thì Systems Manager không biết máy đó tồn tại, nên nó không xuất hiện trong danh sách Session Manager. Với custom AMI, việc cài agent là bước phải làm thủ công.

A — Add permissions for Session Manager to the instance profile. Mặc định Systems Manager không có quyền thao tác trên instance của bạn. Quyền được cấp thông qua IAM instance profile — vật chứa truyền thông tin IAM role vào EC2 instance. Agent dùng credential tạm thời lấy từ instance profile để đăng ký và duy trì kết nối. Yêu cầu này áp cho mọi năng lực của Systems Manager, không riêng Session Manager.

Hai việc này bổ sung cho nhau: cài agent mà không có quyền thì agent chạy nhưng đăng ký thất bại; có quyền mà không có agent thì không có gì để dùng quyền đó.

❌ Vì sao các phương án còn lại sai

B — Add access keys to the instance that grant access to Session Manager. Đây là phương án gần đúng nhất vì nó cũng nói về việc cấp quyền — đúng hướng nhưng sai cơ chế. Cách chuẩn để cấp quyền cho một EC2 instance là IAM instance profile kèm IAM policy, không phải nhét access key vào máy. Access key là credential dài hạn, phải tự xoay vòng, và nếu instance bị xâm nhập thì key rò rỉ luôn.

C — Run Systems Manager Inventory to refresh the instance data. Inventory là tính năng thu thập thông tin phần mềm/cấu hình từ các managed instance đã đăng ký, không phải nút "làm mới danh sách". Đúng như bản giải thích gốc nêu: chạy Inventory cũng chẳng có tác dụng cho tới khi bạn đã cài SSM Agent và cấp đủ quyền — mà lúc đó thì instance tự hiện ra rồi, không cần chạy Inventory nữa. Phương án này nhắm vào triệu chứng ("không thấy trong danh sách") thay vì nguyên nhân.

E — Modify the instance security group to allow inbound traffic on SSH port 22. Sai ở đúng điểm tạo nên giá trị của Session Manager: nó không cần mở port 22 inbound. Kết nối do agent khởi tạo đi ra (outbound) tới endpoint Systems Manager, rồi phiên làm việc chạy qua đường đó. Đề bài có chữ "SSH session" dễ làm người đọc phản xạ theo hướng SSH truyền thống — đây chính là cái bẫy. Mở port 22 vừa không giải quyết vấn đề, vừa mở rộng bề mặt tấn công một cách vô ích.

📌 Điểm cần nhớ

• Instance không hiện trong Session Manager (hoặc trong danh sách managed instance) gần như luôn quy về hai nguyên nhân: thiếu SSM Agent hoặc thiếu quyền qua IAM instance profile. Kiểm hai thứ này trước mọi thứ khác.
• Custom AMI trong đề bài là tín hiệu rất mạnh cho việc SSM Agent chưa được cài — AMI dựng sẵn của AWS mới có sẵn agent.
• Cấp quyền cho EC2 luôn dùng IAM instance profile / IAM role, không bao giờ dùng access key đặt trong máy. Thấy phương án nào nói "add access keys to the instance" thì gần như chắc chắn là mồi nhử.
• Session Manager không đòi mở inbound port 22, không cần bastion host, không cần key pair — agent tự mở kết nối outbound. Nhìn thấy "mở port 22" trong câu hỏi về Session Manager là loại được ngay.
• Phân biệt vai trò từng năng lực Systems Manager: Inventory thu thập dữ liệu từ máy đã quản lý được, không dùng để làm cho máy được quản lý.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một ứng dụng dùng Amazon ElastiCache Memcached cluster, lưu lượng tăng mạnh, và người quản trị cần chuyển sang instance type lớn hơn, nhiều bộ nhớ hơn. Câu hỏi: phải làm gì để thực hiện thay đổi đó?

Cụm từ quyết định đáp án là "Memcached" — chứ không phải "ElastiCache" nói chung. Bốn phương án đều là những lời gọi API có thật của ElastiCache, và nếu đề nói "Redis" thì đáp án sẽ khác hẳn. Cụm thứ hai đáng chú ý là "larger instance type with more memory", tức đây là scale up theo chiều dọc (đổi node type), không phải scale out (thêm node cùng loại). Hai từ khoá này ghép lại loại được ba phương án còn lại.

Điểm mấu chốt: với engine Memcached, ElastiCache không cho phép thay đổi node type của một cluster đang tồn tại. Cách duy nhất để scale up theo chiều dọc là tạo cluster mới với node type mong muốn, rồi chuyển ứng dụng sang endpoint mới và xoá cluster cũ.

✅ Vì sao đáp án đúng là đúng

B — Create a new cache cluster with a new node type using the CreateCacheCluster API.

Memcached trong ElastiCache là bộ nhớ đệm thuần tuý, không có cơ chế bền hoá hay sao chép dữ liệu, nên AWS không cung cấp đường thay đổi node type tại chỗ. Quy trình scale up chuẩn là:

1. Gọi CreateCacheCluster với CacheNodeType mới (loại nhiều memory hơn).
2. Cập nhật endpoint trong cấu hình ứng dụng để trỏ sang cluster mới.
3. Xoá cluster cũ sau khi ứng dụng đã chuyển xong.

Hệ quả cần chấp nhận: cache khởi đầu rỗng — cluster mới phải được "hâm nóng" lại từ nguồn dữ liệu gốc. Đây là đặc tính của Memcached, không phải sai sót thao tác.

❌ Vì sao các phương án còn lại sai

A — Use the CreateReplicationGroup API and specify a new CacheNodeType. Đây là phương án dễ nhầm nhất vì nó có nhận tham số node type. Nhưng CreateReplicationGroup là API dành cho Redis — replication group là khái niệm primary/replica của Redis. Memcached không có replication group nào cả, nên gọi API này trên một triển khai Memcached là sai công cụ ngay từ đầu, chưa nói tới việc nó tạo tài nguyên mới chứ không đụng gì tới cluster Memcached hiện có.

C — Modify the existing cache cluster using the ModifyCacheCluster API. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. ModifyCacheCluster là cách đổi node type — nhưng chỉ với Redis. Với Memcached, thao tác thay đổi node type trên cluster đang chạy không được hỗ trợ. Nếu đề bài đổi một chữ "Memcached" thành "Redis" thì C sẽ là đáp án. Cần đọc kỹ engine trước khi chọn.

D — Specify a new CacheNodeType with the ModifyCacheParameterGroup API. Sai vì nhầm phạm vi tác dụng của API. ModifyCacheParameterGroup chỉ sửa các tham số cấu hình engine (kiểu như giới hạn kích thước item, số luồng…) áp cho cluster. Node type không phải là một parameter trong parameter group — nó là thuộc tính hạ tầng của cluster. API này không nhận CacheNodeType, nên lời gọi sẽ không hợp lệ.

📌 Điểm cần nhớ

• Đọc engine trước khi đọc phương án. Rất nhiều câu ElastiCache phân biệt Redis với Memcached bằng đúng một từ; cùng một API có thể đúng với engine này và sai với engine kia.
• Memcached: không đổi node type tại chỗ. Muốn scale up thì tạo cluster mới bằng CreateCacheCluster, trỏ endpoint sang, rồi xoá cluster cũ — và chấp nhận cache rỗng lúc đầu.
• ModifyCacheParameterGroup chỉ chạm tới tham số engine, không chạm tới hạ tầng (node type, số node). Thấy phương án ghép "parameter group" với thuộc tính phần cứng thì gần như chắc chắn là sai.
• CreateReplicationGroup là địa hạt của Redis (primary/replica). Xuất hiện trong câu hỏi về Memcached thì đó là mồi nhử.
• Phân biệt scale up (node type lớn hơn) với scale out (thêm node) — Memcached scale out dễ dàng bằng cách thêm node, nhưng scale up thì phải dựng cluster mới.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một website bán hàng chạy sau Application Load Balancer (ALB). Quản trị viên thấy rất nhiều lỗi 404 phát ra từ một địa chỉ IP nguồn duy nhất, lặp lại vài giây một lần, và nghi ngờ đây là bot đang cào dữ liệu. Câu hỏi chốt lại: dùng service nào để chặn hoạt động khả nghi đó.

Cụm từ quyết định đáp án là "block the suspected malicious activity" — đề đòi hành động chặn, chứ không phải phát hiện, đánh giá hay ghi nhật ký. Cụm thứ hai quan trọng không kém là "Application Load Balancer" và "404 errors": đây là lưu lượng HTTP/HTTPS ở tầng ứng dụng, đến từ một IP đơn lẻ. Ba chi tiết này gộp lại loại luôn những service chỉ quan sát, và loại cả những service chuyên xử lý tấn công băng thông ở tầng mạng.

✅ Vì sao đáp án đúng là đúng

B — AWS WAF là web application firewall, giám sát các request HTTP và HTTPS được chuyển tới Application Load Balancer, Amazon CloudFront hoặc Amazon API Gateway REST API — đúng kiến trúc mà đề nêu.

Điểm mấu chốt: WAF không dừng ở việc quan sát mà kiểm soát được quyền truy cập vào nội dung. Dựa trên các điều kiện do bạn khai báo — ví dụ địa chỉ IP mà request xuất phát, hoặc giá trị của query string — ALB (hoặc CloudFront, API Gateway) sẽ hoặc trả về nội dung được yêu cầu, hoặc trả về HTTP 403 (Forbidden).

Tình huống trong đề khớp gần như từng chữ với khả năng đó: đã biết chính xác IP nguồn, chỉ cần một điều kiện dựa trên IP là request từ bot bị trả 403 ngay tại ALB, trước khi chạm tới ứng dụng.

❌ Vì sao các phương án còn lại sai

A — Amazon Inspector. Đây là service đánh giá bảo mật (security assessment): nó rà soát và báo cáo các vấn đề bảo mật, chứ không chặn được lưu lượng độc hại. Nó có thể nằm trong bức tranh bảo mật tổng thể, nhưng không đáp ứng động từ "block" mà đề yêu cầu.

C — AWS Shield Standard. Đây là phương án gần đúng nhất và là cái bẫy chính. Shield đúng là service bảo vệ khỏi tấn công DDoS, và nó cũng đứng chắn lưu lượng — nên thoạt nhìn có vẻ "chặn được". Chỗ nó hỏng là loại tấn công không khớp: hiện tượng trong đề không giống một cuộc tấn công từ chối dịch vụ, mà chỉ là một đối thủ đang cào dữ liệu. Một IP đơn lẻ gửi request vài giây một lần không phải là dạng lưu lượng ồ ạt mà Shield sinh ra để đối phó.

D — AWS CloudTrail. CloudTrail là service kiểm toán, ghi lại hoạt động API trong tài khoản AWS. Nó không hoạt động như một web firewall. Nhầm lẫn thường gặp ở đây là lẫn giữa "log lưu lượng người dùng truy cập website" với "log lời gọi API quản trị AWS" — CloudTrail thuộc vế sau, và dù thuộc vế nào thì ghi log cũng không phải là chặn.

📌 Điểm cần nhớ

• Bám vào động từ của đề: "block/chặn" đòi một service có khả năng cưỡng chế (AWS WAF, AWS Shield); "detect/assess/audit" mới là chỗ của Amazon Inspector hay AWS CloudTrail.
• AWS WAF gắn được vào ALB, CloudFront và API Gateway REST API — thấy một trong ba thành phần này trong đề cùng với yêu cầu lọc request là tín hiệu rất mạnh cho WAF.
• WAF ra quyết định theo điều kiện tầng ứng dụng (IP nguồn, giá trị query string…) và trả HTTP 403 cho request bị chặn.
• Phân biệt WAF với Shield theo bản chất mối đe doạ: lạm dụng ở tầng ứng dụng từ nguồn xác định được → WAF; tấn công DDoS → Shield. Đừng chọn Shield chỉ vì đề có chữ "malicious".

🧩 Phân tích nội dung câu hỏi

Đề mô tả một ứng dụng dùng EC2 instances để xử lý message từ hàng đợi Amazon SQS, và Amazon EC2 Auto Scaling đang scale in/out dựa trên CPU utilization. Triệu chứng: số message tồn trong queue tăng lên đáng kể. Câu hỏi yêu cầu chọn hành động khắc phục (remediate) vấn đề.

Cụm từ quyết định đáp án là "scales in and out based on CPU utilization" đặt cạnh "the number of messages in the SQS queue are increasing". Hai vế này chỉ thẳng vào mâu thuẫn: tín hiệu dùng để scale (CPU) không phản ánh đúng lượng công việc thật (số message đang chờ). Một worker có thể chờ I/O, chờ network, hoặc chỉ đơn giản là xử lý nhẹ CPU — khi ấy CPU vẫn thấp nên Auto Scaling không thêm instance, trong khi message vẫn dồn lại. Việc còn phải chú ý là chữ "remediate": đề hỏi cách chữa dứt nguyên nhân, chứ không phải cách giảm nhẹ hậu quả.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là A — Change the scaling policy to scale based upon the number of messages in the Amazon SQS queue.

Số message đang nằm trong queue chính là thước đo trực tiếp của khối lượng công việc chưa xử lý. Khi lấy chỉ số này làm cơ sở scale, Auto Scaling group sẽ bám sát đường cầu thực tế: queue dồn lên thì thêm instance để tiêu thụ nhanh hơn, queue vơi đi thì scale in để tiết kiệm. Đây đúng là kiểu bài mà AWS khuyến nghị dùng target tracking scaling policy trên một custom metric phản ánh lượng backlog của queue (ví dụ số message chờ tính trên mỗi instance), thay vì bám vào một chỉ số hạ tầng gián tiếp như CPU. Chuyển tín hiệu scale từ CPU sang chiều dài queue là hành động duy nhất trong danh sách chạm được vào nguyên nhân gốc: sai metric điều khiển việc scale.

❌ Vì sao các phương án còn lại sai

B — Increase the retention period of the Amazon SQS queue so messages are not lost. Đây là phương án dễ gây phân vân nhất, vì nó có giải quyết một rủi ro thật: message tồn lâu trong queue sẽ bị xoá khi hết retention period, kéo dài thời gian giữ sẽ tránh mất dữ liệu. Nhưng nó hỏng ở chỗ chỉ xử lý hậu quả, không xử lý nguyên nhân. Message vẫn dồn lại đúng như cũ, độ trễ xử lý vẫn tăng, chỉ là chúng nằm chờ lâu hơn trước khi biến mất. Đề hỏi "remediate the issue" — vấn đề ở đây là backlog không được tiêu thụ, chứ không phải mất message.

C — Change the scaling policy to scale based upon the memory utilization of the EC2 instances. Phương án này đúng hướng ở chỗ nhận ra "cần đổi metric", nhưng chọn sai metric. Thứ nhất, memory utilization không phải chỉ số EC2 gửi sẵn cho CloudWatch — hypervisor không nhìn thấy bộ nhớ bên trong guest OS, muốn có phải cài agent để đẩy custom metric. Thứ hai, quan trọng hơn: memory cũng chỉ là một chỉ số tài nguyên của instance, cùng loại với CPU. Nó không nói gì về số việc đang chờ trong queue, nên đổi từ CPU sang memory là đổi một tín hiệu gián tiếp lấy một tín hiệu gián tiếp khác — không có lý do gì để tin nó chính xác hơn.

D — Deploy an Elastic Load Balancer (ELB) to balance the load more evenly across the EC2 instances. Phương án này hiểu sai mô hình phân phối công việc của SQS. ELB phân phối các connection/request đến tới các target — nó đứng giữa client và server theo mô hình push. Còn SQS hoạt động theo mô hình pull: các EC2 instance tự poll queue để lấy message về xử lý. Không có request nào đi ngang qua load balancer để mà cân bằng, nên đặt một ELB vào kiến trúc này chẳng thay đổi gì. Ngoài ra, cơ chế poll vốn đã tự cân bằng tương đối: instance nào rảnh sẽ lấy được message tiếp theo. Vấn đề của đề bài là không đủ instance, chứ không phải tải phân bổ lệch giữa các instance đang có.

📌 Điểm cần nhớ

• Với kiến trúc worker đọc từ SQS, tín hiệu scale đúng là độ sâu của queue (số message chờ), không phải CPU hay memory của instance. Cách làm chuẩn là target tracking policy trên custom metric phản ánh backlog trên mỗi instance.
• Phân biệt push (ELB) và pull (SQS): ELB không đứng trước một queue được. Thấy phương án nào ghép load balancer vào luồng SQS thì gần như chắc chắn là sai.
• Memory utilization không có sẵn trong CloudWatch metrics mặc định của EC2 — phải cài agent. Đây là chi tiết bị hỏi lặp đi lặp lại trong các câu về monitoring và scaling.
• Đọc kỹ động từ trong đề: "remediate" / "resolve" đòi hành động chạm vào nguyên nhân gốc. Những phương án chỉ nới hạn mức, kéo dài thời gian giữ, hay tăng dung lượng chứa thường là bẫy "giảm nhẹ triệu chứng".

🧩 Phân tích nội dung câu hỏi

Đề mô tả một web application đặt sau Amazon CloudFront, dùng tên miền www.sample.com, và đã có sẵn một SSL certificate cho chính tên miền đó được cấp qua AWS Certificate Manager (ACM). Câu hỏi: SysOps administrator phải làm hai việc gì để bảo đảm traffic được mã hoá khi truyền (encrypted in transit)?

Cụm từ quyết định nằm ở hai chỗ:

• "an SSL certificate for www.sample.com has been created through ACM" — certificate đã có rồi, nhưng có không đồng nghĩa với đang được dùng. CloudFront chỉ dùng certificate này khi bạn khai www.sample.com là alternate domain name (CNAME) của distribution và chọn custom SSL certificate. Không khai thì distribution chỉ phục vụ qua tên miền *.cloudfront.net với certificate mặc định, và người dùng gõ www.sample.com sẽ gặp lỗi tên miền không khớp.
• "Ensuring encrypted traffic in transit" / "guarantee that the traffic is encrypted" — chữ guarantee loại bỏ mọi cấu hình chỉ cho phép HTTPS. Muốn bảo đảm thì phải ép, tức là không được để cửa HTTP mở.

Hai ràng buộc này chia năm phương án thành hai nhóm rõ rệt: nhóm động tới lớp TLS/HTTPS của viewer, và nhóm không liên quan gì tới mã hoá.

✅ Vì sao đáp án đúng là đúng

C — Thêm alternate domain name (CNAME) www.sample.com vào distribution và chọn custom SSL certificate. Đây là bước gắn certificate của ACM vào CloudFront. Sau bước này, CloudFront trình certificate của www.sample.com cho viewer, phiên TLS giữa client và CloudFront thiết lập được và hợp lệ. Thiếu bước này thì dù người dùng có gõ https:// cũng vẫn hỏng vì tên trên certificate không khớp tên miền yêu cầu.

D — Đặt Viewer Protocol Policy ở mọi cache behavior thành redirect HTTP sang HTTPS. Viewer Protocol Policy là nơi quyết định CloudFront đối xử thế nào với request HTTP đến từ viewer. Chọn redirect nghĩa là mọi request HTTP đều bị chuyển hướng sang HTTPS, nên dữ liệu luôn đi qua kênh đã mã hoá. Chữ every cache behavior cũng quan trọng: policy này đặt theo từng cache behavior, bỏ sót một behavior là chừa lại một đường đi không mã hoá.

Hai bước bổ trợ cho nhau: C dựng được kênh HTTPS hợp lệ, D bắt buộc traffic phải đi qua kênh đó.

❌ Vì sao các phương án còn lại sai

A — Tạo AWS WAF web ACL gắn vào CloudFront distribution. WAF là web application firewall: nó lọc request theo rule, chặn các mẫu tấn công tầng ứng dụng. Nó không tham gia vào việc thiết lập TLS và không quyết định request đến bằng HTTP hay HTTPS. Đây là biện pháp bảo mật, nhưng không phải bảo mật đường truyền — đề hỏi encryption in transit, không hỏi bảo vệ ứng dụng nói chung.

B — Bật CloudFront Origin Shield cho origin. Origin Shield là một lớp cache trung gian thêm vào trước origin, mục đích giảm số request đánh xuống origin và tăng tỷ lệ cache hit. Nó liên quan tới hiệu năng và tải của origin, không liên quan tới mã hoá. Ngoài ra đề hỏi về traffic tới CloudFront (phía viewer), còn Origin Shield nằm ở phía origin — sai cả về mục đích lẫn về đoạn đường đang được hỏi.

E — Đặt Viewer Protocol Policy thành cho phép cả HTTP lẫn HTTPS. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu này: nó đúng chỗ (Viewer Protocol Policy, đúng cache behavior) nhưng chọn sai giá trị. "HTTP and HTTPS" nghĩa là CloudFront vẫn nhận và phục vụ request HTTP nguyên trạng, không chuyển hướng. Chỉ cần một client gõ http://www.sample.com là dữ liệu đi trên đường không mã hoá. Nó cho phép mã hoá chứ không bảo đảm mã hoá, trong khi đề đòi bảo đảm. So với D, khác biệt chỉ nằm ở chỗ redirect hay không — và chính chỗ đó quyết định câu trả lời.

📌 Điểm cần nhớ

• Certificate cấp từ ACM chỉ có tác dụng khi đã gắn vào distribution: khai alternate domain name (CNAME) rồi chọn custom SSL certificate. Có certificate trong ACM không tự động bảo vệ được gì.
• Viewer Protocol Policy điều khiển đoạn client → CloudFront; muốn ép mã hoá thì chọn "Redirect HTTP to HTTPS" (hoặc "HTTPS Only"), tuyệt đối không chọn "HTTP and HTTPS".
• Policy này đặt theo từng cache behavior — sửa thì phải quét hết mọi behavior, không chỉ default behavior.
• Gặp đề có chữ ensure/guarantee mà mã hoá, hãy loại ngay những phương án chỉ mang nghĩa allow/permit. Và phân biệt rõ: WAF là lọc request, Origin Shield là cache/giảm tải origin — cả hai đều không phải cơ chế mã hoá đường truyền.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một tình huống rất cụ thể: yêu cầu bảo mật là lưu lượng tới S3 bucket phải nằm trong mạng AWS và dùng private IP, VPC endpoint đã được tạo, endpoint policy đã đúng quyền, nhưng EC2 trong VPC vẫn không truy cập được bucket. Câu hỏi là "MOST likely cause" — nguyên nhân khả dĩ nhất.

Cụm từ quyết định đáp án nằm ở hai chỗ ghép lại:

• "A VPC endpoint has been created and an endpoint policy with the correct permissions has been set up" — đề đã chủ động loại bỏ hai nguyên nhân đầu tiên mà người ta hay nghi ngờ. Endpoint có rồi, policy đúng rồi.
• "must remain within the AWS network using private IP addresses" — ràng buộc này loại thẳng mọi phương án dính tới địa chỉ public.

Khi đề nói "đã tạo endpoint" và "policy đã đúng", nó đang dẫn bạn tới bước thứ ba của quy trình dựng gateway endpoint mà đề cố tình không nhắc tới: cập nhật route table. Đó là kiểu ra đề "liệt kê hai trong ba bước, hỏi bước còn thiếu".

✅ Vì sao đáp án đúng là đúng

A — "The subnet does not have the VPC endpoint as a target in the route table" là đáp án đúng.

S3 dùng gateway endpoint (khác với interface endpoint dựa trên ENI và private IP trong subnet). Gateway endpoint hoạt động bằng cách thêm một route vào route table: đích đến là prefix list của S3, target là chính endpoint đó. Cấu hình một gateway endpoint gồm ba việc:

1. Tạo endpoint trong VPC
2. Gắn endpoint policy
3. Thêm route trỏ tới endpoint trong route table của các subnet cần dùng

Đề đã xác nhận việc 1 và 2 xong. Nếu route chưa được thêm vào route table gắn với subnet chứa EC2, thì khi instance gọi tới S3, bảng định tuyến không có mục nào trỏ traffic đó sang endpoint. Traffic sẽ đi theo route mặc định — ra internet gateway hoặc NAT, và trong một subnet private không có đường ra thì đơn giản là không tới đâu cả. Đó chính xác là triệu chứng "vẫn không truy cập được" mà đề mô tả.

Cần nhớ: gateway endpoint là cơ chế định tuyến, không phải cơ chế "bật lên là chạy". Endpoint có tồn tại mà route table không trỏ tới thì nó nằm đó vô dụng.

❌ Vì sao các phương án còn lại sai

B — "The bucket policy must be configured to all private IP addresses"

Đây là phương án gần đúng nhất và đáng phân tích kỹ. Bucket policy có thể chặn truy cập qua endpoint thật — bạn hoàn toàn có thể viết điều kiện dựa trên aws:SourceVpce hoặc aws:SourceVpc để giới hạn ai được gọi vào bucket. Nhưng nó hỏng ở chỗ: đề hỏi nguyên nhân khả dĩ nhất, mà một bucket policy đang sẵn có điều kiện lọc theo IP để rồi chặn nhầm chính traffic private này là tình huống hiếm — đề không hề nhắc tới bất kỳ bucket policy hạn chế nào. Ngoài ra bản thân cách diễn đạt "cấu hình cho tất cả private IP" cũng không phải cách kiểm soát truy cập qua endpoint mà AWS khuyến nghị. So với một bước cấu hình bắt buộc bị bỏ sót, đây là giả thuyết yếu hơn hẳn.

C — "Storage class analytics must be enabled to use private IP addresses"

Storage class analytics là tính năng phân tích mẫu truy cập dữ liệu trong bucket để gợi ý chuyển sang storage class rẻ hơn. Nó thuần tuý là công cụ quan sát và tối ưu chi phí lưu trữ, không liên quan gì tới mạng, định tuyến hay quyền truy cập. Bật hay tắt nó không thay đổi một dòng nào trong đường đi của gói tin. Phương án này chỉ ghép hai khái niệm không dính dáng vào nhau.

D — "The EC2 instances need to have an Elastic IP address assigned"

Đây là phương án mâu thuẫn trực tiếp với yêu cầu của đề. Elastic IP là địa chỉ public tĩnh; gán EIP nghĩa là cho instance đi ra internet bằng địa chỉ công cộng — đúng thứ mà yêu cầu bảo mật trong đề nói phải tránh. Điểm cốt lõi của VPC endpoint chính là instance không cần public IP để nói chuyện với dịch vụ AWS. Chọn D là phá bỏ luôn lý do người ta dựng endpoint ngay từ đầu.

📌 Điểm cần nhớ

• S3 dùng gateway endpoint, và gateway endpoint sống bằng route table. Ba bước bắt buộc: tạo endpoint → gắn endpoint policy → thêm route trỏ tới endpoint. Đề nào kể hai bước đầu rồi báo "vẫn không kết nối được" thì gần như chắc chắn đang hỏi bước thứ ba.
• Đọc kỹ những gì đề đã tuyên bố là "đã làm xong". Chúng không phải chi tiết trang trí — chúng là cách người ra đề loại bỏ các phương án nhiễu và thu hẹp về đúng một nguyên nhân.
• Bất kỳ phương án nào đòi public IP (Elastic IP, internet gateway, NAT) đều tự loại khi đề yêu cầu traffic phải ở trong mạng AWS bằng private IP.
• Phân biệt lỗi tầng mạng và lỗi tầng quyền. Endpoint policy và bucket policy là tầng quyền; route table là tầng định tuyến. Khi đề đã khẳng định phần quyền đúng rồi, hãy tìm lỗi ở tầng định tuyến.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một kiến trúc quen thuộc: EC2 nằm sau Application Load Balancer, phía trước là CloudFront distribution lấy ALB làm origin, và Route 53 có bản ghi CNAME trỏ tên miền về CloudFront. Toàn bộ phần hạ tầng này chạy đúng — trang web vẫn phục vụ được, không ai báo lỗi kết nối.

Cụm từ quyết định nằm ở câu tả triệu chứng: "mobile users are inadvertently being served with the desktop version of the website". Đây không phải sự cố mạng, không phải sự cố định tuyến, không phải sự cố chứng chỉ. Đây là sự cố nội dung trả về sai biến thể — ứng dụng gốc vẫn biết cách sinh bản mobile, nhưng nó không còn nhận ra người dùng đang dùng thiết bị gì.

Lý do rất đặc trưng của CloudFront: theo mặc định, CloudFront không chuyển tiếp mọi header của client tới origin, và nó dùng tập header được chuyển tiếp làm một phần cache key. Header cho biết loại thiết bị chính là User-Agent. Không được chuyển tiếp, origin nhìn request nào cũng như nhau và trả bản mặc định — bản desktop. Tệ hơn, dù origin có đoán đúng một lần thì bản đó cũng bị cache và phục vụ lại cho mọi người.

Vậy câu hỏi thật sự là: làm sao để thông tin thiết bị của client đi được tới origin, và làm sao để cache phân biệt được hai biến thể. Đáp án phải tác động vào behavior (chiều client → CloudFront → origin), chứ không phải vào lớp mạng.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là C — Modify the CloudFront distribution behavior to include the User-Agent header in the forwarding configuration.

Cấu hình forward User-Agent nằm trong cache behavior của distribution, tức là phần điều khiển cách CloudFront xử lý request đến từ người dùng. Khi bật:

• CloudFront giữ lại header User-Agent của chính client và gửi kèm khi đi lấy nội dung từ ALB. Ứng dụng trên EC2 đọc được chuỗi đó, nhận ra là trình duyệt di động, và sinh ra bản mobile.
• User-Agent trở thành một phần của cache key, nên bản mobile và bản desktop được lưu thành hai mục cache riêng. Người dùng mobile tiếp theo nhận đúng bản mobile chứ không nhận nhầm bản desktop đã cache trước đó.

Đây đúng là mắt xích bị đứt trong tình huống của đề: origin có logic phân biệt thiết bị, chỉ thiếu dữ liệu đầu vào để chạy logic đó.

❌ Vì sao các phương án còn lại sai

D — Thêm custom User-Agent header trong phần origin settings. Đây là phương án gần đúng nhất và là bẫy chính của câu này, vì nó cũng nhắc tới User-Agent. Nhưng origin custom headers là header do CloudFront tự đặt ra và gắn thêm vào request gửi tới origin — giá trị của nó là một hằng số bạn gõ vào console, giống hệt nhau cho mọi request. Nó không mang thông tin gì về thiết bị của người dùng thật. Origin sẽ nhận cùng một chuỗi cố định từ mọi khách, và tiếp tục trả bản desktop cho tất cả. Ghi nhớ đúng chỗ hỏng: origin custom header là chiều CloudFront → origin và mang giá trị tĩnh; forward header trong behavior là chiều client → origin và mang giá trị thật của client.

B — Bật IPv6 trên ALB và trỏ origin của CloudFront sang dualstack endpoint. Đây là thay đổi ở tầng mạng, quyết định CloudFront kết nối tới ALB bằng IPv4 hay IPv6. Giao thức IP không mang bất kỳ thông tin nào về loại thiết bị hay trình duyệt. Kể cả khi cấu hình chạy hoàn hảo, origin vẫn không biết ai là mobile — triệu chứng trong đề không đổi một chút nào.

A — Bật IPv6 trên CloudFront distribution và cập nhật bản ghi Route 53 sang dualstack. Cùng một loại nhầm lẫn với B, chỉ đổi chỗ áp dụng sang phía client và DNS. Việc này mở rộng khả năng truy cập cho client chỉ có IPv6 — một cải thiện hợp lệ về mặt hạ tầng, nhưng hoàn toàn không liên quan tới việc nhận diện thiết bị. Nó không tác động gì tới header mà origin nhận được, nên bản desktop vẫn được trả cho người dùng mobile.

Điểm chung của A và B: đề mô tả một lỗi về nội dung, còn hai phương án này chữa ở tầng vận chuyển. Đọc kỹ triệu chứng là loại được cả hai ngay lập tức.

📌 Điểm cần nhớ

• CloudFront mặc định không chuyển tiếp hết header của client, và tập header được chuyển tiếp cũng là một phần của cache key. Origin cần đọc header nào thì header đó phải được khai báo forward trong cache behavior.
• Phân biệt cho rõ hai khái niệm dễ lẫn: forward header (behavior) mang giá trị thật từ client tới origin; origin custom header (origin settings) là giá trị tĩnh do CloudFront tự thêm vào, thường dùng để origin xác minh request đến từ CloudFront chứ không dùng để nhận diện người dùng.
• Triệu chứng "nội dung trả về sai biến thể" (desktop/mobile, sai ngôn ngữ, sai vùng) gần như luôn quy về header hoặc cache key, không phải IPv6, dualstack hay Route 53.
• Khi CloudFront cần phục vụ nhiều biến thể của cùng một URL, hãy nghĩ ngay: thông tin phân biệt biến thể có nằm trong cache key không? Nếu không, một bản sẽ bị cache và trả cho tất cả mọi người.

🧩 Phân tích nội dung câu hỏi

Một công ty vừa gặp sự cố bảo mật và quyết định chặn truy cập công khai vào HTTP (TCP port 80), bắt buộc mọi lưu lượng web đi vào phải dùng HTTPS (TCP port 443). Nhiệm vụ của SysOps Administrator là báo cáo tuân thủ (compliance reporting) cho các security group trong Amazon VPC.

Cụm từ quyết định đáp án nằm ngay ở câu hỏi cuối: "near real-time compliance reporting" — báo cáo tuân thủ gần thời gian thực. Hai chữ khoá tách bạch:

• "compliance": bài toán này thuộc phạm trù đánh giá cấu hình tài nguyên có đúng chuẩn hay không, chứ không phải quét lỗ hổng hay khuyến nghị chung chung.
• "near real-time": bất kỳ cơ chế nào chạy theo lịch định kỳ hoặc theo mẻ quét đều bị loại, vì giữa hai lần chạy sẽ có khoảng mù mà một security group mở port 80 vẫn tồn tại mà không ai biết.

Ràng buộc thứ hai chính là thứ phân biệt các phương án nhìn qua đều "làm được việc": cả bốn phương án đều có thể phát hiện security group mở port 80, nhưng chỉ một cái phản ứng theo thay đổi cấu hình thay vì theo đồng hồ.

✅ Vì sao đáp án đúng là đúng

C — Dùng AWS Config, bật rule restricted-common-ports và thêm port 80 vào tham số.

AWS Config là dịch vụ theo dõi cấu hình tài nguyên AWS và đánh giá chúng theo các rule. Điểm mấu chốt: AWS Config đánh giá lại tài nguyên khi cấu hình của tài nguyên đó thay đổi, nên khi ai đó sửa một security group để mở port 80, rule được kích hoạt và trạng thái tuân thủ cập nhật gần như tức thì — đúng nghĩa "near real-time".

Rule restricted-common-ports kiểm tra xem các security group đang dùng có cho phép lưu lượng TCP đi vào không giới hạn tới các port được chỉ định hay không. Rule ở trạng thái COMPLIANT khi lưu lượng TCP đi vào tới những port đó bị hạn chế nguồn. Quan trọng là rule này nhận tham số danh sách port — quản trị viên chỉ cần thêm 80 vào danh sách là rule khớp đúng yêu cầu của đề. Đây cũng là lý do phương án này vừa vặn: không cần viết code, không cần dựng thêm hạ tầng, chỉ bật một managed rule và truyền tham số. (Lưu ý rule này áp dụng cho IPv4.)

Ngoài ra AWS Config cung cấp sẵn dashboard tuân thủ và lịch sử cấu hình, tức là phần "reporting" mà đề yêu cầu cũng có luôn, không phải tự dựng.

❌ Vì sao các phương án còn lại sai

A — Lên lịch AWS Lambda chạy mỗi giờ để quét và đánh giá toàn bộ security group rồi gửi báo cáo. Đây là phương án gần đúng nhất về mặt kết quả: hàm Lambda hoàn toàn có thể gọi API để liệt kê security group và tìm rule mở port 80. Nhưng nó hỏng ở chỗ chu kỳ chạy mỗi giờ không phải near real-time — một security group bị mở sai có thể phơi ra Internet gần một tiếng trước khi báo cáo phát hiện. Ngoài ra đây là giải pháp tự viết và tự bảo trì, trong khi AWS đã có managed rule làm đúng việc này.

B — Dùng Amazon Inspector để đánh giá security group trong các lần quét và gửi báo cáo hoàn tất. Sai ở hai tầng. Thứ nhất, Inspector làm việc theo mô hình quét (scan), và báo cáo chỉ có khi lần quét hoàn tất — lại là mô hình theo mẻ, không phải near real-time, đúng như lý do bị loại. Thứ hai, Inspector định hướng vào đánh giá bảo mật/lỗ hổng của workload chứ không phải công cụ báo cáo tuân thủ cấu hình theo rule tham số hoá như AWS Config. Dùng nó ở đây là chọn nhầm dịch vụ cho nhầm loại bài toán.

D — Bật AWS Trusted Advisor, tạo CloudWatch alarm kích hoạt khi có cảnh báo Red cho check "unrestricted ports". Nghe rất hợp lý vì Trusted Advisor thật sự có check về security group mở port không giới hạn, và thật sự phát metric sang CloudWatch để đặt alarm. Nhưng nó hỏng đúng ở chi tiết: với check này, port 80 nằm ở mức Green chứ không phải Red. Trusted Advisor coi port 80 mở là chuyện bình thường của một web server, nên alarm bắt theo Red sẽ không bao giờ kêu cho đúng tình huống đề đưa ra. Đây là kiểu bẫy "cơ chế đúng nhưng ngưỡng sai" — dựng xong hệ thống giám sát mà nó im lặng vĩnh viễn. Thêm nữa, tiêu chí phân loại của Trusted Advisor là cố định, không cho tự khai port cần kiểm như tham số của AWS Config.

📌 Điểm cần nhớ

• Thấy cụm "near real-time" + "compliance" trong đề AWS thì phản xạ đầu tiên là AWS Config: nó đánh giá lại khi cấu hình thay đổi, khác hẳn các cơ chế chạy theo lịch.
• Bất kỳ phương án nào có chữ "schedule", "hourly", "during scans" đều tự loại mình khỏi yêu cầu near real-time, dù logic nghiệp vụ bên trong có đúng đến đâu.
• restricted-common-ports nhận tham số danh sách port — nhớ được điều này thì phân biệt ngay với các check có ngưỡng cố định.
• Trusted Advisor không cho tuỳ biến tiêu chí cảnh báo. Khi đề yêu cầu kiểm một port cụ thể theo chính sách riêng của công ty, Trusted Advisor gần như luôn là phương án sai; port 80 ở check unrestricted ports được xếp Green nên alarm theo Red sẽ không kích hoạt.
• Phân vai dịch vụ: AWS Config = tuân thủ cấu hình theo rule; Amazon Inspector = đánh giá bảo mật/lỗ hổng theo mẻ quét; Trusted Advisor = khuyến nghị tổng quát với tiêu chí do AWS định sẵn.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một công ty tư vấn triển khai ứng dụng cho nhiều khách hàng trong cùng một AWS account và cùng một Region. Mỗi ứng dụng dùng chung một base CloudFormation template, và template đó tạo một VPC mới cho mỗi ứng dụng. Lần triển khai gần nhất — cho một khách hàng mới — thất bại. Câu hỏi yêu cầu tìm nguyên nhân khả dĩ nhất.

Cụm từ quyết định nằm ở ba mảnh ghép lại:

• "a single AWS account and AWS Region" — mọi thứ dồn vào một ranh giới hạn mức duy nhất, vì service quota của VPC tính theo cặp account + Region.
• "configures a new VPC for each application" — số VPC tăng tuyến tính theo số khách hàng, tức là có một tài nguyên đang tích luỹ dần theo thời gian.
• "for a new customer" kết hợp với việc cùng template đó đã chạy thành công nhiều lần trước đó — nghĩa là bản thân template không sai, thứ đã đổi là trạng thái của account, không phải nội dung template.

Ba mảnh đó gộp lại vẽ ra đúng một kịch bản: cứ thêm khách hàng là thêm một VPC, đến một lúc nào đó chạm trần hạn mức.

✅ Vì sao đáp án đúng là đúng

B — The account has reached the default limit for VPCs allowed.

Số VPC không mặc định (nondefault VPC) mà một account được tạo trong một Region bị giới hạn bởi service quota mặc định, và giá trị mặc định này khá nhỏ so với nhu cầu của một mô hình "mỗi khách hàng một VPC". Khi CloudFormation gọi API tạo VPC mà quota đã chạm trần, lời gọi bị từ chối, stack thất bại và rollback — dù template hoàn toàn hợp lệ.

Đây là kiểu lỗi rất đặc trưng: hôm qua chạy được, hôm nay không, mà chẳng ai sửa gì trong template cả. Thứ thay đổi là số lượng VPC đã tồn tại trong account. Cách xử lý là mở yêu cầu tăng quota cho VPC trong Region đó (qua Service Quotas hoặc form hỗ trợ của AWS), sau đó deploy lại.

❌ Vì sao các phương án còn lại sai

A — CloudFormation template cần cập nhật lên phiên bản mới nhất. CloudFormation không có khái niệm "template phải là phiên bản mới nhất mới deploy được". Trường AWSTemplateFormatVersion là một nhãn định dạng, không phải cơ chế hết hạn — template cũ vẫn deploy bình thường. Quan trọng hơn, chính template này vừa deploy thành công cho các khách hàng trước, nên "phiên bản template" không thể là biến số đã thay đổi.

C — AMI dùng trong template không có sẵn ở Region đó. Đây là phương án gần đúng nhất, vì AMI thật sự mang tính Region-specific và AMI ID sai Region là một nguyên nhân deploy fail rất phổ biến trong đời thực. Nhưng nó hỏng ở chỗ khớp với dữ kiện đề: đề nói rõ mọi thứ diễn ra trong cùng một Region, và cùng template đó đã chạy trót lọt cho các khách hàng trước. Nếu AMI không tồn tại trong Region này thì lần deploy đầu tiên đã phải thất bại rồi, chứ không đợi tới khách hàng mới. Ngoài ra AMI liên quan tới EC2, còn phần đề nhấn mạnh là VPC.

D — Region đang bảo trì theo lịch nên tạm thời không dùng được. AWS không đưa nguyên một Region offline để bảo trì theo lịch; hạ tầng được thiết kế để bảo trì diễn ra ngầm mà không cắt dịch vụ toàn Region. Kể cả khi có sự cố thật, nó sẽ ảnh hưởng tới mọi khách hàng và mọi thao tác, chứ không chỉ đúng một stack của một khách hàng mới. Đây là phương án loại được ngay bằng hiểu biết vận hành cơ bản.

📌 Điểm cần nhớ

• Service quota của VPC tính theo từng account trong từng Region. Kiến trúc kiểu "mỗi khách hàng / mỗi ứng dụng một VPC" dồn hết vào một account sẽ chạm trần rất nhanh — đây là lý do các công ty tư vấn thường tách account riêng cho từng khách hàng thay vì gom chung.
• Triệu chứng "trước chạy được, giờ không, mà không ai sửa gì" gần như luôn trỏ về service limit/quota, không phải lỗi cú pháp hay cấu hình. Hãy tìm tài nguyên nào đang tích luỹ dần theo thời gian trong đề bài.
• Chi tiết "cùng template đã dùng thành công nhiều lần" là công cụ loại trừ mạnh trong các câu troubleshooting. Nó gạt sạch mọi phương án đổ lỗi cho nội dung template (AMI sai Region, cú pháp, phiên bản), vì những thứ đó sẽ fail ngay từ lần đầu.
• CloudFormation không tự sinh ra lỗi khi template "cũ", và AWS không tắt cả một Region để bảo trì — hai giả định này xuất hiện khá thường xuyên làm phương án nhiễu và luôn có thể loại ngay.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một Aurora DB cluster đang có một writer node và một reader node, chạy trên instance memory-optimized. Khi lưu lượng tăng đột ngột, CloudWatch cho thấy RAM tăng vọt và query latency tăng — tức là tải đọc đang dồn quá nhiều lên số instance ít ỏi hiện có.

Cụm từ quyết định đáp án nằm ở câu yêu cầu: thay đổi phải "ensure minimal disruption to the service and prevent any data loss" — gián đoạn tối thiểu và không mất dữ liệu. Đây chính là ràng buộc phân biệt các phương án gần giống nhau: nhiều phương án cũng "tăng năng lực xử lý", nhưng chỉ một phương án làm được điều đó mà không phải dừng dịch vụ hay di chuyển dữ liệu.

Cụm thứ hai đáng chú ý là "traffic fluctuates over the course of the day" và "during periods of sudden high demand" — vấn đề là các đợt tăng tải theo chu kỳ, không phải tải cao ổn định lâu dài. Điều này loại bỏ những giải pháp mang tính "xây lại hệ thống to hơn một lần cho xong".

✅ Vì sao đáp án đúng là đúng

C — Thêm một Aurora Replica vào cluster.

Aurora Replica dùng chung đúng một volume lưu trữ với instance primary trong cùng DB cluster. Đó là điểm mấu chốt: thêm replica không cần sao chép dữ liệu sang chỗ mới, không cần khôi phục từ snapshot, nên không có nguy cơ mất dữ liệu và cluster hiện tại vẫn phục vụ bình thường trong lúc replica mới được đưa vào — đúng yêu cầu "minimal disruption".

Về mặt hiệu năng, Aurora Replica được dùng chủ yếu để san bớt tải đọc khỏi instance primary. Ứng dụng trỏ các truy vấn đọc vào reader endpoint sẽ được phân phối sang nhiều replica thay vì dồn vào một reader duy nhất. Tải đọc rải ra nhiều instance → mỗi instance giữ ít working set trong bộ nhớ hơn và xử lý ít truy vấn đồng thời hơn → RAM usage và query latency đều giảm trong các đợt cao điểm. Đây là cách xử lý trực tiếp đúng triệu chứng mà CloudWatch báo.

❌ Vì sao các phương án còn lại sai

A — Chuyển cluster thành multi-master DB cluster.

Multi-master nhằm cho phép nhiều instance cùng ghi, tức là giải quyết nút thắt ở phía write. Nhưng triệu chứng trong đề là latency khi đọc và RAM cao do lượng truy vấn tăng, không có dấu hiệu nào cho thấy khả năng ghi là điểm nghẽn. Ngoài ra, chuyển đổi sang mô hình multi-master không tự nhiên giúp gì cho read traffic mà còn kéo theo độ phức tạp đáng kể (xử lý xung đột ghi, ràng buộc về cấu hình cluster). Đây là phương án sai cả về mục tiêu lẫn về chi phí vận hành.

B — Tăng gấp đôi dung lượng disk của cluster.

Đây là phương án dễ loại nhất vì nó nhắm sai tài nguyên hoàn toàn. Vấn đề đang nằm ở RAM và khả năng xử lý truy vấn, còn tăng disk chỉ mở rộng sức chứa lưu trữ. Không có chỗ nào trong đề nói cluster sắp hết chỗ chứa dữ liệu. Thêm nữa, Aurora vốn tự mở rộng lớp lưu trữ theo nhu cầu, nên đây không phải là nút chỉnh mà quản trị viên cần đụng tới để chữa latency.

C — đáp án đúng, đã giải thích ở trên.

D — Tạo snapshot rồi dựng cluster mới với instance memory-optimized lớn hơn.

Đây là phương án gần đúng nhất và cũng là cái bẫy chính của câu hỏi. Nó đúng ở chỗ instance lớn hơn thì có nhiều RAM hơn, quả thật sẽ giảm áp lực bộ nhớ. Nhưng nó hỏng ở đúng hai ràng buộc mà đề nêu ra:

• Restore từ snapshot sang một cluster mới rồi chuyển ứng dụng sang đó gây downtime trong quá trình chuyển đổi — vi phạm "minimal disruption".
• Snapshot là ảnh chụp tại một thời điểm; mọi ghi phát sinh sau thời điểm đó mà chưa được xử lý đều có nguy cơ mất dữ liệu — vi phạm "prevent any data loss".

Về bản chất, scale-up kiểu này là giải pháp dài hạn cho tải cao ổn định, trong khi đề mô tả các đợt tăng đột biến theo thời điểm trong ngày. Sai cả về cách thực hiện lẫn về loại vấn đề mà nó phù hợp.

📌 Điểm cần nhớ

• Aurora Replica dùng chung volume lưu trữ với primary. Chính đặc điểm này khiến việc thêm replica trở thành thao tác không sao chép dữ liệu, ít gián đoạn và không mất dữ liệu — mẫu câu trả lời quen thuộc cho mọi đề có ràng buộc "minimal downtime, no data loss" đi kèm áp lực đọc.
• Đọc kỹ triệu chứng để biết nút thắt nằm ở read hay write. Latency truy vấn đọc + RAM cao → scale out phía đọc (replica). Nghẽn ghi mới là địa hạt của multi-master.
• Phân biệt scale out với scale up. Thêm replica (scale out) phục vụ được tải dao động và làm nóng ngay; đổi sang instance lớn hơn qua snapshot/restore (scale up) hợp với tải cao ổn định nhưng phải trả giá bằng downtime.
• Tăng disk không bao giờ chữa được vấn đề CPU/RAM/latency. Khi đề nêu một loại tài nguyên bị nghẽn, hãy loại ngay những phương án mở rộng một loại tài nguyên khác.