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

Đáp án

D — Dùng kiến trúc hướng sự kiện (event-driven architecture).

Vì sao đúng

Đề mô tả đúng vấn đề: xử lý hiện đang chạy mỗi ngày một lần (theo lịch), nhưng nhu cầu là gần thời gian thực.

Khác biệt giữa hai mô hình:

Theo lịch (hiện tại):
  00:00 mỗi ngày → Lambda chạy → xử lý toàn bộ dữ liệu tích luỹ
  → độ trễ tối đa 24 GIỜ

Hướng sự kiện (cần chuyển sang):
  Dữ liệu được ghi → sự kiện phát ra NGAY → Lambda xử lý
  → độ trễ tính bằng GIÂY

Với DynamoDB, cách hiện thực cụ thể là DynamoDB Streams + Lambda:

Ứng dụng ghi vào bảng
      ↓ DynamoDB tự phát sự kiện
  DynamoDB Streams
      ↓ event source mapping
  Lambda xử lý ngay khi bản ghi thay đổi

aws dynamodb update-table --table-name du-lieu \
  --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

aws lambda create-event-source-mapping \
  --function-name chuan-bi-phan-tich \
  --event-source-arn <arn-cua-stream> \
  --starting-position LATEST --batch-size 100

Điểm hay của kiến trúc hướng sự kiện, ngoài chuyện độ trễ: | Lợi ích | Chi tiết | |---|---| | Ghép lỏng | bên sinh sự kiện không cần biết ai xử lý | | Co giãn tự nhiên | nhiều sự kiện ⇒ nhiều lần gọi song song | | Chỉ trả tiền khi có việc | không có job chạy không | | Mở rộng dễ | thêm consumer mới mà không sửa bên sinh sự kiện |

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

• B. Kiến trúc theo lịch (scheduled) — chính là mô hình đang gây ra vấn đề. Rút ngắn chu kỳ (ví dụ chạy mỗi 5 phút) sẽ cải thiện phần nào, nhưng vẫn là polling: tốn tài nguyên cho những lần chạy không có dữ liệu, và vẫn có độ trễ cố định.
• A. Kiến trúc fan-out — mô tả việc một sự kiện được gửi tới NHIỀU consumer (SNS → nhiều SQS/Lambda). Nó là một mẫu BÊN TRONG kiến trúc hướng sự kiện, giải quyết bài toán "nhiều nơi cùng cần biết", không phải bài toán "xử lý ngay khi có dữ liệu". Đề chỉ có một consumer.
• C. Kiến trúc microservices — nói về cách chia ứng dụng thành các dịch vụ nhỏ độc lập. Đó là vấn đề tổ chức mã và ranh giới triển khai, hoàn toàn không quyết định khi nào việc xử lý được kích hoạt. Một microservice vẫn có thể chạy theo lịch mỗi ngày.

Ghi nhớ

Bốn mẫu kiến trúc hay bị đặt cạnh nhau trong đề thi: | Mẫu | Trả lời câu hỏi | |---|---| | Event-driven | KHI NÀO xử lý được kích hoạt | | Fan-out | BAO NHIÊU consumer nhận cùng một sự kiện | | Microservices | ứng dụng được CHIA như thế nào | | Scheduled/batch | chạy theo chu kỳ cố định |

Nhận dạng nhanh: đề nói "near-real time", "as it is received", "as soon as" ⇒ event-driven.

Các nguồn sự kiện phổ biến trên AWS: | Nguồn | Phát khi | |---|---| | DynamoDB Streams | item được thêm, sửa, xoá | | S3 Event Notifications | object được tạo hoặc xoá | | SQS | có message trong hàng đợi | | Kinesis | bản ghi vào luồng | | EventBridge | sự kiện từ dịch vụ AWS hoặc ứng dụng của bạn |

Với đúng tình huống của đề (dữ liệu trong DynamoDB), Streams là lựa chọn tự nhiên nhất vì nó không đòi sửa mã ứng dụng — DynamoDB tự phát sự kiện, ứng dụng hiện tại không biết và không cần biết.

Đáp án

D — Dùng CloudWatch Metrics với ngưỡng tuỳ chỉnh và nối vào SNS topic có sẵn.

Vì sao đúng

Yêu cầu rất cụ thể: cảnh báo khi tỷ lệ lỗi vượt 10% mỗi giờ. Đó là một ngưỡng trên một tỷ lệ tính toán được, và CloudWatch alarm là công cụ đúng cho việc đó.

Vì "tỷ lệ lỗi" không phải một metric có sẵn, phải tính từ hai metric bằng metric math:

