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

Đáp án

D — Nếu bạn cố xoá một stack đang bật termination protection thì việc xoá thất bại, và stack — kể cả trạng thái của nó — giữ nguyên không đổi.

Vì sao đúng

Triệu chứng đề mô tả rất đặc thù: không có lỗi, không có thông báo thành công, và stack vẫn còn nguyên.

⚠ Điểm mấu chốt — termination protection chặn từ trước khi có gì xảy ra:

Gọi DeleteStack trên một stack có termination protection
        ↓
    CloudFormation từ chối NGAY, trước khi bắt đầu xoá gì
        ↓
    → KHÔNG có sự kiện DELETE_IN_PROGRESS
    → KHÔNG có DELETE_FAILED
    → trạng thái stack GIỮ NGUYÊN như cũ
        ↓
    → nhìn bên ngoài thì như "chẳng có gì xảy ra"

⚠ Cách kiểm tra và xử lý:

# Xem có bật bảo vệ không
aws cloudformation describe-stacks --stack-name <ten> \
  --query 'Stacks[0].EnableTerminationProtection'

# Tắt bảo vệ rồi mới xoá được
aws cloudformation update-termination-protection \
  --stack-name <ten> --no-enable-termination-protection

aws cloudformation delete-stack --stack-name <ten>

⚠ Và phân biệt với các kiểu thất bại KHÁC — chúng đều có dấu hiệu rõ ràng:

Thiếu quyền IAM
        ↓
    → AccessDenied, thông báo lỗi rõ ràng

Bucket S3 chưa rỗng
        ↓
    → stack chuyển sang DELETE_FAILED
    → sự kiện nêu đích danh tài nguyên gây lỗi

Tài nguyên bị stack khác import (export đang dùng)
        ↓
    → lỗi nêu tên export cụ thể
        ↓
    → cả ba đều CÓ tín hiệu, khác hẳn mô tả của đề

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

• B (một số tài nguyên phải rỗng mới xoá được, và stack thất bại mà không báo lỗi) — đây là phương án gần nhất và vế đầu hoàn toàn đúng: bucket S3 chưa rỗng thật sự chặn việc xoá. Nhưng khi đó stack chuyển sang DELETE_FAILED với sự kiện nêu rõ tài nguyên nào — có lỗi hẳn hoi, trái với mô tả "không có thông báo nào".

• C (phải xoá tài nguyên phụ thuộc trước, nếu không stack thất bại lặng lẽ) — sai; CloudFormation TỰ tính thứ tự phụ thuộc và xoá theo thứ tự ngược lại. Bạn không phải tự sắp xếp.

• A (người dùng thiếu quyền) — thiếu quyền cho AccessDenied rõ ràng, không im lặng.

Ghi nhớ

⚠ Các lý do khiến xoá stack thất bại — bảng phải thuộc, phân biệt theo TÍN HIỆU: | Lý do | Dấu hiệu | |---|---| | Termination protection | KHÔNG có sự kiện nào, trạng thái không đổi | | Bucket S3 chưa rỗng | DELETE_FAILED, nêu tên bucket | | ENI còn gắn, ECR còn image | DELETE_FAILED, nêu tên tài nguyên | | Export đang bị stack khác import | lỗi nêu tên export | | Thiếu quyền IAM | AccessDenied | | DeletionPolicy: Retain | tài nguyên giữ lại, nhưng stack vẫn xoá thành công |

Từ khoá nhận diện:

"xoá stack không báo gì, stack vẫn còn" → termination protection "DELETE_FAILED nêu tên bucket" → bucket chưa rỗng "không xoá được vì export" → list-imports tìm stack đang dùng "stack kẹt ở DELETE_FAILED" → delete-stack --retain-resources để bỏ qua tài nguyên kẹt "UPDATE_ROLLBACK_FAILED" → continue-update-rollback

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bật bảo vệ không | describe-stacks, xem EnableTerminationProtection | | Vì sao thất bại | tab Events của stack — dòng DELETE_FAILED đầu tiên | | Ai đã thử xoá | CloudTrail sự kiện DeleteStack |

Và một lời khuyên nên áp dụng ngay hôm nay: hãy bật termination protection cho mọi stack sản xuất, và đưa nó vào quy trình chuẩn khi tạo stack mới. Chính cái "im lặng" gây bối rối trong câu hỏi này là bằng chứng cho thấy cơ chế đang làm đúng việc của nó — nó không cho phép một lệnh xoá nhầm đi được thêm bất kỳ bước nào, kể cả một sự kiện thất bại.

Đáp án

C — Cấu hình CloudFront BẮT BUỘC người xem dùng HTTPS để yêu cầu đối tượng. Tuy nhiên, giữa CloudFront và S3 thì vẫn dùng HTTP để giao tiếp.

Vì sao đúng

Chi tiết quyết định lại nằm ở một cụm từ trong đề: bucket được cấu hình làm website endpoint.

⚠ Điểm mấu chốt — S3 website endpoint KHÔNG hỗ trợ HTTPS:

REST endpoint
    bucket.s3.ap-southeast-1.amazonaws.com
        ↓
    → hỗ trợ HTTP và HTTPS
    → CloudFront coi là "S3 origin", dùng được OAC

WEBSITE endpoint
    bucket.s3-website-ap-southeast-1.amazonaws.com
        ↓
    → CHỈ HTTP, KHÔNG có HTTPS
    → CloudFront coi là "CUSTOM origin"
        ↓
    → CloudFront BUỘC PHẢI nói HTTP với origin này

⚠ Vậy phần nào được mã hoá, phần nào không:

