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

Đáp án

D — Immutable.

Vì sao đúng

Đề đưa ra hai điều kiện, và điều kiện thứ hai là điểm phân biệt:

1. Không chấp nhận downtime
2. Nếu cập nhật thất bại, rollback phải NHANH và DỄ

Immutable là chính sách duy nhất đáp ứng vế thứ hai một cách trọn vẹn:

1. Tạo một Auto Scaling group TẠM THỜI
2. Khởi chạy MỘT instance mới, chờ nó qua health check
3. Nếu đạt → khởi chạy đủ số instance còn lại
4. Chuyển toàn bộ instance mới sang ASG gốc
5. Huỷ các instance cũ

Vì sao rollback nhanh: nếu bước 2 hoặc 3 thất bại, các instance cũ vẫn đang chạy nguyên vẹn, chưa hề bị đụng tới. Beanstalk chỉ cần huỷ ASG tạm — mất vài giây, và không có instance production nào từng chạy mã lỗi.

Immutable thất bại: [cũ][cũ][cũ][cũ] + [mới ✗]  →  xoá cái mới, xong ngay
Rolling thất bại:   [mới][mới][cũ][cũ]           →  phải TRIỂN KHAI LẠI bản cũ

Bước 2 cũng đáng chú ý: Beanstalk thử một instance trước rồi mới nhân rộng — nên lỗi cấu hình bị phát hiện sớm với chi phí thấp nhất.

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

• B. Rolling — không có downtime (thoả điều kiện 1) nhưng rollback chậm và phiền (trượt điều kiện 2): các instance đã cập nhật đang chạy phiên bản mới, muốn quay lại phải triển khai lại bản cũ qua đúng quy trình rolling — mất thêm chừng ấy thời gian nữa, trong khi lỗi vẫn đang phục vụ người dùng. Rolling còn giảm năng lực trong lúc triển khai.
• A. All at once — có downtime hoàn toàn, trượt ngay điều kiện đầu tiên. Rollback cũng đòi triển khai lại.
• C. Incremental — không phải chính sách của Elastic Beanstalk. Năm chính sách hợp lệ là: All at once, Rolling, Rolling with additional batch, Immutable, và Traffic splitting. ("Incremental" nghe hợp lý nên là bẫy tốt.)

Ghi nhớ

Bảng so sánh — đáng thuộc vì chủ đề này xuất hiện rất thường xuyên: | Chính sách | Downtime | Đủ năng lực | Instance mới | Rollback | |---|---|---|---|---| | All at once | CÓ | ❌ | ❌ | chậm — deploy lại | | Rolling | không | ❌ giảm | ❌ | chậm — deploy lại | | Rolling + additional batch | không | ✅ | tạm thời | chậm — deploy lại | | Immutable | không | ✅ | ✅ toàn bộ | NHANH — huỷ ASG tạm | | Traffic splitting | không | ✅ | ✅ toàn bộ | NHANH — chuyển traffic về |

Cách chọn theo từ khoá trong đề:

• "rollback nhanh", "an toàn nhất" ⇒ Immutable
• "canary", "thử với % người dùng" ⇒ Traffic splitting
• "giữ đủ năng lực, dùng instance hiện có" ⇒ Rolling with additional batch
• "nhanh và rẻ, môi trường dev" ⇒ All at once

Cái giá của Immutable: tốn gấp đôi tài nguyên trong lúc triển khai và chậm nhất trong năm chính sách. Với production thì đó là cái giá xứng đáng — và nó cũng là chính sách AWS khuyến nghị cho môi trường production.

Lưu ý về hạn mức: vì Immutable nhân đôi số instance tạm thời, hãy kiểm tra hạn mức EC2 của tài khoản trước — chạm trần giữa chừng sẽ khiến triển khai thất bại vì lý do chẳng liên quan gì tới mã của bạn.

Đáp án

B — Giữ tệp kết quả và tệp log trong Amazon EFS, cho các hàm Lambda truy cập.

Vì sao đúng

Đề có ba điều kiện, và chúng cùng chỉ về EFS:

1. Lambda chạy trong VPC
2. Tệp phải truy cập được bởi các dịch vụ AWS khác
3. Tệp phải truy cập được bởi tài nguyên tại chỗ (on-premises)

EFS là hệ thống tệp NFS, nên nó phục vụ được cả ba nhóm khách hàng:

Lambda (trong VPC) ──┐
EC2, ECS, EKS ───────┼──→ EFS file system
Máy chủ on-premises ─┘     (qua Direct Connect hoặc VPN)

Vế thứ ba là điểm phân biệt: máy chủ tại chỗ mount EFS được qua Direct Connect hoặc Site-to-Site VPN, dùng đúng giao thức NFS chuẩn:

