Ngân hàng đề — AWS Certified SysOps Administrator Associate

Tìm thấy 936 câu.

Câu 181 Domain 5: Networking and Content Delivery

A company wants to migrate a part of its on-premises infrastructure to AWS Cloud. As a starting point, the company is looking at moving their daily workflow files to AWS Cloud, such that the files are accessible from the on-premises systems as well as AWS Cloud. To reduce the management overhead, the company wants a fully managed service.

Which service/tool is the right choice for this requirement?

A
File Gateway of AWS Storage Gateway
B
Amazon Simple Storage Service (Amazon S3)
C
Volume Gateway of AWS Storage Gateway
D
Amazon Elastic Block Store (Amazon EBS)

Xem giải thích

Đáp án

A — File Gateway của AWS Storage Gateway.

Vì sao đúng

Đề nêu ba yêu cầu, và File Gateway đáp ứng cả ba:

Đề nói	Nghĩa
"tệp công việc hằng ngày"	dữ liệu ở mức TỆP, không phải khối
"truy cập được từ CẢ hệ thống tại chỗ LẪN AWS"	cần cầu nối hai chiều
"dịch vụ được quản lý hoàn toàn"	không tự dựng và vận hành máy chủ tệp

⚠ Điểm mấu chốt — File Gateway cho hai bên nhìn thấy cùng một dữ liệu:

Máy chủ tại chỗ
        ↓  mount NFS hoặc SMB
    File Gateway (máy ảo tại chỗ)
        ↓
    MỖI TỆP thành MỘT ĐỐI TƯỢNG trong bucket S3
        ↓
    Ứng dụng trên AWS đọc thẳng từ S3
        ↓
    → tại chỗ thấy nó như một thư mục chia sẻ
    → trên cloud thấy nó như đối tượng S3 bình thường
    → CÙNG MỘT DỮ LIỆU

⚠ Đây chính là điểm khiến File Gateway khác hẳn Volume Gateway:

File Gateway
        ↓
    Dữ liệu trên S3 ở ĐỊNH DẠNG GỐC, một-đối-một
        ↓
    → mở được từ S3 console, từ Athena, từ Lambda,
      từ bất kỳ ứng dụng nào trên AWS

Volume Gateway
        ↓
    Dữ liệu là EBS SNAPSHOT
        ↓
    → KHÔNG đọc trực tiếp từ S3 được
    → phải khôi phục thành volume rồi gắn vào EC2

⚠ Và tệp hay dùng được đệm tại chỗ:

File Gateway có bộ đệm trên đĩa cục bộ
        ↓
    → tệp hay dùng đọc với độ trễ của mạng LAN
    → tệp ít dùng lấy từ S3 khi cần

Xem thêm câu #11603 và #11596: cùng họ Storage Gateway — #11603 cũng chọn File Gateway (thay ổ NFS v3), còn #11596 chọn Volume Gateway vì ứng dụng ở đó dùng iSCSI mức khối.

Vì sao các phương án khác sai

C (Volume Gateway) — đây là phương án gần nhất vì cũng là Storage Gateway và cũng có bộ đệm. Nhưng nó phục vụ iSCSI ở mức KHỐI, và dữ liệu trên AWS nằm dưới dạng snapshot — nên ứng dụng trên AWS không đọc trực tiếp được, trái yêu cầu "truy cập từ cả hai phía".
B (Amazon S3 trực tiếp) — S3 là lưu trữ đối tượng qua API HTTP. Hệ thống tại chỗ không mount nó như thư mục chia sẻ được nếu không có một lớp trung gian — mà lớp trung gian ấy chính là File Gateway.
D (Amazon EBS) — EBS chỉ gắn được vào EC2 instance, và chỉ một instance tại một thời điểm (trừ Multi-Attach). Không có cách nào truy cập từ trung tâm dữ liệu tại chỗ.

Ghi nhớ

⚠ Bốn loại Storage Gateway — bảng phải thuộc: | Loại | Giao thức | Dữ liệu trên AWS | |---|---|---| | File Gateway (S3) | NFS, SMB | đối tượng S3 ở định dạng gốc | | Volume Gateway | iSCSI (khối) | EBS snapshot | | Tape Gateway | iSCSI VTL | băng ảo trong S3/Glacier | | FSx File Gateway | SMB | FSx for Windows File Server |

Từ khoá nhận diện:

"tệp dùng chung giữa tại chỗ và AWS" → File Gateway "muốn đọc tệp thẳng từ S3 sau đó" → File Gateway "iSCSI, ổ đĩa khối" → Volume Gateway "phần mềm sao lưu ra băng từ" → Tape Gateway "chia sẻ tệp cho EC2 TRONG VPC" → EFS (Linux) hoặc FSx (Windows) "di chuyển dữ liệu một lần rồi thôi" → DataSync hoặc Snowball

File Gateway và EFS — khi nào chọn cái nào	Nội dung
File Gateway	truy cập từ TẠI CHỖ, dữ liệu nằm trên S3
EFS	truy cập trong VPC, hoặc từ tại chỗ qua Direct Connect/VPN
Đọc lại bằng ứng dụng cloud	File Gateway: mỗi tệp là một đối tượng S3
Bộ đệm tại chỗ	File Gateway có, EFS không

Cảnh báo lớn nhất khi vận hành File Gateway	Nội dung
Ghi thẳng vào bucket (không qua gateway)	gateway không tự biết
Chữa	chạy `RefreshCache` để gateway quét lại
Hệ quả nếu quên	client NFS/SMB không thấy tệp mới dù chúng đã ở S3
Lời khuyên	chọn một đường ghi duy nhất cho mỗi thư mục

Đặc điểm triển khai	Nội dung
Chạy ở đâu	máy ảo tại chỗ (VMware, Hyper-V, KVM), EC2, hoặc phần cứng chuyên dụng
Bộ đệm	đĩa cục bộ — cấp phát rộng rãi
Lớp lưu trữ đích	S3 Standard, IA, Intelligent-Tiering
Lifecycle policy	vẫn áp được như bucket thường
Tệp lớn nhất	5 TB (giới hạn của đối tượng S3)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ đệm còn chỗ không | chỉ số CachePercentUsed | | Dữ liệu đã lên S3 chưa | CloudBytesUploaded, và xem thẳng bucket | | Client có thấy tệp mới không | nếu ghi ngoài gateway thì phải RefreshCache |

Và một lời khuyên khi lập kế hoạch: hãy cấp phát đĩa đệm rộng rãi ngay từ đầu, và theo dõi CachePercentUsed như một chỉ số vận hành. Toàn bộ trải nghiệm "nhanh như ổ đĩa nội bộ" của File Gateway đứng trên giả định dữ liệu nóng nằm trong bộ đệm — khi bộ đệm đầy, mỗi lần đọc trượt phải đi vòng ra S3 và người dùng đột nhiên thấy thư mục chia sẻ chậm đi hàng chục lần, mà không có lỗi nào xuất hiện ở đâu để chỉ ra nguyên nhân.

Câu 182 Domain 4: Security and Compliance

A systems administrator at a company is trying to create a digital signature for SSH'ing into the Amazon EC2 instances.

Which of the following entities can be used to facilitate this use-case?

A
Access keys
B
Root user credentials
C
Key pairs
D
Multi-Factor Authentication (MFA)

Xem giải thích

Đáp án

C — Key pairs.

Vì sao đúng

SSH dùng mật mã khoá công khai, và trên AWS thì cơ chế đó gọi là EC2 key pair.

⚠ Điểm mấu chốt — AWS chỉ giữ PUBLIC KEY, bạn giữ PRIVATE KEY:

Tạo key pair
        ↓
    AWS giữ PUBLIC KEY
    Bạn tải về PRIVATE KEY (tệp .pem) — CHỈ MỘT LẦN DUY NHẤT
        ↓
    Khởi chạy instance với key pair đó
        ↓
    AWS chép public key vào ~/.ssh/authorized_keys của máy
        ↓
    Bạn SSH với private key
        ↓
    → máy chủ thách thức, client KÝ bằng private key
    → máy chủ kiểm chứng bằng public key
    → đây chính là "chữ ký số" mà đề nói tới