Người xem ──── HTTPS ────► CloudFront ──── HTTP ────► S3 website endpoint
   (mã hoá, qua internet công cộng)      (không mã hoá,
                                          trong mạng AWS)
        ↓
    → chặng nguy hiểm nhất (internet) ĐÃ được mã hoá
    → chặng còn lại nằm trong mạng riêng của AWS

Cấu hình CloudFront tương ứng:

Viewer Protocol Policy   : Redirect HTTP to HTTPS  (hoặc HTTPS Only)
Origin Protocol Policy   : HTTP Only  ← BUỘC PHẢI vậy với website endpoint

⚠ Và nếu yêu cầu tuân thủ đòi mã hoá TOÀN TUYẾN:

Phải BỎ website endpoint, chuyển sang REST endpoint
        ↓
    → dùng OAC, đặt Origin Protocol Policy là HTTPS Only
    → mã hoá cả hai chặng
        ↓
    Đánh đổi: mất tài liệu chỉ mục và quy tắc chuyển hướng
        ↓
    → thay bằng CloudFront Functions hoặc Lambda@Edge,
      và cấu hình Default Root Object

Xem thêm câu #11577: cùng sự thật kỹ thuật này ở góc khác — vì website endpoint không hỗ trợ OAI/OAC, nên muốn chỉ CloudFront vào được S3 thì phải dùng custom header thay vì OAC.

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

• B (cấu hình S3 chỉ hỗ trợ HTTPS để buộc CloudFront dùng HTTPS) — đây là phương án gần nhất và nghe rất hợp lý. Nhưng với website endpoint thì không có HTTPS để mà bắt buộc; đặt Origin Protocol Policy là HTTPS sẽ khiến CloudFront không kết nối được với origin.

• D (CloudFront luôn chuyển tiếp tới origin bằng đúng giao thức mà người xem đã dùng) — sai: Origin Protocol Policy là một cấu hình ĐỘC LẬP. Có tuỳ chọn "Match Viewer", nhưng nó không phải mặc định và không dùng được với website endpoint.

• A (giao tiếp giữa CloudFront và S3 luôn là HTTP vì mạng nội bộ AWS vốn an toàn) — kết luận đúng một cách tình cờ với website endpoint, nhưng lý do thì sai: với REST endpoint thì CloudFront hoàn toàn dùng HTTPS được, và "mạng nội bộ vốn an toàn" không phải lập luận được các chuẩn tuân thủ chấp nhận.

Ghi nhớ

⚠ Hai endpoint của S3 — bảng phải thuộc: | | REST endpoint | Website endpoint | |---|---|---| | Dạng | bucket.s3.<region>.amazonaws.com | bucket.s3-website-<region>.amazonaws.com | | HTTPS | CÓ | KHÔNG | | OAC / OAI | dùng được | KHÔNG | | Tài liệu chỉ mục, chuyển hướng | không | CÓ | | CloudFront coi là | S3 origin | custom origin |

Từ khoá nhận diện:

"website endpoint + HTTPS" → KHÔNG CÓ, buộc dùng HTTP tới origin "website endpoint + OAC" → KHÔNG DÙNG ĐƯỢC, phải custom header "cần mã hoá toàn tuyến" → bỏ website endpoint, dùng REST endpoint + OAC "cần tài liệu chỉ mục cho mỗi thư mục" → website endpoint, hoặc CloudFront Function "ép người xem dùng HTTPS" → Viewer Protocol Policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Origin đang dùng giao thức gì | cấu hình distribution, mục Origin Protocol Policy | | Người xem có bị ép HTTPS không | curl -I http://tenmien.com — phải nhận 301 | | Origin có phải website endpoint không | nhìn tên miền — có chứa s3-website không |

Và một lời khuyên khi yêu cầu tuân thủ nói "mã hoá mọi kênh truyền": hãy làm rõ với bộ phận tuân thủ xem chặng CloudFront-tới-origin trong mạng AWS có nằm trong phạm vi hay không. Nếu có, thì việc dùng website endpoint là bất khả thi và bạn phải chuyển sang REST endpoint cộng với CloudFront Function — một thay đổi kiến trúc thật sự, nên biết sớm bao giờ cũng tốt hơn phát hiện ra trong buổi kiểm toán.

Đáp án

D — CloudTrail logs.

Vì sao đúng

Đề hỏi về các lời gọi API tới Elastic Load Balancer — và đó chính xác là thứ CloudTrail ghi lại.

⚠ Điểm mấu chốt — phân biệt LỜI GỌI API với LƯU LƯỢNG đi qua load balancer:

Lời gọi API (CloudTrail ghi)
        ↓
    CreateLoadBalancer, ModifyListener, RegisterTargets,
    DeleteRule, SetSecurityGroups...
        ↓
    → thao tác QUẢN TRỊ lên chính load balancer
        ↓
Lưu lượng HTTP (access log ghi)
        ↓
    GET /san-pham/123 từ IP 203.0.113.45
        ↓
    → request của NGƯỜI DÙNG đi QUA load balancer

Đề hỏi vế thứ nhất.

⚠ Mỗi bản ghi CloudTrail chứa gì:

userIdentity      → AI gọi
eventName         → ModifyTargetGroupAttributes
eventTime         → lúc nào
requestParameters → tham số đã truyền
responseElements  → kết quả trả về
sourceIPAddress   → gọi từ đâu
        ↓
    → đủ để dựng báo cáo kiểm toán "ai đã đổi gì trên ELB"

⚠ Và tin tốt về chi phí:

Thao tác quản trị ELB là MANAGEMENT EVENT
        ↓
    → MIỄN PHÍ trong bản sao đầu tiên của CloudTrail
        ↓
    Nhưng Event history trên console chỉ giữ 90 NGÀY
        ↓
    → muốn báo cáo dài hơn phải TẠO TRAIL đổ vào S3

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

• C (Load Balancer access logs) — đây là phương án gần nhất và là nguồn dữ liệu rất giá trị, nhưng nó ghi request HTTP của người dùng cuối, không ghi lời gọi API quản trị. Hai loại dữ liệu hoàn toàn khác nhau.

• A (CloudWatch metrics) — cho số liệu tổng hợp về hiệu năng: số request, độ trễ, số lỗi. Không có thông tin về ai gọi API nào.

• B (Load Balancer request tracing) — gắn một id duy nhất vào mỗi request (header X-Amzn-Trace-Id) để lần theo nó qua các dịch vụ. Lại là chuyện của lưu lượng, không phải của API quản trị.

Ghi nhớ

⚠ Bốn nguồn dữ liệu quanh một load balancer — bảng phải thuộc: | Nguồn | Ghi lại | Câu hỏi trả lời được | |---|---|---| | CloudTrail | lời gọi API quản trị | "AI đã đổi cấu hình gì" | | Access log | từng request HTTP | "IP nào, đường dẫn nào, độ trễ bao nhiêu" | | CloudWatch metrics | số liệu tổng hợp | "hệ thống đang chạy ra sao" | | Request tracing | id lần theo request | "request này đi qua những đâu" |

Từ khoá nhận diện:

"lời gọi API", "ai đã thay đổi" → CloudTrail "IP client, đường dẫn, độ trễ từng request" → access log "cảnh báo khi lỗi tăng" → CloudWatch metrics "lần theo một request qua nhiều dịch vụ" → X-Ray / request tracing "cấu hình có đúng chuẩn không" → AWS Config

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trail có đang ghi không | get-trail-status, xem IsLogging | | Sự kiện có trong 90 ngày không | tìm nhanh trên Event history của console | | Log có toàn vẹn không | validate-logs với tệp digest |

Và một cảnh báo bảo mật đáng dựng ngay: hãy tạo cảnh báo EventBridge cho sự kiện SetSecurityGroups và ModifyLoadBalancerAttributes. Đây là hai thao tác có thể mở toang một load balancer ra internet hoặc tắt access log — và cả hai đều là những việc kẻ tấn công làm sớm sau khi chiếm được quyền, chính xác vì chúng không gây ra bất kỳ triệu chứng nào mà người vận hành nhìn thấy.

Đáp án

D, E — hai điều đúng khi xoá một đối tượng trong bucket đã bật versioning:

• D — Một delete marker được đặt lên đối tượng, nhưng đối tượng THẬT thì KHÔNG bị xoá.
• E — Request GET KHÔNG lấy được delete marker.

Vì sao đúng

Delete marker là một phiên bản đặc biệt, rỗng, được đặt lên trên cùng để "che" đối tượng đi.

⚠ Điểm mấu chốt — xoá là THÊM một phiên bản, không phải bỏ đi phiên bản nào:

tai-lieu.pdf
   ├── v1 (dữ liệu thật)
   └── v2 (dữ liệu thật)  ← phiên bản hiện tại

Gọi DeleteObject (không nêu versionId)
        ↓
tai-lieu.pdf
   ├── v1 (dữ liệu thật)
   ├── v2 (dữ liệu thật)
   └── v3 = DELETE MARKER  ← phiên bản hiện tại mới
        ↓
    → v1 và v2 VẪN CÒN NGUYÊN  ← điều D
    → GET không kèm versionId → trả 404

⚠ Điều E — vì sao GET không lấy được delete marker:

GET tai-lieu.pdf
        ↓
    S3 thấy phiên bản hiện tại là delete marker
        ↓
    → trả về 404 Not Found
    → kèm header x-amz-delete-marker: true
        ↓
GET tai-lieu.pdf?versionId=<id-cua-delete-marker>
        ↓
    → trả về 405 Method Not Allowed
        ↓
    → delete marker KHÔNG CÓ DỮ LIỆU để trả về

⚠ Khôi phục lại — chỉ cần xoá chính delete marker:

aws s3api delete-object --bucket kho \
  --key tai-lieu.pdf --version-id <id-cua-delete-marker>
        ↓
    → delete marker biến mất
    → v2 trở lại làm phiên bản hiện tại
    → tệp hiện lại nguyên vẹn

Xem thêm câu #11611: cùng cơ chế này ở góc hậu quả — bucket trông rỗng trên console nhưng không xoá được, vì delete marker và các phiên bản cũ vẫn còn.

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

• B (delete marker có key, version ID và ACL) — đây là phương án gần nhất và hai vế đầu HOÀN TOÀN ĐÚNG: delete marker thật sự có key và version ID như mọi phiên bản khác. Nhưng nó KHÔNG có ACL — đây chính là chi tiết mà câu hỏi kiểm tra. Tài liệu AWS nêu rõ: delete marker không có dữ liệu, không có ACL, và chỉ chủ bucket mới xoá được nó.

• C (request GET lấy được delete marker) — ngược với đáp án E.

• A (delete marker mang cùng dữ liệu với đối tượng thật) — sai; delete marker hoàn toàn RỖNG, nó chỉ là một dấu hiệu. Đó cũng là lý do nó gần như không tốn dung lượng lưu trữ.

Ghi nhớ

