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

Đáp án

B — Triển khai Amazon Macie và áp dụng finding type SensitiveData:S3Object/Financial trên toàn bộ S3 bucket.

Vì sao đúng

Đề nêu hai điều kiện, và Macie khớp cả hai:

1. Dữ liệu nằm rải rác trên nhiều S3 bucket
2. Cần tìm dữ liệu tài chính nhạy cảm có nguy cơ lộ

Amazon Macie là dịch vụ dùng học máy để tự động phát hiện dữ liệu nhạy cảm trong S3 — đúng phạm vi mà đề mô tả.

aws macie2 enable-macie

aws macie2 create-classification-job \
  --job-type SCHEDULED \
  --schedule-frequency '{"dailySchedule":{}}' \
  --name quet-du-lieu-tai-chinh \
  --s3-job-definition '{"bucketDefinitions":[{"accountId":"123456789012","buckets":["kho-a","kho-b"]}]}'

Macie phân loại phát hiện theo finding type, và mỗi loại nhắm vào một nhóm dữ liệu: | Finding type | Phát hiện | |---|---| | SensitiveData:S3Object/Financial | số thẻ tín dụng, số tài khoản ngân hàng | | SensitiveData:S3Object/Personal | tên, địa chỉ, số CMND, hộ chiếu | | SensitiveData:S3Object/Credentials | access key, private key, chuỗi kết nối | | SensitiveData:S3Object/CustomIdentifier | mẫu do bạn tự định nghĩa | | Policy:IAMUser/S3BucketPublic | bucket bị mở công khai |

Vì đề nói rõ là dữ liệu tài chính, finding type đúng là Financial.

Và Macie còn có nhóm Policy finding rất hợp với vế "lộ qua cổng web công khai" — nó phát hiện bucket bị mở public, tắt mã hoá, hoặc chia sẻ ra ngoài tài khoản.

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

• C. Macie với finding type Personal — đúng dịch vụ nhưng sai loại phát hiện: Personal tìm dữ liệu định danh cá nhân (tên, địa chỉ, số hộ chiếu), không phải dữ liệu tài chính. (Phương án này thậm chí tự thừa nhận điều đó trong phần mô tả — dấu hiệu phần giải thích của nguồn bị trộn vào nội dung phương án.)
• D. Dùng CloudTrail log để tìm nơi dữ liệu bị lộ — CloudTrail ghi AI gọi API nào, nhưng không biết NỘI DUNG object là gì. Nó cho biết "ai đã tải object X xuống", không cho biết "object X có chứa số thẻ tín dụng hay không". Sai loại thông tin.
• A. Kiểm tra thủ công từng bucket — bất khả thi ở quy mô này: tổ chức có "nhiều S3 bucket" với khối lượng dữ liệu lớn. Việc này tốn hàng tuần, dễ bỏ sót, và không lặp lại được.

Ghi nhớ

Phạm vi của Amazon Macie — điều quan trọng nhất cần nhớ: | Nguồn dữ liệu | Macie hỗ trợ | |---|---| | Amazon S3 | ✅ (duy nhất) | | CloudWatch Logs | ❌ | | DynamoDB, RDS, EBS | ❌ |

Nên nếu đề hỏi tìm dữ liệu nhạy cảm ở nơi khác S3, Macie không phải đáp án.

Hai nhóm finding của Macie: | Nhóm | Nội dung | |---|---| | Sensitive data finding | phát hiện dữ liệu nhạy cảm trong object | | Policy finding | cấu hình bucket rủi ro — public, không mã hoá, chia sẻ ra ngoài |

Nhóm thứ hai đặc biệt hữu ích cho tình huống "lộ qua cổng web": nó cảnh báo ngay khi có bucket bị mở công khai.

Các dịch vụ bảo mật của AWS và phạm vi của chúng — đừng lẫn: | Dịch vụ | Phát hiện gì | |---|---| | Macie | dữ liệu nhạy cảm trong S3 | | GuardDuty | hành vi đáng ngờ (truy cập bất thường, mã độc, đào tiền ảo) | | Inspector | lỗ hổng phần mềm trên EC2, container, Lambda | | Security Hub | tổng hợp phát hiện từ các dịch vụ trên | | IAM Access Analyzer | tài nguyên bị chia sẻ ra ngoài tài khoản | | Config | thay đổi cấu hình, đánh giá tuân thủ |

Lưu ý về chi phí: Macie tính tiền theo số bucket được giám sát cộng lượng dữ liệu được quét. Với hàng terabyte, nên dùng job có phạm vi hẹp và lấy mẫu thay vì quét toàn bộ mỗi ngày.

Đáp án

A — AWS CloudHSM.

Vì sao đúng

Đề có một yêu cầu rất đặc thù, và nó là chìa khoá: khoá phải được sinh ra từ thiết bị phần cứng chuyên dụng, chống can thiệp vật lý (dedicated, tamper-resistant hardware device).

CloudHSM cung cấp cụm HSM phần cứng dành riêng cho bạn: | Đặc điểm | Chi tiết | |---|---| | Phần cứng dành riêng | HSM chỉ của bạn, không chia sẻ với ai | | Chống can thiệp vật lý | tự huỷ khoá nếu phát hiện xâm phạm | | Tuân thủ FIPS 140-2 Level 3 | mức cao nhất mà nhiều quy định tài chính đòi hỏi | | AWS KHÔNG truy cập được khoá | bạn kiểm soát hoàn toàn, kể cả AWS cũng không xem được |