⚠ Điều tuyệt đối phải nhớ về private key:

AWS KHÔNG GIỮ private key
        ↓
    Mất tệp .pem
        ↓
    → KHÔNG tải lại được, KHÔNG khôi phục được
        ↓
    Muốn vào lại máy thì phải:
        - dùng EC2 Instance Connect, hoặc
        - dùng Session Manager, hoặc
        - chạy AWSSupport-ResetAccess, hoặc
        - tháo volume gắn sang máy khác và sửa authorized_keys

⚠ Với Windows thì key pair dùng khác một chút:

Windows instance
        ↓
    Private key dùng để GIẢI MÃ mật khẩu Administrator
        ↓
    Rồi mới dùng mật khẩu đó để RDP
        ↓
    → vẫn là cùng một key pair, nhưng vai trò khác

Vì sao các phương án khác sai

A (Access keys) — đây là phương án gần nhất vì cũng là "khoá" và cũng là chứng chỉ. Nhưng access key (cặp AKIA... và secret) dùng để gọi API và CLI của AWS, hoàn toàn không liên quan tới việc đăng nhập vào hệ điều hành của một instance.
D (Multi-Factor Authentication) — thêm một lớp xác thực khi đăng nhập vào AWS Console hoặc gọi API nhạy cảm. Nó không phải cơ chế SSH.
B (Root user credentials) — chứng chỉ đăng nhập tài khoản AWS. Không dùng để SSH vào máy nào.

Ghi nhớ

⚠ Các loại chứng chỉ trên AWS và công dụng — bảng phải thuộc: | Chứng chỉ | Dùng để | |---|---| | EC2 key pair | SSH vào Linux / lấy mật khẩu Windows | | Access key (AKIA... + secret) | gọi API và CLI của AWS | | Mật khẩu IAM | đăng nhập Console | | MFA | lớp xác thực thứ hai | | CloudFront key pair / key group | ký signed URL và cookie | | Chứng chỉ ACM | TLS cho tên miền |

Từ khoá nhận diện:

"SSH vào EC2" → key pair "gọi API AWS" → access key — nhưng nên dùng role thay thế "mất tệp .pem" → Session Manager / EC2 Instance Connect / AWSSupport-ResetAccess "vào máy mà không cần cổng 22" → Session Manager "ký signed URL cho CloudFront" → key group

⚠ Ba cách vào EC2 mà KHÔNG cần key pair — đáng biết hơn cả câu trả lời: | Cách | Nội dung | |---|---| | Session Manager | không cần cổng 22, không cần IP công cộng, không cần bastion; có log phiên làm việc, phân quyền bằng IAM | | EC2 Instance Connect | AWS đẩy một public key tạm (sống 60 giây) vào máy | | EC2 Instance Connect Endpoint | vào máy ở private subnet mà không cần bastion |

Vì sao Session Manager tốt hơn SSH truyền thống	Nội dung
Không mở cổng 22 với ai	giảm hẳn bề mặt tấn công
Không quản lý khoá	không có tệp `.pem` để mất hay để lộ
Phân quyền bằng IAM	thu hồi quyền tức thì
Ghi log toàn bộ phiên	ra S3 hoặc CloudWatch Logs — rất quan trọng cho kiểm toán
Điều kiện	SSM Agent + IAM role + đường mạng tới endpoint SSM

Quản lý key pair cho đúng	Nội dung
Key pair theo Region	phải tạo hoặc nhập ở từng Region
Nhập khoá của mình	`import-key-pair` — AWS không bao giờ thấy private key
Đổi khoá cho máy đang chạy	sửa `~/.ssh/authorized_keys`, không đổi được từ console
Xoá key pair khỏi AWS	không gỡ khoá khỏi máy đã khởi chạy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance dùng key pair nào | describe-instances, xem KeyName | | Quyền tệp .pem | phải là chmod 400 — SSH từ chối nếu quá mở | | Ai đã vào máy | log của Session Manager, hoặc /var/log/auth.log với SSH |

Và một lời khuyên về hướng đi dài hạn: hãy chuyển sang Session Manager và bỏ hẳn key pair cho hệ thống sản xuất. Quản lý tệp .pem ở quy mô một đội là bài toán không có lời giải đẹp — khoá bị chép qua chat, nằm lại trên laptop của người đã nghỉ việc, và không ai biết chính xác ai đang giữ khoá nào; trong khi Session Manager biến quyền vào máy thành một dòng chính sách IAM có thể thu hồi trong ba giây.

Câu 183 Domain 4: Security and Compliance

Owing to lapses in security, a development team has deleted a Secrets Manager secret. Now, when the team tried to create a new secret with the same name, they ended up with an error - You can't create this secret because a secret with this name is already scheduled for deletion. The secret has to be created with the same name to avoid issues in their application.

How will you recreate the secret with the same name?

A
When you delete a secret, the Secrets Manager deprecates it with a seven-day recovery window. It is not possible to create a new secret with the same name for this duration
B
The secret key deletion is an asynchronous process. There might be a short delay before updates are received. Try after few minutes for successful completion
C
Use AWS Management Console to delete the key permanently. You will be allowed to create a new key with the same name after the older one is successfully deleted
D
Use AWS Command Line Interface (AWS CLI) to permanently delete a secret without any recovery window, run the DeleteSecret API call with the ForceDeleteWithoutRecovery parameter

Xem giải thích

Đáp án

D — Dùng AWS CLI để xoá vĩnh viễn secret mà không có thời gian chờ khôi phục: gọi DeleteSecret với tham số ForceDeleteWithoutRecovery.

Vì sao đúng

Secrets Manager có cơ chế chờ giống KMS — và đó chính là nguyên nhân của lỗi trong đề.

⚠ Điểm mấu chốt — secret đã xoá vẫn "chiếm chỗ" cái tên của nó:

Xoá một secret
        ↓
    Nó vào trạng thái "scheduled for deletion"
    Thời gian chờ mặc định 30 ngày (khai được 7–30)
        ↓
    Trong thời gian đó:
        - secret không dùng được
        - NHƯNG TÊN CỦA NÓ VẪN BỊ CHIẾM
        ↓
    → tạo secret mới cùng tên → lỗi đúng như đề mô tả

⚠ Hai cách giải quyết:

Cách 1 — KHÔI PHỤC lại secret cũ (nên ưu tiên)
    aws secretsmanager restore-secret --secret-id ten-secret
        ↓
    → secret trở lại nguyên vẹn, dùng ngay được

Cách 2 — XOÁ HẲN rồi tạo mới (đáp án của đề)
    aws secretsmanager delete-secret --secret-id ten-secret \
        --force-delete-without-recovery
        ↓
    → xoá ngay lập tức, KHÔNG có đường lùi
    → sau đó tạo lại secret cùng tên được

⚠ Và chi tiết quan trọng khiến đáp án phải là CLI:

Tuỳ chọn ForceDeleteWithoutRecovery
        ↓
    → chỉ có ở CLI và API
    → Console KHÔNG có nút này
        ↓
    Console luôn buộc bạn chọn thời gian chờ 7–30 ngày

Vì sao các phương án khác sai

A (Secrets Manager có cửa sổ khôi phục bảy ngày và không thể tạo secret cùng tên trong thời gian đó) — đây là phương án gần nhất và mô tả đúng vấn đề, nhưng kết luận sai: hoàn toàn có cách, đó chính là ForceDeleteWithoutRecovery. (Con số bảy ngày cũng chỉ là giá trị tối thiểu; mặc định là 30 ngày.)
C (dùng Console để xoá vĩnh viễn) — Console không có tuỳ chọn xoá ngay; nó luôn đặt thời gian chờ.
B (xoá là thao tác bất đồng bộ, chờ vài phút là xong) — không phải chuyện độ trễ; đây là thời gian chờ có chủ đích, tính bằng ngày chứ không phải phút.

Ghi nhớ

