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

Đáp án

C, E — hai cách ép tạo EFS mã hoá:

• C — Dùng khoá điều kiện IAM elasticfilesystem:Encrypted trong chính sách identity-based.
• E — Định nghĩa Service Control Policy (SCP) trong AWS Organizations để ép mã hoá EFS cho mọi tài khoản trong tổ chức.

Vì sao đúng

Cả hai đều là cơ chế NGĂN CHẶN — chúng chặn việc tạo file system không mã hoá ngay từ đầu.

⚠ Điều C — khoá điều kiện IAM chặn ở cấp người dùng:

{
  "Effect": "Deny",
  "Action": "elasticfilesystem:CreateFileSystem",
  "Resource": "*",
  "Condition": {
    "Bool": { "elasticfilesystem:Encrypted": "false" }
  }
}

    → user hoặc role gắn chính sách này
    → gọi CreateFileSystem mà không bật mã hoá
    → BỊ TỪ CHỐI NGAY, file system không được tạo

⚠ Điều E — SCP chặn ở cấp TÀI KHOẢN, mạnh hơn hẳn:

SCP gắn vào một OU trong Organizations
        ↓
    Áp cho MỌI principal trong mọi tài khoản thuộc OU đó
        ↓
    → kể cả IAM user có AdministratorAccess
    → kể cả tài khoản root của tài khoản thành viên
        ↓
    → không ai lách được, không ai gỡ được

⚠ Và đây là điểm quan trọng nhất về mã hoá EFS:

Mã hoá at-rest của EFS CHỈ ĐẶT ĐƯỢC LÚC TẠO
        ↓
    → KHÔNG bật được cho file system đã có
        ↓
    → muốn mã hoá cái cũ: tạo file system MỚI có mã hoá,
      rồi dùng DataSync chuyển dữ liệu sang
        ↓
    → chính vì không sửa được sau, nên phải NGĂN CHẶN từ đầu

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

• B (dùng AWS Config để ép tạo chỉ file system mã hoá) — đây là phương án gần nhất và AWS Config đúng là công cụ tuân thủ. Nhưng Config là cơ chế PHÁT HIỆN, không phải NGĂN CHẶN: nó chỉ báo sau khi file system chưa mã hoá đã được tạo xong — mà EFS thì không bật mã hoá sau được, nên lúc đó đã muộn. (Config vẫn hữu ích làm lưới an toàn, chỉ không phải cơ chế "ép".)

• A (CLI mặc định bật mã hoá) và D (SDK mặc định bật mã hoá) — cả hai đều sai: mặc định của CreateFileSystem qua CLI và SDK là KHÔNG mã hoá. Chỉ Console mới tick sẵn ô mã hoá. Đây chính là lý do câu hỏi này tồn tại.

Ghi nhớ

⚠ Ngăn chặn và phát hiện — bảng phải thuộc, đây là ranh giới quyết định: | Cơ chế | Loại | Chặn được trước khi xảy ra | |---|---|---| | SCP | NGĂN CHẶN | CÓ, mạnh nhất | | IAM policy + condition key | NGĂN CHẶN | CÓ | | Permissions boundary | ngăn chặn | có | | AWS Config rule | PHÁT HIỆN | KHÔNG | | Security Hub | phát hiện | không | | Kiểm tra trong pipeline IaC | ngăn chặn | có |

Từ khoá nhận diện:

"ÉP phải mã hoá" → SCP hoặc IAM condition key "PHÁT HIỆN cái chưa mã hoá" → AWS Config "bật mã hoá cho EFS đã có" → KHÔNG ĐƯỢC, phải tạo mới + DataSync "mặc định CLI/SDK có mã hoá không" → KHÔNG "áp cho cả tổ chức" → SCP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | File system có mã hoá không | describe-file-systems, xem Encrypted | | SCP có áp không | describe-effective-policy ở cấp tài khoản | | Thử nghiệm | cố tạo một EFS không mã hoá — phải bị từ chối |

Và một lời nhắc quan trọng về thứ tự làm việc: với những dịch vụ mà mã hoá chỉ đặt được lúc tạo — EFS, EBS, RDS — thì cơ chế phát hiện gần như vô dụng nếu đứng một mình. AWS Config sẽ trung thực báo cho bạn biết rằng có một file system chưa mã hoá, nhưng cách sửa duy nhất là tạo mới và chuyển toàn bộ dữ liệu sang — một dự án, không phải một lần bấm nút. Đó là lý do câu hỏi này nhấn mạnh vào ngăn chặn.

Đáp án

D — Các EBS volume bị xoá thông qua lời gọi TerminateInstances sẽ còn hiển thị một thời gian trên AWS Config console.

Vì sao đúng

Đây là một đặc thù trong cách AWS Config nhận biết sự kiện xoá, và nó phụ thuộc vào API nào đã gây ra việc xoá.

⚠ Điểm mấu chốt — hai đường xoá volume, hai cách Config nhận biết:

Gọi THẲNG DeleteVolume
        ↓
    Config nhận được sự kiện xoá TRỰC TIẾP cho volume đó
        ↓
    → cập nhật ngay, đánh dấu tài nguyên đã bị xoá

Gọi TerminateInstances (volume bị xoá KÈM THEO)
        ↓
    Sự kiện chính là việc chấm dứt INSTANCE
    Volume bị xoá như một HỆ QUẢ PHỤ
        ↓
    → Config phải suy ra từ thay đổi của instance
    → có ĐỘ TRỄ trước khi trạng thái volume được cập nhật
        ↓
    → trong khoảng đó, volume vẫn hiện là COMPLIANT

⚠ Vì sao đây không phải lỗi, và làm gì để tránh nhầm lẫn:

Đây là hành vi ĐÃ ĐƯỢC AWS ghi trong tài liệu
        ↓
    Cách tránh nhầm lẫn:
        - đối chiếu với EC2 console hoặc describe-volumes
          trước khi kết luận
        - đọc Config TIMELINE của tài nguyên, không chỉ
          nhìn trạng thái compliance hiện tại
        - hiểu rằng Config phản ánh trạng thái ĐÃ GHI NHẬN,
          có thể trễ so với thực tế

⚠ Và một điều rất đáng nhớ về cách Config báo cáo tài nguyên đã xoá:

Config giữ lại LỊCH SỬ của tài nguyên đã xoá
        ↓
    → đó là tính năng, không phải lỗi
    → cho phép trả lời "tài nguyên này trước đây cấu hình thế nào"
        ↓
    Trạng thái ghi nhận cuối cùng của một tài nguyên đã xoá
    là "ResourceDeleted"

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

• A (volume xoá bằng DeleteVolume còn hiện một thời gian) — đây là phương án gần nhất và chỉ khác đáp án đúng ở TÊN API. Nhưng với DeleteVolume, Config nhận được sự kiện xoá trực tiếp nên cập nhật kịp thời. Chính sự phân biệt giữa hai API này là nội dung câu hỏi.

• C (DeleteOnTermination đặt là false nên volume vẫn còn sống) — nếu vậy thì volume THẬT SỰ chưa bị xoá, và Config báo compliant là hoàn toàn chính xác. Nhưng đề nói rõ volume đã bị xoá.

• B (volume chưa xoá được vì vấn đề quyền) — thiếu quyền thì lời gọi trả về AccessDenied rõ ràng, và người thực hiện sẽ biết ngay.

Ghi nhớ

⚠ Ba đặc điểm của AWS Config cần hiểu để không hiểu nhầm kết quả: | Đặc điểm | Nội dung | |---|---| | Config phản ánh trạng thái ĐÃ GHI NHẬN | có thể trễ so với thực tế | | Giữ lịch sử tài nguyên đã xoá | tính năng, không phải lỗi | | Là cơ chế PHÁT HIỆN | không ngăn chặn được gì |

Từ khoá nhận diện:

"Config vẫn hiện tài nguyên đã xoá" → độ trễ, hoặc lịch sử được giữ lại "tài nguyên trước đây cấu hình thế nào" → Config timeline "ai đã xoá và lúc nào" → CloudTrail "ngăn không cho tạo tài nguyên sai chuẩn" → SCP, không phải Config "tự sửa khi phát hiện vi phạm" → remediation action

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Volume thật sự còn không | describe-volumes — nguồn sự thật duy nhất | | Config ghi nhận trạng thái gì | get-resource-config-history | | Ai đã xoá | CloudTrail sự kiện TerminateInstances hoặc DeleteVolume |

Và một nguyên tắc chung khi làm việc với các công cụ tuân thủ: đừng bao giờ coi bảng compliance là nguồn sự thật cuối cùng — hãy đối chiếu với chính dịch vụ đó. AWS Config là công cụ tuyệt vời để trả lời câu hỏi "trong hàng nghìn tài nguyên, cái nào lệch chuẩn", nhưng khi cần xác nhận trạng thái của một tài nguyên cụ thể ngay lúc này, describe-volumes cho câu trả lời chính xác và tức thì, còn Config thì luôn có một độ trễ nhất định.

Đáp án

A — Dùng CloudTrail log file integrity validation để giữ log không bị sửa đổi.

Vì sao đúng

Kiểm toán viên không hỏi "làm sao chặn người ta sửa log" mà hỏi "làm sao CHỨNG MINH log chưa bị sửa" — và đó là hai bài toán khác nhau.

⚠ Điểm mấu chốt — cơ chế digest file:

CloudTrail bật log file validation
        ↓
    Mỗi giờ, CloudTrail tạo một DIGEST FILE chứa:
        - mã băm SHA-256 của từng tệp log trong giờ đó
        - mã băm của DIGEST FILE của giờ TRƯỚC
        ↓
    Digest file được KÝ SỐ bằng khoá riêng của AWS
        ↓
    → tạo thành một CHUỖI liên kết không đứt đoạn
        ↓
    Sửa một tệp log  → mã băm không khớp → PHÁT HIỆN
    Xoá một tệp log  → digest thiếu → PHÁT HIỆN
    Xoá một digest   → chuỗi đứt → PHÁT HIỆN

⚠ Kiểm chứng bằng một lệnh:

aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:ap-southeast-1:111122223333:trail/kiem-toan \
  --start-time 2026-08-01T00:00:00Z

Kết quả cho biết chính xác tệp nào đã bị sửa hoặc bị xoá — bằng chứng có tính pháp lý mà kiểm toán viên chấp nhận.

⚠ Và đây là kiến trúc đầy đủ mà một công ty tài chính nên dựng:

1. Log file validation          → CHỨNG MINH toàn vẹn
2. S3 Object Lock (Compliance)  → KHÔNG AI xoá được, kể cả root
3. Bucket log ở TÀI KHOẢN RIÊNG → tách khỏi tài khoản bị kiểm toán
4. SSE-KMS với CMK riêng        → kiểm soát ai đọc được log
5. Organization trail           → tài khoản thành viên không tắt được
        ↓
    → mỗi lớp giải quyết một mối đe doạ khác nhau

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

• C (dùng S3 Versioning để giữ mọi phiên bản của tệp) — đây là phương án gần nhất và là một biện pháp bảo vệ thật: nó giúp khôi phục nếu tệp bị ghi đè. Nhưng nó không CHỨNG MINH được điều gì: kiểm toán viên vẫn phải tin rằng phiên bản họ đang xem là phiên bản gốc. Chỉ chữ ký số của digest file mới trả lời được câu hỏi đó.