Dòng cuối là khác biệt lớn nhất so với KMS, và cũng là lý do một số quy định bắt buộc dùng CloudHSM.

aws cloudhsmv2 create-cluster \
  --hsm-type hsm1.medium \
  --subnet-ids subnet-abc subnet-def

aws cloudhsmv2 create-hsm --cluster-id cluster-abc --availability-zone ap-southeast-1a

Và với yêu cầu "mã hoá một khối lượng lớn dữ liệu", mẫu đúng vẫn là envelope encryption — HSM sinh ra data key, còn việc mã hoá dữ liệu lớn diễn ra tại chỗ trong ứng dụng.

(Có một lựa chọn dung hoà đáng biết: KMS custom key store — dùng giao diện quen thuộc của KMS nhưng vật liệu khoá nằm trong cụm CloudHSM của bạn. Nó kết hợp tính tiện dụng của KMS với yêu cầu phần cứng dành riêng.)

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

• B. AWS KMS — đây là phương án gần nhất và cần phân biệt kỹ. KMS cũng dùng HSM bên dưới và cũng đạt FIPS 140-2 (Level 3 với các HSM thế hệ mới), nhưng nó là dịch vụ đa khách hàng (multi-tenant) — HSM được chia sẻ, không phải "dedicated hardware device" như đề yêu cầu. Ngoài ra KMS có giới hạn 4 KB cho Encrypt, nên với "khối lượng lớn dữ liệu" cũng phải qua envelope encryption.
• D. AWS Certificate Manager — quản lý chứng chỉ TLS cho ELB, CloudFront, API Gateway. Nó không sinh khoá mã hoá dữ liệu.
• C. AWS IAM — quản lý danh tính và quyền truy cập. Hoàn toàn không liên quan tới mã hoá dữ liệu.

Ghi nhớ

So sánh CloudHSM và KMS — bảng này quyết định câu trả lời cho mọi câu hỏi dạng này: | | CloudHSM | KMS | |---|---|---| | Phần cứng | dành riêng (single-tenant) | chia sẻ (multi-tenant) | | AWS truy cập được khoá? | ❌ KHÔNG BAO GIỜ | quản lý bởi AWS | | Tuân thủ | FIPS 140-2 Level 3 | FIPS 140-2 (Level 3 với HSM mới) | | Tích hợp dịch vụ AWS | hạn chế | ✅ rất rộng: S3, EBS, RDS, Lambda… | | Vận hành | bạn quản lý cụm, người dùng HSM, sao lưu | AWS quản lý hoàn toàn | | Chi phí | cao — trả theo giờ mỗi HSM | thấp — ~1 USD/khoá/tháng | | Giao thức | PKCS#11, JCE, CNG/KSP | API của AWS |

Cách chọn: | Đề nói | Chọn | |---|---| | "dedicated hardware", "tamper-resistant", "FIPS 140-2 Level 3", "AWS không được thấy khoá" | CloudHSM | | "quản lý khoá đơn giản", "tích hợp với dịch vụ AWS" | KMS | | Cần cả hai | KMS custom key store |

Ba trường hợp thường bắt buộc dùng CloudHSM: xử lý thanh toán theo PCI DSS, làm Certificate Authority riêng, và ký giao dịch cần khoá bất đối xứng do bạn hoàn toàn kiểm soát.

Và một cảnh báo vận hành quan trọng: với CloudHSM, bạn tự chịu trách nhiệm sao lưu và quản lý người dùng HSM. Mất mật khẩu của crypto officer là mất vĩnh viễn khoá — AWS không khôi phục được.

Đáp án

C — Tạo CloudWatch Event (EventBridge) rule với event pattern bắt thay đổi trạng thái EC2, target là hàm Lambda.

Vì sao đúng

EC2 tự phát sự kiện lên EventBridge ở mỗi lần đổi trạng thái, nên bạn chỉ cần bắt đúng sự kiện cần:

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {"state": ["running"]}
}

aws events put-rule --name instance-vua-khoi-chay \
  --event-pattern file://mau-su-kien.json

aws events put-targets --rule instance-vua-khoi-chay \
  --targets "Id"="1","Arn"="arn:aws:lambda:...:function:ghi-metadata"

aws lambda add-permission --function-name ghi-metadata \
  --statement-id EventBridgeInvoke --action lambda:InvokeFunction \
  --principal events.amazonaws.com

Hàm nhận được sự kiện kèm instance ID, rồi tự lấy thêm metadata và ghi vào DynamoDB:

def lambda_handler(event, context):
    instance_id = event['detail']['instance-id']
    thong_tin = ec2.describe_instances(InstanceIds=[instance_id])['Reservations'][0]['Instances'][0]
    table.put_item(Item={
        'instance_id': instance_id,
        'loai': thong_tin['InstanceType'],
        'az': thong_tin['Placement']['AvailabilityZone'],
        'thoi_diem': event['time']
    })