⚠ Delete marker CÓ gì và KHÔNG CÓ gì — bảng phải thuộc: | Thuộc tính | Delete marker | |---|---| | Key | CÓ (cùng key với đối tượng) | | Version ID | CÓ | | Dữ liệu | KHÔNG | | ACL | KHÔNG | | Xoá được bởi | chỉ chủ bucket | | Dung lượng chiếm | gần như không |

Từ khoá nhận diện:

"xoá đối tượng trong bucket có versioning" → tạo delete marker, dữ liệu còn nguyên "GET đối tượng đã xoá" → 404 kèm x-amz-delete-marker: true "GET chính delete marker" → 405 Method Not Allowed "khôi phục tệp đã xoá" → xoá delete marker "xoá VĨNH VIỄN" → DeleteObject KÈM versionId

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối tượng thật sự còn không | list-object-versions, không phải ls | | Có bao nhiêu delete marker | cùng lệnh, xem mảng DeleteMarkers | | Dung lượng phiên bản cũ chiếm bao nhiêu | S3 Storage Lens |

Và một lời khuyên áp dụng ngay khi bật versioning: hãy thêm lifecycle rule dọn phiên bản cũ và delete marker mồ côi ngay trong cùng thao tác. Versioning là lưới an toàn tuyệt vời cho đúng tình huống của đề — đội phát triển xoá nhầm tệp — nhưng nếu không có lifecycle đi kèm, nó âm thầm biến thành nguồn chi phí S3 lớn nhất mà không ai nhìn thấy, vì những phiên bản ấy không xuất hiện trong bất kỳ danh sách tệp thông thường nào.

Đáp án

D — Dùng QUEUE NAME (tên hàng đợi) để lấy dữ liệu cần thiết từ CloudWatch metrics.

Vì sao đúng

Trong CloudWatch, mỗi chỉ số được xác định bằng namespace + tên chỉ số + các dimension, và với SQS thì dimension đó chỉ có một.

⚠ Điểm mấu chốt — SQS chỉ có ĐÚNG MỘT dimension:

Namespace : AWS/SQS
Dimension : QueueName   ← duy nhất
        ↓
    Không có QueueId
    Không có khoá tổ hợp
    Không có cặp name/value tuỳ ý

aws cloudwatch get-metric-statistics \
  --namespace AWS/SQS \
  --metric-name ApproximateNumberOfMessagesVisible \
  --dimensions Name=QueueName,Value=hang-cho-xu-ly \
  --statistic Average --period 300 \
  --start-time ... --end-time ...

⚠ Và chỉ số nào nên dùng để co giãn — đây mới là phần quan trọng thực tế:

ApproximateNumberOfMessagesVisible
        ↓
    Số tin nhắn đang CHỜ được xử lý
        ↓
    → chỉ số dẫn dắt tốt nhất cho ASG đọc từ SQS

⚠ Nhưng có một bẫy khi co giãn theo chỉ số này:

Dùng thẳng số tin nhắn làm ngưỡng
        ↓
    → ngưỡng "1000 tin nhắn" đúng với 5 máy
      nhưng vô nghĩa với 50 máy
        ↓
Cách đúng: dùng BACKLOG PER INSTANCE
        ↓
    backlog mỗi máy = ApproximateNumberOfMessagesVisible
                      ÷ số instance đang chạy
        ↓
    Tính bằng Metric Math, rồi Target Tracking giữ nó ở
    một giá trị mục tiêu
        ↓
    → đây là cách AWS khuyến nghị chính thức

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

• C (dùng Queue ID) — đây là phương án gần nhất vì nghe rất tự nhiên: tài nguyên thì phải có id. Nhưng SQS không có khái niệm "Queue ID" trong CloudWatch; định danh của hàng đợi trong chỉ số là tên của nó.

• A (khoá tổ hợp Queue Name – Queue ID) — bịa: chỉ có một dimension duy nhất.

• B (cặp key-value name:<queue name> và value:<value>) — mô tả sai cấu trúc: dimension của CloudWatch là cặp Name=QueueName, Value=<tên hàng đợi>, không phải cặp tuỳ ý như mô tả.

Ghi nhớ

⚠ Chỉ số SQS quan trọng — bảng phải thuộc: | Chỉ số | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | tin nhắn đang CHỜ — dùng để co giãn | | ApproximateNumberOfMessagesNotVisible | đang được xử lý (trong visibility timeout) | | ApproximateAgeOfOldestMessage | tin nhắn cũ nhất chờ bao lâu — dấu hiệu tụt hậu | | NumberOfMessagesSent / Received / Deleted | thông lượng | | NumberOfEmptyReceives | poll rỗng — nhiều là đang lãng phí lời gọi |

Từ khoá nhận diện:

"dimension của SQS trong CloudWatch" → QueueName, duy nhất "co giãn theo hàng đợi" → backlog per instance (Metric Math) "tin nhắn chờ quá lâu" → ApproximateAgeOfOldestMessage "nhiều poll rỗng" → bật long polling (ReceiveMessageWaitTimeSeconds) "tin nhắn xử lý hỏng nhiều lần" → Dead Letter Queue

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số có đúng dimension không | list-metrics --namespace AWS/SQS | | Hàng đợi có đang tụt hậu không | ApproximateAgeOfOldestMessage tăng dần | | ASG có co giãn không | Activity history của ASG |

Và một lời khuyên rất đáng giá về việc chọn chỉ số cảnh báo: hãy đặt alarm trên ApproximateAgeOfOldestMessage, không chỉ trên số lượng tin nhắn. Số tin nhắn chờ có thể lớn mà vẫn bình thường nếu hệ thống xử lý nhanh; nhưng một tin nhắn đã nằm chờ hai tiếng đồng hồ luôn có nghĩa là có thứ gì đó đang hỏng — và với message retention tối đa 14 ngày, đó cũng là đồng hồ đếm ngược tới lúc dữ liệu bị mất vĩnh viễn.