aws cloudwatch put-metric-alarm \
  --alarm-name ty-le-loi-api-thanh-toan \
  --metrics '[
    {"Id":"loi","MetricStat":{"Metric":{"Namespace":"UngDung","MetricName":"LoiGoiAPI"},
                              "Period":3600,"Stat":"Sum"},"ReturnData":false},
    {"Id":"tong","MetricStat":{"Metric":{"Namespace":"UngDung","MetricName":"TongGoiAPI"},
                               "Period":3600,"Stat":"Sum"},"ReturnData":false},
    {"Id":"tyle","Expression":"loi/tong*100","Label":"Ty le loi (%)","ReturnData":true}
  ]' \
  --threshold 10 --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:ap-southeast-1:123456789012:doi-ho-tro

Ứng dụng chỉ cần đăng hai custom metric:

def goi_api_thanh_toan(don_hang):
    cw.put_metric_data(Namespace='UngDung',
                       MetricData=[{'MetricName': 'TongGoiAPI', 'Value': 1}])
    try:
        return requests.post(URL, json=don_hang, timeout=5)
    except requests.Timeout:
        cw.put_metric_data(Namespace='UngDung',
                           MetricData=[{'MetricName': 'LoiGoiAPI', 'Value': 1}])
        raise

Vì sao cách này đúng: CloudWatch tự tổng hợp theo cửa sổ một giờ và tự đánh giá ngưỡng, còn ứng dụng chỉ việc báo cáo từng sự kiện. Không có mã nào phải tự đếm, tự chia, tự nhớ trạng thái giữa các lần gọi.

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

• A. Cho Lambda gửi thẳng cảnh báo tới SNS mỗi khi có timeout — không tính được tỷ lệ: mỗi lần gọi Lambda là một tiến trình độc lập, không biết gì về các lần gọi khác trong giờ đó. Nó chỉ biết "lần này hỏng", không biết "hỏng bao nhiêu phần trăm". Kết quả là spam thông báo ở mỗi lỗi lẻ, kể cả khi tỷ lệ lỗi hoàn toàn bình thường.
• B. Dùng CloudTrail để giám sát Lambda và gửi cảnh báo khi tỷ lệ lỗi vượt 10% — sai hai chỗ: CloudTrail ghi lời gọi API quản trị (ai tạo/sửa hàm), không ghi lỗi runtime bên trong hàm. Và CloudTrail không có cơ chế ngưỡng hay cảnh báo — nó chỉ ghi log.
• C. Dùng X-Ray để giám sát tỷ lệ lỗi và gửi cảnh báo qua SNS — X-Ray rất giỏi việc hiển thị tỷ lệ lỗi trên service map và trong phân tích trace, nhưng nó không có cơ chế alarm gửi SNS. (Có một đường vòng: X-Ray phát metric TracesRecorded/ErrorRate sang CloudWatch, rồi bạn đặt alarm ở đó — nhưng như vậy vẫn là CloudWatch alarm, tức là đáp án D.)

Ghi nhớ

Vai trò của từng công cụ: | Công cụ | Việc | |---|---| | CloudWatch Metrics + Alarm | đo lường, đặt ngưỡng, KÍCH HOẠT HÀNH ĐỘNG | | CloudWatch Logs | lưu và tìm kiếm log | | X-Ray | theo dấu request, tìm chặng chậm/lỗi | | CloudTrail | kiểm toán lời gọi API quản trị |

Metric math là công cụ đáng nhớ — nó cho phép đặt alarm trên những thứ không có sẵn dưới dạng metric:

loi/tong*100                  # tỷ lệ phần trăm
SUM([m1,m2,m3])               # cộng nhiều metric
RATE(m1)                      # tốc độ thay đổi
ANOMALY_DETECTION_BAND(m1,2)  # phát hiện bất thường theo mô hình học được

Ba trạng thái của alarm, và một chi tiết hay bị bỏ sót: | Trạng thái | Nghĩa | |---|---| | OK | trong ngưỡng | | ALARM | vượt ngưỡng | | INSUFFICIENT_DATA | không đủ dữ liệu để đánh giá |

Với alarm dạng tỷ lệ, nếu không có request nào trong giờ đó thì mẫu số bằng 0 và alarm rơi vào INSUFFICIENT_DATA. Hãy quyết định tường minh muốn coi đó là gì bằng --treat-missing-data notBreaching (im lặng) hoặc breaching (báo động) — để mặc định là nguồn của những cảnh báo khó hiểu lúc nửa đêm.

Đáp án

C — Nối một branch mới, triển khai thành phiên bản tại https://dev.applicationId.amplifyapp.com để thử tính năng mới.

Vì sao đúng

AWS Amplify có mô hình feature branch deployment: mỗi nhánh Git được triển khai thành một môi trường độc lập, với URL riêng.

Nhánh main  → https://main.d1a2b3c4.amplifyapp.com   ← PRODUCTION, không bị đụng tới
Nhánh dev   → https://dev.d1a2b3c4.amplifyapp.com    ← môi trường thử nghiệm
Nhánh feature/x → https://feature-x.d1a2b3c4.amplifyapp.com

