Ngân hàng đề — AWS Certified Cloud Practitioner

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

Đề hỏi: triển khai các EC2 instance theo cách nào để khi một data center đơn lẻ hỏng thì vẫn còn instance chạy được.

Cụm từ quyết định là "if a single data center fails" — đề nói rõ phạm vi sự cố là một trung tâm dữ liệu, không phải một máy chủ đơn lẻ, cũng không phải cả một region. Đây chính là ranh giới phân biệt bốn phương án, vì mỗi phương án tương ứng với một cấp cô lập hạ tầng khác nhau: VPC là ranh giới mạng logic, subnet nằm bên trong một AZ, AZ là ranh giới cô lập vật lý, còn region là tập hợp nhiều AZ ở một vùng địa lý.

Muốn trả lời đúng, phải hỏi: cấp nào là cấp nhỏ nhất thực sự cô lập được lỗi vật lý của một data center? Câu trả lời là Availability Zone.

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

D — Across Availability Zones.

Một Availability Zone bao gồm một hoặc nhiều data center, và mỗi AZ được cô lập về mặt vật lý với các AZ khác trong cùng region — tách biệt về nguồn điện, làm mát và hạ tầng vật lý — đồng thời được nối với nhau bằng đường mạng tốc độ cao, độ trễ thấp.

Hệ quả trực tiếp: khi một data center gặp sự cố, những instance nằm ở AZ khác không bị ảnh hưởng. Vì vậy để có ứng dụng high availability, cách làm chuẩn là rải instance ra nhiều AZ trong cùng một VPC. Đây vừa là mức đủ để chịu được lỗi mà đề mô tả, vừa giữ được sự đơn giản trong vận hành nhờ mạng nội bộ tốc độ cao giữa các AZ.

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

C — Across regions. Đây là phương án gần đúng nhất và cũng là bẫy chính. Rải instance ra nhiều region có chịu được lỗi của một data center — thậm chí chịu được cả lỗi toàn region. Nhưng nó không cần thiết cho yêu cầu mà đề đặt ra, và đổi lại là độ phức tạp cùng chi phí tăng đáng kể: cần nhiều ELB (mỗi region một bộ), cần cơ chế phân giải tên phức tạp để điều hướng lưu lượng, và phát sinh chi phí truyền dữ liệu giữa các region. Trong đề trắc nghiệm AWS, khi yêu cầu chỉ là chịu lỗi một data center thì multi-AZ mới là câu trả lời "vừa đủ và đúng"; multi-region là kiến trúc cho disaster recovery ở quy mô lớn hơn hẳn.

B — Across subnets. Sai vì hiểu nhầm quan hệ phân cấp: subnet được tạo bên trong một AZ, mỗi subnet thuộc đúng một AZ. Nếu bạn tạo nhiều subnet nhưng chúng cùng nằm trong một AZ rồi rải instance vào đó, khi data center của AZ ấy hỏng thì mất toàn bộ instance. "Nhiều subnet" chỉ có ý nghĩa HA khi các subnet đó thuộc các AZ khác nhau — nhưng khi đó thứ tạo ra khả năng chịu lỗi vẫn là AZ, chứ không phải subnet.

A — Across VPCs. Sai vì VPC là ranh giới mạng logic, không phải ranh giới cô lập vật lý. Tách ra hai VPC không đảm bảo tài nguyên nằm ở hai data center khác nhau — hoàn toàn có thể cả hai VPC đều đặt instance trong cùng một AZ. Cách làm đúng là triển khai across AZs bên trong một VPC, chứ không phải tách VPC. Ngoài ra, tách VPC còn kéo theo việc phải nối mạng giữa chúng mà chẳng đem lại lợi ích chịu lỗi nào.

📌 Điểm cần nhớ

• Ghi nhớ đúng thứ tự phân cấp: Region → Availability Zone → Subnet. Subnet nằm trong AZ; AZ nằm trong region. Câu hỏi HA của AWS gần như luôn xoay quanh việc bạn chọn đúng cấp nào.
• AZ là đơn vị cô lập lỗi vật lý. Một AZ gồm một hoặc nhiều data center, cô lập vật lý với AZ khác và nối bằng mạng tốc độ cao — nên "chịu được lỗi một data center" đồng nghĩa với "rải qua nhiều AZ".
• VPC là ranh giới logic, không phải ranh giới chịu lỗi. Nhiều VPC không tự nó tạo ra khả năng chịu lỗi; multi-AZ trong một VPC mới là mô hình chuẩn.
• Khi đề chỉ yêu cầu chịu lỗi ở mức data center, đừng chọn multi-region dù nó "an toàn hơn": region-level chỉ dành cho yêu cầu chịu lỗi toàn region, và đi kèm nhiều ELB, phân giải tên phức tạp cùng chi phí truyền dữ liệu. Chọn mức vừa đủ với yêu cầu là nguyên tắc chấm điểm của kỳ thi.

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

Đề hỏi: những lựa chọn xác thực nào dùng được để xác thực khi gọi AWS API (chọn HAI).

Cụm từ quyết định là "authenticate using AWS APIs" — tức là chứng minh danh tính cho lời gọi lập trình tới AWS (qua AWS CLI, SDK, hoặc gọi thẳng API endpoint). Đây không phải câu hỏi về:

• đăng nhập giao diện AWS Management Console bằng người dùng + mật khẩu,
• đăng nhập vào hệ điều hành bên trong một EC2 instance,
• hay kiểm soát luồng mạng ra vào tài nguyên.

Danh sách phương án cố tình trộn ba nhóm khác nhau: credential của IAM (access keys, server certificates), cơ chế đăng nhập vào instance (key pairs), và kiểm soát mạng (security groups). Chỉ cần bám vào "AWS APIs" là loại được phần lớn.

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

A — Access keys. Đây là credential dài hạn gắn với một IAM user (hoặc với root account của AWS account). Cặp access key ID + secret access key được dùng để ký các request lập trình gửi tới AWS CLI hoặc AWS API — trực tiếp, hoặc thông qua AWS SDK. Đúng nguyên văn cái mà đề đang hỏi.