• B (dùng MFA Delete để biết ai đã xoá log) — MFA Delete chống xoá, nhưng không "cho biết ai đã xoá" (việc đó là của CloudTrail), và nó cũng không chứng minh được nội dung log chưa bị sửa.

• D ("KMS logfile security keys") — không có tính năng nào tên như vậy. CloudTrail có hỗ trợ mã hoá log bằng SSE-KMS, nhưng mã hoá bảo vệ tính bí mật, không bảo vệ tính toàn vẹn.

Ghi nhớ

⚠ Ba tính chất bảo mật và công cụ tương ứng — bảng phải thuộc: | Tính chất | Bảo vệ khỏi | Công cụ cho CloudTrail | |---|---|---| | Confidentiality (bí mật) | người không phận sự ĐỌC | SSE-KMS | | Integrity (toàn vẹn) | ai đó SỬA mà không ai biết | log file validation | | Availability (sẵn có) | ai đó XOÁ | Object Lock, versioning, MFA Delete |

Từ khoá nhận diện:

"chứng minh log chưa bị sửa" → log file validation "không ai xoá được log, kể cả root" → S3 Object Lock chế độ Compliance "ai đọc được log" → SSE-KMS + key policy "tài khoản thành viên không tắt được trail" → organization trail "mã hoá bảo vệ toàn vẹn" → SAI, mã hoá bảo vệ tính bí mật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Validation đã bật chưa | describe-trails, xem LogFileValidationEnabled | | Log có toàn vẹn không | validate-logs với khoảng thời gian cần kiểm | | Có ai tắt trail không | CloudTrail sự kiện StopLogging — nên đặt cảnh báo |

Và một biện pháp nên dựng ngay trong mọi môi trường chịu kiểm toán: cảnh báo EventBridge cho sự kiện StopLogging và DeleteTrail. Việc đầu tiên một kẻ tấn công làm sau khi chiếm được quyền quản trị là tắt kiểm toán — và nếu không có cảnh báo, hành động đó hoàn toàn im lặng: không có lỗi, không có sự cố, chỉ là từ giây phút ấy trở đi bạn không còn ghi lại được gì nữa.

Đáp án

A, D — hai thực hành tốt để khôi phục dữ liệu từ Storage Gateway hỏng:

• A — Với stored volume gateway, bạn khôi phục dữ liệu từ EBS snapshot gần nhất của volume.
• D — Nếu hệ thống tệp bị hỏng, bạn dùng lệnh fsck để sửa.

Vì sao đúng

⚠ Điều A — snapshot là bản sao nằm ở nơi an toàn, độc lập với gateway:

Stored volume gateway
        ↓
    Toàn bộ dữ liệu nằm TẠI CHỖ
    Snapshot được đẩy lên AWS dạng EBS snapshot
        ↓
    Gateway VM hỏng
        ↓
    → dữ liệu tại chỗ có thể mất theo phần cứng
    → nhưng SNAPSHOT trên AWS vẫn còn nguyên
        ↓
    Khôi phục:
        - tạo EBS volume từ snapshot, gắn vào EC2, HOẶC
        - dựng gateway MỚI rồi khôi phục volume từ snapshot

⚠ Điều D — fsck sửa hỏng hệ thống tệp, không phải hỏng dữ liệu:

Gateway hỏng đột ngột (mất điện, treo VM)
        ↓
    Hệ thống tệp trên volume có thể ở trạng thái không nhất quán
        ↓
    fsck (Linux) hoặc chkdsk (Windows)
        ↓
    → sửa cấu trúc hệ thống tệp
    → thường khôi phục được volume mà không mất dữ liệu
        ↓
    → đây là bước ĐẦU TIÊN nên thử, trước khi khôi phục từ snapshot

⚠ Và quy trình khôi phục theo thứ tự nên làm:

1. Chụp snapshot NGAY (nếu volume còn truy cập được)
        ↓
2. Thử fsck/chkdsk để sửa hệ thống tệp
        ↓
3. Nếu không được: dựng gateway MỚI
        ↓
4. Khôi phục volume từ snapshot gần nhất
        ↓
5. Chấp nhận mất phần dữ liệu phát sinh SAU snapshot đó

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

• C (nếu trạng thái volume là IRRECOVERABLE thì không khôi phục dữ liệu được nữa) — đây là phương án gần nhất và nghe rất hợp lý, nhưng nó quá tuyệt đối. IRRECOVERABLE nghĩa là gateway không dùng volume đó được nữa, nhưng bạn vẫn khôi phục được dữ liệu từ SNAPSHOT gần nhất — đúng như đáp án A nói.

• E (khôi phục gateway VM từ snapshot do hypervisor tạo) — AWS KHUYẾN CÁO KHÔNG làm việc này: snapshot của hypervisor chụp gateway VM ở một thời điểm cũ, và khi khôi phục thì trạng thái nội bộ của gateway lệch với trạng thái trên AWS — dẫn tới hỏng dữ liệu. Cách đúng là dựng gateway MỚI.

• B (khôi phục gateway VM từ AMI của EC2) — cùng vấn đề như E, và còn nhầm về kiến trúc: gateway tại chỗ chạy trên hypervisor của bạn, không phải từ AMI.

Ghi nhớ

⚠ Khôi phục Storage Gateway — bảng phải thuộc: | Loại gateway | Khôi phục từ | |---|---| | Stored volumes | EBS snapshot của volume | | Cached volumes | EBS snapshot — dữ liệu chính vốn đã ở AWS | | File Gateway | dữ liệu vẫn nguyên trên S3 — chỉ cần dựng gateway mới và trỏ lại | | Tape Gateway | băng ảo vẫn ở S3/Glacier |