⚠ Các dịch vụ có "thời gian chờ trước khi xoá hẳn" — bảng phải thuộc: | Dịch vụ | Thời gian chờ | Khôi phục bằng | |---|---|---| | Secrets Manager | 7–30 ngày (mặc định 30) | restore-secret | | KMS CMK | 7–30 ngày (mặc định 30) | cancel-key-deletion | | Recycle Bin (EBS snapshot, AMI) | 1 ngày – 1 năm | khôi phục từ thùng rác | | S3 có versioning | vô thời hạn | xoá delete marker | | Route 53, EBS volume | không có | mất ngay |

Từ khoá nhận diện:

"không tạo được secret vì trùng tên đang chờ xoá" → restore-secret hoặc --force-delete-without-recovery "lỡ xoá CMK" → cancel-key-deletion "xoá secret ngay lập tức" → CLI, không phải Console "tự động xoay mật khẩu" → Secrets Manager (Parameter Store không có) "lưu cấu hình miễn phí" → Parameter Store

⚠ Secrets Manager và Parameter Store — bảng phải thuộc: | | Secrets Manager | Parameter Store | |---|---|---| | Chi phí | có phí theo secret + theo lời gọi | MIỄN PHÍ (Standard) | | Tự xoay khoá | CÓ, dựng sẵn | không (tự viết Lambda) | | Tích hợp RDS/Redshift/DocumentDB | có, xoay mật khẩu tự động | không | | Kích thước | 64 KB | 4 KB (8 KB Advanced) | | Sao chép chéo Region | có | không (Advanced có cơ chế riêng) | | Thời gian chờ khi xoá | 7–30 ngày | không có — xoá là mất ngay |

Xoay khoá tự động của Secrets Manager	Nội dung
Cơ chế	một Lambda thực hiện bốn bước: `createSecret`, `setSecret`, `testSecret`, `finishSecret`
Với RDS, Redshift, DocumentDB	AWS cung cấp Lambda sẵn
Với hệ thống khác	tự viết theo khuôn mẫu
Nhãn phiên bản	`AWSCURRENT` (đang dùng), `AWSPENDING` (đang xoay), `AWSPREVIOUS`

Thực hành tốt với secret	Nội dung
Không bao giờ để secret trong mã nguồn hay biến môi trường của image
Ứng dụng gọi lấy secret lúc chạy	và cache lại để đỡ tốn lời gọi
Dùng CMK riêng thay khoá mặc định	kiểm soát và kiểm toán tốt hơn
Đặt cảnh báo cho `DeleteSecret`	biết ngay khi có người xoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Secret đang ở trạng thái nào | describe-secret, xem DeletedDate | | Còn bao lâu nữa mất hẳn | cùng lệnh, tính từ DeletedDate cộng thời gian chờ | | Ai đã xoá | CloudTrail sự kiện DeleteSecret |

Và một lời khuyên trước khi gõ --force-delete-without-recovery: hãy chắc chắn rằng bạn thật sự muốn mất nội dung của secret đó. Trong tình huống của đề, thứ mọi người thường cần lại là restore-secret — khôi phục nguyên vẹn secret cũ cùng với giá trị của nó, thay vì xoá hẳn rồi phải đi tìm lại mật khẩu để tạo mới.

Câu 184 Domain 5: Networking and Content Delivery

An e-commerce company has established a Direct Connect connection between AWS Cloud and their on-premises infrastructure. The development team needs to access the Amazon S3 bucket present in their AWS account to pull the customer data for an application hosted on the on-premises infrastructure.

What is the right way of configuring this requirement?

A
Directly access the S3 bucket through a private virtual interface (VIF) using Direct Connect
B
Create a VPC interface endpoint for the S3 bucket you need to access. Then use the private virtual interface (VIF) using Direct Connect to access the bucket
C
Create a dedicated or hosted connection. Establish a cross-network connection and then create a public virtual interface for your connection. Configure an end router for use with the public virtual interface
D
Create a VPC gateway endpoint for the S3 bucket you need to access. Then use the private virtual interface (VIF) using Direct Connect to access the bucket

Xem giải thích

Đáp án

C — Tạo một kết nối dedicated hoặc hosted, thiết lập cross-network connection, rồi tạo một PUBLIC virtual interface cho kết nối đó và cấu hình router đầu cuối để dùng với public VIF.

Vì sao đúng

Chi tiết quyết định: S3 là dịch vụ CÔNG KHAI của AWS, không nằm trong VPC của bạn.

⚠ Điểm mấu chốt — hai loại VIF phục vụ hai đích khác nhau:

Private VIF
        ↓
    Nối tới VPC của bạn (qua VGW hoặc Direct Connect Gateway)
        ↓
    → tới được EC2, RDS, ENI trong VPC
    → KHÔNG tới được endpoint công khai của S3

Public VIF
        ↓
    Nối tới các ENDPOINT CÔNG KHAI của AWS
        ↓
    → S3, DynamoDB, SQS, và mọi dịch vụ công khai khác
    → dùng IP công cộng, nhưng đi qua CÁP RIÊNG
        ↓
    → đây là đáp án

⚠ Vì sao VPC endpoint không giải quyết được vấn đề này:

Gateway endpoint cho S3
        ↓
    Hoạt động bằng cách thêm một TUYẾN vào ROUTE TABLE của VPC
        ↓
    → chỉ tài nguyên TRONG VPC dùng được
        ↓
    Máy chủ tại chỗ KHÔNG dùng route table của VPC
        ↓
    → gateway endpoint hoàn toàn vô dụng với chúng

Đây chính là chỗ phương án D sai.

⚠ Còn interface endpoint (PrivateLink) thì sao:

Interface endpoint cho S3
        ↓
    Tạo một ENI có IP RIÊNG trong VPC của bạn
        ↓
    → máy tại chỗ TỚI ĐƯỢC qua private VIF
        ↓
    → về kỹ thuật thì CÓ hoạt động
        ↓
    Nhưng: tốn phí theo giờ + phí theo GB,
    và cần cấu hình DNS phức tạp hơn
        ↓
    → public VIF là cách trực tiếp và chuẩn mực cho bài toán này

Vì sao các phương án khác sai

B (tạo interface endpoint cho S3 rồi dùng private VIF) — đây là phương án gần nhất và về kỹ thuật thì khả thi (đó là một kiến trúc có thật). Nhưng nó phức tạp hơn, tốn kém hơn, và không phải cách chuẩn để truy cập S3 từ tại chỗ qua Direct Connect. Đề hỏi "cách đúng", và cách đúng là public VIF.
D (tạo gateway endpoint cho S3 rồi dùng private VIF) — không hoạt động: gateway endpoint chỉ tác dụng với route table của VPC, mà máy tại chỗ không đi qua đó.
A (truy cập thẳng S3 qua private VIF) — không được: private VIF chỉ tới được tài nguyên trong VPC, còn endpoint của S3 là công khai.

Ghi nhớ

⚠ Ba loại Virtual Interface của Direct Connect — bảng phải thuộc: | VIF | Nối tới | Dùng cho | |---|---|---| | Private VIF | VPC (qua VGW hoặc DX Gateway) | EC2, RDS, ENI trong VPC | | Public VIF | endpoint công khai của AWS | S3, DynamoDB, SQS, mọi dịch vụ công khai | | Transit VIF | Transit Gateway | nhiều VPC cùng lúc |

Từ khoá nhận diện:

"từ tại chỗ tới S3 qua Direct Connect" → Public VIF "từ tại chỗ tới EC2/RDS trong VPC" → Private VIF "nối nhiều VPC qua Direct Connect" → Transit VIF + Transit Gateway "gateway endpoint cho máy tại chỗ" → KHÔNG hoạt động "từ TRONG VPC tới S3, không ra internet" → gateway endpoint (miễn phí)

⚠ Hai loại VPC endpoint — phải phân biệt rõ: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ | chỉ S3 và DynamoDB | hầu hết dịch vụ | | Cơ chế | thêm tuyến vào route table | ENI có IP riêng trong subnet | | Chi phí | MIỄN PHÍ | theo giờ + theo GB | | Máy tại chỗ dùng được | KHÔNG | CÓ (qua DX/VPN) | | DNS | dùng tên công khai của S3 | có private DNS |