sudo mount -t nfs4 -o nfsvers=4.1 10.1.2.3:/ /mnt/du-lieu-aws

Với Lambda, mount qua access point:

{"FileSystemConfigs": [{
   "Arn": "arn:aws:elasticfilesystem:...:access-point/fsap-0abc",
   "LocalMountPath": "/mnt/ket-qua"}]}

with open('/mnt/ket-qua/nhat-ky.log', 'a') as f:    # GHI THÊM được
    f.write(f'{datetime.now()} xử lý xong {ten_tep}\n')

Chữ 'a' ở dòng trên là điểm mấu chốt phân biệt với phương án A: EFS hỗ trợ ghi thêm vào tệp có sẵn đúng như hệ thống tệp thông thường.

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

• A. Lưu trên S3 và "ghi thêm các dòng log vào object có sẵn" — S3 KHÔNG hỗ trợ append. Object trên S3 là bất biến; muốn "thêm" thì phải tải toàn bộ object về, nối thêm, rồi ghi đè cả object — cực kỳ tốn kém với tệp log đang lớn dần, và có điều kiện tranh chấp nếu nhiều hàm cùng làm. Đây là bẫy chính của câu hỏi.
• C. Dùng AWS Glue để gộp và lập danh mục rồi "ghi thêm log" — sai công cụ: Glue là dịch vụ ETL và data catalog, dùng để biến đổi và lập chỉ mục dữ liệu cho phân tích. Nó không phải kho lưu trữ tệp và không cho ứng dụng ghi thêm vào tệp.
• D. Lưu tệp trong DynamoDB và bật Streams — DynamoDB không phải nơi lưu tệp: giới hạn 400 KB mỗi item, và nó là CSDL khoá–giá trị chứ không có khái niệm tệp. Streams chỉ gửi thông báo thay đổi, không giải quyết vấn đề truy cập.

Ghi nhớ

Khác biệt cốt lõi giữa S3 và EFS: | | S3 | EFS | |---|---|---| | Mô hình | object, bất biến | hệ thống tệp POSIX | | Ghi thêm (append) | ❌ | ✅ | | Sửa một phần tệp | ❌ (ghi đè cả object) | ✅ | | Truy cập | API HTTPS | mount NFS | | Từ on-premises | qua API | mount được qua DX/VPN | | Khoá tệp | ❌ | ✅ | | Chi phí | rẻ nhất | cao hơn nhiều |

Quy tắc chọn:

• Cần ghi thêm, sửa tại chỗ, hoặc mount như thư mục ⇒ EFS
• Chỉ ghi rồi đọc nguyên object, cần rẻ và bền ⇒ S3

Vài lưu ý khi dùng EFS với Lambda:

1. Hàm phải nằm trong VPC có mount target — và nhớ rằng gắn VPC làm cold start lâu hơn một chút.
2. Dùng access point, đừng mount gốc — nó ép sẵn UID/GID và thư mục riêng cho mỗi ứng dụng.
3. Execution role cần elasticfilesystem:ClientMount và ClientWrite.
4. Cẩn thận với concurrency cao: hàng trăm hàm cùng ghi vào một tệp log sẽ tranh chấp — nên ghi mỗi lần gọi một tệp riêng rồi gộp sau, hoặc đơn giản là dùng CloudWatch Logs cho log.

Đáp án

B — Bật CORS cho method trong API Gateway.

Vì sao đúng

Thông báo lỗi chỉ thẳng nguyên nhân:

No 'Access-Control-Allow-Origin' header is present on the requested resource

Header đó phải do phía trả lời request gửi ra — và ở đây, request đi từ trang web tới API Gateway. Nên API Gateway mới là nơi phải bật CORS, không phải S3.

Cơ chế CORS của trình duyệt hoạt động thế này:

1. Trang web ở origin A gọi API ở origin B
2. Với request "không đơn giản", trình duyệt gửi PREFLIGHT trước:
       OPTIONS /tai-nguyen
       Origin: https://trang-web.com
       Access-Control-Request-Method: POST
3. Máy chủ phải trả lời với các header Access-Control-Allow-*
4. Chỉ khi đó trình duyệt mới gửi request thật

Bật CORS trong API Gateway tự làm hai việc: | Việc | Chi tiết | |---|---| | Tạo method OPTIONS | trả lời preflight bằng mock integration | | Thêm header vào response | Access-Control-Allow-Origin, -Methods, -Headers |

aws apigateway put-method --rest-api-id abc123 --resource-id xyz \
  --http-method OPTIONS --authorization-type NONE
# rồi khai các header Access-Control-Allow-* trong method response và integration response

Với Lambda proxy integration, còn phải thêm header trong chính mã hàm — vì API Gateway chuyển nguyên response của hàm về client:

return {
    'statusCode': 200,
    'headers': {
        'Access-Control-Allow-Origin': 'https://trang-web.com',
        'Access-Control-Allow-Credentials': True
    },
    'body': json.dumps(ket_qua)
}

Đây là chi tiết bị bỏ sót nhiều nhất: bật CORS trong Console chỉ lo được method OPTIONS; response của GET/POST vẫn thiếu header nếu hàm không tự thêm.

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

• A. Bật CORS trên S3 bucket — bẫy chính. CORS trên S3 quy định ai được gọi tới S3; ở đây S3 chỉ phục vụ trang web tĩnh, còn request bị chặn là request đi tới API Gateway. Bật CORS ở S3 hoàn toàn không chạm tới vấn đề.
• C. Thêm header Access-Control-Request-Method vào request và D. Thêm Access-Control-Request-Headers — cả hai đều là header của REQUEST preflight, do TRÌNH DUYỆT tự gửi. Lập trình viên không thêm chúng bằng tay, và chúng cũng không phải thứ đang thiếu — thứ thiếu là header Access-Control-Allow-Origin trong RESPONSE.

Ghi nhớ

Phân biệt hai nhóm header CORS — nhầm chúng là lỗi hiểu phổ biến nhất: | Nhóm | Ai gửi | Ví dụ | |---|---|---| | Request (Access-Control-Request-*) | trình duyệt, tự động | -Method, -Headers | | Response (Access-Control-Allow-*) | máy chủ, bạn phải cấu hình | -Origin, -Methods, -Headers, -Credentials |

Nguyên tắc: CORS luôn được bật ở phía MÁY CHỦ TRẢ LỜI request, không phải ở phía trang web gọi đi.

Về chi tiết Origin 'null' trong thông báo lỗi: nó xuất hiện khi trang được mở bằng file:// thay vì qua HTTP. Đó là dấu hiệu ai đó đang mở tệp HTML trực tiếp trên máy — trong trường hợp đó, kể cả cấu hình CORS đúng cũng vẫn lỗi, vì null hiếm khi nằm trong danh sách origin được phép. Cách thử đúng là mở trang qua chính S3 website endpoint hoặc một máy chủ HTTP cục bộ.

Và lưu ý bảo mật: đừng để Access-Control-Allow-Origin: * cho API có xác thực. Với Allow-Credentials: true, trình duyệt từ chối wildcard — phải khai origin cụ thể.

Đáp án

C — Origin response.

Vì sao đúng

CloudFront có bốn điểm gắn Lambda@Edge, và việc chọn đúng điểm phụ thuộc vào khi nào bạn biết được thông tin cần thiết.

Ở đây, thông tin cần là mã trạng thái 404 từ origin — và nó chỉ tồn tại sau khi origin đã trả lời:

Viewer request  → CloudFront → Origin request → ALB
                                                  ↓ trả về 404
Viewer response ← CloudFront ← Origin response ←──┘
                                     ↑
                          ĐÂY: đã biết là 404, sửa được thành redirect

exports.handler = async (event) => {
    const response = event.Records[0].cf.response;
    if (response.status === '404') {
        return {
            status: '302',
            statusDescription: 'Found',
            headers: {
                location: [{ key: 'Location', value: '/noi-dung-thay-the' }]
            }
        };
    }
    return response;
};

Và có một lý do thứ hai khiến origin response là lựa chọn đúng cho vế "minimum amount of resources":

Vì phần lớn request được cache phục vụ, hàm ở origin response chạy ít hơn rất nhiều — nghĩa là ít lời gọi Lambda hơn và rẻ hơn. Kết quả redirect cũng được cache lại, nên các request sau cho cùng đường dẫn không cần gọi hàm nữa.

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

• D. Viewer response — cũng nhìn thấy mã 404 và cũng sửa được, nhưng nó chạy ở MỌI response gửi về client, kể cả hàng nghìn response 200 lấy từ cache. Tốn tài nguyên hơn hẳn mà không thêm lợi ích nào. Ngoài ra kết quả sửa ở đây không được cache.
• B. Origin request — chạy TRƯỚC khi gửi request tới origin, nên chưa biết origin sẽ trả về gì. Không thể phản ứng với 404 tại điểm này.
• A. Viewer request — chạy sớm nhất, ngay khi CloudFront nhận request. Càng không biết gì về phản hồi của origin.

Ghi nhớ

Bốn điểm gắn và công dụng điển hình: | Điểm | Chạy khi | Dùng cho | |---|---|---| | Viewer request | mọi request đến | xác thực, chuẩn hoá URL, A/B testing | | Origin request | cache miss, trước khi hỏi origin | chọn origin động, sửa đường dẫn | | Origin response | cache miss, sau khi origin trả lời | xử lý lỗi, thêm header, sửa nội dung | | Viewer response | mọi response trả về | thêm header bảo mật cho MỌI response |

