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

Đáp án

D — Tạo một Alias trỏ tới version mới nhất.

Vì sao đúng

Vấn đề: mỗi lần publish, Lambda tạo ra một version mới với ARN mới:

arn:aws:lambda:...:function:xu-ly:1
arn:aws:lambda:...:function:xu-ly:2
arn:aws:lambda:...:function:xu-ly:3    ← ARN đổi ở mỗi lần publish

Nếu ứng dụng trỏ thẳng vào version, nó phải sửa mã ở mỗi lần phát hành.

Alias là con trỏ có tên, cập nhật được — và nó có ARN cố định:

arn:aws:lambda:...:function:xu-ly:prod    ← KHÔNG BAO GIỜ ĐỔI

Quy trình phát hành chỉ còn hai bước, và ứng dụng không đụng tới:

version=$(aws lambda publish-version --function-name xu-ly --query Version --output text)
aws lambda update-alias --function-name xu-ly --name prod --function-version $version

Đây đúng là điều đề yêu cầu: một ARN tĩnh luôn trỏ tới version mới nhất đã publish.

Alias còn hỗ trợ weighted routing cho canary — chuyển dần traffic sang version mới:

aws lambda update-alias --function-name xu-ly --name prod \
  --function-version 3 --routing-config '{"AdditionalVersionWeights": {"2": 0.9}}'
# 10% sang version 3, 90% ở lại version 2

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

• C. Dùng unqualified ARN — đây là bẫy tinh vi nhất. Unqualified ARN (không có phần :version hay :alias ở cuối) trỏ tới $LATEST, chứ không phải version mới nhất đã publish:

  arn:aws:lambda:...:function:xu-ly    → $LATEST
  

  $LATEST là bản đang sửa, thay đổi ngay khi bạn cập nhật mã — kể cả khi chưa publish. Dùng nó cho production nghĩa là mọi thay đổi lập tức lên production, không có kiểm soát phiên bản nào. AWS khuyến nghị rõ: đừng trỏ production vào $LATEST.
• B. "Publish một version có thể thay đổi được, trỏ tới $LATEST" — tự mâu thuẫn: version trong Lambda là BẤT BIẾN theo định nghĩa. Không có khái niệm "mutable version".
• A. Route 53 alias record trỏ tới version — Route 53 định tuyến theo DNS tới endpoint mạng, mà Lambda version không có endpoint DNS riêng. Nó không tham chiếu được ARN của Lambda.

Ghi nhớ

Ba loại ARN của Lambda:

arn:...:function:xu-ly          → unqualified, trỏ $LATEST
arn:...:function:xu-ly:3        → qualified bằng VERSION
arn:...:function:xu-ly:prod     → qualified bằng ALIAS   ← nên dùng

Mẫu thực hành tốt:

$LATEST                    ← nơi phát triển
version 1, 2, 3, 4, 5      ← bất biến
alias "dev"   → $LATEST
alias "test"  → version 5
alias "prod"  → version 4

Ba lưu ý quan trọng khi dùng alias:

1. Cấp quyền cho từng alias, không cấp chung chung — thiếu qualifier là API Gateway trả 500 không nói gì:

   aws lambda add-permission --function-name xu-ly --qualifier prod \
     --statement-id ApiGatewayInvoke --action lambda:InvokeFunction \
     --principal apigateway.amazonaws.com
   

2. Provisioned concurrency chỉ đặt được trên alias hoặc version, không đặt trên $LATEST — nên muốn loại bỏ cold start cho production thì buộc phải dùng alias.
3. CloudWatch metric tách riêng theo version, nên so sánh được tỷ lệ lỗi giữa bản cũ và bản mới khi canary.

Nguyên tắc chung: mọi thứ trỏ tới Lambda trong production đều nên trỏ vào alias.

Đáp án

D — Message bị ẩn trong một khoảng thời gian cấu hình được NGAY KHI vừa được thêm vào hàng đợi.

Vì sao đúng

Delay queue hoãn việc message xuất hiện lần đầu: message đã nằm trong hàng đợi nhưng consumer không nhìn thấy cho tới khi hết DelaySeconds.

0s   SendMessage → message vào hàng đợi nhưng BỊ ẨN
     ...
30s  hết DelaySeconds → message HIỆN RA, consumer nhận được

Cấu hình ở hai mức:

# Mức hàng đợi — áp cho MỌI message mới
aws sqs set-queue-attributes --queue-url <url> --attributes DelaySeconds=30