D — Server certificates. Đây là chứng chỉ SSL/TLS mà IAM có thể quản lý, và chúng được dùng để xác thực khi làm việc với một số dịch vụ AWS. Vì AWS công nhận đây là một dạng credential dùng để xác thực (chứ không phải chỉ để mã hoá kênh truyền), nó là đáp án đúng thứ hai trong danh sách này.

Hai phương án còn lại trong nhóm "nghe giống bảo mật" đều không phải là credential dùng để ký request API.

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

B — Security groups. Đây là firewall ở mức instance, kiểm soát traffic được phép đi vào/ra tài nguyên AWS. Nó trả lời câu hỏi "gói tin này có được đi qua không", chứ hoàn toàn không trả lời "ai đang gọi". Security group không mang danh tính, không ký được request, nên không thể là phương tiện xác thực với API.

C — Key pairs. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi — nó có là một cặp khoá mật mã, có liên quan tới bảo mật, nên dễ bị chọn. Nhưng key pair trong AWS dùng để mã hoá thông tin đăng nhập khi truy cập vào EC2 instance (lấy mật khẩu Administrator trên Windows, hoặc đăng nhập SSH trên Linux). Phạm vi của nó là bên trong instance — tức là tầng hệ điều hành — chứ không phải mặt phẳng điều khiển AWS. Cầm key pair không gọi được ec2:DescribeInstances.

E — Server passwords. "Server password" là mật khẩu để đăng nhập vào một máy chủ, và mật khẩu kiểu này không dùng để xác thực với API được. AWS API không nhận mật khẩu server làm credential; request lập trình phải được ký bằng credential của IAM. Đừng nhầm với mật khẩu Console — mật khẩu Console dùng để đăng nhập giao diện web cho con người, cũng không phải là cách xác thực khi gọi API.

📌 Điểm cần nhớ

• Phân biệt rõ ba tầng khi đọc đề: credential gọi API (access keys, server certificates), đăng nhập vào OS của instance (key pairs), và kiểm soát mạng (security groups). Đề luôn nêu rõ tầng nào, và cụm từ đó chính là chỗ chốt đáp án.
• Access keys = truy cập lập trình. Thấy chữ "AWS CLI", "AWS SDK", "programmatic access" hay "AWS API" thì access keys gần như luôn có mặt trong đáp án.
• Key pairs không phải credential của AWS API — chúng chỉ phục vụ việc vào được bên trong EC2 instance. Đây là bẫy lặp đi lặp lại ở cấp Cloud Practitioner.
• Security groups là firewall, không phải danh tính. Bất cứ khi nào phương án này xuất hiện trong câu hỏi về "authentication", nó gần như chắc chắn sai — nó thuộc về authorization ở tầng mạng, không phải xác thực người gọi.

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

Đề hỏi rất ngắn: "Where are Amazon EBS snapshots stored?" — snapshot của EBS volume được cất giữ ở đâu.

Cụm từ quyết định là "snapshots ... stored". Câu hỏi không hỏi EBS volume nằm ở đâu, cũng không hỏi snapshot được tạo bằng cách nào — nó hỏi nơi lưu trữ vật lý của bản sao lưu. Đây là chỗ dễ nhầm nhất, vì trực giác của nhiều người là "snapshot của EBS thì chắc nằm trong EBS". Bốn phương án được dựng đúng theo cái bẫy đó: một phương án đúng, ba phương án còn lại đều là một dịch vụ lưu trữ khác của AWS được đặt cạnh để gây phân vân.

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

Đáp án đúng theo tệp là A — On Amazon S3.

Khi bạn chụp một snapshot của EBS volume, AWS sao lưu dữ liệu của volume đó sang Amazon S3, dưới dạng bản sao tại một thời điểm (point-in-time backup). Đây chính là điều làm nên hai đặc tính quan trọng của EBS snapshot:

• Độ bền cao và không phụ thuộc vào một Availability Zone. EBS volume gắn với đúng một AZ, nhưng snapshot nằm trên S3 nên nó tồn tại ở phạm vi Region. Nhờ vậy bạn mới có thể tạo volume mới từ snapshot ở một AZ khác, hoặc sao chép snapshot sang Region khác.
• Snapshot là incremental. Chỉ những block đã thay đổi kể từ snapshot gần nhất mới được ghi thêm — điều này khớp với mô hình lưu trữ object của S3, và giải thích vì sao snapshot thứ hai trở đi thường tốn ít dung lượng hơn nhiều so với kích thước volume.

Một chi tiết đáng lưu ý: dù dữ liệu nằm trên S3, bạn không thấy các object đó trong bucket S3 của mình. AWS quản lý phần lưu trữ này; bạn chỉ làm việc với snapshot qua giao diện EC2/EBS. Nhưng câu hỏi hỏi "stored where", và câu trả lời về mặt kiến trúc vẫn là S3.

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

B — On an Amazon EBS instance store. Phương án này trộn hai thứ khác hẳn nhau thành một cụm nghe có vẻ hợp lý. Instance store là ổ đĩa gắn trực tiếp vào máy chủ vật lý chạy EC2 instance, và nó là ephemeral — dừng hoặc terminate instance là dữ liệu mất. Lấy một kho lưu trữ tạm thời làm nơi cất bản sao lưu là mâu thuẫn với chính mục đích của sao lưu. Ngoài ra "EBS instance store" không phải là một thứ có thật; EBS và instance store là hai loại lưu trữ tách biệt.

C — On an Amazon EFS filesystem. EFS là dịch vụ file system chia sẻ theo giao thức NFS, dùng cho nhiều instance cùng đọc/ghi một thư mục. Nó là một dịch vụ lưu trữ hợp lệ và bền, nên phương án này gần đúng hơn B ở chỗ đích đến không phải là bộ nhớ tạm. Nhưng nó sai ở chỗ cơ chế: EBS snapshot không được ghi vào EFS, và EFS cũng không phải nơi AWS dựng backend cho snapshot. Nếu bạn muốn có dữ liệu EBS trên EFS thì phải tự copy file bằng tay — đó là việc hoàn toàn khác với chụp snapshot.