Điểm quan trọng về public VIF	Nội dung
Cần	IP công cộng của riêng bạn (hoặc AWS cấp), và ASN BGP
AWS quảng bá	toàn bộ tiền tố IP công cộng của AWS qua BGP
Lọc bớt	dùng BGP community để chỉ nhận Region cần thiết
Không mã hoá	như mọi Direct Connect — muốn mã hoá thì chạy VPN đè lên

Chi phí truyền dữ liệu qua Direct Connect	Nội dung
Rẻ hơn đáng kể so với truyền qua internet
Vẫn tính	phí cổng theo giờ + phí truyền ra
Với S3	truyền qua public VIF vẫn tính DTO rate của Direct Connect
Lời khuyên	với khối lượng lớn và đều đặn, DX hoàn vốn khá nhanh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VIF đang là loại gì | describe-virtual-interfaces, xem virtualInterfaceType | | BGP đã lên chưa | bgpPeers[].bgpPeerState phải là available | | Lưu lượng có đi qua DX không | traceroute từ máy tại chỗ tới endpoint S3 |

Và một lời khuyên khi thiết kế kết nối lai: hãy tạo cả private VIF lẫn public VIF trên cùng một kết nối Direct Connect vật lý. Một kết nối vật lý hỗ trợ nhiều VIF, nên bạn không phải chọn giữa "tới được VPC" và "tới được S3" — và việc tách bạch hai loại lưu lượng này ngay từ đầu giúp việc chẩn đoán sau này đơn giản hơn nhiều, vì bạn biết chính xác lưu lượng nào đi qua đường nào.

Câu 185 Domain 5: Networking and Content Delivery

A data analytics company wants to seamlessly integrate its on-premises data center with AWS cloud-based IT systems which would be critical to manage as well as scale-up the complex planning and execution of every stage of its analytics workflows. As part of a pilot program, the company wants to integrate data files from its on-premises servers into AWS via an NFS interface.

Which of the following AWS service is the MOST efficient solution for the given use-case?

A
AWS Storage Gateway - Volume Gateway
B
AWS Site-to-Site VPN
C
AWS Storage Gateway - File Gateway
D
AWS Storage Gateway - Tape Gateway

Xem giải thích

Đáp án

C — AWS Storage Gateway – File Gateway.

Vì sao đúng

Đề nêu ba yêu cầu, và từ khoá quyết định nằm ở giữa: "qua giao diện NFS".

Đề nói	Nghĩa
"tích hợp trung tâm dữ liệu tại chỗ với AWS"	cần cầu nối lai
"qua giao diện NFS"	mức TỆP, giao thức NFS
"hiệu quả nhất"	dịch vụ chuyên trách, không tự dựng

⚠ Điểm mấu chốt — mỗi loại Storage Gateway nói một giao thức, và chỉ File Gateway nói NFS:

File Gateway    → NFS và SMB    ← đề bài cần
Volume Gateway  → iSCSI (khối)
Tape Gateway    → iSCSI VTL (thư viện băng)

⚠ Và điều khiến File Gateway đặc biệt hợp với quy trình phân tích dữ liệu:

Máy chủ tại chỗ ghi tệp qua NFS
        ↓
    MỖI TỆP thành MỘT ĐỐI TƯỢNG S3 ở định dạng gốc
        ↓
    → Athena truy vấn ngay bằng SQL
    → Glue crawler dựng catalog
    → EMR, SageMaker, Redshift Spectrum đọc trực tiếp
        ↓
    → dữ liệu vào hồ dữ liệu mà không cần bước chuyển đổi nào

Đây chính là lý do File Gateway thường được chọn làm cửa ngõ đưa dữ liệu tại chỗ vào hồ dữ liệu trên AWS — đúng bối cảnh "quy trình phân tích" mà đề mô tả.

Xem thêm câu #11603 và #11704: cùng đáp án File Gateway ở hai bối cảnh khác — thay ổ NFS v3 tại chỗ, và chia sẻ tệp công việc giữa tại chỗ và cloud. Còn #11596 chọn Volume Gateway vì ứng dụng ở đó dùng iSCSI mức khối.

Vì sao các phương án khác sai

A (Volume Gateway) — đây là phương án gần nhất vì cũng thuộc Storage Gateway. Nhưng nó phục vụ iSCSI ở mức KHỐI, không phải NFS; và dữ liệu trên AWS nằm dưới dạng EBS snapshot, nên các công cụ phân tích không đọc trực tiếp được.
D (Tape Gateway) — giả lập thư viện băng từ cho phần mềm sao lưu. Không liên quan tới NFS hay tới quy trình phân tích.
B (AWS Site-to-Site VPN) — chỉ là đường truyền mạng. Nó không cung cấp giao diện NFS nào, và cũng không có bộ đệm tại chỗ.

Ghi nhớ

Từ khoá nhận diện:

"NFS" hoặc "SMB" → File Gateway "iSCSI", "thiết bị khối" → Volume Gateway "phần mềm sao lưu ra băng" → Tape Gateway "đưa dữ liệu vào hồ dữ liệu để phân tích" → File Gateway (mỗi tệp là một đối tượng S3) "đồng bộ một lần hoặc định kỳ" → DataSync "hàng chục TB trở lên, băng thông không đủ" → Snowball

⚠ Storage Gateway và DataSync — hai công cụ hay bị nhầm: | | Storage Gateway | DataSync | |---|---|---| | Mục đích | cầu nối LÂU DÀI — ứng dụng đọc ghi hằng ngày | di chuyển dữ liệu một lần hoặc định kỳ | | Cách dùng | mount như thư mục chia sẻ | chạy tác vụ đồng bộ | | Bộ đệm tại chỗ | có | không | | Kiểm chứng toàn vẹn | — | có, so checksum | | Kết hợp | dùng chung được — DataSync chuyển khối dữ liệu cũ, File Gateway phục vụ hằng ngày |

Vì sao File Gateway hợp với hồ dữ liệu	Nội dung
Tệp giữ nguyên định dạng trên S3	không phải giải nén hay khôi phục
Lifecycle policy áp được	tự chuyển dữ liệu nguội sang Glacier
S3 Event Notification	kích hoạt Lambda/Glue ngay khi có tệp mới
Truy vấn	Athena, Redshift Spectrum, EMR đọc trực tiếp

Chuẩn bị khi triển khai	Nội dung
Chạy ở đâu	máy ảo tại chỗ, EC2, hoặc phần cứng chuyên dụng
Đĩa đệm	cấp phát rộng rãi — quyết định hiệu năng
Băng thông	giới hạn được bằng bandwidth throttling
Cảnh báo lớn nhất	ghi thẳng vào bucket thì phải chạy `RefreshCache`

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ đệm còn chỗ không | chỉ số CachePercentUsed | | Dữ liệu đã lên S3 chưa | CloudBytesUploaded | | Athena đọc được chưa | tạo bảng ngoài trỏ vào tiền tố tương ứng và truy vấn thử |

Và một lời khuyên cho đúng bối cảnh phân tích dữ liệu của đề: hãy thiết kế cấu trúc thư mục tại chỗ theo kiểu phân vùng ngay từ đầu — ví dụ /du-lieu/nam=2026/thang=09/ngay=02/. Vì mỗi tệp trở thành một đối tượng S3 với đúng đường dẫn đó, cấu trúc thư mục bạn chọn hôm nay sẽ trở thành sơ đồ phân vùng của bảng Athena sau này — và sửa nó về sau đồng nghĩa với việc di chuyển lại toàn bộ dữ liệu.

Câu 186 Chọn nhiều đáp án Domain 2: Reliability and Business Continuity

After a developer had mistakenly shutdown a test instance, the Team Lead has decided to configure termination protection on all the instances. As a systems administrator, you have been tasked to review the termination policy and check its viability for the given requirements.

Which of the following choices are correct about Amazon EC2 instance's termination policy (Select two)?

A
The DisableApiTermination attribute prevents Amazon EC2 Auto Scaling from terminating an instance
B
To prevent instances that are part of an Auto Scaling group from terminating on scale in, use instance protection
C
You can't enable termination protection for Spot Instances
D
The DisableApiTermination attribute prevents you from terminating an instance by initiating shutdown from the instance
E
The DisableApiTermination attribute does not prevent you from terminating an instance by initiating shutdown from Amazon EC2 console