Đáp án

A — Cấu hình Amazon EFS Access Points.

Vì sao đúng

Đề nêu ba yêu cầu, và EFS Access Point sinh ra để giải đúng bộ ba này:

⚠ Điểm mấu chốt — access point "nhốt" ứng dụng vào một thư mục con:

Hệ thống tệp EFS
   /khach-hang/kh-001/
   /khach-hang/kh-002/
        ↓
    Tạo access point cho từng khách hàng:
        Root directory: /khach-hang/kh-001
        POSIX user    : uid 1001, gid 1001
        ↓
    Container mount qua access point đó
        ↓
    → nó thấy thư mục kh-001 NHƯ LÀ GỐC "/"
    → KHÔNG có cách nào đi ra ngoài thư mục ấy

⚠ Và lớp thứ hai — chính sách IAM khoá theo access point:

{
  "Effect": "Allow",
  "Action": ["elasticfilesystem:ClientMount",
             "elasticfilesystem:ClientWrite"],
  "Resource": "arn:aws:elasticfilesystem:...:file-system/fs-xxxx",
  "Condition": {
    "StringEquals": {
      "elasticfilesystem:AccessPointArn":
        "arn:aws:elasticfilesystem:...:access-point/fsap-kh001"
    }
  }
}

Kết quả: role của khách hàng 001 chỉ mount được access point của khách hàng 001, và qua access point đó thì chỉ thấy đúng thư mục của họ.

⚠ Access point còn giải quyết một vấn đề thực tế khác:

Không có access point
        ↓
    Quyền truy cập phụ thuộc UID/GID của tiến trình trong container
        ↓
    → mỗi image một kiểu, rất khó quản
        ↓
Có access point
        ↓
    Access point ÁP ĐẶT POSIX user và group
        ↓
    → mọi thao tác qua nó đều mang đúng uid/gid đã khai
    → container chạy bằng user nào cũng không quan trọng nữa

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

• C (EFS mount target) — đây là phương án gần nhất và là thành phần bắt buộc phải có, nhưng vai trò của nó khác hẳn: mount target là điểm truy cập MẠNG — một ENI có IP riêng trong mỗi Availability Zone. Nó quyết định truy cập được từ đâu, không quyết định thấy thư mục nào và với quyền gì.

• B (EBS Multi-Attach) — cho phép gắn một volume vào tối đa 16 instance trong cùng AZ, nhưng đó là lưu trữ khối, và đòi hệ thống tệp hỗ trợ truy cập đồng thời (cluster file system). Nó không phải NFS và không có cơ chế phân quyền theo thư mục.

• D (VPC Gateway endpoint) — dành cho S3 và DynamoDB, hoàn toàn không liên quan tới EFS.

Ghi nhớ

⚠ Ba thành phần của EFS — bảng phải thuộc, chúng dễ bị lẫn: | Thành phần | Vai trò | |---|---| | File system | chính hệ thống tệp | | Mount target | điểm truy cập MẠNG — một ENI mỗi AZ, có Security Group | | Access point | điểm truy cập ỨNG DỤNG — thư mục gốc + POSIX user + quyền |

Từ khoá nhận diện:

"mỗi ứng dụng một thư mục riêng, phân quyền bằng IAM" → EFS access point "truy cập EFS từ subnet nào" → mount target "một volume nhiều instance, cùng AZ" → EBS Multi-Attach "chia sẻ tệp cho Windows" → FSx for Windows "chia sẻ tệp cho máy TẠI CHỖ" → Storage Gateway File Gateway

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Access point cấu hình gì | describe-access-points, xem RootDirectory và PosixUser | | Mount được không | thử mount -t efs -o tls,accesspoint=fsap-xxxx fs-xxxx:/ /mnt | | Vì sao bị từ chối | kiểm tra cả ba lớp: SG, file system policy, IAM |

Và một lời khuyên khi chạy container với EFS: hãy luôn mount qua access point, đừng mount thẳng hệ thống tệp. Mount thẳng nghĩa là mọi container đều thấy toàn bộ cây thư mục và quyền phụ thuộc vào uid/gid mà image tình cờ dùng — một cấu hình vừa khó kiểm toán vừa dễ rò rỉ dữ liệu giữa các khách hàng, đúng điều mà yêu cầu của đề muốn ngăn chặn.

Đáp án

C — Dùng AWS Key Management Service (SSE-KMS) để mã hoá đối tượng trong bucket S3.

Vì sao đúng

Đề nêu ba yêu cầu, và chỉ SSE-KMS đáp ứng cả ba cùng lúc:

⚠ Điểm mấu chốt — "vòng đời khoá" là thứ chỉ KMS mới có:

Với CMK, bạn làm được:
        - BẬT XOAY KHOÁ TỰ ĐỘNG (mỗi năm một lần)
        - VÔ HIỆU HOÁ khoá — "công tắc ngắt" cho toàn bộ dữ liệu
        - LÊN LỊCH XOÁ với 7–30 ngày chờ
        - KIỂM SOÁT ai dùng bằng key policy
        - TẠO ALIAS và quản lý phiên bản khoá
        ↓
    → đây chính là "lifecycle management" mà đề nói tới

⚠ Và kiểm toán — mỗi lần dùng khoá là một bản ghi CloudTrail:

{
  "eventSource": "kms.amazonaws.com",
  "eventName": "Decrypt",
  "userIdentity": { "arn": "arn:aws:sts::...:assumed-role/UngDung/i-xxx" },
  "requestParameters": {
    "encryptionContext": {
      "aws:s3:arn": "arn:aws:s3:::kho-du-lieu/bao-cao.pdf"
    }
  }
}

encryptionContext cho biết đối tượng nào đã được giải mã — chi tiết mà kiểm toán viên luôn hỏi tới.

⚠ Vì sao xoay khoá tự động của KMS không gây rắc rối:

Xoay khoá của CMK
        ↓
    KMS tạo key material MỚI, giữ lại material CŨ
        ↓
    Dữ liệu mới → mã hoá bằng material mới
    Dữ liệu cũ  → vẫn giải mã được bằng material cũ
        ↓
    → KHÔNG phải mã hoá lại gì cả
    → ARN và alias của khoá KHÔNG ĐỔI
        ↓
    → hoàn toàn trong suốt với ứng dụng

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

• D (SSE-S3) — đây là phương án gần nhất và cũng là "không cần viết mã". Nhưng AWS quản lý khoá hoàn toàn và ẩn khỏi bạn: không có khoá nào trong tài khoản để quản vòng đời, và không có nhật ký dùng khoá trong CloudTrail. Trượt hai trên ba yêu cầu.

• B (client-side encryption để kiểm soát hoàn toàn) — cho kiểm soát cao nhất nhưng cũng đòi công sức lớn nhất: tự mã hoá, tự lưu khoá, tự xoay khoá, tự kiểm toán. Trái thẳng ràng buộc "ít công sức nhất".

• A (SSE-C) — bạn phải gửi khoá theo từng request và tự lưu trữ khoá; mất khoá là mất dữ liệu vĩnh viễn. Cũng nhiều việc và nhiều rủi ro hơn hẳn.

Ghi nhớ

⚠ Bốn kiểu mã hoá S3 — bảng so sánh theo đúng ba tiêu chí của đề: | Kiểu | Quản vòng đời khoá | Kiểm toán khoá | Công sức | |---|---|---|---| | SSE-S3 | không | không | thấp nhất | | SSE-KMS | CÓ | CÓ | thấp | | SSE-C | bạn tự lo | không | cao | | Client-side | bạn tự lo | bạn tự lo | cao nhất |

Từ khoá nhận diện:

"xoay khoá, kiểm toán khoá, ít công sức" → SSE-KMS "chỉ cần mã hoá, không cần quản khoá" → SSE-S3 "khoá phải nằm ngoài AWS" → SSE-C hoặc client-side "AWS không được thấy dữ liệu thô" → client-side "mã hoá hai lớp cho tuân thủ khắt khe" → DSSE-KMS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket dùng khoá nào | get-bucket-encryption | | Xoay khoá đã bật chưa | get-key-rotation-status | | Ai đã dùng khoá | CloudTrail, lọc eventSource = kms.amazonaws.com |

Và một khuyến nghị nên áp dụng cùng lúc với việc chọn SSE-KMS: bật S3 Bucket Keys ngay từ đầu. Nó giữ nguyên mọi thứ bạn cần — xoay khoá, key policy, nhật ký CloudTrail ở mức bucket — trong khi cắt gần hết chi phí và rủi ro throttling; đây gần như luôn là đánh đổi đúng, trừ khi yêu cầu tuân thủ đòi nhật ký giải mã cho từng đối tượng riêng lẻ.

Đáp án

A — Security Group là STATEFUL, nên chỉ cần cho phép lưu lượng VÀO ở cổng cần thiết là kết nối hoạt động. Network ACL là STATELESS, nên bạn phải cho phép CẢ chiều vào LẪN chiều ra.

Vì sao đúng

Đề mô tả một tình huống rất cụ thể: đã mở inbound ở CẢ HAI lớp mà vẫn không kết nối được. Nguyên nhân chỉ có thể là chiều còn lại.

⚠ Điểm mấu chốt — NACL không nhớ gì cả:

Client → EC2 (request đi vào)
        ↓
    NACL inbound: ĐÃ mở cổng 443  ✓ gói tin vào được
        ↓
    Ứng dụng xử lý xong, gửi phản hồi
        ↓
    Phản hồi đi RA, từ cổng 443 tới CỔNG TẠM của client
      (ví dụ 54321)
        ↓
    NACL outbound: chỉ mở cổng 443  ✗ CHẶN
        ↓
    → request vào được, phản hồi KHÔNG ra được
    → client thấy TIMEOUT

⚠ Vì sao Security Group không gặp vấn đề này:

Security Group là STATEFUL
        ↓
    Nó GHI NHỚ mỗi kết nối đã được cho phép
        ↓
    → gói phản hồi tự động được phép đi ra
    → bất kể luật outbound viết gì
        ↓
    → mở inbound là đủ

⚠ Luật NACL outbound phải viết thế nào:

Chiều RA phải cho phép DẢI CỔNG TẠM, không phải cổng dịch vụ:
        ↓
    Linux           : 32768–60999
    Windows 2008+   : 49152–65535
    NLB / Lambda    : 1024–65535
        ↓
    → cách an toàn: mở 1024–65535 ở chiều ra

Xem thêm câu #11727: cùng tình huống và cùng đáp án với câu này, chỉ khác cách diễn đạt đề bài. Cùng chủ đề còn có #11631 (mất kết nối tới RDS) và #11686 (cho phép hai VPC nói chuyện).

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