Đây đúng là điều đề yêu cầu: thử tính năng mới mà không ảnh hưởng phiên bản đã publish. Hai môi trường hoàn toàn tách biệt — khác build, khác biến môi trường, khác backend resource nếu muốn.

aws amplify create-branch --app-id d1a2b3c4 --branch-name dev \
  --environment-variables API_URL=https://api-dev.example.com

Từ đó mọi commit lên dev tự động build và triển khai vào URL của dev, còn main giữ nguyên.

Amplify còn có thêm hai tính năng cho đúng nhu cầu này: | Tính năng | Việc | |---|---| | Pull request preview | mỗi PR có URL tạm riêng, tự xoá khi PR đóng | | Password protection | đặt mật khẩu cho môi trường không phải production |

Tính năng thứ hai đáng bật cho nhánh dev: không thì bản thử nghiệm của bạn nằm công khai trên Internet và có thể bị Google lập chỉ mục.

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

• A. Nối branch mới nhưng triển khai thành https://main.applicationId.amplifyapp.com — URL đó chính là môi trường production. Triển khai vào đó là ghi đè lên bản đang phục vụ người dùng — đúng thứ đề yêu cầu tránh. Đây là bẫy chính, và nó chỉ khác đáp án đúng đúng một chữ trong URL.
• B và D. Nối môi trường production vào AWS Cloud9 rồi thử tính năng — sai bản chất: Cloud9 là IDE, không phải môi trường triển khai. Và việc "nối môi trường production" vào IDE để thử tính năng nghĩa là thao tác trực tiếp trên production — rủi ro cao nhất có thể. Phương án D còn tệ hơn khi nói thử sau khi publish, tức là người dùng đã gặp bản chưa kiểm thử.

Ghi nhớ

Mô hình môi trường của Amplify: | Khái niệm | Nghĩa | |---|---| | App | một ứng dụng, gắn với một kho mã | | Branch | một nhánh Git = một môi trường có URL riêng | | Backend environment | tập tài nguyên backend (Cognito, AppSync, S3) riêng cho môi trường đó | | Preview | URL tạm cho mỗi pull request |

Quy trình làm việc điển hình:

feature/abc  → preview URL tự sinh khi mở PR
     ↓ merge
dev          → https://dev....amplifyapp.com    (QA kiểm thử)
     ↓ merge
main         → https://main....amplifyapp.com   (production, gắn tên miền thật)

Vài điểm thực dụng:

• Biến môi trường khai riêng cho từng nhánh — nên nhánh dev trỏ vào API và CSDL của môi trường dev một cách tự nhiên.
• Tên miền tuỳ chỉnh gắn được cho từng nhánh: example.com cho main, dev.example.com cho dev.
• Với backend, dùng amplify env add để mỗi môi trường có tài nguyên AWS riêng — nếu không, nhánh dev sẽ ghi vào chính CSDL production.

Điểm cuối là sai lầm nguy hiểm nhất khi dùng Amplify: tách được frontend nhưng quên tách backend, và bản thử nghiệm ghi thẳng vào dữ liệu thật.

Đáp án

A — aws sts assume-role.

Vì sao đúng

Yêu cầu: lập trình viên muốn kiểm tra xem role thật sự có những quyền gì khi ứng dụng dùng nó.

Cách duy nhất để biết chắc là trở thành chính role đó rồi thử các thao tác — và sts assume-role làm việc đó:

# 1. Assume role của ứng dụng
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/RoleUngDung \
  --role-session-name kiem-tra-quyen

# 2. Đặt credential trả về vào biến môi trường
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

# 3. Thử đúng thao tác mà ứng dụng đang làm
aws dynamodb get-item --table-name BangUngDung --key '{"id":{"S":"test"}}'

Vì sao đây là cách kiểm tra đáng tin nhất: nó thực thi đúng đường đi mà ứng dụng đi qua, nên nó tính tới mọi thứ ảnh hưởng tới quyết định cho phép:

• Identity-based policy gắn vào role
• Resource-based policy (bảng, bucket, khoá KMS)
• Permissions boundary
• Service control policy của tổ chức
• Session policy nếu có

Đọc policy bằng mắt không bao giờ cho biết chắc kết quả, vì các lớp trên có thể chặn hoặc mở thêm.

Cách gọn hơn cho việc dùng lặp lại — khai profile trong ~/.aws/config:

[profile kiem-tra-ung-dung]
role_arn = arn:aws:iam::123456789012:role/RoleUngDung
source_profile = default

aws dynamodb get-item --profile kiem-tra-ung-dung --table-name BangUngDung --key ...

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