Xem giải thích

Đáp án

B, C — hai điều đúng về chính sách chấm dứt instance:

B — Để ngăn instance trong Auto Scaling group bị chấm dứt khi scale in, hãy dùng INSTANCE PROTECTION.
C — Không bật được termination protection cho Spot Instance.

Vì sao đúng

⚠ Điều B — DisableApiTermination KHÔNG chặn được Auto Scaling:

DisableApiTermination
        ↓
    Chặn lệnh TerminateInstances gọi qua API/Console/CLI
        ↓
    Nhưng Auto Scaling dùng CƠ CHẾ RIÊNG để chấm dứt máy
        ↓
    → ASG vẫn giết máy đó khi scale in
        ↓
    Muốn ngăn ASG → dùng INSTANCE PROTECTION
        aws autoscaling set-instance-protection \
          --instance-ids i-xxxx \
          --auto-scaling-group-name ten-asg \
          --protected-from-scale-in

⚠ Điều C — Spot instance có vòng đời do AWS quyết định:

Spot instance có thể bị THU HỒI bất cứ lúc nào
        ↓
    Việc thu hồi là quyền của AWS, không phải lời gọi API của bạn
        ↓
    → termination protection không có ý nghĩa gì ở đây
        ↓
    → AWS không cho bật thuộc tính này cho Spot

⚠ Và đây là bảng phân định các cơ chế bảo vệ — chỗ dễ nhầm nhất:

Muốn chặn	Dùng
Terminate qua API/Console	`DisableApiTermination`
Stop qua API	`DisableApiStop`
ASG giết khi scale in	instance protection
ASG đụng vào khi bảo trì	`enter-standby`
Tắt từ trong hệ điều hành	`InstanceInitiatedShutdownBehavior`
Spot bị thu hồi	không chặn được — chỉ có 2 phút cảnh báo

Ghi nhớ về chất lượng câu hỏi

Phương án C phản ánh tài liệu AWS đời cũ. Hiện nay AWS đã nới quy định này:

Tài liệu hiện tại
        ↓
    BẬT được termination protection cho Spot Instance
    (với persistent Spot request)
        ↓
    NHƯNG nó KHÔNG ngăn AWS thu hồi instance
        ↓
    → nó chỉ chặn lệnh terminate do BẠN gọi

Khoá đáp án giữ nguyên vì nó đúng theo tài liệu ở thời điểm bộ đề được soạn, và tinh thần của câu hỏi vẫn đúng tuyệt đối: không có cách nào ngăn AWS thu hồi một Spot instance. Đó mới là điều cần nhớ khi thiết kế hệ thống — chứ không phải chi tiết thuộc tính có bật được hay không.

Vì sao các phương án khác sai

A (DisableApiTermination ngăn EC2 Auto Scaling chấm dứt instance) — đây là phương án gần nhất và là hiểu nhầm phổ biến nhất về thuộc tính này. Nó chỉ chặn lời gọi API trực tiếp; ASG có đường riêng.
D (DisableApiTermination ngăn bạn chấm dứt instance bằng cách tắt máy từ BÊN TRONG hệ điều hành) — sai: lệnh shutdown gõ trong máy không đi qua API, nên thuộc tính này không chạm tới nó. Hành vi khi đó do InstanceInitiatedShutdownBehavior quyết định.
E (DisableApiTermination KHÔNG ngăn bạn chấm dứt instance từ Console) — ngược: Console gọi chính API TerminateInstances, nên thuộc tính này có chặn — Console sẽ báo lỗi và yêu cầu tắt bảo vệ trước.

Ghi nhớ

⚠ Bốn thuộc tính bảo vệ EC2 — bảng phải thuộc: | Thuộc tính | Chặn | KHÔNG chặn | |---|---|---| | DisableApiTermination | terminate qua API/Console/CLI | ASG scale in, shutdown trong OS, Spot bị thu hồi | | DisableApiStop | stop qua API | shutdown trong OS | | InstanceInitiatedShutdownBehavior | quyết định stop hay terminate khi tắt từ trong OS | — | | Instance protection (ASG) | ASG chọn máy đó khi scale in | terminate thủ công |

Từ khoá nhận diện:

"ASG không được giết máy này" → instance protection "chặn terminate qua Console" → DisableApiTermination "shutdown từ trong OS" → InstanceInitiatedShutdownBehavior "bảo trì một máy trong ASG" → enter-standby "ngăn AWS thu hồi Spot" → KHÔNG CÓ CÁCH NÀO

Termination policy của ASG — thứ tự chọn máy để giết	Mặc định
1	AZ có nhiều instance nhất
2	instance dùng launch configuration/template cũ nhất
3	instance gần điểm tính tiền theo giờ tiếp theo nhất
Tuỳ chỉnh	`OldestInstance`, `NewestInstance`, `ClosestToNextInstanceHour`, `Default`, hoặc Lambda tự viết

Bảo vệ đúng cách khi bảo trì	Nội dung
`enter-standby`	tách khỏi lưu lượng, ASG không đụng tới, có thể giảm desired capacity
Instance protection	máy vẫn phục vụ, chỉ không bị chọn khi scale in
Lifecycle hook	tạm dừng trước khi máy bị chấm dứt để kịp gom log
Đừng	dùng `suspend-processes` — nó làm tê liệt cả ASG

Với Spot instance thì thiết kế thế nào	Nội dung
Bắt cảnh báo 2 phút	qua metadata hoặc EventBridge
Checkpoint lên S3	chạy lại từ điểm gần nhất
Nhiều loại instance + nhiều AZ	giảm xác suất bị thu hồi đồng loạt
`capacity-optimized`	chọn nhóm dung lượng dồi dào nhất
Nguyên tắc	thiết kế sao cho mất một máy giữa chừng không cần ai làm gì

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thuộc tính hiện tại | describe-instance-attribute --attribute disableApiTermination | | Máy nào đang được bảo vệ khỏi scale in | describe-auto-scaling-instances, xem ProtectedFromScaleIn | | Vì sao máy bị giết | Activity history của ASG — đọc trường Cause |

Và một nguyên tắc kiến trúc đáng nhớ hơn cả bốn thuộc tính trên: một instance mà bạn phải bảo vệ khỏi bị chấm dứt là một instance đang nắm giữ thứ gì đó không nên nằm ở đó. Hãy đưa trạng thái ra EBS volume tách rời, EFS, RDS hay S3 — khi ấy việc mất một máy trở thành chuyện bình thường, và bạn không còn cần tới bất kỳ lớp bảo vệ nào cả.

Câu 187 Domain 3: Deployment, Provisioning, and Automation

A junior developer is tasked with creating necessary configurations for AWS CloudFormation that is extensively used in a project. After declaring the necessary stack policy, the developer realized that the users still do not have access to stack resources. The stack policy created by the developer looks like so:

{
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "*"
    },
    {
      "Effect" : "Deny",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "LogicalResourceId/ProductionDatabase"
    }
  ]
}

Why are the users unable to access the stack resources even after giving access permissions to all?

A
Stack policies are associated with a particular IAM role or an IAM user. Hence, they only work for the users you have explicitly attached the policy to
B
Stack policies do not allow wildcard character value (*) for the Principal element of the policy
C
The stack policy is invalid and hence the users are not granted any permissions. The developer needs to fix the syntactical errors in the policy
D
A stack policy applies only during stack updates, it doesn't provide access controls. The developer needs to provide access through IAM policies

Xem giải thích

Đáp án

D — Stack policy CHỈ áp dụng trong lúc CẬP NHẬT stack; nó không phải cơ chế kiểm soát truy cập. Muốn cấp quyền cho người dùng thì phải dùng chính sách IAM.

Vì sao đúng

Lập trình viên trong đề đã nhầm hai cơ chế hoàn toàn khác nhau chỉ vì chúng dùng chung cú pháp JSON.

⚠ Điểm mấu chốt — stack policy trả lời một câu hỏi rất hẹp:

Stack policy trả lời:
    "Trong một lần UPDATE STACK, tài nguyên nào được phép
     bị sửa hoặc thay thế?"
        ↓
    → nó KHÔNG quyết định ai được xem stack
    → KHÔNG quyết định ai được tạo, xoá stack
    → KHÔNG quyết định ai được gọi API nào
        ↓
IAM policy trả lời:
    "AI được phép làm gì trên tài nguyên nào?"
        ↓
    → đây mới là kiểm soát truy cập

⚠ Và "Principal": "*" trong stack policy không có nghĩa gì cả:

Stack policy BẮT BUỘC Principal phải là "*"
        ↓
    Vì nó không phân biệt người dùng — nó chỉ nói về
    TÀI NGUYÊN NÀO được đụng tới
        ↓
    → viết "*" là đúng cú pháp, nhưng nó không "cấp quyền cho tất cả"
    → đó chỉ là giá trị duy nhất được chấp nhận

⚠ Chính sách trong đề thật ra làm gì:

Cho phép cập nhật mọi tài nguyên
    NHƯNG chặn cập nhật ProductionDatabase
        ↓
    → một chính sách hợp lệ và hữu ích
    → nó bảo vệ cơ sở dữ liệu khỏi bị sửa nhầm khi update stack
        ↓
    → nhưng nó không liên quan gì tới việc "người dùng có
      truy cập được stack hay không"

Vì sao các phương án khác sai

C (chính sách không hợp lệ, cần sửa lỗi cú pháp) — đây là phương án gần nhất vì người ta hay đổ lỗi cho cú pháp khi thứ gì đó "không có tác dụng". Nhưng chính sách này hoàn toàn hợp lệ; vấn đề là nó không phải công cụ cho mục đích đó.
B (stack policy không cho dùng ký tự đại diện cho Principal) — ngược lại: "Principal": "*" là giá trị BẮT BUỘC trong stack policy.
A (stack policy gắn với một IAM role hoặc IAM user cụ thể) — sai; stack policy gắn với một STACK, không gắn với danh tính nào.

Ghi nhớ

⚠ Bốn cơ chế bảo vệ của CloudFormation — bảng phải thuộc, chúng hoàn toàn độc lập: | Cơ chế | Trả lời câu hỏi | |---|---| | IAM policy | AI được gọi API CloudFormation nào | | Stack policy | tài nguyên nào được sửa KHI UPDATE | | DeletionPolicy | tài nguyên có bị xoá khi xoá stack không | | Termination protection | có xoá được cả stack không | | (kèm) Service role | CloudFormation dùng quyền của role đó, không dùng quyền người gọi |

Từ khoá nhận diện:

"ai được truy cập stack" → IAM policy "chặn sửa một tài nguyên khi update" → stack policy "chặn xoá cả stack" → termination protection "giữ dữ liệu khi xoá stack" → DeletionPolicy: Retain "stack policy cấp quyền cho user" → LUÔN SAI

Đặc điểm của stack policy	Nội dung
Gắn vào	một stack
`Principal`	*bắt buộc là `""`**
Action	`Update:Modify`, `Update:Replace`, `Update:Delete`, `Update:*`
Resource	`LogicalResourceId/<ten>` — dùng tên logic trong template
Mặc định	không có stack policy → mọi tài nguyên đều update được
Ghi đè tạm	dùng `--stack-policy-during-update-body` cho một lần update

Ba giá trị Action đáng nhớ	Ý nghĩa
`Update:Modify`	sửa tại chỗ
`Update:Replace`	XOÁ và tạo lại — nguy hiểm nhất
`Update:Delete`	gỡ tài nguyên khỏi stack

Service role — cơ chế đáng biết	Nội dung
CloudFormation dùng quyền của service role, không dùng quyền người gọi
Lợi ích	người dùng không cần quyền tạo EC2, RDS — chỉ cần quyền chạy stack
Kết hợp với	stack policy để bảo vệ tài nguyên trọng yếu
Đây là	mẫu chuẩn cho việc uỷ quyền an toàn trong tổ chức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Stack đang có policy gì | get-stack-policy --stack-name <ten> | | Vì sao user không vào được | IAM Policy Simulator cho các action cloudformation:* | | Update sẽ động vào gì | tạo change set và đọc cột Replacement |

Và một mẫu bảo vệ rất đáng áp dụng cho mọi stack sản xuất: stack policy chặn Update:Replace và Update:Delete trên mọi tài nguyên có lưu trạng thái. Nó không cản trở việc cập nhật hằng ngày, nhưng nó biến một thay đổi vô tình gây thay thế cơ sở dữ liệu — thứ trông hoàn toàn vô hại trong một pull request — thành một lỗi rõ ràng ngay lúc triển khai, thay vì một cuộc mất dữ liệu được phát hiện sau đó.

Câu 188 Domain 4: Security and Compliance

A Systems Administrator has just configured an internet facing Load Balancer for traffic distribution across the EC2 instances placed in different Availability Zones. The clients, however, are unable to connect to the Load Balancer.

What is the most plausible reason for this issue?

A
The target returned the error code of 200 indicating an error on the server side
B
A security group or network ACL is not allowing traffic from the client
C
It is an internal server error
D
The target was incorrectly configured as a Lambda function and not an EC2 instance

Xem giải thích

Đáp án

B — Một Security Group hoặc Network ACL đang không cho phép lưu lượng từ phía client.

Vì sao đúng

Triệu chứng của đề là "client KHÔNG KẾT NỐI ĐƯỢC tới load balancer" — tức là lỗi xảy ra trước khi request tới được ứng dụng.

⚠ Điểm mấu chốt — phân biệt "không kết nối được" với "kết nối được nhưng lỗi":

KHÔNG kết nối được (timeout, connection refused)
        ↓
    → vấn đề ở TẦNG MẠNG
    → Security Group, NACL, hoặc subnet/route table

Kết nối được nhưng nhận mã lỗi (502, 503, 504)
        ↓
    → mạng thông, vấn đề ở TARGET hoặc ở ứng dụng

⚠ Ba lớp mạng phải đúng cho một internet-facing ALB:

1. Security Group CỦA LOAD BALANCER
        ↓
    Inbound: cho phép 80/443 từ 0.0.0.0/0 (hoặc dải client)

2. Network ACL CỦA SUBNET chứa load balancer
        ↓
    Inbound: cho phép 80/443
    Outbound: cho phép CỔNG TẠM 1024–65535  ← rất hay quên

3. Subnet phải là PUBLIC SUBNET
        ↓
    Route table có 0.0.0.0/0 → Internet Gateway

⚠ Và một điều kiện nữa rất hay bị bỏ sót:

ALB internet-facing đòi subnet ở ÍT NHẤT HAI AZ
        ↓
    Mỗi subnet cần ÍT NHẤT 8 địa chỉ IP trống
        ↓
    → thiếu là ALB không tạo được, hoặc không co giãn được

Vì sao các phương án khác sai

C (lỗi máy chủ nội bộ) — đây là phương án gần nhất nếu hiểu là HTTP 500. Nhưng lỗi 500 nghĩa là client ĐÃ kết nối được và nhận về một phản hồi — trái với mô tả "không kết nối được".
A (target trả về mã 200 báo hiệu lỗi phía máy chủ) — tự mâu thuẫn: 200 là THÀNH CÔNG, không phải lỗi.
D (target bị cấu hình nhầm thành Lambda thay vì EC2) — ALB hỗ trợ Lambda làm target một cách hợp lệ. Và nếu target sai thì client vẫn kết nối được tới ALB, chỉ là nhận mã lỗi 502 hoặc 503.

Ghi nhớ

⚠ Chẩn đoán ALB theo triệu chứng — bảng phải thuộc: | Triệu chứng | Nguyên nhân thường gặp | |---|---| | Timeout, không kết nối được | Security Group, NACL, route table, subnet sai | | HTTP 503 | không có target khoẻ, hoặc target group rỗng | | HTTP 502 | target trả phản hồi không hợp lệ, hoặc lỗi bắt tay SSL | | HTTP 504 | target không trả lời kịp — so với idle timeout (mặc định 60 giây) | | HTTP 403 | WAF, hoặc listener rule từ chối | | Kết nối được nhưng chậm | TargetResponseTime cao — ứng dụng chậm |