• D (NACL là stateful, Security Group là stateless) — đây là phương án gần nhất và đảo ngược hoàn toàn hai khái niệm. Đây chính là bẫy trung tâm: hai phương án A và D chỉ khác nhau ở chỗ đổi vị trí hai từ.

• B (IAM role trong Security Group khác với IAM role được cấp quyền trong NACL) — bịa hoàn toàn: Security Group và NACL lọc theo IP và cổng, chúng không biết gì về IAM.

• C (không được sửa luật NACL từ dòng lệnh) — bịa: CLI, API và Console đều gọi cùng một API, kết quả hoàn toàn giống nhau.

Ghi nhớ

⚠ Security Group và Network ACL — bảng phải thuộc, đây là câu hỏi VPC kinh điển nhất: | | Security Group | Network ACL | |---|---|---| | Gắn vào | ENI (instance) | subnet | | Trạng thái | STATEFUL — nhớ kết nối | STATELESS — xét từng gói | | Luật | CHỈ có Allow | có cả Allow và Deny | | Mặc định | chặn vào, cho ra | cho cả hai chiều | | Thứ tự xét | xét tất cả | theo số thứ tự, dừng ở luật khớp đầu | | Chặn một IP | KHÔNG được | được | | Tham chiếu SG khác | CÓ | không |

Từ khoá nhận diện:

"mở inbound rồi mà vẫn timeout" → NACL outbound thiếu cổng tạm "chặn một IP xấu" → NACL (SG không có Deny) "SG là stateless" → LUÔN SAI "NACL là stateful" → LUÔN SAI "connection refused ngay lập tức" → thường là ứng dụng chưa chạy, không phải mạng "timeout" → thường là NACL, SG, hoặc route table

Ba việc kiểm chứng: | Việc | Cách | |---|---| | NACL có mở chiều ra không | describe-network-acls — xem cả Egress: true | | Gói bị bỏ ở đâu | VPC Flow Logs, lọc action = REJECT | | Đường đi có thông không | VPC Reachability Analyzer |

Và một lời khuyên về cách dùng hai lớp này: hãy để NACL ở mặc định (cho phép tất cả) và dồn toàn bộ luật lọc vào Security Group, trừ khi bạn thật sự cần chặn một IP cụ thể. NACL stateless là nguồn gốc của một tỷ lệ rất lớn các sự cố mạng khó chẩn đoán trên AWS — chúng gây ra timeout thay vì lỗi rõ ràng, và người ta luôn quên mất chiều còn lại vì trong đầu ai cũng nghĩ về kết nối như một thứ hai chiều.

Đáp án

D — Dùng AWS Health API để tích hợp dữ liệu sức khoẻ và thông báo vào các công cụ quản lý nội bộ sẵn có.

Vì sao đúng

Từ khoá quyết định: "tích hợp với công cụ quản lý nội bộ hiện có" — tức là cần dữ liệu lấy được bằng máy, không phải một trang web để nhìn.

⚠ Điểm mấu chốt — Health API biến sự kiện sức khoẻ thành dữ liệu tự động hoá được:

AWS Health API
        ↓
    describe-events              → danh sách sự kiện
    describe-event-details       → chi tiết và hướng dẫn giảm thiểu
    describe-affected-entities   → TÀI NGUYÊN NÀO của bạn bị ảnh hưởng
        ↓
    → đưa thẳng vào hệ thống ticket, kênh chat,
      bảng điều khiển nội bộ

⚠ Và cách dùng phổ biến nhất — qua EventBridge, không cần poll:

{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"],
  "detail": {
    "eventTypeCategory": ["issue", "scheduledChange"]
  }
}

Sự kiện xảy ra
        ↓
    EventBridge bắt được ngay
        ↓
    → SNS báo cho đội trực
    → Lambda tự mở ticket, tự chuyển lưu lượng
    → đẩy vào Slack/Teams
        ↓
    → đúng yêu cầu "tích hợp với công cụ nội bộ"

⚠ Một điều kiện phải nhớ:

AWS Health API yêu cầu gói hỗ trợ
        ↓
    BUSINESS, ENTERPRISE ON-RAMP, hoặc ENTERPRISE
        ↓
    Gói Developer và Basic: chỉ xem được trên console,
    KHÔNG gọi API được

Xem thêm câu #11604: cùng dịch vụ AWS Health nhưng ở góc xem thủ công — khi CTO hỏi "tài nguyên nào của chúng ta bị ảnh hưởng", câu trả lời là Personal Health Dashboard. Hai câu không mâu thuẫn: cần tự động hoá thì dùng API, cần xem ngay thì dùng dashboard.

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

• B (chạy chẩn đoán ngay bên trong Personal Health Dashboard bằng Lambda rồi tích hợp kết quả) — đây là phương án gần nhất vì nó cũng nói tới Lambda và tích hợp. Nhưng Personal Health Dashboard là một GIAO DIỆN, không phải nơi chạy mã; bạn không "chạy Lambda bên trong" nó. Cách đúng là Lambda gọi Health API hoặc nhận sự kiện từ EventBridge.

• A (Service Health Dashboard) — cho biết tình trạng chung của dịch vụ AWS, giống nhau với mọi khách hàng. Nó không biết tài nguyên nào của bạn bị ảnh hưởng, và cũng không có API để tích hợp.

• C (tính năng thông báo của Trusted Advisor) — Trusted Advisor gửi báo cáo khuyến nghị định kỳ hằng tuần về tối ưu chi phí, bảo mật, hạn mức. Nó không phải kênh sự kiện về sự cố dịch vụ.

Ghi nhớ

