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

Đáp án

B — Tạo LSI (Local Secondary Index).

Vì sao đúng

Manh mối quyết định nằm ở cuối đề: "phải thêm khi tạo bảng lần đầu, sau đó không đổi được". Đó là đặc tính riêng của LSI.

Đề cũng khớp với vế thứ hai: truy vấn theo primary key và một alternate key — tức là giữ nguyên partition key, chỉ thêm một sort key khác. Đó chính xác là LSI:

Bảng gốc: partition = user_id, sort = order_date
LSI     : partition = user_id, sort = order_amount    ← cùng partition key

Cho phép truy vấn "đơn hàng của người này, sắp theo giá trị" mà không cần bảng mới.

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

• D. Tạo GSI — bẫy chính. GSI linh hoạt hơn (đổi được cả partition key, tạo được bất cứ lúc nào) — nhưng chính vì tạo được sau mà nó không khớp với ràng buộc trong đề. Đề nói rõ tuỳ chọn này phải thêm lúc tạo bảng.
• A. Gọi Scan — quét toàn bộ bảng rồi lọc ở phía client. Cực chậm và tốn RCU với bảng lớn, và không phải index.
• C. Rời bỏ DynamoDB — phản ứng quá mức: DynamoDB hỗ trợ đầy đủ nhu cầu này qua secondary index.

Ghi nhớ

Bảng những gì đổi được và không đổi được sau khi tạo bảng DynamoDB: | Đổi được | Không đổi được | |---|---| | Throughput / billing mode | Partition key | | Thêm/xoá GSI | Sort key | | Bật/tắt stream, TTL, PITR | LSI (chỉ lúc tạo bảng) | | Bật/tắt deletion protection | |

Hai điểm nữa về LSI đáng biết: nó dùng chung RCU/WCU với bảng gốc (nên tiêu thụ của nó tính vào hạn mức bảng), và mỗi partition key có giới hạn 10 GB khi bảng có LSI — hạn chế mà GSI không có.

Câu thần chú: cần đổi partition key ⇒ GSI. Cần nhất quán mạnh hoặc chỉ đổi sort key ⇒ LSI (nhưng phải nghĩ từ lúc tạo bảng).

Đáp án

B — Thêm rule cho Network ACL cho phép traffic đi ra trên cổng 1024 – 65535.

Vì sao đúng

Cấu hình hiện tại: NACL và security group đều cho phép inbound cổng 80. Nhưng người dùng vẫn không vào được.

Nguyên nhân: NACL là stateless. Nó xét từng gói tin độc lập, không ghi nhớ kết nối. Nên gói đi vào và gói phản hồi đi ra là hai chuyện hoàn toàn riêng biệt, mỗi chiều cần một rule.

Và đây là chỗ dễ bỏ sót: phản hồi HTTP không đi ra từ cổng 80 — nó đi tới cổng nguồn của client, nằm trong dải ephemeral port:

Client:54321  ──→  Server:80      ← rule inbound cho phép ✅
Client:54321  ←──  Server:80      ← rule OUTBOUND phải cho phép cổng 54321 ❗

Vì cổng nguồn của client không đoán trước được, phải mở cả dải:

Rule 100  Outbound  TCP  1024-65535  0.0.0.0/0  ALLOW

Vì sao 1024–65535 chứ không phải dải hẹp hơn — đây là điểm phân biệt giữa các phương án. Dải ephemeral port khác nhau theo hệ điều hành và theo dịch vụ:

Vì client đến từ Internet với đủ loại hệ điều hành, và traffic có thể đi qua load balancer, 1024–65535 là dải an toàn duy nhất.

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

• A. Cổng 1025–5000 — dải của Windows Server 2003 trở về trước, quá hẹp cho client hiện đại.
• C. Cổng 32768–61000 — dải của Linux, nhưng bỏ sót Windows client (49152–65535 vượt ra ngoài) và các dịch vụ AWS.
• D. Thêm outbound rule cho security group trên cổng 80 — sai hai chỗ: security group là stateful nên phản hồi tự động được phép; và outbound mặc định của security group vốn đã cho phép tất cả.