Vì sao đây là cách hiệu quả nhất: nó là hướng sự kiện, gần thời gian thực, không có gì chạy khi không có instance nào khởi chạy, và hoàn toàn là cấu hình — không có mã điều phối nào phải viết.

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

• A. Tạo "CloudTrail trail alarm" kích hoạt Lambda dựa trên API RunInstances — CloudTrail không có cơ chế alarm. Nó chỉ ghi log. (Cách vòng vo là: CloudTrail → CloudWatch Logs → metric filter → alarm → SNS → Lambda — bốn tầng cho việc mà EventBridge làm trong một bước. Và CloudTrail có độ trễ vài phút.)
• B. CloudWatch alarm dựa trên log stream báo thay đổi trạng thái EC2 — alarm hoạt động trên METRIC số, không phản ứng với nội dung log. Và thay đổi trạng thái EC2 không xuất hiện trong CloudWatch Logs theo mặc định.
• D. Bật detailed monitoring và tạo alarm kích hoạt Lambda lúc khởi tạo — detailed monitoring chỉ đổi chu kỳ metric từ 5 phút xuống 1 phút. Nó không phát sự kiện vòng đời nào, và alarm vẫn cần một metric số để so ngưỡng.

Ghi nhớ

Phân biệt hai công cụ hay bị lẫn của CloudWatch: | | Alarm | EventBridge Rule | |---|---|---| | Đầu vào | metric (số) | sự kiện (JSON) | | Kích hoạt khi | vượt ngưỡng | khớp mẫu | | Ví dụ | CPU > 80% trong 5 phút | instance chuyển sang running |

Nhận dạng nhanh: "khi trạng thái X thay đổi" ⇒ EventBridge rule. "khi giá trị vượt ngưỡng" ⇒ CloudWatch alarm.

Các trạng thái EC2 mà EventBridge bắt được:

pending → running → shutting-down → terminated
                  → stopping → stopped

Mỗi lần chuyển đều phát một sự kiện EC2 Instance State-change Notification.

Vài nguồn sự kiện phổ biến khác của EventBridge: | Source | Ví dụ sự kiện | |---|---| | aws.ec2 | thay đổi trạng thái instance, Spot interruption | | aws.s3 | object được tạo, xoá | | aws.codepipeline | pipeline hoặc action đổi trạng thái | | aws.health | sự kiện bảo trì của AWS | | aws.autoscaling | instance launch/terminate trong ASG |

Dòng cuối đáng biết: nếu instance được tạo bởi Auto Scaling, dùng lifecycle hook còn mạnh hơn — nó giữ instance ở trạng thái chờ cho tới khi Lambda xử lý xong, đảm bảo metadata luôn được ghi trước khi instance nhận traffic.

Và một lựa chọn hoàn toàn khác đáng cân nhắc cho việc theo dõi tài nguyên: AWS Config — nó tự ghi lại mọi thay đổi cấu hình của mọi tài nguyên vào một kho có sẵn, không cần bạn tự dựng bảng DynamoDB.

Đáp án

A — Nhận message bằng long polling, chu kỳ 15 giây.

Vì sao đúng

Đề có hai dữ kiện quan trọng: message đến không thường xuyên, và cần độ trễ ngắn nhất giữa lúc message tới và lúc bảng xếp hạng được cập nhật.

Long polling là câu trả lời, và lý do nằm ở cách nó hoạt động:

Short polling (10 giây):
  0s   hỏi → rỗng, trả về ngay
  2s   ← MESSAGE TỚI, nằm chờ
  10s  hỏi → nhận được message
  ⇒ độ trễ: 8 giây

Long polling (chờ tới 20 giây):
  0s   hỏi → không có message, GIỮ KẾT NỐI CHỜ
  2s   ← MESSAGE TỚI → TRẢ VỀ NGAY LẬP TỨC
  ⇒ độ trễ: gần như 0

Điểm mấu chốt: long polling trả về NGAY khi message xuất hiện, không phải chờ hết khoảng chờ. Nên với message đến thưa thớt, nó cho độ trễ thấp hơn nhiều so với hỏi lại định kỳ.

sqs.receive_message(
    QueueUrl=url,
    WaitTimeSeconds=20,        # tối đa
    MaxNumberOfMessages=10
)

Và nó còn rẻ hơn hẳn: SQS tính tiền theo số request, mà long polling giảm số lời gọi rỗng khoảng 20 lần.

Lợi ích thứ ba ít người biết: long polling quét toàn bộ server của SQS, nên nó giảm hẳn trường hợp trả về rỗng dù hàng đợi có message — vấn đề cố hữu của short polling do SQS lưu trữ phân tán.

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

• C. Short polling mỗi 10 giây — đây là phương án gần nhất và cần phân biệt rõ: nó hỏi thường xuyên hơn (10 giây so với 15 giây), nghe như sẽ nhanh hơn. Nhưng nó trả về ngay lập tức khi hàng đợi rỗng, nên message tới giữa hai lần hỏi phải nằm chờ tới lần hỏi sau — độ trễ trung bình khoảng 5 giây. Long polling không có khoảng chờ đó.
• B. Nén message trước khi gửi — message chỉ 4 KB, nằm gọn trong giới hạn 256 KB của SQS. Nén không giảm được độ trễ nào đáng kể, và còn thêm thời gian xử lý ở cả hai đầu.
• D. Lưu payload trên S3 và dùng SQS Extended Client Library — thư viện này dùng khi message vượt quá 256 KB. Với message 4 KB, nó thêm hẳn một lần đi mạng tới S3 ở cả khi gửi lẫn khi nhận — làm tăng độ trễ, ngược hẳn mục tiêu.