# Mức từng message — chỉ với standard queue
aws sqs send-message --queue-url <url> --message-body "..." --delay-seconds 60

Phạm vi: 0 đến 900 giây (15 phút).

Vài tình huống thực tế cần delay queue: | Tình huống | Vì sao cần hoãn | |---|---| | Chờ giao dịch CSDL commit xong | consumer đọc phải dữ liệu chưa có | | Cho người dùng thời gian huỷ đơn | hoãn 60 giây trước khi xử lý | | Chờ hệ thống downstream sẵn sàng | tránh gọi khi nó chưa kịp cập nhật |

(Lưu ý về FIFO queue: nó không hỗ trợ delay ở mức từng message — chỉ đặt được DelaySeconds ở mức hàng đợi.)

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

• B. Message bị ẩn một khoảng thời gian SAU KHI được consume — đây là mô tả của VisibilityTimeout, không phải delay queue. Khác biệt cốt lõi:

  DelaySeconds      → ẩn khi message MỚI ĐƯỢC THÊM VÀO
  VisibilityTimeout → ẩn khi message ĐÃ ĐƯỢC NHẬN
  

  Đây là bẫy chính của câu hỏi.
• A. Consumer có thể chờ một khoảng thời gian trước khi nhận message — đây là mô tả của long polling (WaitTimeSeconds), một tham số của lời gọi ReceiveMessage.
• C. Message không thể xoá trong một khoảng thời gian sau khi consume — không có cơ chế nào như vậy trong SQS. Message xoá được bất cứ lúc nào bằng DeleteMessage với receipt handle hợp lệ.

Ghi nhớ

Bốn tham số thời gian của SQS — phân biệt cho rõ vì chúng rất hay bị lẫn: | Tham số | Áp cho | Việc | Phạm vi | |---|---|---|---| | DelaySeconds | message MỚI | ẩn lần xuất hiện đầu | 0 – 15 phút | | VisibilityTimeout | message ĐÃ nhận | ẩn trong lúc xử lý | 0 – 12 giờ | | WaitTimeSeconds | lời gọi nhận | long polling | 0 – 20 giây | | MessageRetentionPeriod | mọi message | giữ bao lâu | 60 giây – 14 ngày |

Cách nhớ nhanh bằng dòng thời gian của một message:

SendMessage
   ↓ [DelaySeconds] ẩn lần đầu
Hiện ra trong hàng đợi
   ↓ ReceiveMessage (có thể chờ [WaitTimeSeconds] nếu rỗng)
Được nhận
   ↓ [VisibilityTimeout] ẩn khỏi consumer khác
DeleteMessage → biến mất
   (nếu không xoá → hiện lại; quá [MessageRetentionPeriod] → tự xoá)

Phân biệt delay queue và timer ở mức message: | | Queue-level DelaySeconds | Message-level DelaySeconds | |---|---|---| | Áp cho | mọi message mới | từng message riêng | | FIFO queue | ✅ | ❌ không hỗ trợ |

Và nếu cần hoãn lâu hơn 15 phút, delay queue không đủ — hãy dùng EventBridge Scheduler với biểu thức at() để lên lịch một lần, hoặc Step Functions với Wait state (chờ tới 1 năm).

Đáp án

C — Gọi API ReceiveMessage với tham số WaitTimeSeconds đặt thành 20.

Vì sao đúng

Đề mô tả chính xác triệu chứng của short polling: consumer kết nối theo chu kỳ ngắn, hàng đợi thường không trả về message nào, và chi phí API tăng.

Đặt WaitTimeSeconds lớn hơn 0 là bật long polling — và 20 giây là giá trị tối đa:

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

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

Vì SQS tính tiền theo số request API, hiệu quả rất trực tiếp:

Consumer hỏi liên tục, hàng đợi rỗng:
  short polling → khoảng 3.600 request/giờ
  long polling  → khoảng   180 request/giờ   ← giảm 95%

Dòng cuối của bảng là lợi ích í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. Đó cũng chính là hiện tượng "queue often does not return messages" mà đề nêu.

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

• A. ReceiveMessage với VisibilityTimeout = 30 — quyết định message bị ẩn bao lâu SAU KHI được nhận, để tránh xử lý trùng. Không liên quan tới số lần hỏi hàng đợi hay chi phí API.
• D. SetQueueAttributes với DelaySeconds = 900 — hoãn message MỚI trước khi nó xuất hiện lần đầu. Nó làm chậm việc xử lý tới 15 phút và không giảm request nào.
• B. SetQueueAttributes với maxReceiveCount = 20 — maxReceiveCount là tham số của redrive policy (dead-letter queue): message hỏng bao nhiêu lần thì chuyển sang DLQ. Không liên quan tới polling.