Ghi nhớ

Nhớ nhanh: stateless ⇒ phải mở cả hai chiều, và chiều về luôn dùng ephemeral port 1024–65535.

Đáp án

A và D.

• D — CloudWatch Metrics — Lambda tự phát metric Errors.
• A — CloudWatch Alarms — đặt cảnh báo trên metric đó.

Vì sao đúng

Yêu cầu: theo dõi tỷ lệ lỗi của các hàm Lambda và tạo alarm trên chúng.

D — metric có sẵn. Lambda tự động phát một bộ metric vào namespace AWS/Lambda, không cần cấu hình gì:

A — alarm. Đặt cảnh báo trên metric, và dùng metric math để tính đúng tỷ lệ lỗi thay vì số tuyệt đối:

Expression: (errors / invocations) * 100 > 5

Đây là điểm quan trọng về mặt vận hành: 10 lỗi trên 100 lần gọi và 10 lỗi trên 1.000.000 lần gọi là hai tình huống hoàn toàn khác nhau. Alarm theo con số tuyệt đối sẽ kêu sai ở cả hai chiều.

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

• B. X-Ray — công cụ theo dấu phân tán: cho biết request đi qua đâu và chậm ở chặng nào. Nó rất hữu ích để chẩn đoán một lỗi cụ thể, nhưng không phát metric tỷ lệ lỗi và không đặt alarm được.
• E. CloudTrail — ghi lời gọi API quản trị (CreateFunction, UpdateFunctionCode, ai deploy lúc nào). Nó không theo dõi lỗi lúc chạy của hàm.
• C. Systems Manager — công cụ vận hành hạm đội máy chủ: chạy lệnh, vá, kiểm kê. Không liên quan tới giám sát Lambda.

Ghi nhớ

Bộ công cụ quan sát cho Lambda, dùng chồng lên nhau: | Công cụ | Cho biết | |---|---| | CloudWatch Metrics | số liệu: Errors, Duration, Throttles | | CloudWatch Alarms | cảnh báo khi vượt ngưỡng | | CloudWatch Logs | hàm đã ghi gì — nguồn gỡ lỗi chính | | X-Ray | request chậm ở chặng nào | | Lambda Insights | metric hệ thống chi tiết |

Ba alarm nên có cho mọi hàm production:

1. Tỷ lệ Errors vượt ngưỡng (dùng metric math, không dùng số tuyệt đối)
2. Throttles > 0 — đang chạm trần concurrency
3. Duration p99 gần chạm timeout — sắp bị cắt giữa chừng

Đáp án

D — Dùng lệnh aws logs associate-kms-key và chỉ định ARN của KMS key.

Vì sao đúng

Điểm mấu chốt: log group đã tồn tại 3 tháng. Nên không thể dùng lệnh tạo mới, và cũng không có nút bật trong Console.

associate-kms-key là lệnh dành riêng cho việc gắn CMK vào một log group đã có:

aws logs associate-kms-key \
  --log-group-name /ung-dung/log-quan-trong \
  --kms-key-id arn:aws:kms:ap-southeast-1:123456789012:key/xxxx

Và có một đặc tính quan trọng cần nêu rõ: mã hoá chỉ áp dụng cho dữ liệu ghi vào TỪ THỜI ĐIỂM NÀY TRỞ ĐI. Log đã có từ trước vẫn không được mã hoá — CloudWatch không mã hoá lại dữ liệu cũ.

Điều này khớp đúng với đề: "so any future data can be encrypted".

Điều kiện bắt buộc: key policy phải cho phép dịch vụ CloudWatch Logs dùng khoá:

{
  "Effect": "Allow",
  "Principal": {"Service": "logs.ap-southeast-1.amazonaws.com"},
  "Action": ["kms:Encrypt*", "kms:Decrypt*", "kms:ReEncrypt*",
             "kms:GenerateDataKey*", "kms:Describe*"],
  "Resource": "*"
}

Thiếu vế này thì lệnh thất bại, hoặc tệ hơn: log ngừng được ghi.

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

• B. create-log-group với KMS key ARN — chỉ dùng cho log group MỚI. Log group trong đề đã tồn tại 3 tháng, nên lệnh này sẽ báo ResourceAlreadyExistsException.
• C. "Bật tính năng encrypt trên Console" — Console không có nút này. Việc gắn KMS key cho log group chỉ làm được qua CLI, SDK hoặc CloudFormation.
• A. describe-log-groups với KMS key ARN — lệnh chỉ đọc: nó liệt kê thông tin log group. Nó không thay đổi gì cả.

Ghi nhớ

Ba lệnh liên quan tới mã hoá log group: | Lệnh | Dùng khi | |---|---| | create-log-group --kms-key-id | tạo mới kèm mã hoá | | associate-kms-key | gắn khoá vào log group ĐÃ CÓ | | disassociate-kms-key | gỡ khoá (dữ liệu cũ vẫn mã hoá) |

Và ba lưu ý vận hành:

• Log cũ không được mã hoá lại — chỉ áp cho dữ liệu mới
• Xoá KMS key sẽ khiến không đọc được log đã mã hoá bằng nó
• Luôn kiểm key policy trước khi gắn, nếu không log có thể ngừng ghi mà không có cảnh báo rõ ràng

Đáp án

D — 'x-amz-server-side-encryption': 'aws:kms'

Vì sao đúng

Header x-amz-server-side-encryption chỉ nhận một tập giá trị cố định, và mỗi giá trị ứng với một cơ chế mã hoá:

Đề nói rõ đang dùng SSE-KMS, nên giá trị đúng là aws:kms.

Với SSE-KMS, thường khai thêm khoá cụ thể:

PutObjectRequest req = PutObjectRequest.builder()
    .bucket("kho-du-lieu").key("tep.json")
    .serverSideEncryption(ServerSideEncryption.AWS_KMS)
    .ssekmsKeyId("arn:aws:kms:ap-southeast-1:123456789012:key/xxxx")
    .build();

Về vế "permission errors" trong đề — đây là chi tiết đáng nêu: với SSE-KMS, ngoài quyền S3 còn cần quyền KMS:

{"Effect": "Allow",
 "Action": ["kms:GenerateDataKey", "kms:Decrypt"],
 "Resource": "arn:aws:kms:...:key/xxxx"}

Thiếu kms:GenerateDataKey là nguyên nhân số một của AccessDenied khi ghi vào bucket SSE-KMS — và S3 không nhắc gì tới KMS trong thông báo lỗi.

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

• C. AES256 — đây là giá trị của SSE-S3, không phải SSE-KMS. Gửi nó thì object được mã hoá bằng khoá do S3 quản lý, không phải CMK của bạn.
• A. SSE-S3 và B. SSE-KMS — cả hai đều không phải giá trị hợp lệ. Đây là tên gọi của cơ chế trong tài liệu, không phải giá trị header. S3 sẽ từ chối với lỗi tham số không hợp lệ.

Ghi nhớ

Ba cơ chế server-side encryption của S3: | | SSE-S3 | SSE-KMS | SSE-C | |---|---|---|---| | Header | AES256 | aws:kms | x-amz-server-side-encryption-customer-* | | Ai giữ khoá | AWS | bạn, qua KMS | bạn hoàn toàn | | Vết CloudTrail cho khoá | ❌ | ✅ | ❌ | | Bắt buộc HTTPS | ❌ | ❌ | ✅ |

Và mẹo chẩn đoán: gặp AccessDenied khi PutObject mà quyền S3 nhìn có vẻ đủ ⇒ kiểm tra ngay xem bucket có SSE-KMS không, và policy có kms:GenerateDataKey chưa.