Từ khoá nhận diện:

"khôi phục volume gateway" → từ EBS snapshot "khôi phục gateway VM từ snapshot hypervisor" → AWS KHUYẾN CÁO KHÔNG "hệ thống tệp hỏng" → fsck hoặc chkdsk "trạng thái IRRECOVERABLE" → volume không dùng lại được, nhưng snapshot vẫn còn "gateway VM hỏng, dữ liệu ở đâu" → tuỳ loại gateway, xem bảng trên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trạng thái volume | describe-cached-iscsi-volumes / describe-stored-iscsi-volumes | | Snapshot gần nhất khi nào | describe-snapshots lọc theo tag của gateway | | Gateway còn liên lạc với AWS không | trạng thái trong console Storage Gateway |

Và một lời khuyên rút ra từ chính sự cố này: hãy đo xem lịch snapshot hiện tại tương ứng với RPO bao nhiêu, và hỏi bộ phận nghiệp vụ xem con số đó có chấp nhận được không. Khi gateway hỏng, lượng dữ liệu bạn mất chính xác bằng khoảng thời gian từ snapshot gần nhất tới lúc sự cố — và đó là một con số nên được thống nhất từ trước, chứ không phải phát hiện ra trong lúc đang khôi phục.

Đáp án

B, E — hai bước BẮT BUỘC:

• E — Đăng ký tên miền với Route 53 hoặc một nhà đăng ký tên miền khác.
• B — Lấy chứng chỉ SSL/TLS từ một tổ chức chứng thực (CA) được uỷ quyền, bao phủ tên miền đó.

Vì sao đúng

Muốn dùng tên miền riêng cho CloudFront thì phải thoả hai điều kiện tiên quyết, và cả hai đều là điều kiện cần.

⚠ Điều E — phải SỞ HỮU tên miền đã:

CloudFront không cấp tên miền cho bạn
        ↓
    Bạn phải tự đăng ký tên miền ở một registrar
        ↓
    (Route 53, hoặc GoDaddy, Namecheap, bất kỳ đâu)
        ↓
    → rồi mới trỏ được nó về distribution

⚠ Điều B — CloudFront BẮT BUỘC có chứng chỉ cho tên miền riêng:

Dùng tên miền mặc định d111111abcdef8.cloudfront.net
        ↓
    → CloudFront đã có chứng chỉ sẵn

Dùng tên miền riêng cdn.congty.com
        ↓
    → PHẢI có chứng chỉ bao phủ tên miền đó
    → nếu không, trình duyệt báo lỗi chứng chỉ
        ↓
    Hai nguồn chứng chỉ:
        - ACM (miễn phí) — BẮT BUỘC ở Region us-east-1
        - CA bên thứ ba, nhập vào ACM hoặc IAM

⚠ Ba bước hoàn chỉnh để thêm alternate domain name:

1. Đăng ký tên miền                         ← điều E
2. Có chứng chỉ SSL/TLS cho tên miền đó     ← điều B
        ↓
    (nếu dùng ACM: chứng chỉ PHẢI ở us-east-1)
        ↓
3. Thêm tên miền vào mục "Alternate domain names (CNAMEs)"
   của distribution, và chọn chứng chỉ
        ↓
4. Tạo bản ghi DNS trỏ tên miền về distribution
        ↓
    Route 53  → dùng ALIAS record (miễn phí truy vấn)
    Nơi khác  → dùng CNAME record

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

• C (đăng ký một PRIVATE certificate với ACM) — đây là phương án gần nhất và chỉ sai một từ: chứng chỉ phải là PUBLIC, không phải private. Chứng chỉ từ AWS Private CA chỉ được tin cậy trong nội bộ tổ chức bạn; trình duyệt của người dùng trên internet sẽ báo lỗi vì không tin CA đó.

• D (dùng SNI để "uỷ quyền" chứng chỉ cho tên miền) — hiểu sai công dụng: SNI là một cơ chế của TLS cho phép nhiều tên miền dùng chung một địa chỉ IP. CloudFront mặc định đã dùng SNI và nó miễn phí; nó không phải một bước bạn phải làm, và cũng không "uỷ quyền" chứng chỉ nào.

• A (cấu hình AWS Global Accelerator để định tuyến tới các tên miền) — Global Accelerator cấp IP tĩnh anycast cho ALB, NLB, EC2 và Elastic IP. Nó không liên quan tới việc gắn tên miền riêng cho CloudFront.

Ghi nhớ

⚠ Chứng chỉ cho CloudFront — bảng phải thuộc: | Yêu cầu | Nội dung | |---|---| | Region của chứng chỉ ACM | BẮT BUỘC us-east-1 (N. Virginia) | | Loại chứng chỉ | PUBLIC — trình duyệt phải tin cậy được | | Phải bao phủ | đúng alternate domain name (hoặc wildcard *.congty.com) | | Chứng chỉ bên thứ ba | nhập vào ACM (us-east-1) hoặc IAM certificate store | | Chi phí ACM public | MIỄN PHÍ |

Từ khoá nhận diện:

"tên miền riêng cho CloudFront" → đăng ký tên miền + chứng chỉ PUBLIC "chứng chỉ ACM cho CloudFront" → us-east-1, BẮT BUỘC "private certificate cho website công khai" → LUÔN SAI "trỏ tên miền GỐC về CloudFront" → Route 53 ALIAS (CNAME không dùng được ở zone apex) "IP tĩnh cho ALB/NLB" → Global Accelerator

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chứng chỉ ở Region nào | ACM console — đổi sang us-east-1 để xem | | Distribution triển khai xong chưa | trạng thái phải là Deployed | | DNS đã lan chưa | dig cdn.congty.com — phải trỏ về *.cloudfront.net |