⚠ Các thành phần của AWS Health — bảng phải thuộc: | Thành phần | Nội dung | |---|---| | Service Health Dashboard | tình trạng chung của dịch vụ, công khai, không cần đăng nhập | | Personal Health Dashboard | ảnh hưởng cụ thể tới TÀI KHOẢN của bạn | | AWS Health API | truy vấn bằng máy — cần gói Business trở lên | | EventBridge integration | sự kiện đẩy tới bạn, không cần poll | | Organizational view | sức khoẻ của toàn bộ tổ chức ở một chỗ |

Từ khoá nhận diện:

"tích hợp vào công cụ nội bộ" → AWS Health API / EventBridge "tài nguyên nào của tôi bị ảnh hưởng" → Personal Health Dashboard "dịch vụ AWS có đang sập không" → Service Health Dashboard "khuyến nghị tối ưu" → Trusted Advisor "tự động phản ứng khi AWS có sự cố" → EventBridge + Lambda

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có sự kiện nào không | describe-events | | Tài nguyên nào dính | describe-affected-entities | | Quy tắc EventBridge có khớp không | dùng Test event pattern trong console |

Và một lời khuyên vận hành nên làm ngay hôm nay, không phải trong lúc sự cố: dựng một quy tắc EventBridge đẩy mọi sự kiện AWS Health vào kênh trực của đội. Giữa một sự cố lớn, mười phút đầu tiên luôn tiêu vào việc trả lời câu hỏi "lỗi của chúng ta hay lỗi của AWS" — và câu trả lời ấy luôn nằm sẵn trong AWS Health, chỉ là không ai nghĩ tới việc mở nó ra.

Đáp án

B — AWS OpsHub.

Vì sao đúng

AWS OpsHub là ứng dụng đồ hoạ chính thức để quản lý thiết bị họ Snow, ra đời chính vì lý do đề nêu: trước đó mọi thao tác đều phải qua CLI.

⚠ Điểm mấu chốt — OpsHub thay thế toàn bộ quy trình dòng lệnh:

Trước khi có OpsHub:
        ↓
    Mở khoá thiết bị bằng CLI với manifest và unlock code
    Cấu hình mạng bằng lệnh
    Chép dữ liệu bằng lệnh
    Quản lý instance EC2 trên thiết bị bằng lệnh
        ↓
Với OpsHub (ứng dụng cài trên máy tính):
        ↓
    Mở khoá và cấu hình bằng giao diện
    Kéo thả để chép dữ liệu
    Khởi chạy và quản lý EC2 ngay trên thiết bị
    Theo dõi dung lượng, tình trạng thiết bị
    Quản lý NHIỀU thiết bị cùng lúc

⚠ Vài điểm đáng nhớ về OpsHub:

MIỄN PHÍ, tải từ trang AWS
Chạy trên Windows và macOS
Hoạt động khi thiết bị KHÔNG có kết nối internet
Hỗ trợ cả Snowball Edge, Snowcone và Snowball

(Ghi chú: AWS OpsWorks ở phương án D là một dịch vụ có thật nhưng đã ngừng hoạt động từ 26/5/2024; dù còn hay đã ngừng thì nó cũng không liên quan tới họ Snow.)

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

• D (AWS OpsWorks) — đây là phương án gần nhất vì tên gọi rất giống OpsHub, đúng kiểu bẫy tên trong đề thi AWS. Nhưng OpsWorks là dịch vụ quản lý cấu hình bằng Chef và Puppet (và đã EOL tháng 5/2024), hoàn toàn không liên quan tới thiết bị Snow.

• A (AWS Control Tower) — dựng và quản trị môi trường nhiều tài khoản AWS (landing zone, guardrail). Không liên quan.

• C ("Service Workbench on AWS") — là một giải pháp mã nguồn mở của AWS dành cho nghiên cứu khoa học, giúp các nhà nghiên cứu tự cấp phát môi trường tính toán. Không liên quan tới Snow.

Ghi nhớ

⚠ Họ AWS Snow — bảng phải thuộc: | Thiết bị | Dung lượng | Đặc điểm | |---|---|---| | Snowcone | 8–14 TB | nhỏ nhất, chạy pin được, mang ra hiện trường | | Snowball Edge Storage Optimized | ~80 TB dùng được | di chuyển dữ liệu lớn | | Snowball Edge Compute Optimized | ít dung lượng hơn | có GPU, chạy EC2 và Lambda tại chỗ | | Snowmobile | tới 100 PB | xe container 45 foot |

Từ khoá nhận diện:

"quản lý thiết bị Snow bằng giao diện" → AWS OpsHub "OpsWorks" → Chef/Puppet, đã EOL 5/2024 — không liên quan Snow "dựng môi trường nhiều tài khoản" → Control Tower "hàng chục TB tới PB, băng thông không đủ" → Snowball Edge "xử lý dữ liệu ngay tại chỗ" → Snowball Edge Compute Optimized

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thiết bị đã mở khoá chưa | trạng thái trong OpsHub | | Chép dữ liệu tới đâu | OpsHub hiển thị tiến độ | | Job đã hoàn tất chưa | Snow Family console trên AWS |

Và một lời khuyên thực tế khi lập kế hoạch di chuyển dữ liệu bằng Snowball: thời gian chép dữ liệu VÀO thiết bị thường lâu hơn thời gian vận chuyển. Một Snowball Edge nhận dữ liệu qua mạng nội bộ 10 Gbps vẫn cần khoảng một ngày để chép đầy 80 TB — nên lịch trình thật phụ thuộc vào việc bạn chép được bao nhiêu thiết bị song song, chứ không phải vào tốc độ giao hàng của AWS.