• B. aws iam get-role-policy — chỉ hiển thị nội dung một inline policy gắn vào role. Hữu ích để đọc, nhưng nó không kiểm tra gì: nó bỏ sót managed policy, resource-based policy, permissions boundary và SCP — tức là bỏ sót phần lớn những thứ quyết định quyền thật.
• C. aws sts get-session-token — trả về credential tạm thời cho CHÍNH danh tính đang gọi (thường dùng khi cần phiên có MFA). Nó không chuyển sang role khác, nên không kiểm tra được quyền của role ứng dụng.
• D. aws dynamodb describe-endpoints — trả về danh sách endpoint khu vực của DynamoDB. Không liên quan gì tới quyền hạn.

Ghi nhớ

Các API của STS: | API | Việc | |---|---| | AssumeRole | chuyển sang một IAM role (cùng hoặc khác tài khoản) | | AssumeRoleWithSAML | từ IdP doanh nghiệp | | AssumeRoleWithWebIdentity | từ Cognito, Google, Facebook | | GetSessionToken | credential tạm thời cho chính mình, thường kèm MFA | | GetCallerIdentity | "tôi đang là ai?" — lệnh gỡ lỗi hữu ích nhất |

aws sts get-caller-identity đáng nhớ vì nó trả lời ngay câu hỏi hay gây nhầm nhất khi gỡ lỗi quyền: credential hiện tại thuộc về ai. Rất nhiều lỗi "AccessDenied" hoá ra là do đang dùng nhầm profile.

Các công cụ kiểm tra quyền khác: | Công cụ | Việc | |---|---| | iam simulate-principal-policy | mô phỏng: role X có làm được hành động Y không — không thực thi thật | | IAM Access Analyzer | tìm tài nguyên bị chia sẻ ra ngoài, và sinh policy từ log CloudTrail | | IAM Access Advisor | dịch vụ nào thật sự được dùng trong 400 ngày qua | | CloudTrail | ghi lại mọi lời gọi bị từ chối, kèm lý do |

Khi gỡ lỗi AccessDenied, hãy đọc kỹ thông báo trong CloudTrail — nó thường nói rõ policy loại nào đã từ chối (identity-based, SCP, boundary), và đó là manh mối nhanh nhất.

Đáp án

B và D.

• B — Tải lên index document và khai tên tệp đó khi bật static website hosting.
• D — Bật public access và cấp cho mọi người quyền s3:GetObject.

Vì sao đúng

Có đúng hai việc bắt buộc để một bucket phục vụ được website tĩnh công khai.

B — index document là bắt buộc, error document thì không. Khi bật static website hosting, S3 yêu cầu tên của index document (thường là index.html); nó là tệp trả về khi người dùng truy cập thư mục gốc hoặc một "thư mục" bất kỳ.

aws s3 website s3://trang-web-cua-toi/ --index-document index.html

Error document là tuỳ chọn — không khai thì S3 trả về trang lỗi mặc định của mình.

D — nội dung phải đọc được công khai. Bucket mặc định riêng tư hoàn toàn, nên phải làm hai bước:

# 1. Tắt Block Public Access
aws s3api put-public-access-block --bucket trang-web-cua-toi \
  --public-access-block-configuration \
  "BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false"

# 2. Bucket policy cho phép đọc
aws s3api put-bucket-policy --bucket trang-web-cua-toi --policy '{
  "Version":"2012-10-17",
  "Statement":[{"Sid":"ChoDocCongKhai","Effect":"Allow","Principal":"*",
                "Action":"s3:GetObject","Resource":"arn:aws:s3:::trang-web-cua-toi/*"}]}'

Bước 1 hay bị quên: Block Public Access bật mặc định và nó ghi đè mọi bucket policy — bạn có thể đặt policy cho phép công khai mà truy cập vẫn bị từ chối, không có thông báo nào giải thích.

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

• A. Tải lên cả index lẫn error document và khai cả hai — gần đúng nhưng quá mức bắt buộc: error document là tuỳ chọn. Đề hỏi những bước MUST, nên phương án B (chỉ index) mới chính xác.
• E. Tạo object ACL cấp quyền READ cho nhóm AllUsers — về kỹ thuật thì từng làm được, nhưng nó là cách cũ và có ba vấn đề: phải đặt ACL cho TỪNG object (không tự áp cho object mới), Block Public Access chặn ACL công khai theo mặc định, và quan trọng nhất — từ tháng 4/2023, AWS tắt ACL theo mặc định cho bucket mới (Object Ownership: Bucket owner enforced), khiến ACL hoàn toàn không có tác dụng. Bucket policy là cách đúng.
• C. Tải chứng chỉ từ ACM lên — S3 không nhận chứng chỉ, và website endpoint của S3 chỉ hỗ trợ HTTP. Muốn HTTPS thì phải đặt CloudFront phía trước — nhưng đó là bước tuỳ chọn, không phải yêu cầu để bật static website hosting.