Và một chi tiết khiến rất nhiều người mất cả buổi: chứng chỉ ACM cho CloudFront BẮT BUỘC phải nằm ở Region us-east-1, kể cả khi toàn bộ hạ tầng của bạn ở Singapore hay Frankfurt. Triệu chứng là bạn đã tạo chứng chỉ thành công, nó hiện trạng thái Issued, nhưng ô chọn chứng chỉ trong cấu hình CloudFront lại trống trơn — và không có thông báo nào giải thích vì sao.

Đáp án

B — Bạn KHÔNG thể vô hiệu hoá Availability Zone cho Network Load Balancer sau khi đã tạo nó.

Vì sao đúng

Đây là một khác biệt cơ bản giữa NLB và ALB mà rất nhiều người không biết cho tới khi cần dùng.

⚠ Điểm mấu chốt — NLB gắn AZ vĩnh viễn, ALB thì không:

Application Load Balancer
        ↓
    Thêm hoặc BỚT Availability Zone bất cứ lúc nào
        ↓
    aws elbv2 set-subnets --load-balancer-arn ... --subnets ...

Network Load Balancer
        ↓
    THÊM AZ mới thì được
    BỚT AZ đã có thì KHÔNG
        ↓
    → AZ đã bật là bật vĩnh viễn cho vòng đời của NLB đó

⚠ Vì sao NLB lại có ràng buộc này:

Mỗi AZ của NLB có một ĐỊA CHỈ IP TĨNH riêng
        ↓
    Địa chỉ đó được công bố qua DNS
    Khách hàng có thể đã ghi cứng nó vào firewall
        ↓
    Gỡ AZ = làm biến mất một địa chỉ IP mà người khác đang dùng
        ↓
    → AWS không cho phép, để tránh phá vỡ kết nối của bên thứ ba

⚠ Vậy đội phát triển trong đề nên làm gì:

Muốn "tắt" một AZ để thử nghiệm — cách thực tế:
        ↓
    1. Gỡ đăng ký (deregister) mọi target ở AZ đó
       → NLB không gửi lưu lượng tới đó nữa
       → nhưng địa chỉ IP của AZ đó vẫn còn trong DNS

    2. Hoặc: bật cross-zone load balancing (đề đã bật)
       → lưu lượng tới AZ đó vẫn được chuyển sang AZ khác
       → thử nghiệm mà không gián đoạn

    3. Nếu thật sự cần bỏ hẳn AZ
       → TẠO MỘT NLB MỚI với đúng các AZ mong muốn

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

• C (xoá hết target trong AZ đó để vô hiệu hoá AZ) — đây là phương án gần nhất và về mặt thực tế thì đúng là cách nên làm để ngừng lưu lượng tới AZ. Nhưng nó không "vô hiệu hoá AZ": AZ vẫn nằm trong cấu hình NLB, địa chỉ IP của nó vẫn được công bố qua DNS, và client vẫn kết nối tới đó (rồi được chuyển sang AZ khác nhờ cross-zone).

• D (xoá subnet của AZ đó) — không làm được: subnet đang có ENI của NLB thì không xoá được, và làm vậy sẽ phá hỏng chính NLB.

• A (gỡ Elastic IP của subnet để vô hiệu hoá AZ) — không có cơ chế như vậy. Elastic IP của NLB gắn lúc tạo và không gỡ ra được; gỡ nó cũng không loại AZ khỏi cấu hình.

Ghi nhớ

⚠ NLB và ALB — bảng phải thuộc, đây là những khác biệt hay bị hỏi: | | NLB | ALB | |---|---|---| | Tầng | 4 (TCP/UDP/TLS) | 7 (HTTP/HTTPS) | | Bớt AZ sau khi tạo | KHÔNG ĐƯỢC | được | | IP tĩnh mỗi AZ | CÓ (gán Elastic IP được) | không | | Cross-zone mặc định | TẮT (bật thì tính phí liên AZ) | BẬT (miễn phí) | | Giữ IP nguồn của client | CÓ (target theo instance id) | qua X-Forwarded-For | | Hỗ trợ UDP | CÓ | không | | Quy mô | hàng triệu request/giây | thấp hơn | | Pre-warm | không cần | có thể cần |

Từ khoá nhận diện:

"bớt AZ của NLB" → KHÔNG ĐƯỢC, phải tạo NLB mới "bớt AZ của ALB" → được, set-subnets "IP tĩnh cho load balancer" → NLB "cross-zone của NLB" → TẮT mặc định, bật thì tính phí "ngừng lưu lượng tới một AZ" → deregister target ở AZ đó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | NLB đang ở những AZ nào | describe-load-balancers, xem AvailabilityZones | | Cross-zone đã bật chưa | thuộc tính load_balancing.cross_zone.enabled | | Target ở AZ nào | describe-target-health, xem trường AvailabilityZone |

Và một lời khuyên cần nhớ khi dựng NLB: hãy chọn danh sách Availability Zone cho đúng ngay từ đầu, vì đó là một quyết định không đảo ngược được. Với ALB thì việc chọn thiếu hay thừa AZ chỉ là một lệnh set-subnets để sửa, còn với NLB thì cách duy nhất là dựng một load balancer mới và chuyển toàn bộ lưu lượng sang — kèm theo việc mọi địa chỉ IP tĩnh mà khách hàng đã ghi vào firewall của họ đều phải thay đổi.

Đáp án

A — Dùng account-to-account sharing (chia sẻ danh mục giữa các tài khoản).

Vì sao đúng

Ràng buộc quyết định nằm ở cuối đề: "mọi bản sao của danh mục phải luôn ĐỒNG BỘ".