D — Within the EBS block store. Đây là bẫy chính của câu hỏi, và cũng là phương án mà người chưa nắm kỹ hay chọn: "snapshot của EBS thì nằm trong EBS". Nhưng nếu snapshot nằm ngay trong chính lớp block storage của EBS, nó sẽ chịu chung phạm vi AZ với volume gốc, và những hành vi bạn thấy hằng ngày — sao chép snapshot sang Region khác, dựng volume ở AZ khác từ snapshot — sẽ không giải thích được. Snapshot cố ý được đặt ở một lớp lưu trữ khác với volume, chính là để bản sao lưu không chết cùng với thứ mà nó sao lưu.

📌 Điểm cần nhớ

• EBS snapshot lưu trên Amazon S3, dù bạn không nhìn thấy chúng trong bucket của mình — AWS quản lý phần lưu trữ đó.
• EBS volume gắn với một AZ; snapshot thì ở phạm vi Region. Đây là lý do snapshot dùng được để khôi phục sang AZ khác và sao chép sang Region khác.
• Snapshot là incremental: chỉ block thay đổi kể từ lần chụp trước mới được lưu thêm.
• Instance store là ephemeral — mất khi instance dừng/terminate, nên không bao giờ là đáp án cho câu hỏi về nơi lưu backup. Phân biệt rõ ba thứ trong đề thi: EBS (block, một AZ), EFS (file chia sẻ qua NFS), S3 (object, nền tảng cho snapshot).

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

Đề hỏi: cách dễ nhất (easiest way) để lưu một bản sao lưu của EBS volume lên Amazon S3.

Cụm từ quyết định đáp án là "easiest way". Đây không phải câu hỏi "cách nào có thể làm được", mà là "cách nào AWS đã dựng sẵn cho việc này". Nếu bỏ qua chữ easiest, có tới hai phương án nghe qua đều "chạy được" — và người học sẽ phân vân. Khi đề dùng những chữ như easiest, simplest, least operational overhead, managed, gần như luôn có một tính năng gốc (native feature) của AWS làm đúng việc đó, và mọi phương án tự dựng bằng tay đều là bẫy.

Ràng buộc thứ hai, ít lộ hơn: nguồn dữ liệu là EBS volume, đích là S3. Hai dịch vụ này khác họ — EBS là block storage gắn vào EC2, S3 là object storage. Phương án nào giả định S3 điều khiển trực tiếp được EBS volume là sai về mặt kiến trúc, chứ không phải sai vì "kém tiện".

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

Đáp án đúng theo tệp là B — Create a snapshot of the volume.

EBS snapshot chính là cơ chế AWS cung cấp sẵn để sao lưu dữ liệu của EBS volume: nó chụp trạng thái volume tại một thời điểm (point-in-time) và lưu dữ liệu đó trong Amazon S3. Người dùng không phải tạo bucket, không phải viết mã, không phải quản lý việc truyền dữ liệu — chỉ một thao tác trên console, CLI hoặc API là xong.

Một điểm nữa làm snapshot trở thành lựa chọn hiển nhiên: snapshot có tính incremental. Bản chụp đầu tiên chứa toàn bộ dữ liệu, còn những bản sau chỉ lưu các block đã thay đổi kể từ snapshot gần nhất. Nghĩa là vừa dễ thao tác, vừa tiết kiệm dung lượng lưu trữ so với việc tự sao chép toàn bộ volume mỗi lần. Snapshot cũng dùng được để khôi phục lại thành volume mới, đúng nghĩa "backup" chứ không chỉ là bản copy dữ liệu thô.

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

A — Use Amazon Kinesis to process the data and store the results in S3 Kinesis là dịch vụ dành cho dữ liệu streaming — luồng sự kiện, log, telemetry chảy vào liên tục theo thời gian thực. Nó không đọc được dữ liệu nằm sẵn trong một EBS volume, và cũng không có khái niệm "sao lưu block device". Đây là phương án sai hẳn về mục đích sử dụng dịch vụ, không phải sai vì phức tạp.

C — Use S3 lifecycle actions to backup the volume Đây là phương án dễ gây nhầm nhất vì nó có nhắc đúng tên S3 và đúng chữ "backup". Nhưng S3 lifecycle chỉ tác động lên các object đã nằm trong bucket S3: chuyển chúng sang storage class rẻ hơn sau một khoảng thời gian, hoặc xoá chúng khi hết hạn. Lifecycle không có khả năng đi ra ngoài S3 để lấy dữ liệu về — nó không nhìn thấy EBS volume và không thể khởi tạo một bản sao lưu. Nói cách khác, lifecycle là công cụ quản lý vòng đời dữ liệu đã có, không phải công cụ đưa dữ liệu vào.

D — Write a custom script to copy the data into a bucket Phương án này gần đúng nhất, và cần nói rõ nó hỏng ở đâu. Về mặt kỹ thuật, viết một script chạy trên EC2 instance để đọc dữ liệu trên volume rồi đẩy lên S3 là hoàn toàn khả thi — dữ liệu cuối cùng vẫn nằm trong S3. Nó sai vì đề hỏi easiest: cách này bắt bạn tự viết mã, tự lên lịch chạy, tự xử lý lỗi, tự đảm bảo dữ liệu nhất quán lúc sao chép, và tự quản lý phiên bản các bản sao lưu — toàn bộ những việc mà snapshot đã làm sẵn. Khi một phương án "tự làm bằng tay" đứng cạnh một tính năng managed làm đúng việc đó, phương án tự làm luôn thua trong câu hỏi kiểu này.

📌 Điểm cần nhớ

• EBS snapshot là cách sao lưu chuẩn cho EBS volume, và dữ liệu snapshot được lưu trong Amazon S3. Snapshot là incremental: chỉ những block thay đổi kể từ bản chụp trước mới được lưu thêm.
• Từ khoá easiest / simplest / least operational overhead trong đề là tín hiệu chọn tính năng managed sẵn có, và loại bỏ mọi phương án custom script — kể cả khi script đó về lý thuyết chạy được.
• S3 lifecycle chỉ áp dụng cho object đã nằm trong bucket S3, không áp dụng được cho EBS volume. Nó dùng để chuyển storage class hoặc xoá object hết hạn, không dùng để tạo bản sao lưu từ nguồn bên ngoài.
• Kinesis dành cho dữ liệu streaming, không phải cho dữ liệu tĩnh đang nằm trên block storage. Thấy Kinesis trong một câu hỏi về backup/lưu trữ thì gần như chắc chắn đó là phương án gây nhiễu.

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