Ghi nhớ

Ba việc để dựng website tĩnh trên S3: | Bước | Bắt buộc | |---|---| | Bật static website hosting + khai index document | ✅ | | Tắt Block Public Access + bucket policy s3:GetObject | ✅ | | Khai error document | ❌ tuỳ chọn | | CloudFront phía trước | ❌ tuỳ chọn (nhưng cần nếu muốn HTTPS) |

Hai loại endpoint của S3 — khác nhau ở chỗ rất quan trọng: | Endpoint | HTTPS | Chức năng website | |---|---|---| | bucket.s3-website-<region>.amazonaws.com | ❌ | ✅ index, error, redirect | | bucket.s3.<region>.amazonaws.com | ✅ | ❌ |

Nghĩa là bạn không thể vừa có HTTPS vừa có chức năng website chỉ với S3 — đó là lý do kiến trúc chuẩn luôn có CloudFront:

Route 53 → CloudFront (ACM cert ở us-east-1, OAC) → S3 bucket RIÊNG TƯ

Với kiến trúc này, bucket không cần công khai chút nào — CloudFront truy cập qua Origin Access Control, và đó là cách nên làm cho website thật.

Đáp án

A — Mã hoá dữ liệu trực tiếp bằng customer managed CMK.

Vì sao đúng

Hai chi tiết trong đề quyết định câu trả lời: tệp chỉ 1 KB, và yêu cầu là cách AN TOÀN NHẤT (không phải nhanh nhất hay rẻ nhất).

Về kích thước: kms:Encrypt có giới hạn 4 KB. Tệp 1 KB nằm gọn trong đó, nên mã hoá trực tiếp là hợp lệ:

response = kms.encrypt(
    KeyId='arn:aws:kms:...:key/abc-123',
    Plaintext=noi_dung_tep,                          # 1 KB
    EncryptionContext={'loai': 'PII', 'nguon': 'ung-dung-A'}
)
ciphertext = response['CiphertextBlob']

Về độ an toàn: đây là điểm mấu chốt. Với mã hoá trực tiếp, không có khoá bản rõ nào từng xuất hiện trong ứng dụng của bạn:

Với dữ liệu định danh cá nhân (PII), hai dòng cuối rất đáng giá: mọi lần mã hoá và giải mã đều để lại vết kiểm toán riêng lẻ trong CloudTrail — điều mà envelope encryption không có (một data key có thể được dùng lại nhiều lần mà KMS không hề biết).

Customer managed CMK thay vì AWS managed vì nó cho bạn: đặt key policy riêng, vô hiệu hoá khoá khi cần thu hồi toàn bộ, tự chọn lịch xoay vòng, và dùng được grant để phân quyền chi tiết.

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

• C. Tạo data key từ CMK rồi mã hoá bằng data key (envelope encryption) — đây là phương án gần nhất và hoàn toàn đúng đắn về kỹ thuật; nó là cách bắt buộc với dữ liệu lớn. Nhưng ở đây tệp chỉ 1 KB nên không cần, và nó kém an toàn hơn một chút vì khoá bản rõ có đi qua bộ nhớ ứng dụng. Đề hỏi "SAFEST", không hỏi "most scalable".
• B. "Tạo data key từ CMK rồi mã hoá dữ liệu bằng CMK" — tự mâu thuẫn: sinh ra data key rồi lại không dùng tới nó. Không phải mẫu hợp lệ nào cả.
• D. Mã hoá trực tiếp bằng AWS managed CMK — làm được, nhưng kém an toàn hơn về mặt kiểm soát: AWS managed key (aws/dịch-vụ) không cho bạn sửa key policy, không vô hiệu hoá được, và không xoá được. Với dữ liệu PII cần kiểm soát chặt, customer managed CMK là lựa chọn đúng.

Ghi nhớ

Chọn phương pháp theo kích thước dữ liệu: | Kích thước | Cách | |---|---| | ≤ 4 KB | kms:Encrypt trực tiếp — an toàn nhất | | > 4 KB | GenerateDataKey + envelope encryption — bắt buộc |

So sánh ba loại khoá KMS: | Loại | Key policy | Vô hiệu hoá | Chi phí | |---|---|---|---| | AWS owned | không thấy | ❌ | miễn phí | | AWS managed | không sửa được | ❌ | miễn phí (trả phí request) | | Customer managed | toàn quyền | ✅ | ~1 USD/tháng + phí request |

Và luôn dùng encryption context khi mã hoá:

EncryptionContext={'maNhanVien': 'NV-001', 'muc': 'ho-so-y-te'}

Nó được xác thực nhưng không mã hoá, phải khớp chính xác khi giải mã, và xuất hiện trong CloudTrail — nên nó vừa ngăn việc dùng nhầm khoá cho dữ liệu khác, vừa làm log kiểm toán có nghĩa hơn nhiều.