Quy tắc chọn: muốn phản ứng với phản hồi của origin ⇒ origin response. Muốn áp cho mọi request bất kể cache ⇒ viewer.

Giới hạn của Lambda@Edge khác hẳn Lambda thường: | | Viewer request/response | Origin request/response | |---|---|---| | Timeout | 5 giây | 30 giây | | Bộ nhớ | 128 MB cố định | tới 10 GB | | Kích thước gói | 1 MB | 50 MB |

Và với các việc rất đơn giản (viết lại URL, thêm header, chuyển hướng cơ bản), cân nhắc CloudFront Functions thay vì Lambda@Edge: nó chạy bằng JavaScript thuần ở edge, nhanh hơn nhiều và rẻ hơn khoảng 6 lần — nhưng chỉ gắn được vào viewer request/response và không gọi được dịch vụ mạng. Câu này cần origin response nên bắt buộc dùng Lambda@Edge.

Đáp án

A — Amazon Cognito identity pools.

Vì sao đúng

Đề nêu ba yêu cầu, và chỉ identity pool đáp ứng đủ với ít mã nhất:

1. Hỗ trợ SAML
2. Hỗ trợ nhà cung cấp danh tính xã hội (Google, Facebook, Apple…)
3. Được uỷ quyền truy cập S3 và DynamoDB

Yêu cầu thứ ba là điểm quyết định: để gọi được S3 và DynamoDB trực tiếp, ứng dụng cần thông tin xác thực AWS — và identity pool chính là bộ đổi danh tính lấy credential AWS:

Người dùng đăng nhập qua SAML / Google / Facebook / Cognito user pool
        ↓ token
   Cognito Identity Pool
        ↓ sts:AssumeRoleWithWebIdentity
   Credential AWS TẠM THỜI (access key, secret, session token)
        ↓
   Gọi thẳng S3 và DynamoDB từ ứng dụng

const credentials = fromCognitoIdentityPool({
  identityPoolId: 'ap-southeast-1:xxxx-xxxx',
  logins: { 'accounts.google.com': googleToken }
});
const s3 = new S3Client({ credentials });   // gọi S3 với danh tính của chính người dùng

Identity pool hỗ trợ rất nhiều nguồn danh tính cùng lúc: | Nguồn | Hỗ trợ | |---|---| | SAML 2.0 | ✅ | | Google, Facebook, Amazon, Apple | ✅ | | OpenID Connect | ✅ | | Cognito user pool | ✅ | | Guest (chưa xác thực) | ✅ |

Và nó còn cho phép phân quyền tới từng người dùng bằng biến thay thế trong IAM policy:

"Resource": "arn:aws:s3:::du-lieu/${cognito-identity.amazonaws.com:sub}/*"

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

• C. Cognito user pools — đây là phương án gần nhất và cần phân biệt kỹ. User pool có hỗ trợ SAML và social login, và nó xác thực rất tốt. Nhưng nó chỉ phát ra JWT, mà JWT không gọi được S3 hay DynamoDB — hai dịch vụ đó cần chữ ký SigV4 từ credential AWS. Muốn có credential thì vẫn phải đi qua identity pool. (Kiến trúc đầy đủ thường dùng cả hai: user pool xác thực, identity pool cấp credential.)
• B. API Gateway REST API — là cửa ngõ, không phải cơ chế danh tính. Nó không có sẵn hỗ trợ SAML hay social login (phải tự viết Lambda authorizer), và bản thân nó không cấp credential AWS.
• D. AppSync GraphQL API — cũng là cửa ngõ dữ liệu, hỗ trợ Cognito và OIDC làm cơ chế xác thực nhưng không phải nhà cung cấp danh tính. Và nó không giảm mã cho bài toán này — bạn vẫn cần Cognito ở dưới.

Ghi nhớ

Câu thần chú: cần JWT ⇒ user pool. Cần credential AWS ⇒ identity pool.

Nhận dạng nhanh trong đề: thấy cụm "authorized to access data in S3 / DynamoDB" hoặc "gọi trực tiếp dịch vụ AWS" ⇒ identity pool. Thấy "đăng ký, đăng nhập, quản lý người dùng" ⇒ user pool.

Và với identity pool, nhớ có hai role: một cho người dùng đã xác thực và một cho khách — cấu hình role của khách quá rộng là lỗ hổng hay gặp, vì bất kỳ ai trên Internet cũng lấy được credential đó.

Đáp án

C — Dùng Parallel state để chạy các nhánh đồng thời.

Vì sao đúng