⚠ Điểm mấu chốt — chia sẻ tạo ra một THAM CHIẾU, không phải bản sao:

Tài khoản A (quản lý danh mục) chia sẻ portfolio
        ↓
    Tài khoản B "imports" portfolio đó
        ↓
    → B nhận một THAM CHIẾU tới portfolio gốc
    → KHÔNG phải bản sao độc lập
        ↓
    A cập nhật sản phẩm, thêm phiên bản mới, sửa ràng buộc
        ↓
    → B THẤY NGAY thay đổi đó
    → không cần đồng bộ thủ công

⚠ Ba cách chia sẻ portfolio — biết cả ba:

1. Chia sẻ cho MỘT tài khoản cụ thể
       aws servicecatalog create-portfolio-share \
         --portfolio-id port-xxxx --account-id 444455556666

2. Chia sẻ cho cả ORGANIZATION hoặc một OU
       --organization-node Type=ORGANIZATIONAL_UNIT,Value=ou-xxxx

3. Chia sẻ qua AWS RAM
       → quản lý tập trung cùng các tài nguyên chia sẻ khác

⚠ Và một chi tiết vận hành quan trọng:

Bên NHẬN phải chấp nhận (accept) portfolio share
        ↓
    aws servicecatalog accept-portfolio-share --portfolio-id ...
        ↓
    Rồi gán quyền cho người dùng của mình:
        associate-principal-with-portfolio
        ↓
    → chia sẻ không tự động cấp quyền cho end user

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

• B (dùng StackSets để triển khai danh mục sang tài khoản khác) — đây là phương án gần nhất và về kỹ thuật thì làm được. Nhưng StackSets tạo ra các bản SAO ĐỘC LẬP ở mỗi tài khoản; khi bạn cập nhật danh mục gốc, các bản sao không tự đổi theo — bạn phải triển khai lại StackSet. Trái ràng buộc "luôn đồng bộ".

• C (triển khai một bản sao vào mỗi tài khoản nhận) — cùng vấn đề với B, và còn thủ công hơn: mỗi lần đổi là phải làm lại ở từng tài khoản.

• D (không chia sẻ được, chỉ triển khai lại hoặc tạo lại) — sai; account-to-account sharing là tính năng cốt lõi của Service Catalog, sinh ra đúng cho mô hình nhiều tài khoản.

Ghi nhớ

⚠ AWS Service Catalog — các khái niệm phải thuộc: | Khái niệm | Nội dung | |---|---| | Product | một CloudFormation template đã được duyệt, có phiên bản | | Portfolio | tập hợp product + quyền + ràng buộc | | Constraint | giới hạn cách triển khai (loại instance, tag bắt buộc, launch role) | | Provisioned product | một stack đã được người dùng tạo ra từ product | | Launch constraint | IAM role mà Service Catalog dùng để tạo tài nguyên |

Từ khoá nhận diện:

"chia sẻ danh mục, luôn đồng bộ" → account-to-account sharing "triển khai stack sang nhiều tài khoản" → StackSets (bản sao độc lập) "chia sẻ tài nguyên giữa các tài khoản nói chung" → AWS RAM "người dùng tự cấp phát mà không cần quyền IAM trực tiếp" → Service Catalog + launch constraint "dựng sẵn môi trường nhiều tài khoản theo chuẩn" → Control Tower

⚠ Vì sao Service Catalog đáng dùng — cơ chế launch constraint:

Người dùng KHÔNG cần quyền tạo EC2, RDS, VPC
        ↓
    Họ chỉ cần quyền "launch product X từ portfolio Y"
        ↓
    Service Catalog dùng LAUNCH ROLE để tạo tài nguyên
        ↓
    → tài nguyên được tạo theo đúng chuẩn công ty
    → người dùng không thể lệch khỏi template
    → quyền IAM của họ vẫn rất hẹp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Portfolio đã chia sẻ cho ai | list-portfolio-access | | Bên nhận đã chấp nhận chưa | list-accepted-portfolio-shares ở tài khoản nhận | | Người dùng có thấy product không | search-products bằng chính danh tính của họ |

Và một lời khuyên về mô hình quản trị: hãy tập trung toàn bộ portfolio ở một tài khoản duy nhất và chia sẻ ra, thay vì để mỗi đội tự dựng danh mục riêng. Toàn bộ giá trị của Service Catalog nằm ở chỗ "chỉ có một định nghĩa đúng cho mỗi loại hạ tầng" — và ngay khi có hai bản sao độc lập của cùng một portfolio, bạn đã mất đúng cái tính chất khiến công cụ này đáng dùng.

Đáp án

A — AWS Systems Manager.

Vì sao đúng

Systems Manager không chỉ quản lý EC2 — nó quản lý được mọi máy có cài SSM Agent, kể cả máy tại chỗ.

⚠ Điểm mấu chốt — Hybrid Activation đưa máy ngoài AWS vào cùng một hệ thống quản lý:

Tạo một hybrid activation ở Systems Manager
        ↓
    Nhận activation code và activation ID
        ↓
    Cài SSM Agent lên máy tại chỗ, đăng ký bằng mã đó
        ↓
    → máy xuất hiện trong Fleet Manager với id dạng "mi-"
      (thay vì "i-" như EC2)
        ↓
    → dùng được Run Command, Patch Manager, Inventory,
      Session Manager, State Manager — Y HỆT máy EC2

⚠ Và chi tiết đặc thù của đề — Raspbian:

SSM Agent hỗ trợ RẤT NHIỀU nền tảng:
        Amazon Linux, Ubuntu, Debian, RHEL, CentOS, SUSE
        Windows Server
        macOS
        RASPBIAN (Raspberry Pi OS)          ← đề nhắc đích danh
        ↓
    → đây chính là lý do câu hỏi nêu Raspbian:
      để khẳng định SSM phủ được cả thiết bị nhỏ, thiết bị biên