Từ khoá nhận diện:

"không kết nối được ALB" → SG của ALB, NACL, hoặc subnet không public "503" → không có target khoẻ "504" → target quá chậm, tăng idle timeout hoặc sửa ứng dụng "chỉ có ALB gọi được EC2" → SG của EC2 tham chiếu SG của ALB "ALB không tạo được" → thiếu AZ thứ hai, hoặc subnet hết địa chỉ IP

⚠ Hai Security Group phải cấu hình đúng — đây là mẫu chuẩn: | SG | Inbound | |---|---| | SG của ALB | 80/443 từ 0.0.0.0/0 (hoặc dải client) | | SG của EC2 | cổng ứng dụng từ SG CỦA ALB (tham chiếu SG, không dùng CIDR) | | Lợi ích của tham chiếu SG | máy mới của ASG tự động được phép |

Điều kiện tạo ALB	Nội dung
Ít nhất 2 Availability Zone	bắt buộc
Subnet /27 trở lên, còn ít nhất 8 IP trống	để ALB co giãn
Internet-facing	subnet phải có tuyến `0.0.0.0/0 → IGW`
Internal	không cần IGW, chỉ dùng IP riêng

Công cụ chẩn đoán theo thứ tự	Bước
1	`describe-target-health` — target có khoẻ không, đọc `Reason`
2	VPC Reachability Analyzer — chỉ đích danh thành phần chặn
3	VPC Flow Logs — tìm bản ghi `REJECT`
4	ALB access log — request có tới nơi không
5	`curl -v` từ ngoài và từ trong VPC để khoanh vùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | ALB có nghe cổng đó không | describe-listeners | | SG cho phép gì | describe-security-groups — đọc JSON | | Subnet có public không | route table có 0.0.0.0/0 → igw không |

Và một mẹo khoanh vùng rất nhanh cho loại sự cố này: thử curl tới ALB từ một EC2 trong cùng VPC, rồi thử từ máy bên ngoài. Nếu trong VPC thì được mà ngoài thì không, vấn đề nằm ở đường ra internet — subnet không public, hoặc NACL chặn; còn nếu cả hai đều không được, vấn đề nằm ở Security Group của chính ALB hoặc ở listener. Hai lệnh này thường tiết kiệm được cả buổi đọc luật bằng mắt.

Câu 189 Domain 4: Security and Compliance

A healthcare company has developed its flagship application on AWS Cloud with data security requirements such that the encryption key must be stored in a custom application running on-premises. The company wants to offload the data storage as well as the encryption process to Amazon S3 but continue to use the existing encryption keys.

Which of the following S3 encryption options allows the company to leverage Amazon S3 for storing data with given constraints?

A
Server-Side Encryption with Customer Master Keys (CMKs) Stored in AWS Key Management Service (SSE-KMS)
B
Server-Side Encryption with Customer-Provided Keys (SSE-C)
C
Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3)
D
Client-Side Encryption with data encryption is done on the client-side before sending it to Amazon S3

Xem giải thích

Đáp án

B — Server-Side Encryption with Customer-Provided Keys (SSE-C).

Vì sao đúng

Đề nêu hai ràng buộc tưởng như mâu thuẫn, và chỉ SSE-C dung hoà được cả hai:

Đề yêu cầu	Nghĩa
"khoá mã hoá phải nằm ở ứng dụng TẠI CHỖ"	AWS không được giữ khoá
"giao việc mã hoá và lưu trữ cho S3"	S3 phải là bên thực hiện mã hoá

⚠ Điểm mấu chốt — SSE-C là cách duy nhất tách hai việc này ra:

Client gửi ĐỐI TƯỢNG + KHOÁ trong header của mỗi request
        ↓
    S3 dùng khoá đó MÃ HOÁ dữ liệu
        ↓
    S3 lưu dữ liệu đã mã hoá
    S3 lưu một GIÁ TRỊ BĂM (HMAC) của khoá để kiểm chứng
        ↓
    S3 XOÁ KHOÁ KHỎI BỘ NHỚ ngay lập tức
        ↓
    → khoá KHÔNG BAO GIỜ được lưu ở AWS  ← ràng buộc thứ nhất
    → nhưng S3 vẫn là bên mã hoá         ← ràng buộc thứ hai

Header phải gửi kèm mỗi request:

x-amz-server-side-encryption-customer-algorithm: AES256
x-amz-server-side-encryption-customer-key: <khoá base64>
x-amz-server-side-encryption-customer-key-MD5: <MD5 base64>

⚠ Và hệ quả nghiêm trọng phải hiểu rõ:

Mỗi lần ĐỌC lại đối tượng
        ↓
    → PHẢI gửi lại ĐÚNG khoá đó
        ↓
    MẤT KHOÁ = MẤT DỮ LIỆU VĨNH VIỄN
        ↓
    → AWS không giữ bản sao nào
    → AWS Support không cứu được
        ↓
    → toàn bộ trách nhiệm quản lý khoá thuộc về bạn

⚠ Ràng buộc bắt buộc:

SSE-C BẮT BUỘC dùng HTTPS
        ↓
    Vì khoá đi trong header của request
        ↓
    → gọi qua HTTP thuần → S3 TỪ CHỐI

Vì sao các phương án khác sai

D (client-side encryption — mã hoá ở phía client trước khi gửi lên S3) — đây là phương án gần nhất và cũng giữ khoá ở phía bạn. Nhưng nó vi phạm ràng buộc thứ hai: đề nói rõ muốn giao việc mã hoá cho S3, còn client-side thì chính bạn phải mã hoá trước khi gửi.
A (SSE-KMS) — khoá nằm trong KMS của AWS, trái ràng buộc "khoá phải ở ứng dụng tại chỗ".
C (SSE-S3) — AWS quản lý khoá hoàn toàn, càng trái ràng buộc hơn.

Ghi nhớ

⚠ Bốn kiểu mã hoá của S3 — bảng phải thuộc, và ai làm gì: | Kiểu | Ai giữ khoá | Ai mã hoá | |---|---|---| | SSE-S3 | AWS | S3 | | SSE-KMS | KMS (trong tài khoản bạn) | S3 | | SSE-C | BẠN, ngoài AWS | S3 | | Client-side | BẠN | BẠN |

Từ khoá nhận diện:

"khoá của tôi, nhưng S3 mã hoá hộ" → SSE-C "tôi tự mã hoá trước khi gửi" → client-side "cần nhật ký ai dùng khoá" → SSE-KMS "đơn giản, không quản khoá" → SSE-S3 "AWS không được thấy khoá" → SSE-C hoặc client-side

Xem thêm câu #11655 và #11662: cùng bài toán chọn kiểu mã hoá S3 nhưng đáp án khác nhau vì yêu cầu khác nhau — #11655 cần nhật ký kiểm toán nên chọn SSE-KMS, #11662 chỉ cần AES-256 mà không quản khoá nên chọn SSE-S3. Ba câu không mâu thuẫn: ràng buộc về khoá quyết định đáp án.

Hạn chế của SSE-C — phải cân nhắc trước khi chọn	Nội dung
Mọi request đọc/ghi phải gửi khoá	mã ứng dụng phức tạp hơn
BẮT BUỘC HTTPS
Không dùng được với Console	không tải tệp lên/xuống bằng giao diện
Lifecycle transition vẫn chạy	nhưng thao tác đọc thì luôn cần khoá
Mất khoá = mất dữ liệu	không có đường lùi
Cross-Region Replication	hỗ trợ hạn chế

Client-side encryption — khi nào chọn	Nội dung
Yêu cầu tuân thủ đòi AWS không bao giờ thấy dữ liệu thô
Công cụ	AWS Encryption SDK, S3 Encryption Client
Có thể dùng KMS làm nơi giữ khoá gốc	mà vẫn mã hoá ở phía client
Đánh đổi	ứng dụng phải lo mã hoá, giải mã, và xoay khoá