Vấn đề: nhiều hàm Lambda tra cứu các thông tin độc lập với nhau (địa chỉ, số điện thoại…), và chúng đang chạy tuần tự:

Tuần tự:  [địa chỉ 200ms] → [điện thoại 180ms] → [email 150ms] = 530 ms

Song song: ┌ [địa chỉ 200ms] ┐
           ├ [điện thoại 180ms] ┤ = 200 ms  ← thời gian của nhánh CHẬM NHẤT
           └ [email 150ms] ┘

Parallel state chạy tất cả nhánh cùng lúc, và tổng thời gian bằng nhánh chậm nhất thay vì tổng các nhánh:

{
  "TraCuuKhachHang": {
    "Type": "Parallel",
    "Branches": [
      {"StartAt": "LayDiaChi",
       "States": {"LayDiaChi": {"Type": "Task", "Resource": "arn:...:function:dia-chi", "End": true}}},
      {"StartAt": "LayDienThoai",
       "States": {"LayDienThoai": {"Type": "Task", "Resource": "arn:...:function:dien-thoai", "End": true}}},
      {"StartAt": "LayEmail",
       "States": {"LayEmail": {"Type": "Task", "Resource": "arn:...:function:email", "End": true}}}
    ],
    "ResultPath": "$.ketQua",
    "Next": "TongHop"
  }
}

Hai đặc điểm cần biết:

• Mỗi nhánh nhận CÙNG một đầu vào
• Kết quả là một MẢNG, theo đúng thứ tự khai báo nhánh — không phải theo thứ tự hoàn thành

Đề nói lập trình viên "đã tạo các branch" — nghĩa là cấu trúc đã sẵn sàng, chỉ cần đặt chúng trong Parallel state.

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

• A. Map state — cũng chạy song song, nhưng cho một mục đích khác: nó lặp qua các phần tử của một MẢNG, chạy CÙNG MỘT logic cho mỗi phần tử. Ở đây có các hàm KHÁC NHAU cho các loại thông tin khác nhau — đó là Parallel, không phải Map.

  Map:      cùng một logic × nhiều dữ liệu
  Parallel: nhiều logic khác nhau × cùng một dữ liệu
  

• B. Choice state — rẽ nhánh theo điều kiện: chọn MỘT đường đi trong nhiều đường. Nó không chạy song song gì cả, và ở đây ta cần tất cả thông tin chứ không phải chọn một.
• D. Wait state — tạm dừng máy trạng thái trong một khoảng thời gian hoặc tới một mốc. Nó làm chậm hơn, không nhanh hơn — mô tả trong phương án ("giảm thời gian chờ") hoàn toàn ngược với chức năng thật.

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…) | | 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 | | Choice | rẽ nhánh theo điều kiện | | Wait | tạm dừng | | Pass | truyền dữ liệu, biến đổi, hoặc làm chỗ giữ chỗ | | Succeed / Fail | kết thúc |

Phân biệt Parallel và Map — đây là cặp hay bị hỏi nhất: | | Parallel | Map | |---|---|---| | Số nhánh | cố định, khai trong định nghĩa | theo số phần tử đầu vào | | Logic | khác nhau mỗi nhánh | giống nhau | | Ví dụ | tra cứu địa chỉ + điện thoại + email | xử lý 1.000 tệp ảnh |

Hai lưu ý về Parallel:

1. Một nhánh hỏng là cả state hỏng — các nhánh khác bị huỷ. Muốn chịu lỗi từng nhánh thì thêm Catch bên trong mỗi nhánh.
2. Với Map, có thêm MaxConcurrency để giới hạn số phần tử chạy đồng thời — hữu ích khi downstream có hạn mức.

Đáp án

C — Dùng Route 53 để đăng ký tên miền, định tuyến traffic Internet tới tên miền, và khai các giá trị để thực hiện health check trên tài nguyên.

Vì sao đúng

Route 53 làm cả ba việc mà đề nêu — đó là điểm mấu chốt, vì các phương án sai đều chia bớt việc cho dịch vụ khác:

Về vế health check, cách khai đúng như phương án C mô tả — bạn chỉ định các giá trị để Route 53 biết kiểm tra cái gì:

aws route53 create-health-check --caller-reference kiem-tra-web-01 \
  --health-check-config '{
    "IPAddress": "203.0.113.10",
    "Port": 443,
    "Type": "HTTPS",
    "ResourcePath": "/health",
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

Route 53 kiểm tra từ nhiều vị trí trên toàn cầu, và khi endpoint được coi là không lành, nó tự động ngừng trả về bản ghi đó — traffic chuyển sang endpoint dự phòng mà không cần ai can thiệp.

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