Lưu ý về hạn mức: kms:Encrypt chịu giới hạn số request mỗi giây (thay đổi theo Region, thường vài nghìn). Với khối lượng rất lớn tệp nhỏ, có thể chạm trần — khi đó envelope encryption với data key caching lại trở thành lựa chọn thực tế hơn, dù kém an toàn hơn về lý thuyết.

Đáp án

D — Đặt tham số ConsistentRead thành true khi gọi GetItem.

Vì sao đúng

Triệu chứng — nhiều instance cùng ghi, và thỉnh thoảng đọc phải dữ liệu cũ — là hành vi mặc định của DynamoDB, không phải lỗi.

DynamoDB nhân bản mỗi item lên ba AZ. Đọc kiểu eventually consistent (mặc định) lấy dữ liệu từ bất kỳ bản sao nào, nên có thể trúng bản chưa kịp nhận cập nhật mới nhất:

Instance A ghi → bản sao chính → lan truyền sang AZ-b, AZ-c (thường < 1 giây)
                                     ↑
             Instance B đọc trúng AZ-b ngay lúc này → nhận dữ liệu CŨ

Strongly consistent read đọc từ bản sao chính, nên luôn phản ánh mọi lần ghi đã hoàn tất:

response = table.get_item(
    Key={'id': 'BG-001'},
    ConsistentRead=True
)

Cái giá: gấp đôi RCU (1 RCU/4 KB thay vì 0,5) và độ trễ cao hơn một chút.

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

• A. Dùng TransactWriteItems khi ghi — giải quyết bài toán nguyên tử khi GHI (nhiều thao tác thành công hoặc không thao tác nào), không liên quan tới tính nhất quán khi ĐỌC. Ghi bằng giao dịch xong vẫn có thể đọc phải dữ liệu cũ nếu đọc kiểu eventually consistent. (Có TransactGetItems cho đọc nhất quán trên nhiều item, nhưng phương án nói về PutItem.)
• B. "Dùng UpdateGlobalTable API để tạo global secondary index" — tự mâu thuẫn: UpdateGlobalTable quản lý bản sao xuyên Region, không tạo GSI. Và GSI luôn eventually consistent — dùng nó sẽ làm vấn đề tệ hơn, không phải tốt hơn.
• C. Cache các lần ghi bằng DAX — DAX làm dữ liệu CŨ HƠN, không mới hơn: nó là lớp cache đọc. Và DAX không hỗ trợ strongly consistent read — request kiểu đó đi thẳng xuống DynamoDB, bỏ qua cache hoàn toàn.

Ghi nhớ

Nơi có và không có strongly consistent read: | Thao tác | Hỗ trợ | |---|---| | GetItem, BatchGetItem, Query, Scan | ✅ ConsistentRead=True | | Query trên LSI | ✅ | | Query trên GSI | ❌ KHÔNG BAO GIỜ | | Qua DAX | ❌ (bỏ qua cache) | | Global Tables xuyên Region | ❌ |

Hai dòng in đậm là chỗ hay bị hỏi nhất: GSI được cập nhật bất đồng bộ sau khi ghi vào bảng gốc, nên nó không bao giờ đảm bảo nhất quán mạnh — kể cả khi bạn truyền ConsistentRead=True (DynamoDB sẽ trả lỗi).

Cách chọn trong thực tế: | Cần strongly consistent | Không cần | |---|---| | Số dư, tồn kho, quota | danh sách bài viết, hồ sơ | | Đọc lại ngay sau khi ghi để xác nhận | dữ liệu gợi ý, thống kê | | Kiểm tra điều kiện trước khi hành động | nội dung ít thay đổi |

Nguyên tắc thực dụng: để mặc định eventually consistent cho phần lớn truy vấn (rẻ một nửa, nhanh hơn), rồi bật ConsistentRead=True có chọn lọc ở đúng chỗ mà dữ liệu cũ gây hậu quả nghiệp vụ.

Và một cách khác đáng biết cho tình huống "nhiều instance cùng sửa một item": dùng conditional write với ConditionExpression để tránh ghi đè lẫn nhau, thay vì chỉ chữa ở phía đọc.

Đáp án

A — AWS CodeCommit.

Vì sao đúng

Đề liệt kê bốn yêu cầu, và chúng mô tả chính xác một hệ thống quản lý mã nguồn:

Vế cuối là điểm phân biệt: "support multiple versions and batch change tracking" chính là mô tả commit trong Git — một tập thay đổi (batch) được ghi lại thành một phiên bản, có tác giả, thời điểm, và thông điệp.

Bảo mật cũng khớp: mã hoá at-rest và in-transit đều mặc định, phân quyền bằng IAM tới từng kho, và mọi thao tác đều để lại vết trong CloudTrail.

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