Ghi nhớ

So sánh hai chế độ polling: | | Short polling (WaitTimeSeconds=0) | Long polling (> 0) | |---|---|---| | Khi hàng đợi rỗng | trả về NGAY, rỗng | chờ tới khi có message hoặc hết thời gian | | Độ trễ nhận message | phụ thuộc chu kỳ hỏi lại | gần như tức thì | | Số request rỗng | rất nhiều | ít hơn ~20 lần | | Phạm vi quét | chỉ một tập con server | toàn bộ server | | Chi phí | cao | thấp |

Long polling thắng ở mọi tiêu chí — không có lý do nào để dùng short polling trong thực tế. Đó là lý do AWS khuyến nghị luôn bật nó.

Bốn tham số thời gian của SQS: | Tham số | Phạm vi | Việc | |---|---|---| | WaitTimeSeconds | 0 – 20 giây | long polling | | VisibilityTimeout | 0 – 12 giờ | ẩn message đang xử lý | | DelaySeconds | 0 – 15 phút | hoãn message mới xuất hiện | | MessageRetentionPeriod | 60 giây – 14 ngày | giữ message bao lâu |

Cấu hình tối ưu cho consumer thông thường:

sqs.receive_message(QueueUrl=url, MaxNumberOfMessages=10, WaitTimeSeconds=20)

Và nếu muốn độ trễ thấp hơn nữa: dùng SQS làm event source cho Lambda. Lambda tự poll liên tục bằng long polling và gọi hàm ngay khi có message — không có khoảng chờ nào giữa các chu kỳ, và bạn không phải viết consumer.

Đáp án

A — 12 RCU và 18 WCU.

Vì sao đúng

Hai phép tính riêng biệt, với đơn vị khác nhau — đây là chỗ hay sai nhất.

RCU — đơn vị 4 KB:

Bước 1: làm tròn lên   → ceil(9 / 4) = 3 đơn vị
Bước 2: strongly consistent → × 1     = 3 RCU mỗi lần đọc
Bước 3: nhân số lần    → 3 × 4        = 12 RCU

WCU — đơn vị 1 KB:

Bước 1: làm tròn lên   → ceil(9 / 1) = 9 đơn vị
Bước 2: ghi thường     → × 1          = 9 WCU mỗi lần ghi
Bước 3: nhân số lần    → 9 × 2        = 18 WCU

Kết quả: 12 RCU và 18 WCU.

Điểm quan trọng nhất trong bài này: cùng một item 9 KB tốn 3 đơn vị đọc nhưng 9 đơn vị ghi — vì RCU dùng đơn vị 4 KB còn WCU dùng đơn vị 1 KB. Ghi luôn đắt hơn đọc rất nhiều.

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

• B. 12 RCU và 36 WCU — RCU đúng, nhưng WCU nhân đôi như thể là transactional write. Đề nói "standard write", không phải transactional.
• C. 24 RCU và 18 WCU — WCU đúng, nhưng RCU nhân đôi. Có thể do nhầm sang công thức transactional read.
• D. 6 RCU và 18 WCU — WCU đúng, nhưng RCU bị chia đôi như thể là eventually consistent. Đề nói rõ strongly consistent.

Ba phương án sai này đều đúng một nửa — chúng kiểm tra xem bạn có nắm chắc cả hai công thức hay chỉ nhớ một.

Ghi nhớ

Hai công thức cần thuộc, và chúng không đối xứng:

RCU — đơn vị 4 KB:

Strongly consistent  : ceil(size / 4 KB)       × số_lần_đọc
Eventually consistent: ceil(size / 4 KB) ÷ 2   × số_lần_đọc
Transactional        : ceil(size / 4 KB) × 2   × số_lần_đọc

WCU — đơn vị 1 KB:

Ghi thường     : ceil(size / 1 KB)       × số_lần_ghi
Transactional  : ceil(size / 1 KB) × 2   × số_lần_ghi

Ba lỗi phổ biến nhất:

1. Nhầm đơn vị — RCU dùng 4 KB, WCU dùng 1 KB. Đây là lỗi số một.
2. Quên làm tròn LÊN — item 9,1 KB tốn như 12 KB khi đọc (3 đơn vị) và như 10 KB khi ghi.
3. Bỏ qua từ khoá "strongly", "eventually", "transactional" trong đề.

Bảng đối chiếu cho item 9 KB để nắm chắc: | Thao tác | Đơn vị | Mỗi lần | 4 lần/giây | |---|---|---|---| | Đọc strongly | ceil(9/4) = 3 | 3 RCU | 12 | | Đọc eventually | 3 ÷ 2 | 1,5 RCU | 6 | | Đọc transactional | 3 × 2 | 6 RCU | 24 | | Ghi thường | ceil(9/1) = 9 | 9 WCU | (× 2 lần) = 18 | | Ghi transactional | 9 × 2 | 18 WCU | 36 |