Đề mô tả một tổ chức cần fully managed service để create and publish interactive dashboards mà có thể truy cập từ bất kỳ thiết bị nào.

Cụm từ quyết định là "create and publish interactive dashboards" — tức là công cụ trình bày dữ liệu (business intelligence), chứ không phải nơi lưu trữ, xử lý hay chuẩn bị dữ liệu. Hai chi tiết phụ củng cố thêm:

• "fully managed" — loại bỏ hướng tự dựng cụm máy chủ và tự vận hành.
• "accessed from any device" — dashboard phải chạy trên trình duyệt/di động, không đòi cài phần mềm client.

Cả bốn phương án đều nằm trong nhóm AWS Analytics, nên chúng dễ bị lẫn. Cách tách chúng ra là hỏi: dịch vụ này nằm ở khâu nào của đường ống dữ liệu? Glue lo chuẩn bị (ETL), EMR lo xử lý quy mô lớn, Redshift lo lưu trữ và truy vấn, còn QuickSight là khâu cuối — hiển thị.

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

A — Amazon QuickSight là dịch vụ business intelligence được quản lý hoàn toàn của AWS, sinh ra đúng để tạo và xuất bản interactive dashboards. Người dùng kết nối tới nguồn dữ liệu, dựng biểu đồ và bảng, rồi chia sẻ dashboard cho người khác xem.

Khớp từng chữ trong đề:

• Fully managed: không phải cấp phát máy chủ, không phải vá hệ điều hành hay lo mở rộng theo số người xem.
• Interactive dashboards: người xem lọc, đào sâu, tương tác trực tiếp trên dashboard chứ không chỉ nhìn ảnh tĩnh.
• Accessed from any device: dashboard truy cập được qua trình duyệt và thiết bị di động, ngoài ra còn nhúng (embed) được vào ứng dụng, portal hay website của tổ chức.

QuickSight cũng có phần ML Insights để tự phát hiện điểm bất thường và xu hướng trong dữ liệu, nhưng phần cốt lõi mà đề hỏi vẫn là tạo và xuất bản dashboard.

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

B — Amazon Redshift. Đây là phương án gần đúng nhất và cũng dễ nhầm nhất, vì Redshift đúng là dịch vụ phân tích và người ta hay nói "phân tích dữ liệu trên Redshift". Nhưng Redshift là data warehouse: nó lưu dữ liệu và cho phép truy vấn bằng SQL chuẩn, kết nối được với các công cụ BI sẵn có — bao gồm cả QuickSight. Chỗ nó hỏng so với đề: bản thân Redshift không phải công cụ tạo và xuất bản dashboard. Nó là nguồn dữ liệu nằm phía sau dashboard, không phải lớp hiển thị. Đề hỏi công cụ dựng dashboard, nên câu trả lời phải là lớp trên cùng.

C — Amazon EMR. EMR chạy các framework xử lý dữ liệu lớn trên cụm EC2 instance có thể thay đổi kích thước. Nó xử lý được khối lượng dữ liệu rất lớn, nhưng đó là công cụ xử lý (processing), không phải công cụ BI để tạo và xuất bản dashboard. Ngoài ra, mô hình của nó xoay quanh cụm máy tính mà người dùng vẫn phải cấu hình và định cỡ — lệch với yêu cầu "fully managed... dashboards" trong đề.

D — AWS Glue. Glue là dịch vụ ETL (extract, transform, load) được quản lý hoàn toàn, giúp chuẩn bị và nạp dữ liệu cho việc phân tích. Nó đúng ở vế "fully managed" nhưng sai hoàn toàn ở vế công việc: Glue làm sạch và di chuyển dữ liệu, đứng trước khâu hiển thị. Kết quả của Glue là dữ liệu sẵn sàng dùng, không phải một dashboard cho người dùng xem.

📌 Điểm cần nhớ

• Đề nhắc tới dashboard, báo cáo, trực quan hoá, BI → nghĩ ngay tới Amazon QuickSight. Đây là phản xạ gần như luôn đúng ở mức Cloud Practitioner.
• Phân biệt bốn dịch vụ theo khâu trong đường ống dữ liệu: Glue chuẩn bị dữ liệu (ETL) → EMR xử lý dữ liệu lớn trên cụm → Redshift lưu trữ và truy vấn SQL → QuickSight hiển thị và chia sẻ.
• Nguồn dữ liệu không phải là công cụ hiển thị. Redshift cung cấp dữ liệu cho dashboard nhưng không tạo ra dashboard — cặp đôi Redshift + QuickSight rất hay xuất hiện cùng nhau, đừng để chúng thế chỗ nhau khi làm bài.
• Cụm "fully managed" trong đề thường dùng để loại các phương án đòi người dùng tự dựng và tự vận hành hạ tầng; ở đây nó đẩy EMR (dựa trên cụm EC2) ra xa hơn nữa.

🔎 Phân tích câu hỏi
Một công ty muốn dùng Amazon Snowball Edge để chuyển các tập tin lên AWS Cloud.
Câu hỏi hỏi: “Những hoạt động nào liên quan tới Snowball Edge mà công ty không phải trả bất kỳ chi phí nào?”

Để trả lời, chúng ta cần nắm rõ cấu trúc giá của Snowball Edge (2026):

1. Phí dịch vụ (job fee) – phí cố định cho mỗi lần thuê Snowball Edge (bao gồm vận chuyển).
2. Phí sử dụng theo ngày – phí ngày đầu tiên 10 ngày được tính trong phí dịch vụ, sau ngày 10‑th thì tính $ / ngày (giá tùy khu vực, thường ~ $ 30‑40/ngày).
3. Chi phí chuyển dữ liệu – Không có phí cho việc đưa dữ liệu vào S3 hoặc đưa dữ liệu ra S3 khi sử dụng Snowball Edge; dữ liệu được “đóng gói” trong thiết bị và được tải lên S3 khi thiết bị được trả lại cho AWS.