• A. Route 53 đăng ký và định tuyến, Shield làm health check — AWS Shield là dịch vụ chống DDoS. Nó không có health check và không giám sát tình trạng endpoint.
• D. Route 53 đăng ký, ACM định tuyến, Shield health check — sai hai chỗ: ACM cấp và quản lý chứng chỉ TLS, nó không định tuyến gì cả; và Shield vẫn không làm health check.
• B. "Route 53 để chỉ định địa chỉ IP nhằm thực hiện health check, đăng ký tên miền, và định tuyến" — đây là phương án gần nhất và khác biệt rất tinh tế. Cả ba việc đều đúng thuộc về Route 53, nhưng cách diễn đạt thu hẹp health check thành chỉ mỗi địa chỉ IP. Thực tế health check cấu hình bằng nhiều giá trị — kiểu (HTTP/HTTPS/TCP), cổng, đường dẫn, khoảng thời gian, ngưỡng thất bại — và có loại health check không dùng IP chút nào (theo tên miền, theo CloudWatch alarm, hoặc calculated health check). Phương án C nói "specify the values" mới bao quát đúng.

Ghi nhớ

Ba vai trò của Route 53 — dịch vụ này làm cả ba, khác với nhiều dịch vụ DNS khác: | Vai trò | Chi tiết | |---|---| | Domain registration | mua, chuyển, gia hạn tên miền | | DNS có thẩm quyền | hosted zone công khai và riêng tư | | Health check + failover | giám sát và tự chuyển traffic |

Ba loại health check: | Loại | Kiểm tra | |---|---| | Endpoint | gọi HTTP/HTTPS/TCP tới một IP hoặc tên miền | | Calculated | kết hợp nhiều health check khác bằng AND/OR | | CloudWatch alarm | dựa vào trạng thái của một alarm — hữu ích cho tài nguyên không có endpoint công khai |

Các chính sách định tuyến, để chọn đúng khi đề hỏi: | Chính sách | Dùng khi | |---|---| | Simple | một tài nguyên | | Failover | chủ động – dự phòng | | Latency-based | người dùng nhiều Region, cần nhanh nhất | | Geolocation | phục vụ nội dung theo quốc gia | | Weighted | chia % traffic — canary, A/B | | Multivalue answer | trả nhiều IP, có health check |

Và lưu ý thực dụng: health check của Route 53 cần endpoint truy cập được từ Internet công khai. Với tài nguyên trong private subnet, dùng loại CloudWatch alarm thay thế.

Đáp án

B — Metric Latency.

Vì sao đúng

Đề định nghĩa rất chính xác thứ cần đo: thời gian từ khi API Gateway NHẬN request cho tới khi TRẢ response về client.

Đó đúng là định nghĩa của metric Latency — nó bao trùm toàn bộ thời gian API Gateway giữ request:

Client ──request──→ API Gateway ──→ Backend
                        │              │
                        │◄─ IntegrationLatency ─►│
                        │
       │◄────────── Latency (TOÀN BỘ) ──────────►│
                        │
Client ◄──response── API Gateway ◄──┘

Hai metric này chênh nhau đúng bằng phần chi phí của chính API Gateway: xác thực, uỷ quyền (kể cả gọi Lambda authorizer), kiểm tra request, mapping template, tra cache, ghi log.

Đó cũng là lý do so sánh hai metric rất hữu ích khi chẩn đoán: | Quan sát | Kết luận | |---|---| | Latency ≈ IntegrationLatency | backend chậm — tối ưu Lambda hoặc CSDL | | Latency ≫ IntegrationLatency | API Gateway chậm — thường do Lambda authorizer, mapping template phức tạp, hoặc request validation |

Trường hợp thứ hai rất hay gặp mà ít người nghĩ tới: một Lambda authorizer chậm sẽ cộng thẳng vào Latency của mọi request, trong khi IntegrationLatency trông hoàn toàn bình thường.

aws cloudwatch get-metric-statistics \
  --namespace AWS/ApiGateway --metric-name Latency \
  --dimensions Name=ApiName,Value=ApiCuaToi Name=Stage,Value=prod \
  --start-time 2026-08-05T00:00:00Z --end-time 2026-08-05T23:59:59Z \
  --period 300 --statistics Average p99

Nên xem p99 và p95, không chỉ Average — độ trễ đuôi mới là thứ người dùng phàn nàn.

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

• A. IntegrationLatency — đây là phương án gần nhất, và nó đo chỉ phần backend: từ lúc API Gateway chuyển tiếp request tới backend cho tới lúc nhận được phản hồi. Nó bỏ sót toàn bộ chi phí của chính API Gateway — mà đề hỏi từ lúc "receives a request from a client".
• C. CacheHitCount — đếm số lần được phục vụ từ cache. Hữu ích để đánh giá hiệu quả cache, nhưng nó là số đếm, không phải thời gian.
• D. 5XXError — đếm số lỗi phía máy chủ. Cho biết có bao nhiêu request hỏng, không cho biết chúng mất bao lâu.