Và một quan sát thiết kế đáng nhớ từ bảng trên: vì WCU đắt hơn RCU khoảng 5 lần cho cùng kích thước item, việc giảm kích thước item hoặc giảm tần suất ghi thường tiết kiệm nhiều hơn hẳn so với tối ưu đường đọc.

Với tải khó dự đoán, on-demand mode loại bỏ hẳn việc tính toán này — bạn trả tiền theo số request thật, đổi lại đơn giá cao hơn khi tải đều.

Đáp án

B — AWS Step Functions.

Vì sao đúng

Đề mô tả chính xác vấn đề mà Step Functions sinh ra để giải: nhiều hàm Lambda gọi lẫn nhau như một máy trạng thái lớn, và việc điều phối được viết bằng mã tự chế nên rất dễ hỏng.

Step Functions tách logic điều phối ra khỏi mã ứng dụng, đưa nó vào một định nghĩa khai báo bằng Amazon States Language:

{
  "StartAt": "XacThucDonHang",
  "States": {
    "XacThucDonHang": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:xac-thuc",
      "Retry": [{"ErrorEquals": ["States.Timeout"], "MaxAttempts": 3, "BackoffRate": 2.0}],
      "Catch": [{"ErrorEquals": ["States.ALL"], "ResultPath": "$.loi", "Next": "XuLyLoi"}],
      "Next": "KiemTraTonKho"
    },
    "KiemTraTonKho": {
      "Type": "Choice",
      "Choices": [{"Variable": "$.conHang", "BooleanEquals": true, "Next": "ThanhToan"}],
      "Default": "BaoHetHang"
    },
    "ThanhToan": {"Type": "Task", "Resource": "...", "End": true},
    "BaoHetHang": {"Type": "Task", "Resource": "...", "End": true},
    "XuLyLoi": {"Type": "Fail"}
  }
}

Vì sao nó thay thế được "legacy custom code": | Việc bạn từng phải tự viết | Step Functions làm sẵn | |---|---| | Thử lại khi lỗi | Retry với backoff, khai báo | | Bắt và xử lý lỗi | Catch với đường rẽ riêng | | Rẽ nhánh theo điều kiện | Choice | | Chạy song song | Parallel, Map | | Chờ | Wait | | Lưu trạng thái giữa các bước | tự động | | Theo dõi đang chạy tới đâu | sơ đồ trực quan trong Console |

Điểm cuối rất đáng giá cho một máy trạng thái phức tạp: bạn nhìn thấy luồng thực thi, biết nó dừng ở bước nào và vì sao — thay vì phải ghép log của hàng chục hàm Lambda.

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

• C. AWS CloudFormation — công cụ hạ tầng dưới dạng mã: tạo và cập nhật tài nguyên AWS. Nó không điều phối luồng thực thi lúc chạy. (Bạn dùng nó để triển khai state machine, nhưng nó không phải state machine.)
• D. AWS CodePipeline — điều phối quy trình CI/CD (build, test, deploy). Nó là workflow của việc phát hành phần mềm, không phải workflow của logic nghiệp vụ lúc chạy.
• A. AWS CodeBuild — biên dịch mã và chạy test. Không liên quan tới điều phối runtime.

Ghi nhớ

Tám loại state của Step Functions: | State | Việc | |---|---| | Task | gọi một dịch vụ (Lambda, ECS, SNS, SQS, DynamoDB…) | | Choice | rẽ nhánh theo điều kiện | | Parallel | chạy nhiều NHÁNH KHÁC NHAU đồng thời | | Map | chạy CÙNG logic trên từng phần tử mảng | | Wait | tạm dừng | | Pass | truyền dữ liệu, biến đổi | | Succeed / Fail | kết thúc |

Hai loại workflow: | | Standard | Express | |---|---|---| | Thời gian tối đa | 1 năm | 5 phút | | Tốc độ | 2.000 lần bắt đầu/giây | 100.000 lần/giây | | Đảm bảo | exactly-once | at-least-once | | Giá | theo lần chuyển trạng thái | theo số lần chạy và thời lượng | | Lịch sử | hiện đầy đủ trong Console | chỉ trong CloudWatch Logs |

Cách chọn: quy trình nghiệp vụ dài, cần kiểm toán ⇒ Standard. Xử lý sự kiện khối lượng lớn, ngắn ⇒ Express.

Và một tính năng rất mạnh: AWS SDK integrations cho phép Task gọi thẳng hơn 200 dịch vụ AWS mà không cần Lambda trung gian — ví dụ ghi DynamoDB, gửi SNS, khởi chạy ECS task đều khai trực tiếp trong state machine.

Đáp án

D — Cài AWS SAM CLI, chạy sam init và chọn một trong các AWS Quick Start Template.

Vì sao đúng

Đề hỏi cách ĐƠN GIẢN NHẤT để bắt đầu với một hàm Hello World bằng SAM, và sam init là lệnh dựng riêng cho việc đó:

# Cài SAM CLI (macOS)
brew install aws-sam-cli

# Khởi tạo dự án từ template có sẵn
sam init

Lệnh này hỏi vài câu rồi sinh ra một dự án hoàn chỉnh:

ung-dung-cua-toi/
├── template.yaml          ← template SAM đã viết sẵn
├── hello-world/
│   ├── app.js             ← mã Hello World
│   └── package.json
├── events/
│   └── event.json         ← sự kiện mẫu để kiểm thử
└── tests/

Từ đó chạy được ngay, cả cục bộ lẫn trên cloud:

sam local invoke HelloWorldFunction --event events/event.json
sam local start-api                 # dựng API giả tại localhost:3000
sam build && sam deploy --guided    # triển khai lên AWS

Và đề nhắc tới "shorthand syntax to express functions, APIs, databases, and event source mappings" — đó chính là mô tả của SAM, nên công cụ đi kèm nó là SAM CLI.

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

• A. Cài AWS CLI rồi chạy aws sam init — không có lệnh aws sam. SAM CLI là một công cụ RIÊNG BIỆT, cài độc lập với AWS CLI. Lệnh là sam, không phải aws sam. Đây là bẫy chính.
• C. Dùng AWS Management Console để truy cập SAM và triển khai — SAM không có giao diện Console riêng. Nó là framework và bộ CLI chạy trên máy của bạn. (Console có Lambda và CloudFormation, nhưng không có mục "SAM".)
• B. Dùng CloudFormation triển khai stack Hello World bằng SAM — làm được nhưng nhiều việc hơn hẳn: bạn phải tự viết template từ đầu, tự tạo bucket S3, tự chạy package rồi deploy. sam init cho sẵn tất cả.

Ghi nhớ

Các lệnh chính của SAM CLI: | Lệnh | Việc | |---|---| | sam init | tạo dự án mới từ template | | sam build | biên dịch, cài phụ thuộc | | sam local invoke | chạy hàm CỤC BỘ trong Docker | | sam local start-api | dựng API Gateway giả tại localhost:3000 | | sam local generate-event | sinh sự kiện mẫu (S3, SNS, API Gateway…) | | sam package | tải mã lên S3 | | sam deploy --guided | triển khai, hỏi và lưu cấu hình | | sam logs | xem log của hàm | | sam sync --watch | đồng bộ thay đổi lên AWS ngay khi sửa mã |

Lệnh cuối rất tiện cho vòng lặp phát triển: sửa mã là nó tự đẩy lên, không phải build và deploy lại.

Ba công cụ hay bị lẫn: | Công cụ | Là gì | Lệnh | |---|---|---| | AWS CLI | công cụ chung cho mọi dịch vụ AWS | aws | | SAM CLI | framework serverless + chạy cục bộ | sam | | AWS CDK | hạ tầng bằng ngôn ngữ lập trình | cdk |

Chúng không loại trừ nhau — nhiều đội dùng CDK để định nghĩa hạ tầng rồi dùng sam local để kiểm thử hàm cục bộ (qua cdk synth ra template rồi sam local invoke).

Và hạn chế cần biết của sam local: nó mô phỏng Lambda và API Gateway, nhưng không mô phỏng các dịch vụ AWS khác. Hàm gọi DynamoDB sẽ gọi tới DynamoDB thật trên đám mây bằng credential của bạn — trừ khi bạn trỏ endpoint sang DynamoDB Local hoặc LocalStack.

Đáp án

B — Gắn Lambda@Edge vào CloudFront distribution, kích hoạt ở viewer request, cấp cho execution role của hàm quyền gọi AWS STS, và chuyển mọi lời gọi SDK từ frontend vào hàm đó.

Vì sao đúng

Vấn đề trong đề rất nghiêm trọng: credential đang nằm ở dạng bản rõ trong tệp Python của frontend — tức là ai mở mã nguồn trang web cũng đọc được.

Cách chữa đúng gồm hai phần, và cả hai đều nằm trong đáp án B:

1. Chuyển lời gọi SDK từ frontend sang backend. Mã chạy ở trình duyệt không bao giờ giữ được bí mật. Đưa nó ra khỏi frontend là điều kiện tiên quyết.

2. Dùng execution role thay vì credential nhúng cứng. Đây là điểm phân biệt quan trọng nhất: hàm Lambda@Edge tự nhận credential tạm thời từ execution role của nó — không có credential nào được lưu ở đâu cả.

// Lambda@Edge — SDK tự lấy credential từ execution role
const { STSClient, AssumeRoleCommand } = require('@aws-sdk/client-sts');
const sts = new STSClient({ region: 'us-east-1' });   // KHÔNG truyền credential

exports.handler = async (event) => {
    const result = await sts.send(new AssumeRoleCommand({
        RoleArn: 'arn:aws:iam::123456789012:role/RoleNguoiDung',
        RoleSessionName: 'phien-nguoi-dung'
    }));
    // ... xử lý rồi trả về
};

Và execution role cần trust cả hai service principal — điều bắt buộc với Lambda@Edge:

{
  "Effect": "Allow",
  "Principal": {"Service": ["lambda.amazonaws.com", "edgelambda.amazonaws.com"]},
  "Action": "sts:AssumeRole"
}

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