Đáp án

B — 'x-amz-server-side-encryption': 'AES256'

Vì sao đúng

Đề yêu cầu mã hoá bằng SSE-S3 — khoá do chính S3 quản lý — và giá trị header tương ứng là AES256:

s3.put_object(
    Bucket='kho-du-lieu',
    Key='tep.json',
    Body=noi_dung,
    ServerSideEncryption='AES256'      # SSE-S3
)

Bảng giá trị hợp lệ của header x-amz-server-side-encryption: | Cơ chế | Giá trị | |---|---| | SSE-S3 | AES256 | | SSE-KMS | aws:kms | | SSE-KMS DSSE | aws:kms:dsse |

SSE-S3 là lựa chọn đơn giản nhất: khoá hoàn toàn do S3 quản lý và xoay vòng, không tốn thêm chi phí, và không cần quyền KMS nào. Đổi lại là không có kiểm soát và không có vết CloudTrail cho từng lần dùng khoá.

Muốn bắt buộc mọi upload phải có header này, dùng bucket policy:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::kho-du-lieu/*",
  "Condition": {
    "StringNotEquals": {"s3:x-amz-server-side-encryption": "AES256"}
  }
}

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

• D. aws:kms — giá trị của SSE-KMS, dùng CMK trong KMS. Đề chỉ định rõ SSE-S3.
• A. SSE-S3 và C. SSE-KMS — cả hai đều không phải giá trị hợp lệ. Đây là tên gọi của cơ chế, không phải giá trị header. S3 từ chối với lỗi tham số.

Ghi nhớ

Câu này và #5260 là một cặp đối xứng — cùng một header, hai cơ chế khác nhau: | Đề nói | Giá trị | |---|---| | SSE-S3 | AES256 | | SSE-KMS | aws:kms |

Ghi chú thời sự đáng biết: từ đầu 2023, S3 mã hoá mặc định bằng SSE-S3 cho mọi object mới — nên về mặt kỹ thuật, object đã được mã hoá kể cả khi không gửi header. Nhưng bucket policy dạng deny vẫn cần khi phải chứng minh cho kiểm toán rằng không upload nào lách được, hoặc khi muốn bắt buộc dùng SSE-KMS thay vì SSE-S3.

Đáp án

D — Có, kích thước message tối đa là 256 KB.

Vì sao đúng

Giới hạn của SQS là 256 KB (262.144 byte) cho mỗi message. Message trong đề nằm trong khoảng 20 KB đến 200 KB — nên hoàn toàn nằm trong giới hạn.

Vài chi tiết quan trọng về giới hạn này:

Điểm thứ ba đáng lưu ý trong thực tế: nếu message của bạn 200 KB, bạn không gộp được 2 message vào một batch — tổng sẽ vượt 256 KB.

Nếu payload có thể vượt 256 KB trong tương lai, giải pháp là SQS Extended Client Library — nó cất payload lớn trên S3 và chỉ đưa con trỏ vào hàng đợi, nâng giới hạn lên 2 GB.

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

• A. 512 KB — không phải giới hạn của SQS. (Đó là giới hạn payload của SNS cho một số trường hợp, hoặc kích thước /tmp mặc định của Lambda — dễ nhớ nhầm.)
• B. 64 KB và C. 128 KB — cả hai đều thấp hơn giới hạn thật, và nếu đúng thì message 200 KB trong đề đã không gửi được.

Ghi nhớ

Bảng giới hạn của SQS — nên thuộc: | Giới hạn | Giá trị | |---|---| | Kích thước message | 256 KB | | Số message trong queue | không giới hạn | | Message in-flight (standard) | 120.000 | | Message in-flight (FIFO) | 20.000 | | Thời gian giữ | 60 giây – 14 ngày (mặc định 4 ngày) | | Visibility timeout | 0 – 12 giờ | | Delay | 0 – 15 phút | | Long polling | tối đa 20 giây | | Batch | tối đa 10 message |

Và bảng giới hạn payload của các dịch vụ hay bị nhầm với nhau: | Dịch vụ | Payload tối đa | |---|---| | SQS | 256 KB | | SNS | 256 KB | | Kinesis Data Streams | 1 MB mỗi bản ghi | | Lambda (đồng bộ) | 6 MB | | Lambda (bất đồng bộ) | 256 KB |

Đáp án

A — Dùng parallel scan.

Vì sao đúng

Bối cảnh: bảng 25 GB, không tạo index được, và cần lấy dữ liệu nhanh nhất có thể.

Vấn đề của Scan thường: nó tuần tự và đơn luồng. DynamoDB đọc từng phần bảng, trả về tối đa 1 MB mỗi lần gọi, rồi bạn phải lặp với LastEvaluatedKey. Với 25 GB, đó là hàng nghìn lời gọi nối đuôi nhau.

Parallel scan chia bảng thành nhiều segment logic và quét chúng đồng thời:

def quet_segment(so_hieu, tong_segment):
    kq = []
    khoa_cuoi = None
    while True:
        tham_so = {'TableName': 'du-lieu',
                   'Segment': so_hieu, 'TotalSegments': tong_segment}
        if khoa_cuoi: tham_so['ExclusiveStartKey'] = khoa_cuoi
        r = dynamodb.scan(**tham_so)
        kq.extend(r['Items'])
        khoa_cuoi = r.get('LastEvaluatedKey')
        if not khoa_cuoi: break
    return kq

# Chạy 8 luồng song song
with ThreadPoolExecutor(max_workers=8) as pool:
    ket_qua = list(pool.map(lambda i: quet_segment(i, 8), range(8)))

Với 8 segment, thời gian giảm gần 8 lần. Đánh đổi: tiêu thụ RCU cũng tăng tương ứng, nên phải đảm bảo bảng có đủ throughput hoặc dùng on-demand mode.

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

• B. FilterExpression — đây là hiểu nhầm quan trọng nhất về DynamoDB: filter được áp SAU KHI đọc dữ liệu. Bạn vẫn đọc và trả tiền cho toàn bộ 25 GB, chỉ là bớt dữ liệu trả về qua mạng. Nó không làm scan nhanh hơn.
• C. ProjectionExpression — chỉ giới hạn những thuộc tính được trả về. Giảm băng thông mạng một chút, nhưng DynamoDB vẫn đọc toàn bộ item, nên RCU và thời gian scan gần như không đổi.
• D. Dùng Query — Query nhanh hơn Scan rất nhiều, nhưng nó đòi biết partition key. Đề nói rõ không tạo index được và không truy xuất theo cách dự đoán được — nên không có khoá nào để query.

Ghi nhớ

Ba điều cần nhớ về Scan:

1. FilterExpression không giảm RCU — lọc sau khi đọc
2. Parallel scan tăng tốc nhưng cũng tăng RCU tương ứng
3. Luôn ưu tiên thiết kế lại khoá hoặc thêm GSI hơn là scan — scan chỉ nên là phương án cuối

Đáp án

C — 24 RCU.

Vì sao đúng

Phép tính RCU của DynamoDB có ba bước, và cả ba đều có chỗ dễ sai:

Bước 1 — làm tròn kích thước item lên bội số của 4 KB:

12 KB → đã là bội số của 4 → 12 KB (= 3 đơn vị 4 KB)

Bước 2 — tính RCU cho một lần đọc: | Loại đọc | Quy tắc | |---|---| | Strongly consistent | 1 RCU cho mỗi 4 KB | | Eventually consistent | 0,5 RCU cho mỗi 4 KB |

Đề nói rõ "không lo dữ liệu cũ" ⇒ eventually consistent:

3 đơn vị × 0,5 RCU = 1,5 RCU cho mỗi lần đọc

Bước 3 — nhân với số lần đọc mỗi giây:

1,5 RCU × 16 lần/giây = 24 RCU

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

• D. 48 — kết quả nếu tính strongly consistent (3 × 1 × 16 = 48). Bỏ qua manh mối "not concerned about receiving stale data".
• A. 12 — có lẽ do chia 48 cho 4, hoặc nhầm ở bước làm tròn.
• B. 192 — nhầm sang cách tính hoàn toàn khác, có thể do dùng 12 KB × 16 rồi chia sai.

Ghi nhớ

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

RCU — làm tròn lên bội số 4 KB:

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

WCU — làm tròn lên bội số 1 KB:

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

Ba điểm dễ sai nhất:

1. RCU dùng 4 KB, WCU dùng 1 KB — hai con số khác nhau
2. Luôn làm tròn LÊN — item 4,1 KB tốn như item 8 KB
3. Eventually consistent rẻ một nửa — luôn tìm manh mối "stale data is acceptable" trong đề

(Với chế độ on-demand, bạn không phải tính RCU/WCU — DynamoDB tự co giãn. Nhưng công thức này vẫn cần cho chế độ provisioned và cho đề thi.)

Đáp án

A và C.

• A — Path-based routing — cho smart.com/api và smart.com/mobile.
• C — Host-based routing — cho api.smart.com và mobile.smart.com.

Vì sao đúng

Đề mô tả hai đề xuất khác nhau, và mỗi đề xuất ứng với một kiểu định tuyến của ALB:

A — path-based (đề xuất của Developer chính):

smart.com/api    → target group API
smart.com/mobile → target group Mobile

Rule khớp theo đường dẫn trong URL:

{"Conditions": [{"Field": "path-pattern", "Values": ["/api/*"]}],
 "Actions": [{"Type": "forward", "TargetGroupArn": "...tg-api"}]}

C — host-based (đề xuất của lập trình viên kia):

api.smart.com    → target group API
mobile.smart.com → target group Mobile

Rule khớp theo tên miền trong header Host:

{"Conditions": [{"Field": "host-header", "Values": ["api.smart.com"]}],
 "Actions": [{"Type": "forward", "TargetGroupArn": "...tg-api"}]}

Cả hai đều hợp lệ và đều được ALB hỗ trợ — đó là lý do câu hỏi có hai đáp án. Khác biệt thực tế: host-based cần thêm bản ghi DNS và chứng chỉ SSL bao được các tên miền con (wildcard hoặc SAN), còn path-based thì không.

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

• B. "Phiên bản trình duyệt web" — ALB không có điều kiện định tuyến theo phiên bản trình duyệt. Nó có http-header để khớp header bất kỳ (kể cả User-Agent), nhưng đó là khớp chuỗi thô, không phải hiểu phiên bản.
• D. "Client IP" — ALB có điều kiện source-ip để khớp dải CIDR. Nhưng nó không liên quan gì tới hai đề xuất trong đề, vốn phân biệt theo loại thiết bị, không theo IP.
• E. "Giá trị cookie" — ALB không định tuyến theo giá trị cookie. Cookie chỉ được ALB dùng cho sticky session (AWSALB), không phải làm điều kiện rule.

Ghi nhớ

Năm điều kiện định tuyến của ALB — danh sách đầy đủ: | Điều kiện | Khớp theo | |---|---| | host-header | tên miền | | path-pattern | đường dẫn URL | | http-header | header HTTP bất kỳ | | http-request-method | GET, POST, PUT… | | query-string | tham số truy vấn | | source-ip | dải CIDR của client |

Kết hợp được nhiều điều kiện trong một rule, và mỗi rule có priority quyết định thứ tự đánh giá.

Nhớ nhanh: /api ⇒ path-based; api. ⇒ host-based. Cả hai là tính năng cơ bản của ALB và không có ở NLB.