⚠ Ba điều kiện để một máy tại chỗ được quản lý:

1. Cài SSM Agent
2. Đăng ký bằng hybrid activation (nhận vai trò IAM tương ứng)
3. Có đường mạng tới endpoint SSM
       ssm.<region>.amazonaws.com
       ssmmessages.<region>.amazonaws.com
       ec2messages.<region>.amazonaws.com

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

• D (AWS Control Tower) — đây là phương án gần nhất theo nghĩa "quản lý tập trung", nhưng nó quản lý NHIỀU TÀI KHOẢN AWS (landing zone, guardrail, OU), không quản lý máy chủ nào.

• C (Amazon Inspector) — quét lỗ hổng bảo mật cho EC2, container và Lambda. Nó dùng SSM Agent để lấy kiểm kê, nhưng bản thân nó không phải công cụ quản lý cấu hình.

• B (AWS Service Catalog) — quản lý danh mục sản phẩm hạ tầng để người dùng tự cấp phát. Không quản lý máy chủ đang chạy.

Ghi nhớ

⚠ Các capability của Systems Manager — bảng phải thuộc: | Capability | Việc | |---|---| | Fleet Manager | xem và quản lý máy qua giao diện | | Session Manager | shell không cần SSH, không cần cổng 22 | | Run Command | chạy lệnh một lần trên nhiều máy | | Patch Manager | vá và báo cáo tuân thủ bản vá | | Inventory | kiểm kê phần mềm và cấu hình | | State Manager | giữ máy ở đúng trạng thái mong muốn | | Automation | runbook nhiều bước | | Parameter Store | lưu cấu hình và bí mật | | Compliance | tổng hợp tuân thủ |

Từ khoá nhận diện:

"quản lý cả máy tại chỗ lẫn EC2" → Systems Manager Hybrid Activation "Raspbian, thiết bị biên" → SSM Agent hỗ trợ "quản lý nhiều TÀI KHOẢN AWS" → Control Tower / Organizations "quét lỗ hổng" → Inspector "danh mục hạ tầng cho người dùng tự cấp phát" → Service Catalog

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy tại chỗ đã đăng ký chưa | describe-instance-information — tìm id mi- | | Agent có kết nối được không | log agent tại /var/log/amazon/ssm/ | | Máy nào bị bỏ sót | đối chiếu số node trong Fleet Manager với số máy thật |

Và một điểm đáng chú ý về chi phí mà nhiều đội bỏ qua khi mở rộng sang môi trường lai: node lai được tính phí ở advanced tier, và ngưỡng chuyển tier là theo số lượng node. Với một dự án IoT hay thiết bị biên có hàng nghìn Raspberry Pi, hãy tính con số này từ đầu — nó không lớn tính trên mỗi máy, nhưng nhân với số lượng thì có thể đổi hẳn bài toán kinh tế của cả dự án.

Đáp án

C — Tính TỔNG (sum) của chỉ số ClientConnections để biết số instance đang kết nối.

Vì sao đúng

EFS có một chỉ số dành riêng cho việc đếm kết nối, và tên của nó là ClientConnections.

⚠ Điểm mấu chốt — chỉ số này đếm số kết nối tới file system:

ClientConnections
        ↓
    Số kết nối đang hoạt động tới file system
        ↓
    Thống kê nên dùng: SUM
        ↓
    → cộng lại được tổng số kết nối trong khoảng thời gian

aws cloudwatch get-metric-statistics \
  --namespace AWS/EFS --metric-name ClientConnections \
  --dimensions Name=FileSystemId,Value=fs-xxxxxxxx \
  --statistics Sum --period 3600 \
  --start-time 2026-09-01T00:00:00Z --end-time 2026-09-02T00:00:00Z

⚠ Nhưng có một sắc thái quan trọng phải hiểu:

ClientConnections đếm SỐ KẾT NỐI, không phải SỐ MÁY
        ↓
    Một EC2 instance mount file system
        ↓
    → thường tạo MỘT kết nối
    → nhưng có thể nhiều hơn nếu mount nhiều lần,
      hoặc dùng nhiều access point
        ↓
    → dùng nó làm ƯỚC LƯỢNG số máy, không phải con số tuyệt đối

⚠ Muốn biết chính xác máy nào đang mount:

CloudWatch chỉ cho con số tổng
        ↓
    Muốn danh sách cụ thể:
        - describe-mount-targets rồi xem ENI
        - hoặc CloudTrail data event của EFS
        - hoặc chạy "netstat" trên mount target

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

• B (tính tổng chỉ số InstanceConnections) — đây là phương án gần nhất và cái tên nghe đúng hơn cả tên thật, nên rất dễ chọn. Nhưng InstanceConnections KHÔNG TỒN TẠI trong namespace AWS/EFS. Đây là bẫy tên gọi kinh điển.

• A (tính trung bình BurstCreditBalance) — đây là chỉ số tín dụng burst của throughput, cho biết file system còn bao nhiêu khả năng bùng phát. Hoàn toàn không liên quan tới số kết nối.

• D (tính trung bình TotalIOBytes để biết số kết nối hoạt động) — TotalIOBytes là khối lượng dữ liệu đọc ghi, không phải số kết nối. Một máy có thể tạo ra rất nhiều byte, và trăm máy có thể gần như không tạo ra byte nào.

Ghi nhớ