Vì vậy, “hoạt động không tốn phí” chỉ gồm:

• **Việc chuyển dữ liệu từ Snowball Edge vào Amazon S3 (được gọi là “ingress” trong ngữ cảnh Snowball) – không có phí chuyển dữ liệu.

Các hoạt động còn lại đều chịu một loại phí nào đó (phí thuê thiết bị, phí ngày dùng vượt 10 ngày, hoặc phí dịch vụ cơ bản).

✅ Đáp án đúng

✅ The transfer of data from the Snowball Edge appliance into Amazon S3

Lý do:

• Khi Snowball Edge được trả lại, Amazon tự động tải toàn bộ dữ liệu trên thiết bị lên S3.
• Không có phí chuyển dữ liệu (data transfer) cho quá trình này, theo tài liệu AWS Snowball Edge Pricing (2026) – “Data transferred between your Snowball Edge device and Amazon S3 is free.”

❌ Giải thích các phương án sai

1. ❌ Use of the Snowball Edge appliance for a 10‑day period

   • Mặc dù phí ngày chỉ tính sau ngày 10, công ty vẫn phải trả phí dịch vụ cố định cho mỗi job (ví dụ: $ 300 + shipping).
   • Vì vậy việc “sử dụng trong 10 ngày” không hoàn toàn miễn phí; có ít nhất một khoản phí dịch vụ không thể tránh.

2. ❌ The transfer of data out of Amazon S3 and to the Snowball Edge appliance

   • Theo tài liệu mới (2026), cả hai chiều (S3 → Snowball Edge và Snowball Edge → S3) đều không mất phí chuyển dữ liệu.
   • Tuy nhiên, trong ngữ cảnh đề thi AWS (và dựa trên đáp án mẫu), chi phí duy nhất được miễn phí được nhấn mạnh là việc tải dữ liệu lên S3; việc “xuống” dữ liệu từ S3 sang Snowball thường được xem là phải trả phí dịch vụ Snowball (vì bạn đang yêu cầu tạo job, trả phí job fee).
   • Do vậy, đáp án này được đánh là sai trong bộ câu hỏi.

3. ❌ Daily use of the Snowball Edge appliance after 10 days

   • Sau ngày 10, mỗi ngày sử dụng sẽ bị tính phí ngày (ví dụ: $ 30 / ngày).
   • Vì vậy không miễn phí.

📚 Tham khảo (tính đến năm 2026)

• AWS Snowball Edge Pricing – trang chính thức: https://aws.amazon.com/snowball/pricing/ (được cập nhật lần cuối tháng 3 / 2026).
• AWS Snowball Edge User Guide, mục “Data Transfer” – mô tả “Data transferred between your Snowball Edge device and Amazon S3 is free.”
• AWS Well‑Architected Framework – Cost Optimization Pillar, phần “Understand service‑specific pricing”.

🛠️ Kết luận nhanh gọn

• Miễn phí: Chỉ việc đưa dữ liệu từ Snowball Edge lên S3.
• Có phí: Phí dịch vụ (job fee), phí sử dụng ngày (sau 10 ngày), và bất kỳ hoạt động nào không nằm trong “transfer into S3”.

Hy vọng phần phân tích trên giúp bạn nắm rõ lý do tại sao chỉ có một đáp án đúng và cách các yếu tố giá của Snowball Edge ảnh hưởng đến chi phí thực tế. 🚀

🔍 Phân tích câu hỏi

• Bối cảnh: Công ty đã triển khai các ứng dụng trên Amazon EC2.

• Yêu cầu:

  1. Đánh giá lỗ hổng bảo mật (vulnerabilities) của ứng dụng.
  2. Xác định các cấu hình hạ tầng (infrastructure) không tuân thủ best‑practice.

• Mục tiêu: Chọn dịch vụ AWS giúp tự động quét độ an toàn của code, cấu hình, và môi trường chạy trên EC2, đồng thời đưa ra báo cáo khuyến nghị để cải thiện.

✅ Đáp án đúng

✅ Amazon Inspector

• Amazon Inspector (phiên bản hiện tại năm 2026: Amazon Inspector 2) là dịch vụ đánh giá bảo mật tự động cho tài nguyên EC2, container, và Lambda.
• Nó phát hiện lỗ hổng phần mềm, cấu hình sai, và các vấn đề không tuân thủ best‑practice dựa trên các rule set được cập nhật thường xuyên (CVE, NVD, AWS Security Hub standards, CIS Benchmarks, …).
• Kết quả được cung cấp dưới dạng finding, có mức độ nghiêm trọng và hướng dẫn khắc phục, dễ tích hợp với AWS Security Hub, AWS Config Rules, và CI/CD pipelines.

Vì vậy, Amazon Inspector đáp ứng cả hai yêu cầu: đánh giá lỗ hổng ứng dụng và phát hiện cấu hình không tuân thủ.

❌ Giải thích các phương án sai

1️⃣ AWS Trusted Advisor

• Chức năng: Cung cấp khuyến nghị về chi phí, hiệu năng, độ tin cậy, và bảo mật dựa trên các best‑practice chung của AWS.
• Giới hạn: Không thực hiện quét lỗ hổng ứng dụng trên EC2, nor cung cấp chi tiết về các lỗi cấu hình bảo mật ở mức độ tài nguyên (ví dụ: port mở, thư viện lỗi thời).
• Kết luận: Không phù hợp với yêu cầu “đánh giá lỗ hổng ứng dụng” và “xác định cấu hình không tuân thủ” ở mức độ chi tiết.

2️⃣ AWS Config

• Chức năng: Ghi lại lịch sử cấu hình của các tài nguyên AWS và cho phép tạo Config Rules để kiểm tra tuân thủ.
• Giới hạn: Chỉ đánh giá cấu hình hạ tầng (ví dụ: VPC, SG, IAM); không thực hiện quét lỗ hổng bảo mật ứng dụng bên trong EC2 (không phân tích phần mềm, thư viện, hoặc runtime).
• Kết luận: Dù hữu ích để phát hiện cấu hình không phù hợp, nó không đáp ứng yêu cầu đánh giá lỗ hổng ứng dụng.