Ghi nhớ

Các metric của API Gateway: | Metric | Đo | |---|---| | Latency | TOÀN BỘ thời gian API Gateway xử lý | | IntegrationLatency | chỉ phần backend | | Count | tổng số request | | 4XXError | lỗi phía client (400, 403, 429…) | | 5XXError | lỗi phía máy chủ (500, 502, 504) | | CacheHitCount / CacheMissCount | hiệu quả cache |

Nguyên tắc chẩn đoán độ trễ: luôn xem Latency và IntegrationLatency cùng nhau. Một con số đơn lẻ không cho biết vấn đề nằm ở đâu.

Vài chi tiết đáng nhớ:

• Count không tính request bị chặn bởi WAF hoặc bị throttle trước khi vào.
• Muốn có metric theo từng method và resource, phải bật detailed metrics ở stage — và nó có tính phí theo số metric sinh ra.
• Với chuỗi nhiều dịch vụ, X-Ray cho bức tranh đầy đủ hơn metric: nó tách được thời gian ở authorizer, ở integration, và ở từng dịch vụ downstream.

Đáp án

D — Tạo AWS Cloud9 EC2 environment, môi trường này tự cấp phát phần lớn tài nguyên và quản lý vòng đời của chúng.

Vì sao đúng

Cloud9 có hai kiểu môi trường, và khác biệt nằm đúng ở chỗ đề quan tâm — công sức cấu hình:

EC2 environment đúng là lựa chọn "spend minimal time configuring resources": bạn chọn instance type, Cloud9 lo phần còn lại — tạo instance, cài môi trường phát triển, cấu hình quyền, và tự dừng instance khi không dùng để khỏi tốn tiền.

aws cloud9 create-environment-ec2 \
  --name moi-truong-phat-trien \
  --instance-type t3.small \
  --image-id amazonlinux-2023-x86_64 \
  --automatic-stop-time-minutes 30

Tính năng tự dừng sau 30 phút không hoạt động đáng chú ý: bạn chỉ trả tiền EC2 cho thời gian thực sự làm việc, và lần sau mở IDE ra thì Cloud9 tự khởi động lại máy.

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

• B. Tạo SSH environment — nhiều việc hơn hẳn: bạn phải tự chuẩn bị máy chủ (EC2 hoặc máy vật lý), tự cài Node.js và các phụ thuộc của Cloud9, tự cấu hình khoá SSH, tự quản lý vòng đời. SSH environment chỉ đáng dùng khi bắt buộc phải làm việc trên một máy có sẵn — ví dụ máy on-premises hoặc máy có cấu hình đặc thù.
• A. "Dùng AWS Toolkit để tạo EC2 environment" và C. "Dùng AWS Toolkit để tạo SSH environment" — nhầm công cụ: AWS Toolkit là bộ mở rộng cho các IDE khác (VS Code, JetBrains, Visual Studio), giúp phát triển ứng dụng AWS từ IDE trên máy bạn. Nó không tạo môi trường Cloud9; hai thứ này là các con đường thay thế nhau, không phải bổ sung cho nhau.

Ghi nhớ

Cloud9 là IDE chạy trên trình duyệt, và điểm mạnh của nó: | Tính năng | Chi tiết | |---|---| | Cài sẵn công cụ AWS | AWS CLI, SAM CLI, Docker, Git, nhiều runtime | | Dùng credential tạm thời | AWS managed temporary credentials — không cần lưu access key | | Cộng tác thời gian thực | nhiều người cùng sửa một tệp, có chat | | Gỡ lỗi tích hợp | breakpoint cho Lambda, Node.js, Python | | Truy cập từ mọi nơi | chỉ cần trình duyệt |

Đặc điểm đáng chú ý nhất về bảo mật: AWS managed temporary credentials — Cloud9 tự cung cấp credential tạm thời của chính người dùng đang đăng nhập, nên không có access key nào nằm trên đĩa. Đây là lý do tốt để dùng Cloud9 cho việc thử nghiệm nhanh với AWS CLI.

Vài lưu ý thực dụng:

• Cloud9 không tính phí riêng — bạn chỉ trả tiền EC2 và EBS bên dưới.
• Muốn làm việc với tài nguyên trong private subnet, đặt môi trường vào đúng VPC đó (cần NAT hoặc VPC endpoint để Cloud9 kết nối được).
• Ổ đĩa mặc định khá nhỏ; dự án lớn nên tăng dung lượng EBS ngay từ đầu.