Ghi nhớ

Hai cách bật long polling:

# Mặc định cho cả hàng đợi
aws sqs set-queue-attributes --queue-url <url> \
  --attributes ReceiveMessageWaitTimeSeconds=20

# Hoặc cho từng lời gọi
aws sqs receive-message --queue-url <url> --wait-time-seconds 20

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 là kết hợp hai tham số:

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

Chúng giải quyết hai vấn đề khác nhau:

• WaitTimeSeconds giảm request rỗng khi hàng đợi trống
• MaxNumberOfMessages giảm số lần gọi khi hàng đợi có nhiều message (10 message một lần thay vì 1)

Long polling thắng ở mọi tiêu chí — rẻ hơn, độ trễ thấp hơn, ít phản hồi rỗng hơn. Đó là lý do AWS khuyến nghị luôn bật nó, và cũng là lý do không có tình huống thực tế nào nên dùng short polling.

Và nếu dùng SQS làm event source cho Lambda, Lambda tự dùng long polling — bạn không phải cấu hình gì.

Đáp án

C — AWS Step Functions.

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: dịch vụ điều phối nhiều dịch vụ AWS thành workflow serverless. Đó là định nghĩa của Step Functions.

Nó cho phép khai luồng nghiệp vụ dưới dạng máy trạng thái khai báo, thay vì mã điều phối tự viết:

{
  "StartAt": "CapNhatHeThong",
  "States": {
    "CapNhatHeThong": {
      "Type": "Task",
      "Resource": "arn:aws:states:::aws-sdk:ssm:sendCommand",
      "Retry": [{"ErrorEquals": ["States.ALL"], "MaxAttempts": 3, "BackoffRate": 2.0}],
      "Next": "ChoHoanTat"
    },
    "ChoHoanTat": {"Type": "Wait", "Seconds": 300, "Next": "KiemTraKetQua"},
    "KiemTraKetQua": {
      "Type": "Choice",
      "Choices": [{"Variable": "$.trangThai", "StringEquals": "Success", "Next": "BaoThanhCong"}],
      "Default": "BaoLoi"
    },
    "BaoThanhCong": {"Type": "Succeed"},
    "BaoLoi": {"Type": "Fail"}
  }
}

Những gì bạn từng phải tự viết, Step Functions làm sẵn: | Việc | Cơ chế | |---|---| | 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 — tới 1 năm | | 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 |

Và với các tác vụ vận hành như đề mô tả, AWS SDK integrations đặc biệt mạnh: Task gọi thẳng hơn 200 dịch vụ AWS — chạy lệnh SSM, khởi chạy EC2, gửi SNS — mà không cần Lambda trung gian nào.

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

• D. Amazon SWF — tiền thân của Step Functions, cũng điều phối workflow. Nhưng nó đòi bạn tự chạy decider và worker (không serverless), dùng SDK phức tạp hơn, và AWS đã khuyến nghị dùng Step Functions cho mọi workflow mới từ lâu.
• A. AWS Lambda — dịch vụ tính toán, nó là thành phần được điều phối, không phải bộ điều phối. Dùng Lambda gọi Lambda chính là "legacy custom code" mà đề đang muốn thay thế.
• B. AWS Batch — chạy công việc tính toán theo lô (mô phỏng khoa học, xử lý dữ liệu lớn) trên EC2 hoặc Fargate. Nó quản lý hàng đợi công việc và tài nguyên tính toán, không điều phối nhiều dịch vụ AWS.

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, SDK integration…) | | Choice | rẽ nhánh theo điều kiện | | Parallel | nhiều NHÁNH KHÁC NHAU đồng thời | | Map | 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 |

Với tác vụ vận hành định kỳ như đề mô tả (thường chạy vài phút tới vài giờ, cần kiểm toán), Standard workflow là lựa chọn đúng.

Nhận dạng nhanh: đề nói "coordinate multiple AWS services", "workflow", "state machine", "orchestration" ⇒ Step Functions.

Và một mẫu rất hay dùng cho tự động hoá vận hành: EventBridge Scheduler kích hoạt Step Functions theo lịch, thay cho cron job trên một máy chủ nào đó.

Đáp án

C — Execution role của hàm thiếu quyền ghi log vào CloudWatch Logs.

Vì sao đúng