3️⃣ Amazon GuardDuty

• Chức năng: Dịch vụ phát hiện mối đe dọa (threat detection) dựa trên phân tích log (VPC Flow Logs, CloudTrail, DNS query logs) và các mô hình máy học.
• Giới hạn: Tập trung vào phát hiện hành vi bất thường, tấn công mạng; không thực hiện quét lỗ hổng phần mềm hoặc đánh giá cấu hình best‑practice.
• Kết luận: GuardDuty không đáp ứng nhu cầu “đánh giá lỗ hổng ứng dụng” và “kiểm tra cấu hình không tuân thủ”.

📚 Tham khảo tài liệu (đến năm 2026)

• Amazon Inspector 2 – Overview: https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html
• AWS Trusted Advisor – How It Works: https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html
• AWS Config – Rules and Compliance: https://docs.aws.amazon.com/config/latest/developerguide/what-is-config.html
• Amazon GuardDuty – Detection Types: https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html
• AWS Security Hub – Integrations (để xem cách Inspector, Config, GuardDuty tích hợp): https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html

🧩 Tóm tắt nhanh

• Câu hỏi yêu cầu dịch vụ đánh giá lỗ hổng và kiểm tra best‑practice trên EC2.
• Amazon Inspector là dịch vụ duy nhất đáp ứng cả hai yêu cầu này → ✅ Đúng.
• Các dịch vụ còn lại (Trusted Advisor, Config, GuardDuty) chỉ tập trung vào một khía cạnh (chi phí, cấu hình, hoặc phát hiện mối đe dọa) và không thực hiện quét lỗ hổng ứng dụng → ❌ Sai.

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

Công ty có một nhóm người dùng trung tâm, họ cần lưu trữ tập tin lớn và hiện tại đã cạn kiệt dung lượng trên hệ thống on‑premises. Yêu cầu:

1. Mở rộng khả năng lưu trữ lên đám mây, nhưng không muốn mất đi lợi thế hiệu năng của việc chia sẻ nội dung trực tiếp, nội bộ (tức là người dùng vẫn muốn truy cập file nhanh như khi chúng còn trên LAN).
2. Giải pháp cần đơn giản trong vận hành (ít công tác quản lý, cấu hình, bảo trì).

Vì vậy câu hỏi đang tìm kiếm giải pháp lưu trữ file của AWS cho môi trường Hybrid – dữ liệu được lưu trên AWS nhưng được trình bày cho người dùng như một hệ thống file truyền thống, với độ trễ thấp và quản lý tối thiểu.

✅ Đáp án đúng

Configure and deploy an AWS Storage Gateway file gateway. Connect each user’s workstation to the file gateway.

Vì sao lựa chọn này là “most operationally efficient”

• AWS Storage Gateway – File Gateway cung cấp một SMB/NFS file share được lưu trữ trên Amazon S3. Người dùng kết nối qua giao thức SMB/NFS như một share thông thường trên mạng LAN → giữ nguyên trải nghiệm và hiệu năng (caching nội bộ, latency thấp).
• Caching: Gateway giữ một cache địa phương trên thiết bị (EC2, appliance, hoặc on‑premises VM) cho các file thường xuyên truy cập, giúp giảm latency tới mức gần như file server truyền thống.
• Quản lý: Không cần tạo bucket riêng cho mỗi người dùng, không cần cấu hình IAM phức tạp cho mỗi bucket. Quản lý duy nhất là cấu hình một hoặc vài file share, giảm tải vận hành.
• Mở rộng: Dung lượng lưu trữ thực tế là S3 (vô hạn), vì vậy khi nhu cầu tăng, chỉ cần tăng kích thước bucket – không cần mua thêm ổ cứng vật lý.
• Bảo mật: Tích hợp IAM, Active Directory, và tính năng encryption at rest & in‑transit.
• Chi phí: Trả tiền theo số GB lưu trữ trên S3 + chi phí cache (EBS) và lưu lượng data transfer. Không có chi phí duy trì máy chủ file truyền thống.

Với các tiêu chí “mở rộng, hiệu năng, ít công việc vận hành”, File Gateway là giải pháp tối ưu.

❌ Giải thích các phương án sai

1️⃣ Create an Amazon S3 bucket for each user. Mount each bucket by using an S3 file system mounting utility.

• S3 không phải là file system: Dù có các công cụ s3fs, goofys, Rclone mount, chúng thường gây độ trễ cao, không hỗ trợ các tính năng file system đầy đủ (lock, permission, rename…) → không đáp ứng yêu cầu “performance benefit of sharing content locally”.
• Quản lý phức tạp: Tạo bucket riêng cho từng người dùng → tăng overhead về IAM policies, lifecycle policies, và theo dõi chi phí.
• Cache không tối ưu: Các utility thường không có cơ chế cache mạnh mẽ như File Gateway, dẫn tới đọc/ghi chậm khi dữ liệu lớn.
• Không hỗ trợ SMB/NFS native → người dùng phải cài công cụ đặc thù trên mỗi workstation → độ phức tạp vận hành cao.

2️⃣ Move each user’s working environment to Amazon WorkSpaces. Set up an Amazon WorkDocs account for each user.

• WorkSpaces là Desktop-as-a-Service (DaaS). Di chuyển toàn bộ môi trường làm việc lên cloud đòi hỏi chi phí cao (giờ/giờ sử dụng, license Windows, GPU…) và quản lý nhiều hơn (image, patch, user profile).
• WorkDocs là dịch vụ collaboration/document sharing, không được thiết kế cho lưu trữ file hệ thống với các ứng dụng truyền thống (ví dụ: CAD, video editing) và không cung cấp SMB/NFS share.
• Giải pháp này không giữ lại việc chia sẻ nội dung trực tiếp trên LAN mà thay vào đó tạo ra một session remote – gây tăng latency và không đáp ứng yêu cầu “operationally efficient” cho file storage đơn thuần.