• C. Amazon S3 — có mã hoá và có versioning, nhưng versioning của S3 là theo TỪNG OBJECT, không phải theo tập thay đổi. Nó không có khái niệm commit, branch, merge, diff, hay pull request. Bạn không thể xem "thay đổi nào đã sửa cùng lúc năm tệp này và vì sao" — mà đó chính là "batch change tracking".
• B. AWS CodeBuild — biên dịch mã và chạy test. Nó lấy mã từ nơi khác để build; nó không lưu trữ mã và không có lịch sử phiên bản.
• D. AWS Cloud9 — IDE chạy trên trình duyệt. Nó có tính năng cộng tác thời gian thực (nhiều người cùng gõ một tệp), nhưng nó không phải kho lưu trữ mã: đóng môi trường là mất, và không có lịch sử phiên bản nào.

Ghi nhớ

Phân biệt versioning của S3 với version control thật: | | S3 Versioning | Git (CodeCommit) | |---|---|---| | Đơn vị | một object | một tập thay đổi (commit) | | Nhánh | ❌ | ✅ | | Merge, diff | ❌ | ✅ | | Ai sửa gì, vì sao | chỉ có thời điểm | tác giả + thông điệp + diff | | Review trước khi nhận | ❌ | ✅ pull request |

Vai trò các dịch vụ trong bộ công cụ phát triển: | Dịch vụ | Việc | |---|---| | CodeCommit | lưu trữ mã nguồn (Git) | | CodeBuild | biên dịch, test, đóng gói | | CodeDeploy | triển khai | | CodePipeline | điều phối toàn bộ | | CodeArtifact | kho package | | Cloud9 | IDE |

(Ghi chú thời sự quan trọng: từ 25/7/2024, AWS ngừng cho khách hàng mới tạo repository trên CodeCommit; tài khoản đã dùng vẫn hoạt động bình thường và AWS cam kết tiếp tục vận hành. Với dự án mới, hãy dùng GitHub, GitLab hoặc Bitbucket — chúng nối vào CodePipeline qua CodeStar Connections một cách trơn tru. Câu hỏi này vẫn nằm trong phạm vi kỳ thi, nhưng đừng chọn CodeCommit cho hệ thống mới.)

Đáp án

D — Dùng lệnh sam local invoke với tên hàm Lambda cụ thể.

Vì sao đúng

Đề đã nêu sẵn điều kiện: máy của lập trình viên đã cài cả SAM CLI lẫn CDK. Và SAM CLI là công cụ duy nhất chạy được Lambda tại chỗ, bằng cách mô phỏng môi trường Lambda trong một container Docker.

Điểm đáng chú ý: SAM làm việc được với dự án CDK, dù hai công cụ khác nhau. Cách nối là qua template CloudFormation đã tổng hợp:

# 1. CDK sinh ra template
cdk synth --no-staging > template.yaml

# 2. SAM chạy hàm từ template đó
sam local invoke HamXuLyDonHang --event su-kien-thu.json

--no-staging quan trọng: nó khiến CDK giữ đường dẫn mã nguồn ở dạng cục bộ thay vì trỏ tới S3, nên SAM tìm được mã để chạy.

SAM CLI cung cấp mấy chế độ, tuỳ nhu cầu: | Lệnh | Việc | |---|---| | sam local invoke <Ham> | chạy một hàm với một sự kiện | | sam local start-api | dựng API Gateway giả tại localhost:3000 | | sam local start-lambda | dựng endpoint Lambda giả để SDK gọi vào | | sam local generate-event | sinh sự kiện mẫu (S3, SNS, API Gateway…) |

Lệnh cuối rất tiện khi cần một payload đúng định dạng:

sam local generate-event apigateway aws-proxy > su-kien-thu.json

Vì hàm chạy trong container giống môi trường Lambda thật, bạn phát hiện được cả những lỗi phụ thuộc hệ điều hành mà chạy trực tiếp trên máy sẽ không thấy.

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

• A. Dùng CDK CLI để chạy hàm tại chỗ — CDK không có lệnh nào chạy Lambda cục bộ. CDK lo việc định nghĩa và triển khai hạ tầng (synth, deploy, diff, destroy); nó không phải công cụ thực thi.
• C. Chạy trực tiếp hàm Lambda trên máy — làm được nếu chỉ gọi hàm Python như một hàm thường, nhưng nó không mô phỏng môi trường Lambda: không có đúng runtime, không có event/context chuẩn, không có giới hạn bộ nhớ và timeout, không có biến môi trường của Lambda. Lỗi liên quan tới môi trường sẽ không lộ ra cho tới khi triển khai.
• B. Kiểm thử qua AWS Management Console — không phải kiểm thử cục bộ: phải triển khai lên AWS trước, tức là vòng lặp chậm hơn nhiều và tốn tiền. Đề hỏi cách "locally test".