Lambda ghi log bằng chính execution role của hàm. Nếu role đó thiếu quyền, việc ghi log thất bại — nhưng thất bại âm thầm: nó không làm hàm lỗi, không có thông báo nào, và bạn chỉ thấy CloudWatch trống rỗng.

Quyền tối thiểu cần có:

{
  "Effect": "Allow",
  "Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"],
  "Resource": "arn:aws:logs:*:*:*"
}

Cách sửa nhanh nhất là gắn managed policy có sẵn:

aws iam attach-role-policy --role-name RoleHamCuaToi \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

AWSLambdaBasicExecutionRole chính là policy chứa đúng ba quyền trên — và nó được gắn tự động khi tạo hàm qua Console. Vấn đề này thường xuất hiện khi hàm được tạo bằng CloudFormation, CDK hay Terraform với role tự khai mà quên phần log.

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

• B. Hàm không có câu lệnh log tường minh nào — đây là phương án đáng cân nhắc, nhưng nó không giải thích được toàn bộ triệu chứng: kể cả khi mã không hề gọi print hay logger, Lambda vẫn luôn ghi ba dòng hệ thống cho mỗi lần chạy:

  START RequestId: abc-123 Version: $LATEST
  END RequestId: abc-123
  REPORT RequestId: abc-123  Duration: 12.34 ms  Billed Duration: 13 ms  Memory Size: 128 MB
  

  Đề nói không tìm thấy dữ liệu log nào — nên ngay cả ba dòng này cũng không tới được, và đó chỉ có thể là vấn đề quyền.
• A. Hàm thiếu CloudWatch Logs làm source trigger — hiểu ngược chiều: CloudWatch Logs là ĐÍCH ĐẾN của log, không phải nguồn kích hoạt hàm. (CloudWatch Logs có thể làm trigger cho Lambda qua subscription filter, nhưng đó là kịch bản hoàn toàn khác — xử lý log, không phải ghi log.)
• D. Hàm thiếu log group đích — Lambda TỰ TẠO log group ở lần chạy đầu tiên (tên /aws/lambda/<ten-ham>) — với điều kiện role có quyền CreateLogGroup. Nên nếu thiếu, nguyên nhân gốc vẫn quay về quyền.

Ghi nhớ

Ba dòng log hệ thống là manh mối chẩn đoán rất hữu ích: | Quan sát | Kết luận | |---|---| | Không có dòng nào | thiếu quyền ghi log | | Có START/END/REPORT nhưng thiếu log của bạn | mã không ghi log, hoặc sai mức log | | Có log nhưng thiếu vài lần gọi | có thể bị throttle ở CloudWatch Logs |

Danh sách kiểm khi Lambda không có log:

1. Execution role có AWSLambdaBasicExecutionRole chưa? ← nguyên nhân phổ biến nhất
2. Có SCP hoặc permissions boundary nào chặn logs:* không?
3. Log group có bị đặt retention quá ngắn khiến log đã bị xoá?
4. Đang xem đúng Region chứ?

Các managed policy hay dùng cho Lambda: | Policy | Thêm quyền | |---|---| | AWSLambdaBasicExecutionRole | log CloudWatch | | AWSLambdaVPCAccessExecutionRole | log + tạo/xoá ENI trong VPC | | AWSLambdaDynamoDBExecutionRole | log + đọc DynamoDB Streams | | AWSLambdaSQSQueueExecutionRole | log + đọc SQS |

Ba policy cuối đã bao gồm quyền log — nên gắn một trong số chúng là đủ.

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

aws logs put-retention-policy --log-group-name /aws/lambda/xu-ly --retention-in-days 30

Đáp án

A và E.

• A — Kiểm tra IAM role gắn vào EC2 instance xem có đủ quyền truy cập bucket không
• E — Kiểm tra bucket policy xem có cho phép truy cập từ các EC2 instance không

Vì sao đúng

Truy cập S3 từ EC2 được quyết định bởi hai lớp policy, và cả hai đều phải cho phép:

EC2 instance (có IAM role)
     ↓  ① IAM policy của role: "tôi được phép làm gì?"
   S3 API
     ↓  ② Bucket policy: "ai được phép chạm vào bucket này?"
   Object

A — kiểm tra IAM role (identity-based policy):

aws sts get-caller-identity                    # đang là danh tính nào?
aws iam list-attached-role-policies --role-name RoleEC2