• D. Lambda@Edge nhưng chuyển credential từ tệp Python vào hàm — vẫn còn credential nhúng cứng, chỉ là chuyển từ chỗ này sang chỗ khác. Đề yêu cầu rõ "without embedding any credentials". An toàn hơn frontend, nhưng không giải quyết đúng vấn đề.
• C. CloudFront Function với execution role có quyền STS — ý tưởng đúng nhưng CloudFront Functions không làm được: chúng chạy trong môi trường JavaScript rất hạn chế, không có quyền truy cập mạng, không gọi được dịch vụ AWS, và không có execution role. Chúng chỉ dùng để thao tác header và URL.
• A. CloudFront Function và chuyển credential vào đó — sai cả hai vế: vẫn nhúng credential, và CloudFront Functions vẫn không gọi được STS.

Ghi nhớ

So sánh hai cơ chế tính toán ở edge — bảng này quyết định câu trả lời: | | CloudFront Functions | Lambda@Edge | |---|---|---| | Gọi dịch vụ AWS | ❌ không có mạng | ✅ | | Execution role | ❌ | ✅ | | Runtime | JavaScript hạn chế | Node.js, Python | | Thời gian chạy | dưới 1 mili giây | 5 giây (viewer) / 30 giây (origin) | | Điểm gắn | chỉ viewer request/response | cả bốn điểm | | Chi phí | rẻ hơn ~6 lần | cao hơn | | Dùng cho | viết lại URL, thêm header, chuyển hướng đơn giản | logic cần gọi dịch vụ AWS |

Nguyên tắc chọn: cần gọi dịch vụ AWS hoặc cần mạng ⇒ Lambda@Edge. Chỉ thao tác header và URL ⇒ CloudFront Functions.

Các hạn chế của Lambda@Edge cần nhớ: | Hạn chế | Chi tiết | |---|---| | Region | BẮT BUỘC us-east-1 | | Version | phải trỏ tới version cụ thể, không dùng $LATEST hay alias | | Biến môi trường | không hỗ trợ | | VPC | không gắn được |

Dòng thứ ba đáng chú ý trong bối cảnh câu hỏi này: Lambda@Edge không có biến môi trường, nên nếu bạn định "giấu" credential ở đó cũng không được — càng củng cố việc phải dùng execution role.

Và nguyên tắc bao trùm rút ra từ câu này: mã chạy ở client không bao giờ giữ được bí mật. Mọi credential trong JavaScript, ứng dụng di động, hay tệp cấu hình phía trình duyệt đều coi như đã bị lộ.

Đáp án

C — Thêm codecommit:CreateBranch và codecommit:DeleteBranch.

Vì sao đúng

Đề yêu cầu đặc quyền tối thiểu, và lập trình viên cần đúng hai việc: tạo nhánh và xoá nhánh. Nên chỉ thêm đúng hai quyền tương ứng:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "codecommit:BatchGetRepositories",
      "codecommit:Get*",
      "codecommit:List*",
      "codecommit:GitPull",
      "codecommit:CreateBranch",
      "codecommit:DeleteBranch"
    ],
    "Resource": "arn:aws:codecommit:ap-southeast-1:123456789012:kho-du-an"
  }]
}

Đối chiếu với policy hiện có trong đề: | Quyền đã có | Cho phép | |---|---| | Get*, List*, BatchGetRepositories | đọc thông tin kho | | GitPull | clone và pull | | thiếu CreateBranch | không tạo được nhánh | | thiếu DeleteBranch | không xoá được nhánh |

(Ghi chú thực dụng: nếu lập trình viên tạo nhánh bằng lệnh Git (git push origin nhanh-moi) chứ không qua Console hay API, thì quyền cần là codecommit:GitPush. CreateBranch và DeleteBranch là các API dùng khi thao tác qua Console, CLI hoặc SDK. Với đề bài này — hỏi về quyền IAM cho hai thao tác cụ thể — hai action đó là câu trả lời chính xác nhất.)

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

• A. codecommit:Put* — quá rộng và không đúng đối tượng: nhóm này gồm PutFile, PutRepositoryTriggers, PutCommentReaction… Nó cho phép sửa nội dung tệp nhưng không có action nào tạo nhánh cả.
• D. codecommit:Update* — cũng quá rộng và sai: gồm UpdateRepositoryName, UpdateDefaultBranch, UpdatePullRequestStatus… không có action tạo hay xoá nhánh.
• B. codecommit:* — vi phạm nặng nhất nguyên tắc đặc quyền tối thiểu: nó cho phép mọi thứ, kể cả DeleteRepository — xoá sạch cả kho mã. Đây là kiểu cấp quyền "cho tiện" mà đề đang kiểm tra xem bạn có tránh được không.

Ghi nhớ

Các nhóm quyền của CodeCommit: | Nhóm | Action tiêu biểu | |---|---| | Đọc | GitPull, GetBranch, GetFile, GetRepository, ListBranches | | Ghi mã | GitPush, PutFile, CreateCommit, DeleteFile | | Quản lý nhánh | CreateBranch, DeleteBranch, UpdateDefaultBranch | | Pull request | CreatePullRequest, MergePullRequestByFastForward, PostCommentForPullRequest | | Quản trị kho | CreateRepository, DeleteRepository, UpdateRepositoryName |

Ba managed policy dựng sẵn, để tham khảo mức độ: | Policy | Phạm vi | |---|---| | AWSCodeCommitReadOnly | chỉ đọc | | AWSCodeCommitPowerUser | đọc ghi đầy đủ, NHƯNG không xoá kho | | AWSCodeCommitFullAccess | mọi thứ |