(Ghi chú thời sự: từ giữa năm 2024, AWS ngừng nhận khách hàng mới cho Cloud9; các tài khoản đã dùng vẫn tiếp tục hoạt động. AWS hướng người dùng mới sang CodeCatalyst Dev Environments hoặc dùng AWS Toolkit với IDE cục bộ. Câu hỏi vẫn nằm trong phạm vi kỳ thi, nhưng với dự án mới thì đừng chọn Cloud9 làm nền tảng.)

Đáp án

B — Dùng DynamoDB Encryption Client để mã hoá phía client, bảo vệ đầu-cuối.

Vì sao đúng

Chính sách bảo mật trong đề rất cụ thể: "dữ liệu phải được mã hoá TRƯỚC KHI gửi tới DynamoDB".

Đó là định nghĩa của client-side encryption, và nó khác hẳn mã hoá at-rest mà DynamoDB cung cấp sẵn:

Client-side (yêu cầu của đề):
  Ứng dụng mã hoá → gửi ciphertext qua mạng → DynamoDB lưu ciphertext
  → DynamoDB KHÔNG BAO GIỜ thấy bản rõ

Server-side (mặc định của DynamoDB):
  Ứng dụng gửi bản rõ → DynamoDB nhận BẢN RÕ → rồi mới mã hoá khi ghi xuống đĩa

Với server-side, DynamoDB có thấy bản rõ ở thời điểm nhận request — nên nó không thoả yêu cầu "encrypted before it is submitted".

DynamoDB Encryption Client làm việc này ở mức thuộc tính:

from dynamodb_encryption_sdk.encrypted.table import EncryptedTable
from dynamodb_encryption_sdk.material_providers.aws_kms import AwsKmsCryptographicMaterialsProvider

provider = AwsKmsCryptographicMaterialsProvider(key_id='arn:aws:kms:...:key/abc')
bang_ma_hoa = EncryptedTable(table=dynamodb.Table('du-lieu-nhay-cam'),
                             materials_provider=provider)

bang_ma_hoa.put_item(Item={'id': 'KH-001', 'soCMND': '123456789'})
# soCMND được mã hoá TRƯỚC khi rời khỏi ứng dụng

Hai đặc điểm quan trọng của thư viện này: | Đặc điểm | Chi tiết | |---|---| | Khoá chính không bị mã hoá | để DynamoDB vẫn Query và Scan được | | Ký số toàn item | phát hiện nếu ai đó sửa dữ liệu trực tiếp trong bảng |

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

• C. UpdateTable để chuyển sang customer managed CMK và D. UpdateTable để chuyển sang AWS managed CMK — cả hai đều là server-side encryption. Chúng cải thiện việc kiểm soát khoá và vết kiểm toán, nhưng DynamoDB vẫn nhận bản rõ rồi mới mã hoá. Không thoả yêu cầu của đề. (Ghi chú: DynamoDB đã mã hoá at-rest cho MỌI bảng theo mặc định kể từ 2018 — nên hai phương án này chỉ đổi loại khoá, không phải bật thêm mã hoá.)
• A. Dùng ACM tạo một chứng chỉ cho mỗi bảng DynamoDB — không có cơ chế nào như vậy. ACM cấp chứng chỉ TLS cho tên miền và gắn vào ELB, CloudFront, API Gateway. Bảng DynamoDB không nhận chứng chỉ.

Ghi nhớ

Ba lớp mã hoá của DynamoDB: | Lớp | Ai mã hoá | DynamoDB thấy bản rõ? | |---|---|---| | In transit | TLS, luôn bật | — | | At rest (SSE) | DynamoDB, mặc định | ✅ CÓ | | Client-side | ứng dụng của bạn | ❌ KHÔNG |

Ba loại khoá cho SSE của DynamoDB: | Loại | Chi phí | Kiểm soát | |---|---|---| | AWS owned key | miễn phí, mặc định | không thấy khoá | | AWS managed key (aws/dynamodb) | có phí KMS | thấy trong CloudTrail | | Customer managed CMK | có phí | toàn quyền: tắt khoá, đặt key policy, xoay vòng |

Nhận dạng nhanh trong đề: cụm "before it is submitted", "end-to-end", "AWS must not see the plaintext" ⇒ client-side encryption. Cụm "encrypted at rest", "kiểm soát khoá" ⇒ SSE với CMK.

Cái giá của client-side encryption cần cân nhắc thật: thuộc tính đã mã hoá không dùng làm điều kiện lọc được (FilterExpression, ConditionExpression), không tạo GSI trên đó được, và mỗi thao tác đọc/ghi tốn thêm một lời gọi KMS (giảm được bằng caching material provider). Nên chỉ mã hoá những trường thật sự nhạy cảm, đừng mã hoá cả item.