Quyền cần có:

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::kho-du-lieu/*"}

E — kiểm tra bucket policy (resource-based policy):

aws s3api get-bucket-policy --bucket kho-du-lieu

Đặc biệt để ý các statement Deny — vì Deny tường minh thắng mọi Allow, một điều kiện chặt (ví dụ chỉ cho phép từ một VPC endpoint cụ thể) có thể chặn instance của bạn dù IAM role hoàn toàn đúng.

Quy tắc đánh giá: cần ít nhất một Allow và không có Deny nào ở cả hai lớp.

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

• D. Kiểm tra security group xem có inbound rule phù hợp không — sai hai chỗ. Thứ nhất, S3 là dịch vụ công khai, không nằm trong VPC — không có "kết nối vào" nào để mở inbound. Thứ hai, nếu có vấn đề mạng thì đó là OUTBOUND từ EC2 đi ra (mà security group mặc định cho phép hết outbound).
• B. Kiểm tra VPC peering để đảm bảo bucket S3 tới được — VPC peering nối hai VPC với nhau. S3 không nằm trong VPC nào, nên peering hoàn toàn không liên quan. (Thứ có liên quan là VPC endpoint cho S3 nếu instance nằm trong private subnet không có NAT — nhưng đó là khái niệm khác hẳn peering.)
• C. Đặt bucket thành công khai để EC2 truy cập được — sai lầm bảo mật nghiêm trọng: mở bucket ra Internet để giải quyết một vấn đề phân quyền nội bộ. Cách đúng là sửa IAM role hoặc bucket policy.

Ghi nhớ

Danh sách kiểm khi EC2 không truy cập được S3, theo thứ tự: | Bước | Kiểm tra | |---|---| | 1 | aws sts get-caller-identity — đang dùng danh tính nào? | | 2 | IAM policy của role có Allow không? | | 3 | Bucket policy có Deny nào chặn không? | | 4 | SCP của tổ chức có chặn không? | | 5 | Đường mạng: private subnet có NAT hoặc VPC endpoint cho S3 chưa? | | 6 | Bucket có ở đúng Region đang gọi không? |

Bước 1 rất hay lộ ra nguyên nhân thật: nhiều lỗi AccessDenied hoá ra là do access key cũ trong biến môi trường được SDK ưu tiên trước instance role — chuỗi tìm credential đặt instance profile cuối cùng.

Hai lớp policy và khả năng chéo tài khoản: | | Identity-based (IAM policy) | Resource-based (bucket policy) | |---|---|---| | Gắn vào | role, user, group | bucket | | Có Principal | ❌ | ✅ bắt buộc | | Trả lời câu hỏi | "tôi được làm gì?" | "ai được chạm vào tôi?" |

Và với instance trong private subnet, có hai cách ra tới S3: | Cách | Đặc điểm | |---|---| | NAT Gateway | đi qua Internet, có phí theo GB | | VPC Gateway Endpoint cho S3 | đi qua mạng AWS, MIỄN PHÍ |

Gateway endpoint là lựa chọn nên dùng — vừa rẻ hơn vừa an toàn hơn, và còn cho phép thắt chặt bucket policy theo aws:SourceVpce.

Đáp án

C — Dùng BatchGetItem.

Vì sao đúng

Đề nêu ba dữ kiện, và chúng khớp chính xác với BatchGetItem:

1. Đọc tối đa 100 item mỗi lần
2. Mỗi item tối đa 100 KB
3. Giảm thiểu độ trễ

BatchGetItem gom nhiều thao tác GetItem vào một request duy nhất — kể cả trên nhiều bảng:

response = dynamodb.batch_get_item(
    RequestItems={
        'san-pham': {
            'Keys': [{'id': {'S': 'SP-001'}}, {'id': {'S': 'SP-002'}}, ...]
        }
    }
)

Vì sao nó cho độ trễ thấp nhất:

100 lần GetItem riêng lẻ → 100 lần đi mạng, độ trễ cộng dồn
1 lần BatchGetItem       → 1 lần đi mạng, DynamoDB xử lý SONG SONG bên trong

Và các con số trong đề khớp vừa vặn với giới hạn: | Giới hạn | Giá trị | Đề bài | |---|---|---| | Số item mỗi lời gọi | 100 | đúng 100 ✓ | | Kích thước trả về | 16 MB | 100 × 100 KB = 10 MB ✓ |

Nhưng phải xử lý UnprocessedKeys — BatchGetItem không đảm bảo lấy được hết:

while response.get('UnprocessedKeys'):
    response = dynamodb.batch_get_item(RequestItems=response['UnprocessedKeys'])

Bỏ qua trường này nghĩa là ứng dụng thỉnh thoảng thiếu dữ liệu mà không có lỗi nào.

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

• D. Dùng GetItem với projection expression — GetItem lấy một item mỗi lần, nên cần 100 lần đi mạng — độ trễ cao nhất. Và ProjectionExpression mâu thuẫn với đề: đề nói "all attributes must be retrieved", còn projection dùng để lấy bớt thuộc tính.
• B. Dùng Scan với phân trang — Scan đọc TOÀN BỘ bảng rồi mới lọc, tốn RCU cho mọi item dù bạn chỉ cần 100 cái. Vừa chậm vừa đắt, và phân trang còn thêm nhiều lần đi mạng.
• A. Dùng Query với FilterExpression — Query chỉ hợp khi cần nhiều item CÙNG partition key. Ở đây ta biết chính xác từng item cần lấy. Ngoài ra FilterExpression không giảm RCU — nó lọc sau khi dữ liệu đã được đọc và tính tiền.

Ghi nhớ

Bốn cách đọc dữ liệu, theo hiệu quả giảm dần: | Thao tác | Dùng khi | Số lần đi mạng | |---|---|---| | GetItem | biết khoá của một item | 1 | | BatchGetItem | biết khoá của NHIỀU item | 1 cho tới 100 item | | Query | nhiều item cùng partition key | 1 mỗi trang | | Scan | không có lựa chọn nào khác | nhiều, và đắt |

So sánh hai API batch: | | BatchGetItem | BatchWriteItem | |---|---|---| | Số item | 100 | 25 | | Kích thước | 16 MB | 16 MB | | Nguyên tử | ❌ | ❌ | | Phần chưa xong | UnprocessedKeys | UnprocessedItems |

Cả hai đều không nguyên tử — cần "tất cả hoặc không" thì phải dùng TransactGetItems / TransactWriteItems (giới hạn 100 item, tốn gấp đôi capacity).

Ba mẹo thực dụng với BatchGetItem:

1. Luôn xử lý UnprocessedKeys kèm exponential backoff.
2. Dùng ProjectionExpression khi không cần hết thuộc tính — giảm cả RCU lẫn dữ liệu truyền. (Đề này cần hết nên không áp dụng.)
3. Với item 100 KB, chú ý giới hạn 400 KB mỗi item của DynamoDB — bạn đang dùng 1/4 hạn mức, còn chỗ nhưng nên theo dõi.

Và về chi phí đọc: 100 KB → ceil(100/4) = 25 đơn vị. Với eventually consistent thì 12,5 RCU mỗi item, tức 1.250 RCU cho cả lô 100 item — con số đáng tính vào thiết kế capacity.

Đáp án

C — Dùng AWS Secrets Manager để lưu và lấy API key.

Vì sao đúng

Đề nêu hai yêu cầu: quản lý API key bằng mã, và mức bảo mật cao nhất.

Secrets Manager là dịch vụ chuyên dụng cho việc lưu trữ bí mật, và nó vượt trội ở mọi tiêu chí bảo mật:

import boto3, json
sm = boto3.client('secretsmanager')
bi_mat = json.loads(sm.get_secret_value(SecretId='doi-tac/api-key')['SecretString'])

response = requests.get(
    'https://api.doi-tac.com/benh-nhan',
    headers={'x-api-key': bi_mat['apiKey']}
)

Với dữ liệu y tế (HIPAA) như đề mô tả, vết kiểm toán trong CloudTrail đặc biệt quan trọng — bạn chứng minh được ai đã truy cập khoá và khi nào.

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

• B. Lưu API key trong biến môi trường trên máy chủ ứng dụng — an toàn hơn nhúng vào mã, nhưng kém hơn Secrets Manager rõ rệt: biến môi trường hiện nguyên văn trong cấu hình task ECS hoặc cấu hình hàm Lambda, không có vết kiểm toán khi đọc, và không xoay vòng được mà không triển khai lại.
• A. Lưu API key trong DynamoDB — tự dựng lại một dịch vụ đã có, kém hơn ở mọi mặt: bạn phải tự lo mã hoá ở mức thuộc tính, tự phân quyền, tự viết cơ chế xoay vòng. Và không có vết kiểm toán riêng cho việc đọc bí mật.
• D. Lưu API key trong mã ứng dụng — sai lầm bảo mật nghiêm trọng nhất: bí mật nằm trong lịch sử Git vĩnh viễn, mọi người có quyền đọc kho mã đều thấy, và đổi khoá thì phải build lại và triển khai lại.

Ghi nhớ

Cách chọn:

• Bí mật cần xoay vòng, cần kiểm toán chặt ⇒ Secrets Manager
• Cấu hình không nhạy cảm (URL, feature flag) ⇒ Parameter Store (miễn phí)

Với API key của đối tác bên ngoài, Secrets Manager là lựa chọn đúng — nhất là khi đối tác có thể yêu cầu đổi khoá định kỳ.

Ba lưu ý khi triển khai:

1. Cache giá trị trong bộ nhớ ứng dụng — đừng gọi get_secret_value ở mỗi request (tốn phí API và thêm độ trễ). AWS có sẵn Parameters and Secrets Lambda Extension làm việc này bằng cấu hình.
2. Đặt resource policy cho secret để giới hạn chính xác role nào đọc được:

   {"Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::123456789012:role/RoleUngDung"},
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "*"}
   

3. Nếu ứng dụng nằm trong VPC, cần VPC endpoint cho Secrets Manager (hoặc NAT) để gọi được.

Và với dữ liệu y tế: nhớ rằng Secrets Manager là dịch vụ đủ điều kiện HIPAA, nhưng bạn vẫn phải ký BAA với AWS và mã hoá mọi lớp khác trong kiến trúc.

Đáp án

B — Sinh cặp khoá SSH công khai/riêng tư, rồi tải public key lên tài khoản IAM của lập trình viên.

Vì sao đúng

Đề nói rõ cần kết nối bằng SSH, và CodeCommit xác thực SSH bằng cách đối chiếu với public key đã tải lên IAM user.

Quy trình ba bước:

# 1. Sinh cặp khoá trên máy lập trình viên
ssh-keygen -t rsa -b 4096 -C "nguyen-van-a@congty.com" -f ~/.ssh/codecommit_rsa

# 2. Tải PUBLIC key lên IAM (giữ private key trên máy)
aws iam upload-ssh-public-key --user-name nguyen-van-a \
  --ssh-public-key-body file://~/.ssh/codecommit_rsa.pub
# → AWS trả về SSHPublicKeyId, ví dụ APKAEIBAERJR2EXAMPLE

# 3. Cấu hình SSH client
cat >> ~/.ssh/config <<'EOF'
Host git-codecommit.*.amazonaws.com
  User APKAEIBAERJR2EXAMPLE      # ← chính là SSHPublicKeyId
  IdentityFile ~/.ssh/codecommit_rsa
EOF

Chi tiết đáng chú ý ở bước 3: User là SSHPublicKeyId, không phải tên IAM user. Đây là chỗ hay cấu hình sai.

Rồi clone bằng URL SSH:

git clone ssh://git-codecommit.ap-southeast-1.amazonaws.com/v1/repos/du-an

Private key không bao giờ rời khỏi máy — đó là điểm mạnh của xác thực bằng khoá công khai.

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

• D. Tạo HTTPS Git credentials trong IAM — cách hợp lệ nhưng cho giao thức KHÁC. Đề nói rõ "using SSH". Git credentials là cặp username/password dùng với URL https://git-codecommit....
• A. Tạo access key và secret ID — access key dùng cho AWS CLI và SDK, không dùng để xác thực SSH với Git. (Nó gián tiếp có ích nếu dùng credential helper qua HTTPS, nhưng đó lại là giao thức khác.)
• C. Tạo tài khoản GitHub và dùng thông tin đó đăng nhập CodeCommit — hai dịch vụ hoàn toàn riêng biệt. CodeCommit xác thực qua IAM, không nhận tài khoản GitHub.

Ghi nhớ

Bốn cách xác thực với CodeCommit: | Cách | Giao thức | Cần gì | |---|---|---| | SSH key | SSH | tải public key lên IAM user | | Git credentials | HTTPS | sinh username/password trong IAM | | git-remote-codecommit | HTTPS (grc://) | dùng được với role, SSO, MFA | | Credential helper | HTTPS | trên EC2, CodeBuild — dùng role |

Quyền IAM cần cho thao tác SSH:

{"Effect": "Allow",
 "Action": ["iam:UploadSSHPublicKey", "iam:ListSSHPublicKeys"],
 "Resource": "arn:aws:iam::123456789012:user/${aws:username}"}

Cộng với quyền trên chính repository (AWSCodeCommitPowerUser hoặc policy tự viết).

Cách thứ ba trong bảng — git-remote-codecommit — được AWS khuyến nghị hiện nay vì nó không cần IAM user cố định, hoạt động với role và SSO:

pip install git-remote-codecommit
git clone codecommit://ho-so-aws@kho-cua-toi

Ba lỗi hay gặp khi cấu hình SSH với CodeCommit:

1. Đặt User là tên IAM user thay vì SSHPublicKeyId — lỗi phổ biến nhất.
2. Quyền tệp private key không đúng — SSH từ chối nếu không phải 600.
3. Quên khai IdentityFile khi có nhiều khoá trên máy.

(Ghi chú thời sự: CodeCommit ngừng nhận khách hàng mới từ 25/7/2024; tài khoản đã dùng vẫn hoạt động bình thường.)

Đáp án

C — Tạo một deny list và liệt kê các API action cần từ chối.

Vì sao đúng

Bối cảnh: hạn chế mọi user và role trong một tài khoản thành viên của AWS Organizations, và chỉ cần từ chối một vài API action cụ thể.

Đó là công việc của Service Control Policy (SCP), và SCP có hai chiến lược: | Chiến lược | Cách viết | Dùng khi | |---|---|---| | Deny list | cho phép hết, rồi Deny một số action | chỉ cần chặn vài thứ | | Allow list | chặn hết, rồi Allow những gì cần | kiểm soát rất chặt |

Đề nói "deny access to a few specific API actions" — nên deny list là cách hiệu quả nhất:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ChanCacHanhDongNguyHiem",
    "Effect": "Deny",
    "Action": [
      "cloudtrail:StopLogging",
      "cloudtrail:DeleteTrail",
      "config:DeleteConfigurationRecorder",
      "guardduty:DeleteDetector"
    ],
    "Resource": "*"
  }]
}

Vì sao đây là cách "MOST efficient": | Lợi ích | Chi tiết | |---|---| | Chỉ viết những gì cần chặn | vài dòng thay vì liệt kê hàng nghìn action được phép | | Không phải bảo trì khi AWS ra dịch vụ mới | dịch vụ mới tự động được phép | | Áp cho MỌI danh tính, kể cả root | không ai lách được |

Dòng cuối là điều làm SCP khác biệt với IAM policy — nó là rào chắn ở cấp tổ chức.

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

• A. Tạo allow list rồi "chỉ định các API action cần từ chối" — tự mâu thuẫn: allow list hoạt động bằng cách liệt kê những gì ĐƯỢC PHÉP, phần còn lại bị chặn ngầm. Bạn không "chỉ định action cần từ chối" trong một allow list.
• B. Tạo IAM policy chỉ cho phép các action không bị hạn chế — hai vấn đề. Thứ nhất, đây là cách allow list, phải liệt kê hàng nghìn action và bảo trì mãi mãi. Thứ hai và quan trọng hơn: IAM policy phải gắn vào TỪNG user và role — không phủ được "all users and roles" một cách tự động, và không áp cho root user.
• D. Tạo IAM policy từ chối các action cho mọi user và role — đúng ý tưởng Deny nhưng sai công cụ: bạn vẫn phải gắn policy đó vào từng danh tính, và ai đó tạo user mới sẽ không có policy này. SCP thì áp tự động cho toàn tài khoản.

Ghi nhớ

Bốn cơ chế giới hạn quyền — bảng này rất đáng thuộc: | Cơ chế | Phạm vi | Áp cho root user? | |---|---|---| | SCP | tài khoản hoặc OU | ✅ CÓ | | Permissions boundary | một IAM user/role | ❌ | | IAM policy | danh tính cụ thể | ❌ | | Session policy | một phiên tạm thời | ❌ |

Quyền hiệu lực là giao của tất cả:

Quyền = SCP ∩ IAM policy ∩ permissions boundary ∩ session policy

Điểm cần hiểu đúng: SCP KHÔNG CẤP quyền, nó chỉ GIỚI HẠN. Người dùng vẫn cần IAM policy cho phép — SCP quyết định điều gì là không thể.

Ba lưu ý quan trọng khi dùng SCP:

1. SCP không áp cho tài khoản quản lý (management account) — kể cả khi gắn vào gốc tổ chức. Đây là lý do AWS khuyến nghị không chạy workload trong tài khoản quản lý.
2. Chính sách mặc định là FullAWSAccess — cho phép mọi thứ. Với deny list thì giữ nguyên nó; với allow list thì phải gỡ ra.
3. Deny list bền vững hơn allow list — AWS liên tục thêm dịch vụ mới, và allow list sẽ chặn nhầm chúng.

Các guardrail hay dùng: chặn tắt CloudTrail, chặn tắt GuardDuty, chặn xoá log, giới hạn Region được phép, và chặn tạo IAM user (ép dùng SSO).