PowerUser là lựa chọn hợp lý cho hầu hết lập trình viên — nó chặn đúng thao tác nguy hiểm nhất.

Một kỹ thuật phân quyền tinh vi hơn đáng biết: giới hạn theo nhánh bằng condition key codecommit:References — ví dụ cho phép push vào nhánh tính năng nhưng chặn push thẳng vào main:

{
  "Effect": "Deny",
  "Action": ["codecommit:GitPush", "codecommit:DeleteBranch"],
  "Resource": "arn:aws:codecommit:*:*:kho-du-an",
  "Condition": {
    "StringEqualsIfExists": {"codecommit:References": ["refs/heads/main"]}
  }
}

Cách này ép mọi thay đổi lên nhánh chính phải đi qua pull request — một guardrail rất hữu ích cho đội nhiều người.

(Ghi chú thời sự: CodeCommit ngừng nhận khách hàng mới từ 7/2024; tài khoản đã dùng vẫn hoạt động. Với dự án mới, dùng GitHub, GitLab hoặc Bitbucket.)

Đáp án

D — Cài CloudWatch Logs agent và thu thập log từ các instance.

Vì sao đúng

Đề hỏi cách DỄ NHẤT để tập trung log, và CloudWatch agent là công cụ AWS làm sẵn cho đúng việc đó — không phải viết một dòng mã nào.

# Cài agent
sudo yum install -y amazon-cloudwatch-agent

# Cấu hình rồi khởi động
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/config.json -s

Tệp cấu hình khai đường dẫn log cần thu thập:

{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {"file_path": "/var/log/ung-dung/*.log",
           "log_group_name": "/ung-dung/production",
           "log_stream_name": "{instance_id}",
           "retention_in_days": 30}
        ]
      }
    }
  }
}

Agent lo trọn các việc khó: | Việc | Agent tự làm | |---|---| | Theo dõi tệp thay đổi | ✅ như tail -f | | Nhớ vị trí đã đọc | ✅ không gửi trùng sau khi khởi động lại | | Gom lô và thử lại | ✅ chịu được mất mạng tạm thời | | Xoay vòng tệp log | ✅ theo kịp khi log rotate | | Tự tạo log group và stream | ✅ |

Và đề nêu hai yêu cầu, cả hai đều được đáp ứng: | Yêu cầu | CloudWatch Logs | |---|---| | Truy vấn được | Logs Insights với cú pháp truy vấn riêng | | Lưu giữ | retention policy từ 1 ngày tới vĩnh viễn |

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)

Instance cần IAM role với quyền CloudWatchAgentServerPolicy.

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

• B. Viết script dùng AWS SDK để thu thập và gửi log — tự dựng lại chính CloudWatch agent, và bạn phải tự lo mọi việc trong bảng trên: theo dõi tệp, nhớ vị trí, gom lô, thử lại, xử lý log rotate. Nhiều mã phải viết và bảo trì.
• A. Script sao chép log lên S3 theo lịch cron — không phải thời gian thực (log chỉ xuất hiện sau mỗi chu kỳ cron), phải tự viết và bảo trì script, và truy vấn khó hơn (phải qua Athena, và phải tự tổ chức phân vùng). (Cách này hợp lý cho lưu trữ dài hạn giá rẻ, nhưng không phải cách "dễ nhất" để tập trung log.)
• C. CloudWatch Events rule kích hoạt SNS khi có log file được tạo — EventBridge không phát hiện được việc tạo tệp trên EC2: nó phản ứng với sự kiện của dịch vụ AWS, không theo dõi hệ thống tệp bên trong instance. Và SNS gửi thông báo, không tập trung log.

Ghi nhớ

Hai phiên bản agent — nên dùng bản nào: | | Unified CloudWatch agent | CloudWatch Logs agent (cũ) | |---|---|---| | Thu thập | log VÀ metric hệ thống | chỉ log | | Hỗ trợ | được khuyến nghị | đã ngừng phát triển | | Nền tảng | Linux, Windows, on-premises | Linux |

Unified agent còn thu thập được các metric mà CloudWatch không tự có: | Metric | Vì sao cần agent | |---|---| | Bộ nhớ đã dùng | CloudWatch không thấy được từ bên ngoài | | Dung lượng đĩa còn trống | tương tự | | Số tiến trình, swap | tương tự |

Đây là điều nhiều người ngạc nhiên: CloudWatch mặc định KHÔNG có metric bộ nhớ và ổ đĩa cho EC2 — vì hypervisor không nhìn được vào bên trong hệ điều hành. Muốn có thì bắt buộc phải cài agent.

Ba lựa chọn tập trung log, theo mục đích: | Cách | Hợp cho | |---|---| | CloudWatch Logs agent | tập trung, truy vấn, cảnh báo — dễ nhất | | Kinesis Data Firehose → S3 | khối lượng rất lớn, lưu trữ giá rẻ | | FluentBit → OpenSearch | cần tìm kiếm và trực quan hoá nâng cao |

Và mẹo tiết kiệm chi phí: đặt retention policy cho mọi log group — mặc định là "Never expire", và log tích luỹ nhiều năm là khoản chi phí ẩn khá lớn.