Cách khác nếu muốn dùng khoá riêng mà đỡ vất vả	Nội dung
KMS External Key Store (XKS)	khoá nằm trong HSM của bạn, KMS gọi ra ngoài để dùng
Import key material vào KMS	bạn sinh khoá, nhập vào KMS, giữ bản gốc
CloudHSM key store	khoá trong cụm CloudHSM của riêng bạn
Lợi ích	vẫn dùng được SSE-KMS với mọi tiện ích đi kèm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối tượng mã hoá kiểu gì | head-object kèm khoá — thấy SSECustomerAlgorithm | | Khoá có đúng không | sai khoá → 403, S3 so với HMAC đã lưu | | Ai đã truy cập | CloudTrail data event hoặc S3 access log |

Và một cảnh báo cần nói thẳng với đội kiến trúc: SSE-C đặt toàn bộ rủi ro mất dữ liệu lên hệ thống quản lý khoá tại chỗ của bạn. Trước khi chọn nó, hãy hỏi xem hệ thống ấy có sao lưu không, có khôi phục được không, và ai chịu trách nhiệm khi nó hỏng — vì với hàng terabyte dữ liệu y tế đã mã hoá, một sự cố ở kho khoá tại chỗ không phải là gián đoạn dịch vụ, mà là mất dữ liệu vĩnh viễn.

Câu 190 Domain 5: Networking and Content Delivery

A company uses Amazon S3 bucket replication to copy data from one S3 bucket into the other, for compliance purposes. The Technical Lead of the development team wants to be notified if replication of an object across S3 buckets fails.

How will you configure this automatic notification?

A
Amazon S3 publishes object events to CloudWatch. Configure Amazon Simple Notification Service (Amazon SNS) to send notifications for replication failure of objects
B
Enable S3 Replication with Notification, which allows you to set up notifications for objects that failed replication
C
Use Amazon Simple Queue Service (Amazon SQS) queue to copy objects from one S3 bucket to the other. If replication fails, messages in the queue can be configured to send notification using SNS
D
Enable S3 Replication Time Control (S3 RTC), which allows you to set up notifications for eligible objects that failed replication

Xem giải thích

Đáp án

D — Bật S3 Replication Time Control (S3 RTC), cơ chế cho phép thiết lập thông báo cho những đối tượng đủ điều kiện mà sao chép thất bại.

Vì sao đúng

Sao chép S3 thông thường không phát ra tín hiệu nào khi thất bại — phải bật RTC mới có.

⚠ Điểm mấu chốt — RTC mang theo cả SLA lẫn hệ thống chỉ số và sự kiện:

S3 Replication Time Control
        ↓
    Cam kết: 99,99% đối tượng được sao chép TRONG 15 PHÚT
        ↓
    Kèm theo:
        - chỉ số CloudWatch chi tiết
        - SỰ KIỆN khi sao chép vượt ngưỡng 15 phút
        - SỰ KIỆN khi sao chép THẤT BẠI  ← đề cần
        ↓
    → EventBridge bắt sự kiện → SNS → báo cho Team Lead

⚠ Các sự kiện mà RTC phát ra:

s3:Replication:OperationMissedThreshold
        → chưa xong trong 15 phút
s3:Replication:OperationFailedReplication
        → THẤT BẠI                        ← thứ đề cần
s3:Replication:OperationReplicatedAfterThreshold
        → xong nhưng trễ hơn 15 phút
s3:Replication:OperationNotTracked
        → đối tượng không nằm trong phạm vi RTC

Quy tắc EventBridge tương ứng:

{
  "source": ["aws.s3"],
  "detail-type": ["Object Replication"],
  "detail": { "reason": ["OperationFailedReplication"] }
}

⚠ Ba chỉ số CloudWatch mà RTC bổ sung:

ReplicationLatency        → độ trễ sao chép hiện tại
BytesPendingReplication   → còn bao nhiêu dữ liệu chờ
OperationsPendingReplication → còn bao nhiêu đối tượng chờ
        ↓
    → đặt alarm trên các chỉ số này để biết
      sao chép đang tụt lại TRƯỚC khi có ai phàn nàn

Xem thêm câu #11664: cùng chủ đề sao chép thất bại nhưng hỏi ở góc khác — ở đó cần một DANH SÁCH đối tượng lỗi tạo hằng ngày, và câu trả lời là S3 Inventory với cột ReplicationStatus. Hai công cụ bổ sung cho nhau: RTC báo NGAY, Inventory cho DANH SÁCH.

Vì sao các phương án khác sai

B (bật "S3 Replication with Notification") — đây là phương án gần nhất và cái tên nghe rất thuyết phục, nhưng không có tính năng nào tên như vậy. Tên đúng là S3 Replication Time Control.
A (S3 publish object event tới CloudWatch, cấu hình SNS gửi thông báo) — mô tả không chính xác: S3 phát sự kiện tới EventBridge, SNS, SQS hoặc Lambda — không "publish object event tới CloudWatch". Và quan trọng hơn: sự kiện sao chép thất bại chỉ có khi bật RTC.
C (dùng SQS để copy đối tượng giữa hai bucket) — hiểu sai kiến trúc: sao chép S3 là cơ chế dựng sẵn của chính S3, không phải thứ bạn tự dựng bằng hàng đợi.

Ghi nhớ

⚠ Sao chép S3 — bảng phải thuộc: | Kiểu | Nội dung | |---|---| | CRR (Cross-Region) | khác Region — khôi phục thảm hoạ, tuân thủ, giảm độ trễ | | SRR (Same-Region) | cùng Region — gom log, tách môi trường, đổi chủ sở hữu | | RTC | cam kết 15 phút + chỉ số + sự kiện — có phí thêm | | Batch Replication | sao chép dữ liệu đã có TỪ TRƯỚC khi bật replication |

Từ khoá nhận diện:

"báo NGAY khi sao chép lỗi" → S3 RTC + EventBridge "danh sách đối tượng lỗi hằng ngày" → S3 Inventory "cam kết thời gian sao chép" → RTC, 15 phút, có SLA "sao chép dữ liệu đã có từ trước" → S3 Batch Replication "đếm số lần lỗi" → chỉ số CloudWatch của replication

Điều kiện bắt buộc để sao chép S3 hoạt động	Nội dung
Versioning bật ở CẢ HAI bucket
IAM role cho S3 với quyền đọc nguồn, ghi đích
Đối tượng mã hoá	role cần quyền dùng KMS key ở CẢ HAI Region
Chỉ áp cho đối tượng GHI MỚI	dữ liệu cũ dùng Batch Replication
Không sao chép	đối tượng đã là bản sao (`REPLICA`) từ replication khác

Vì sao sao chép thất bại — nguyên nhân thường gặp	Nội dung
Thiếu quyền trên IAM role	phổ biến nhất
KMS key ở Region đích không cho role dùng
Bucket đích chưa bật versioning
Bucket đích ở tài khoản khác thiếu bucket policy
Đối tượng vượt giới hạn kích thước

Chi phí của RTC	Nội dung
Phí theo GB được sao chép với RTC	cao hơn replication thường
Cộng thêm	phí truyền dữ liệu liên Region, phí lưu trữ ở đích
Cân nhắc	bật RTC chỉ cho tiền tố thật sự cần SLA, không bật cho cả bucket

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trạng thái sao chép của một đối tượng | head-object, xem ReplicationStatus | | Có bao nhiêu đối tượng lỗi | S3 Inventory với cột ReplicationStatus | | Độ trễ hiện tại | chỉ số ReplicationLatency |

Và một lời khuyên về mức độ giám sát cho dữ liệu tuân thủ: hãy đặt cảnh báo trên BytesPendingReplication chứ đừng chỉ chờ sự kiện thất bại. Sao chép hiếm khi hỏng đột ngột — nó thường tụt lại dần trong im lặng khi khối lượng ghi tăng hoặc quyền bị siết, và một đồ thị "dữ liệu chờ sao chép" đang leo đều đặn là cảnh báo sớm hơn nhiều so với sự kiện lỗi đầu tiên.

Trang 19 / 94 — tổng 936 câu hỏi