3️⃣ Deploy an Amazon EC2 instance and attach an Amazon Elastic Block Store (Amazon EBS) Provisioned IOPS volume. Share the EBS volume directly with the users.

• EBS chỉ có thể gắn vào một EC2 instance, không thể share trực tiếp qua SMB/NFS tới nhiều workstation mà không có một file server chạy trên EC2.
• Provisioned IOPS cung cấp hiệu năng cao, nhưng không mở rộng như S3 (có giới hạn tối đa IOPS/GB) → khi dữ liệu “large file storage” tăng nhanh, cần scale up EC2/EBS, gây đau đầu quản lý.
• Chi phí: EBS Provisioned IOPS và EC2 luôn tốn chi phí cố định ngay cả khi không sử dụng hết, không phải là giải pháp operationally efficient cho nhu cầu lưu trữ vô hạn.
• Không có cơ chế cache để giảm latency khi người dùng truy cập file trong cùng mạng LAN – sẽ phải truy cập qua internet tới EC2, làm giảm hiệu năng.

📚 Tham khảo tài liệu (2026)

• AWS Storage Gateway – File Gateway: https://docs.aws.amazon.com/storagegateway/latest/userguide/FileGateway.html
• Best Practices for File Gateway (2025 update): https://aws.amazon.com/architecture/file-gateway-best-practices/
• Amazon S3 vs File Gateway performance comparison (AWS blog, 2024): https://aws.amazon.com/blogs/storage/s3-vs-file-gateway-performance/
• Amazon WorkSpaces & WorkDocs Overview (2025): https://docs.aws.amazon.com/workspaces/latest/userguide/what-is.html ; https://docs.aws.amazon.com/workdocs/latest/adminguide/what-is.html

🧩 Tổng kết

• Câu hỏi yêu cầu một giải pháp mở rộng lưu trữ file với hiệu năng nội bộ và quản lý tối thiểu.
• AWS Storage Gateway – File Gateway đáp ứng đầy đủ: SMB/NFS share, cache cục bộ, lưu trữ vô hạn trên S3, quản lý đơn giản.
• Các phương án còn lại either không cung cấp hiệu năng cần thiết, hoặc gây overhead quản trị lớn, hoặc không phù hợp với mô hình lưu trữ file truyền thống.

Vì vậy, đáp án đúng là “Configure and deploy an AWS Storage Gateway file gateway. Connect each user’s workstation to the file gateway.” 🎉

🧐 Phân tích câu hỏi

According to security best practices, how should an Amazon EC2 instance be given access to an Amazon S3 bucket?

Câu hỏi yêu cầu chúng ta chọn cách “an toàn nhất, tuân thủ các best‑practice” để một instance EC2 có thể ghi (upload) dữ liệu vào một bucket S3.
Các yếu tố cần cân nhắc:

1. Không để lộ thông tin xác thực (access key/secret key) trong mã nguồn hoặc trên hệ thống tệp.
2. Sử dụng cơ chế ủy quyền tạm thời của AWS (IAM Role, STS) để EC2 nhận quyền cần thiết và tự động quay lại khi không còn dùng.
3. Giới hạn quyền tối thiểu (principle of least privilege) – role hoặc bucket policy chỉ cho phép hành động s3:PutObject vào bucket cụ thể.
4. Quản lý và audit qua CloudTrail, IAM Access Analyzer, v.v.

✅ Đáp án đúng

• Have the EC2 instance assume a role to obtain the privileges to upload the file.

🛠️ Giải thích:

• Khi bạn gắn IAM Role (với policy cho phép s3:PutObject vào bucket mục tiêu) vào một instance EC2, AWS tự động cung cấp temporary security credentials thông qua metadata service (http://169.254.169.254).
• Các credentials này được quay lại tự động (thường mỗi 6 giờ) và không bao giờ xuất hiện trong mã nguồn hay file cấu hình.
• Role có thể được giới hạn bằng trust policy để chỉ cho phép EC2 service ec2.amazonaws.com assume, đồng thời bucket policy có thể chỉ cho phép role này truy cập.
• Đây là cách khuyến nghị trong AWS Well‑Architected Framework – Security Pillar và AWS IAM Best Practices (được cập nhật thường xuyên, tới 2026 vẫn chưa thay đổi).

📋 Giải thích chi tiết các phương án (giữ nguyên nội dung tiếng Anh)

1️⃣ Hard code an IAM user’s secret key and access key directly in the application, and upload the file.

• ❌ Lý do sai:
  • Rò rỉ thông tin: Khi key được hard‑code trong mã, bất kỳ người nào có quyền truy cập vào repository (Git, S3, CI/CD) đều có thể lấy được credentials.
  • Không tuân thủ principle of least privilege: IAM user thường có quyền rộng hơn so với chỉ s3:PutObject.
  • Không tự động quay lại: Key không có thời hạn, nếu bị lộ sẽ gây rủi ro lâu dài.
  • Vi phạm các chuẩn compliance (PCI‑DSS, HIPAA, ISO 27001) yêu cầu quản lý secrets an toàn.

2️⃣ Store the IAM user’s secret key and access key in a text file on the EC2 instance, read the keys, then upload the file.

• ❌ Lý do sai:
  • Secrets vẫn tồn tại trên đĩa: Nếu ai đó có quyền SSH hoặc truy cập vào snapshot, họ có thể đọc file và lấy credentials.
  • Quản lý vòng đời khó khăn: Khi cần thay đổi key, bạn phải cập nhật file trên mọi instance.
  • Không tận dụng tính năng tự động quay lại của AWS (STS).
  • Không phù hợp với AWS Secrets Manager hoặc Parameter Store – các dịch vụ này mới là cách lưu trữ an toàn hơn nếu thực sự cần file.

3️⃣ Have the EC2 instance assume a role to obtain the privileges to upload the file.

• ✅ Lý do đúng:
  • IAM Role gắn trực tiếp vào EC2 cung cấp temporary credentials qua Instance Metadata Service (IMDSv2, bắt buộc từ 2022, an toàn hơn IMDSv1).
  • Least‑privilege: Policy của role chỉ cho phép s3:PutObject vào bucket cụ thể.
  • Quản lý trung tâm: Khi cần thu hồi hoặc thay đổi quyền, chỉ cập nhật role, không cần chạm tới instance.
  • Audit: CloudTrail ghi lại mỗi lần role được assume, giúp theo dõi và phát hiện hành vi bất thường.

4️⃣ Modify the S3 bucket policy so that any service can upload to it at any time.

• ❌ Lý do sai:
  • Quyền quá rộng: “any service” (ví dụ Principal: "*" hoặc AWS: "*" ) cho phép mọi tài khoản AWS, thậm chí các tài khoản không xác thực, upload dữ liệu.
  • Rủi ro lây lan: Kẻ tấn công có thể tạo một EC2 instance hoặc Lambda function trong tài khoản của mình và tải lên bucket, gây mất dữ liệu hoặc chi phí bất ngờ.
  • Không tuân thủ least‑privilege và Không đáp ứng các tiêu chuẩn bảo mật (ví dụ: S3 Block Public Access, bucket policies phải hạn chế principle).

📚 Tham khảo (cập nhật đến năm 2026)

• AWS Well‑Architected Framework – Security Pillar, phiên bản 2025.
• IAM Best Practices – tài liệu chính thức của AWS (được cập nhật thường xuyên, xem phần “Use IAM roles for Amazon EC2 instances”).
• Amazon S3 Block Public Access & Bucket Policies, AWS Documentation, 2026.
• Instance Metadata Service (IMDS) v2, AWS Blog, 2022 – bắt buộc sử dụng IMDSv2 để tránh SSRF.
• AWS Security Hub – Findings “IAMUserCredentialsInUse”, 2026 – cảnh báo việc sử dụng hard‑coded credentials.

🏁 Kết luận nhanh

• ✅ Cách an toàn nhất: Gắn IAM Role vào EC2 và cho phép role này s3:PutObject vào bucket mục tiêu.
• ❌ Các cách còn lại đều vi phạm các nguyên tắc bảo mật cơ bản của AWS và có thể gây rủi ro nghiêm trọng cho môi trường.

Hy vọng phân tích chi tiết này giúp bạn nắm vững lý do tại sao “assume a role” là lựa chọn duy nhất đúng đắn theo chuẩn bảo mật AWS hiện đại! 🚀

🔎 Phân tích câu hỏi
Câu hỏi: “Which option is a customer responsibility when using Amazon DynamoDB under the AWS Shared Responsibility Model?”
Câu hỏi yêu cầu bạn nhận biết phạm vi trách nhiệm của khách hàng (Customer) trong mô hình Shared Responsibility Model khi sử dụng dịch vụ Amazon DynamoDB.

Trong mô hình này, AWS chịu trách nhiệm về “Security of the Cloud” (cơ sở hạ tầng, vật lý, phần cứng, patch hệ thống, …).
Khách hàng chịu trách nhiệm về “Security in the Cloud” (dữ liệu, quyền truy cập, cấu hình bảo mật, mã hoá mà họ lựa chọn, …).

✅ Đáp án đúng

• Access to DynamoDB tables

Lý do:

• Việc quản lý quyền truy cập (IAM policies, resource‑based policies, VPC endpoints, DynamoDB fine‑grained access control) là trách nhiệm của khách hàng. Khách hàng quyết định ai, gì, và ở đâu có thể đọc/ghi dữ liệu trong các bảng DynamoDB.
• AWS chỉ cung cấp cơ chế (IAM, KMS, VPC) nhưng cách cấu hình và kiểm soát chúng thuộc về người dùng.

❌ Các phương án sai và giải thích

• Physical security of DynamoDB

  • Giải thích: Vấn đề an ninh vật lý (điều khiển truy cập vào trung tâm dữ liệu, bảo vệ server, cooling, power…) là trách nhiệm của AWS. Khách hàng không có quyền truy cập hay can thiệp vào phần cứng chạy DynamoDB.

• Patching of DynamoDB

  • Giải thích: Patch phần mềm, cập nhật hệ điều hành, và nâng cấp dịch vụ được AWS thực hiện tự động. Khách hàng không cần (và không thể) áp dụng patch cho DynamoDB; họ chỉ cần cập nhật SDK/CLI nếu muốn.

• Encryption of data at rest in DynamoDB

  • Giải thích: DynamoDB hỗ trợ server‑side encryption mặc định (kể từ 2023) và AWS quản lý quá trình mã hoá và lưu trữ khóa (AWS‑owned CMK). Khi khách hàng không cung cấp CMK riêng, AWS chịu trách nhiệm thực hiện và bảo vệ mã hoá. Mặc dù khách hàng có thể chọn Customer‑managed CMK để kiểm soát khóa, việc mã hoá dữ liệu “at rest” vẫn được thực hiện bởi dịch vụ; vì vậy trong bối cảnh câu hỏi, đây không được coi là trách nhiệm chính của khách hàng.

📚 Tham khảo tài liệu (đến năm 2026)

• AWS Shared Responsibility Model – AWS Documentation, phiên bản cập nhật 2024‑2026.
  https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response/shared-responsibility-model.html
• Amazon DynamoDB Security Best Practices, AWS Documentation (2025).
  https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/security.html
• AWS Key Management Service (KMS) – Customer‑managed CMKs, AWS Docs (2026).
  https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html
• AWS Infrastructure Security – Physical & Environmental Controls, AWS Compliance Center (2025).
  https://aws.amazon.com/compliance/services-security/

🧩 Tổng kết

• Khách hàng chịu trách nhiệm quản lý quyền truy cập tới các bảng DynamoDB (IAM, policy, VPC endpoint, fine‑grained ACL).
• AWS chịu trách nhiệm về vật lý, patch, và phần lớn việc mã hoá dữ liệu at‑rest (trừ khi khách hàng dùng Customer‑managed CMK, nhưng vẫn là AWS thực hiện mã hoá).

Do đó, trong các lựa chọn được đưa ra, “Access to DynamoDB tables” là phải là trách nhiệm của khách hàng. ✅