Ghi nhớ

Ba công cụ và phạm vi của chúng: | Công cụ | Việc | |---|---| | AWS CDK | định nghĩa hạ tầng bằng ngôn ngữ lập trình | | AWS SAM | framework serverless + CLI chạy và gỡ lỗi CỤC BỘ | | CloudFormation | dịch vụ triển khai nằm dưới cả hai |

Chúng không loại trừ nhau: CDK sinh ra CloudFormation, và SAM đọc được CloudFormation — nên dùng CDK để định nghĩa, SAM để kiểm thử là kết hợp hoàn toàn hợp lệ và khá phổ biến.

Vài mẹo khi dùng sam local:

# Gắn debugger (ví dụ VS Code) vào cổng 5858
sam local invoke HamCuaToi -d 5858 --event su-kien.json

# Truyền biến môi trường
sam local invoke HamCuaToi --env-vars bien-moi-truong.json

# Dựng API giả để gọi bằng curl
sam local start-api
curl http://localhost:3000/don-hang

Hạn chế cần biết: sam local 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 tự trỏ endpoint sang DynamoDB Local hoặc LocalStack.

Đáp án

B — Dùng AWS Secrets Manager: tạo managed rotation trong phần Rotation Schedule và hẹn giờ tự động xoay vòng bằng biểu thức cron.

Vì sao đúng

Secrets Manager là dịch vụ duy nhất trong bốn phương án có cơ chế xoay vòng bí mật được quản lý sẵn, và nó tích hợp riêng với RDS.

Cách bật chỉ là một lời gọi:

aws secretsmanager rotate-secret \
  --secret-id prod/csdl/mat-khau \
  --rotation-lambda-arn arn:aws:lambda:...:function:SecretsManagerRDSPostgreSQLRotation \
  --rotation-rules '{"ScheduleExpression": "cron(0 3 1 * ? *)"}'

Biểu thức trên nghĩa là 3 giờ sáng ngày 1 hằng tháng. Secrets Manager cũng nhận dạng rate(30 days) nếu không cần mốc cụ thể.

Với RDS, AWS cung cấp sẵn Lambda xoay vòng cho từng engine (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB) — bạn không phải viết mã. Quy trình bốn bước mà hàm đó thực hiện:

Chiến lược "alternating users" (hai tài khoản luân phiên) khiến việc xoay vòng không gây gián đoạn: ứng dụng đang dùng tài khoản A trong khi tài khoản B được đổi mật khẩu, rồi mới chuyển sang.

Ứng dụng chỉ cần luôn lấy bí mật từ Secrets Manager thay vì nhúng cứng:

bi_mat = json.loads(sm.get_secret_value(SecretId='prod/csdl/mat-khau')['SecretString'])
conn = psycopg2.connect(host=bi_mat['host'], user=bi_mat['username'], password=bi_mat['password'])

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

• A. SSM Parameter Store — lưu được giá trị nhạy cảm dưới dạng SecureString, nhưng không có tính năng xoay vòng tích hợp. Muốn xoay vòng thì phải tự viết Lambda, tự lên lịch, tự xử lý bốn bước ở trên — nhiều việc hơn hẳn.
• C. "Dùng AWS RDS để tạo managed rotation" — RDS không có mục Rotation Schedule. RDS quản lý CSDL, không quản lý bí mật. (RDS có tích hợp với Secrets Manager — khi tạo instance, bạn chọn được "Manage master credentials in AWS Secrets Manager" — nhưng cơ chế xoay vòng vẫn thuộc về Secrets Manager.)
• D. "Dùng IAM để tạo managed rotation" — IAM không quản lý mật khẩu CSDL. Nó quản lý danh tính và quyền hạn AWS. (IAM có xoay vòng access key, nhưng đó là thứ khác hẳn — và cũng phải làm thủ công hoặc bằng script.)

Ghi nhớ

Cách chọn:

• Mật khẩu CSDL, khoá API cần xoay vòng định kỳ ⇒ Secrets Manager
• Cấu hình không nhạy cảm (endpoint, feature flag, tên bucket) ⇒ Parameter Store (miễn phí)

Ba lưu ý khi triển khai xoay vòng:

1. Đừng cache bí mật quá lâu trong ứng dụng — nếu cache 24 giờ mà xoay vòng mỗi 12 giờ thì ứng dụng sẽ dùng mật khẩu đã hết hiệu lực. Dùng thư viện caching chính thức của AWS, nó tự làm mới.
2. Lambda xoay vòng phải nằm trong VPC có đường tới CSDL, và cần VPC endpoint cho Secrets Manager (hoặc NAT).
3. Thử xoay vòng ở môi trường staging trước — lỗi ở bước setSecret giữa đêm trên production là loại sự cố rất khó chịu.