⚠ Các chỉ số quan trọng của EFS — bảng phải thuộc: | Chỉ số | Ý nghĩa | |---|---| | ClientConnections | số kết nối tới file system | | BurstCreditBalance | tín dụng burst còn lại — tụt về 0 là hiệu năng sập | | TotalIOBytes | tổng byte đọc + ghi | | DataReadIOBytes / DataWriteIOBytes | tách theo chiều | | PercentIOLimit | đang dùng bao nhiêu % giới hạn I/O (chế độ General Purpose) | | PermittedThroughput | throughput hiện được phép | | MeteredIOBytes | byte tính tiền |

Từ khoá nhận diện:

"bao nhiêu máy đang kết nối EFS" → ClientConnections "InstanceConnections" → KHÔNG TỒN TẠI "EFS đột nhiên chậm" → BurstCreditBalance cạn "chạm giới hạn số thao tác" → PercentIOLimit gần 100% "RAM, đĩa của EC2" → CloudWatch agent, không liên quan EFS

⚠ Hai chế độ hiệu năng của EFS — chọn sai là không sửa được: | Chế độ | Đặc điểm | |---|---| | General Purpose | độ trễ thấp nhất, giới hạn 7.000 thao tác/giây — mặc định | | Max I/O | độ trễ cao hơn, nhưng số thao tác gần như không giới hạn | | Lưu ý | chọn lúc tạo, KHÔNG đổi được sau | | Dấu hiệu cần Max I/O | PercentIOLimit thường xuyên gần 100% |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu kết nối | chỉ số ClientConnections | | Máy nào đang mount | describe-mount-targets rồi rà ENI, hoặc kiểm tra từ máy | | Hiệu năng có bị giới hạn không | BurstCreditBalance và PercentIOLimit |

Và một cảnh báo đáng đặt lên hàng đầu khi vận hành EFS: hãy đặt alarm trên BurstCreditBalance. Đây là sự cố tự che giấu điển hình — file system chạy nhanh suốt nhiều tuần rồi đột nhiên chậm đi hàng chục lần, trong khi mọi chỉ số khác đều bình thường và không có lỗi nào ở đâu. Nguyên nhân là tín dụng burst đã cạn, và cách chữa (tăng dung lượng hoặc chuyển sang chế độ Elastic) thì mất thời gian đúng vào lúc bạn cần nó nhất.

Đáp án

A — Amazon FSx for Windows File Server.

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều chỉ thẳng về một dịch vụ duy nhất:

⚠ Điểm mấu chốt — FSx for Windows là Windows File Server thật, do AWS vận hành:

Bên dưới là Windows Server thật
        ↓
    → NTFS thật, với ACL của Windows
    → SMB thật, máy Windows mount như ổ mạng bình thường
    → tham gia DOMAIN Active Directory
        ↓
    → người dùng đăng nhập bằng tài khoản AD
    → quyền thư mục theo đúng mô hình Windows
        ↓
    Còn AWS lo: vá, sao lưu, sẵn sàng cao, mở rộng

⚠ Và những tính năng Windows mà chỉ FSx mới có:

DFS Namespaces        → gộp nhiều share thành một cây thư mục
Shadow Copies         → người dùng TỰ khôi phục phiên bản cũ của tệp
Data Deduplication    → khử trùng lặp, tiết kiệm rất nhiều dung lượng
User quotas           → hạn ngạch theo người dùng
Multi-AZ              → tự failover, có tên DNS không đổi

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

• B (Amazon EFS) — đây là phương án gần nhất vì nó cũng là hệ thống tệp chia sẻ có quản lý. Nhưng EFS dùng NFS, không phải SMB; nó không có NTFS, không tích hợp Active Directory để xác thực người dùng Windows. EFS là lựa chọn cho Linux.

• C (Amazon FSx for Lustre) — cùng họ FSx nhưng cho HPC và tính toán hiệu năng cao, tích hợp chặt với S3. Không phải SMB, không phải Windows.

• D (AWS Storage Gateway) — là cầu nối giữa TẠI CHỖ và AWS. Đề nói ứng dụng đã chạy trên AWS Cloud, nên không cần cầu nối nào; và File Gateway lưu dữ liệu dạng đối tượng S3, không phải NTFS.

Ghi nhớ

⚠ Các dịch vụ hệ thống tệp của AWS — bảng phải thuộc: | Dịch vụ | Giao thức | Dùng cho | |---|---|---| | EFS | NFS v4.1 | Linux, chia sẻ cho nhiều EC2 | | FSx for Windows | SMB | Windows, NTFS, Active Directory | | FSx for Lustre | Lustre | HPC, ML, tích hợp S3 | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | đa giao thức, tính năng NetApp | | FSx for OpenZFS | NFS | ZFS, snapshot tức thì |

Từ khoá nhận diện:

"SMB, NTFS, Active Directory" → FSx for Windows "NFS, Linux" → EFS "HPC, huấn luyện ML, tích hợp S3" → FSx for Lustre "cần cả NFS lẫn SMB" → FSx for NetApp ONTAP "chia sẻ tệp cho máy TẠI CHỖ" → Storage Gateway File Gateway "lưu trữ đối tượng" → S3

Ba việc kiểm chứng: | Việc | Cách | |---|---| | File system đã sẵn sàng chưa | describe-file-systems, trạng thái AVAILABLE | | Mount được không | từ máy Windows: net use Z: \\<dns-name>\share | | AD đã nối chưa | xem WindowsConfiguration.ActiveDirectoryId |

Và một tính năng của FSx for Windows rất đáng bật ngay từ đầu vì nó giảm hẳn khối lượng công việc cho đội hỗ trợ: Shadow Copies. Nó cho phép người dùng tự khôi phục phiên bản cũ của tệp bằng cách chuột phải → "Previous Versions" — đúng thao tác họ đã quen trên Windows tại chỗ — thay vì phải mở ticket mỗi lần ai đó ghi đè nhầm một tài liệu.