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

Đáp án

A — Task Placement Constraint.

Vì sao đúng

Yêu cầu là đặt task lên đúng nhóm instance có tên "databases" — đó là một ràng buộc về nơi được phép chạy, và ECS gọi cơ chế đó là placement constraint.

ECS phân biệt rất rõ hai khái niệm: | Khái niệm | Vai trò | |---|---| | Constraint | BỘ LỌC — instance nào ĐƯỢC PHÉP nhận task | | Strategy | ƯU TIÊN — trong số các instance hợp lệ, chọn cái nào |

Với yêu cầu "phải nằm trong nhóm databases", ta cần bộ lọc, dùng constraint kiểu memberOf:

{
  "family": "csdl",
  "placementConstraints": [
    {"type": "memberOf", "expression": "task:group == databases"}
  ]
}

Hoặc lọc theo thuộc tính tuỳ chỉnh gắn lên instance:

# Gắn thuộc tính cho instance
aws ecs put-attributes --cluster cum-chinh \
  --attributes name=loai-may,value=csdl,targetId=<arn-container-instance>

{"type": "memberOf", "expression": "attribute:loai-may == csdl"}

Hiệu lực là tuyệt đối: nếu không có instance nào thoả biểu thức, task ở trạng thái PENDING thay vì được đặt lên máy khác.

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

• B. Cluster Query Language — đây là phương án gần nhất và cần phân biệt kỹ: Cluster Query Language là CÚ PHÁP dùng để viết biểu thức trong constraint (attribute:ecs.instance-type =~ t3.*). Nó là ngôn ngữ, không phải cơ chế — bạn không "dùng CQL" để điều khiển đặt task, bạn dùng placement constraint và viết biểu thức bằng CQL.
• C. ECS Container Agent — phần mềm chạy trên mỗi container instance, lo việc đăng ký instance vào cluster và khởi chạy container theo lệnh của ECS. Nó thực thi quyết định, không đưa ra quyết định đặt task.
• D. IAM Group — chỉ chứa IAM user và dùng để phân quyền. Không liên quan gì tới việc đặt task lên instance nào.

Ghi nhớ

Hai constraint của ECS (bộ lọc): | Type | Hành vi | |---|---| | distinctInstance | mỗi instance tối đa một task | | memberOf | chỉ instance thoả biểu thức Cluster Query Language |

Vài biểu thức CQL hữu ích:

attribute:ecs.instance-type =~ t3.*                    họ instance
attribute:ecs.availability-zone in [ap-southeast-1a, ap-southeast-1c]
attribute:ecs.os-type == linux
attribute:loai-may == csdl                             thuộc tính tuỳ chỉnh
task:group == databases                                nhóm task

Ba strategy của ECS (ưu tiên): | Type | Mục tiêu | |---|---| | spread | rải đều — sẵn sàng cao | | binpack | dồn chặt — tiết kiệm chi phí | | random | ngẫu nhiên |

Thứ tự áp dụng: constraint chạy trước để thu hẹp tập ứng viên, rồi strategy mới chọn trong tập đó — nên hai cơ chế này kết hợp được:

"placementConstraints": [{"type": "memberOf", "expression": "attribute:loai-may == csdl"}],
"placementStrategy": [{"field": "attribute:ecs.availability-zone", "type": "spread"}]

Cấu hình này nghĩa là: chỉ chạy trên máy loại csdl, và trong số đó thì rải đều giữa các AZ.

Cách nhớ nhanh khi làm bài: | Đề nói | Chọn | |---|---| | "must", "only on", "in the X group" | constraint | | "distribute evenly", "high availability" | strategy spread | | "minimize instances", "reduce cost" | strategy binpack |

Và lưu ý: với Fargate, placement constraint không dùng được — không có instance nào để lọc, vì AWS quản lý toàn bộ hạ tầng.

Đáp án

B — Immutable.

Vì sao đúng

Đề đưa ra một ưu tiên duy nhất và rất rõ: khả năng rollback nhanh phải được đặt lên trên mọi cân nhắc khác.

Immutable là chính sách có rollback nhanh nhất trong bốn phương án, và lý do nằm ở cách nó hoạt động:

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ũ

Điểm mấu chốt: cho tới bước 4, các instance cũ vẫn chạy nguyên vẹn và chưa hề bị đụng tới. Nên nếu có vấn đề, 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.

So sánh trực quan:

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 — lỗi cấu hình bị phát hiện sớm với chi phí thấp nhất.

Cái giá phải trả: 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. Nhưng đề đã nói rõ rollback là ưu tiên số một, nên đó là đánh đổi chấp nhận được — và đây cũng là chính sách AWS khuyến nghị cho production.

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

• A. Rolling with additional batch và D. Rolling — cả hai cập nhật TẠI CHỖ trên các instance đang chạy. Khi triển khai hỏng, các instance đã cập nhật vẫn đang chạy bản mới, nên muốn quay lại phải triển khai lại phiên bản cũ qua đúng quy trình đó — mất thêm chừng ấy thời gian, trong khi lỗi vẫn đang phục vụ người dùng.
• C. All at once — tệ nhất về mọi mặt cho yêu cầu này: gây downtime hoàn toàn, và rollback cũng đòi triển khai lại toàn bộ.

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Ó | ❌ | 0 | chậm — deploy lại | | Rolling | không | ❌ giảm | 0 | chậm — deploy lại | | Rolling + additional batch | không | ✅ | một lô | 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 đề: | Đề nhấn mạnh | Chọn | |---|---| | "rollback nhanh", "an toàn nhất", "critical application" | Immutable | | "không giảm năng lực" + "tiết kiệm chi phí" | Rolling with additional batch | | "canary", "thử với % người dùng" | Traffic splitting | | "nhanh và rẻ, môi trường dev" | All at once |

Lưu ý về hạn mức khi dùng Immutable: vì nó 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.

Và Traffic splitting cũng có rollback nhanh tương đương Immutable — nó dựa trên Immutable rồi thêm bước chia traffic theo tỷ lệ. Chọn nó khi muốn canary release; chọn Immutable khi chỉ cần an toàn và rollback nhanh mà không cần thử nghiệm dần.

Đáp án

C — dynamodb:UpdateItem, dynamodb:GetItem, và dynamodb:PutItem.

Vì sao đúng

Đề mô tả ba thao tác mà hàm phải làm được, và mỗi thao tác cần một quyền:

{
  "Effect": "Allow",
  "Action": [
    "dynamodb:GetItem",
    "dynamodb:UpdateItem",
    "dynamodb:PutItem"
  ],
  "Resource": "arn:aws:dynamodb:ap-southeast-1:123456789012:table/BangCuaToi"
}

Chú ý sự khác nhau giữa hai quyền ghi — đây là chỗ hay nhầm: | API | Hành vi | |---|---| | PutItem | THAY THẾ toàn bộ item (hoặc tạo mới nếu chưa có) | | UpdateItem | sửa MỘT SỐ thuộc tính, giữ nguyên phần còn lại |

Đề nói "update SOME of its attributes", nên UpdateItem là bắt buộc — dùng PutItem sẽ xoá mất các thuộc tính không được nêu trong request.

(Ghi chú thực dụng: UpdateItem thực ra làm được cả hai việc — nó tự tạo item nếu chưa tồn tại (hành vi upsert). Nên trong thực tế, chỉ GetItem + UpdateItem là đủ, và đó là cách viết gọn hơn:

table.update_item(
    Key={'id': 'SP-001'},
    UpdateExpression='SET so_luong = :n, cap_nhat_luc = :t',
    ExpressionAttributeValues={':n': 42, ':t': int(time.time())}
)   # tự tạo item nếu chưa có

Nhưng câu hỏi liệt kê ba việc riêng biệt, nên đáp án gồm cả ba quyền.)

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

• B. UpdateItem, GetItem, DescribeTable — hai quyền đầu đúng, nhưng DescribeTable trả về METADATA của bảng (lược đồ khoá, capacity, index, kích thước). Nó không tạo được item, nên thiếu khả năng "create if not exists".
• A. DeleteItem, GetItem, PutItem — DeleteItem không được yêu cầu (thừa quyền, vi phạm đặc quyền tối thiểu), và thiếu UpdateItem — nên không sửa được một phần thuộc tính.
• D. GetRecords, PutItem, UpdateTable — sai hai chỗ nghiêm trọng: GetRecords thuộc về DynamoDB Streams (đọc luồng thay đổi), không phải đọc item; và UpdateTable sửa CẤU HÌNH bảng (capacity, index), không phải sửa dữ liệu.

Ghi nhớ

Phân biệt hai nhóm quyền của DynamoDB — nhầm chỗ này rất phổ biến: | Nhóm | Action | Tác động lên | |---|---|---| | Dữ liệu (data plane) | GetItem, PutItem, UpdateItem, DeleteItem, Query, Scan, BatchGetItem, BatchWriteItem | item trong bảng | | Quản trị (control plane) | CreateTable, UpdateTable, DeleteTable, DescribeTable, ListTables | cấu hình bảng | | Streams | GetRecords, GetShardIterator, DescribeStream | luồng thay đổi |

Cách chọn API ghi: | Nhu cầu | API | |---|---| | Tạo mới hoặc thay thế hoàn toàn | PutItem | | Sửa vài thuộc tính, giữ phần còn lại | UpdateItem | | Tăng/giảm một số một cách nguyên tử | UpdateItem với ADD hoặc SET x = x + :n | | Nhiều item, tất cả hoặc không | TransactWriteItems |

Và nguyên tắc đặc quyền tối thiểu: chỉ định ARN của bảng cụ thể, đừng dùng "Resource": "*". Nếu bảng có GSI và hàm cần truy vấn qua chúng, nhớ thêm dòng thứ hai:

"Resource": [
  "arn:aws:dynamodb:...:table/BangCuaToi",
  "arn:aws:dynamodb:...:table/BangCuaToi/index/*"
]

Thiếu dòng thứ hai là Query trên index bị từ chối, dù quyền trên bảng đã có.

Đáp án

A và C.

• C — Dùng group để gán quyền cho người dùng
• A — Tạo standalone policy (managed policy) thay vì inline policy

Vì sao đúng

Cả hai đều là khuyến nghị chính thức trong tài liệu thực hành tốt của IAM.

C — quản lý quyền qua group. Gán policy cho từng user riêng lẻ sẽ trở nên không kiểm soát nổi khi số người tăng lên:

aws iam create-group --group-name LapTrinhVien
aws iam attach-group-policy --group-name LapTrinhVien \
  --policy-arn arn:aws:iam::123456789012:policy/QuyenLapTrinhVien
aws iam add-user-to-group --group-name LapTrinhVien --user-name nguyen-van-a

A — dùng managed policy thay vì inline. Inline policy gắn chặt vào một danh tính và xoá theo danh tính đó:

Khả năng rollback của managed policy đáng giá: sửa nhầm policy làm hỏng production thì quay lại version trước bằng một lệnh.

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

• D. Tạo tài khoản dùng chung cho hiệu quả — vi phạm nguyên tắc bảo mật cơ bản nhất: tài khoản dùng chung khiến không thể biết ai đã làm gì (CloudTrail chỉ ghi tên tài khoản chung), không thu hồi quyền cho một người được, và mật khẩu lan truyền không kiểm soát. AWS khuyến nghị mỗi người một danh tính riêng.
• B. Dùng tài khoản người dùng để uỷ quyền — sai cơ chế: uỷ quyền trong AWS được thực hiện bằng IAM role kèm sts:AssumeRole, không phải bằng cách chia sẻ user. Role cho credential tạm thời tự hết hạn và có vết kiểm toán rõ ràng.
• E. Luôn dùng customer managed policy thay vì AWS managed policy — quá tuyệt đối. AWS managed policy rất hữu ích cho các trường hợp phổ biến (AWSLambdaBasicExecutionRole, AmazonS3ReadOnlyAccess), được AWS cập nhật khi có dịch vụ mới, và không tốn công bảo trì. Khuyến nghị đúng là dùng AWS managed để bắt đầu, chuyển sang customer managed khi cần thu hẹp quyền — chứ không phải "luôn luôn".

Ghi nhớ

Các thực hành tốt của IAM — danh sách đáng thuộc: | Nên | Không nên | |---|---| | Mỗi người một danh tính riêng | tài khoản dùng chung | | Gán quyền qua group | gán trực tiếp cho từng user | | Managed policy | inline policy (trừ khi thật sự chỉ dùng một lần) | | Bật MFA, nhất là cho tài khoản có quyền cao | dựa vào mật khẩu đơn thuần | | Dùng role cho ứng dụng | nhúng access key vào mã | | Đặc quyền tối thiểu | cấp * cho tiện | | IAM Identity Center (SSO) cho nhân sự | tạo IAM user cho mọi người | | Xoay vòng credential định kỳ | giữ access key nhiều năm |

Ba loại policy: | Loại | Ai quản | Tái sử dụng | |---|---|---| | AWS managed | AWS | ✅, nhưng thường rộng hơn mức cần | | Customer managed | bạn | ✅ — thu hẹp được đúng nhu cầu | | Inline | bạn | ❌ |

Khi nào inline policy vẫn hợp lý: khi bạn muốn đảm bảo quan hệ một–một tuyệt đối giữa policy và danh tính — ví dụ một role rất đặc thù mà không bao giờ được dùng lại ở đâu khác.

Và công cụ đáng dùng để thu hẹp quyền: IAM Access Advisor cho biết dịch vụ nào thật sự được gọi trong 400 ngày qua — thường lộ ra rất nhiều quyền được cấp mà chưa bao giờ dùng tới.

Đáp án

A — Application Load Balancer với header X-Forwarded-For.

Vì sao đúng

Đề nêu hai yêu cầu: dùng listener HTTP/HTTPS, và lấy được địa chỉ IP của client.

Yêu cầu đầu tiên đã quyết định phần lớn: HTTP/HTTPS là listener của tầng 7, và đó là ALB.

Vấn đề cần giải: ALB kết thúc kết nối từ client và mở một kết nối MỚI tới instance, nên từ góc nhìn của instance, mọi request đều đến từ IP riêng của ALB:

Client (203.0.113.45) → ALB → EC2 thấy IP nguồn = 10.0.1.20 (chính ALB)

ALB tự động thêm header X-Forwarded-For chứa IP thật của client:

X-Forwarded-For: 203.0.113.45

Nếu có nhiều proxy nối tiếp (CloudFront rồi mới tới ALB), header thành danh sách:

X-Forwarded-For: 203.0.113.45, 70.41.3.18
                 ↑ client thật    ↑ proxy trung gian

Việc còn lại là cấu hình máy chủ web ghi header đó thay vì IP kết nối:

log_format chinh '$http_x_forwarded_for - $remote_user [$time_local] "$request" $status';

Hoặc dùng mod_remoteip với Apache để %h tự trả về IP thật.

Điểm quan trọng: đây là hành vi mặc định của ALB, không cần bật gì — phương án A nói "with X-Forwarded-For headers enabled" chỉ là cách diễn đạt.

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

• B. Network Load Balancer với Proxy Protocol — NLB hoạt động ở tầng 4, nó không hỗ trợ listener HTTP/HTTPS theo nghĩa xử lý nội dung HTTP. Đề yêu cầu rõ HTTP/HTTPS listener. (Proxy Protocol v2 đúng là cách giữ IP client với NLB — nhưng nó cần backend hỗ trợ đọc giao thức đó, và vẫn không đáp ứng yêu cầu về loại listener.)
• C. Application Load Balancer với Proxy Protocol — ALB KHÔNG hỗ trợ Proxy Protocol. Đó là cơ chế của NLB và CLB. ALB dùng X-Forwarded-For. Đây là bẫy hoán đổi hai cơ chế giữa hai loại load balancer.
• D. Gateway Load Balancer với X-Forwarded-For — GWLB dùng cho thiết bị bảo mật ảo (tường lửa, IDS/IPS) ở tầng 3, dùng giao thức GENEVE. Nó không phải load balancer cho ứng dụng web và không thêm header HTTP nào.

Ghi nhớ

Ba loại load balancer và cách giữ IP client: | Loại | Tầng | Listener | Giữ IP client bằng | |---|---|---|---| | ALB | 7 | HTTP, HTTPS | X-Forwarded-For | | NLB | 4 | TCP, UDP, TLS | Proxy Protocol v2 hoặc client IP preservation | | GWLB | 3 | GENEVE | (dùng cho thiết bị bảo mật) |

Ba header mà ALB tự thêm: | Header | Nội dung | |---|---| | X-Forwarded-For | IP thật của client | | X-Forwarded-Proto | giao thức gốc: http hoặc https | | X-Forwarded-Port | cổng client kết nối tới |

Header thứ hai cũng quan trọng: thiếu nó, ứng dụng tưởng client dùng HTTP và có thể sinh link sai giao thức hoặc lặp vô hạn khi tự chuyển hướng sang HTTPS.

Cảnh báo bảo mật quan trọng: X-Forwarded-For là header client có thể tự đặt. Nếu instance nhận request trực tiếp (không qua ALB), kẻ tấn công giả mạo IP trong log được. Hai biện pháp phòng:

1. Security group chỉ cho phép traffic từ SG của ALB.
2. Khi đọc header, lấy giá trị bên phải cùng do proxy tin cậy thêm vào, không phải giá trị đầu tiên.

Và nếu chỉ cần phân tích chứ không cần log trên máy: bật ALB access log ghi thẳng vào S3 rồi truy vấn bằng Athena — không cần đụng tới cấu hình máy chủ web.

Đáp án

A — Đặt thuộc tính ReceiveMessageWaitTimeSeconds của hàng đợi thành 20 giây.

Vì sao đúng

Đề nêu hai vấn đề, và cả hai đều do short polling gây ra:

1. Chi phí cao vì consumer hỏi hàng đợi liên tục
2. Nhiều phản hồi rỗng (empty responses)

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

aws sqs set-queue-attributes --queue-url <url> \
  --attributes ReceiveMessageWaitTimeSeconds=20

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ì khi có message | | 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%

Và 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.

Điểm hay nữa: đề nói message đến không thường xuyên, nên long polling càng hợp — consumer chờ sẵn và nhận được ngay khi có việc, thay vì hỏi vô ích hàng nghìn lần.

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

• B. Đặt DelaySeconds của message thành 20 giây — DelaySeconds hoãn message MỚI trước khi nó xuất hiện lần đầu (delay queue). Nó làm chậm việc xử lý, và không giảm số request nào.
• C. Đặt MessageRetentionPeriod thành 20 giây — quyết định message được giữ bao lâu trước khi bị xoá. Đặt 20 giây nghĩa là message chưa kịp xử lý đã biến mất — vừa không giảm chi phí, vừa mất dữ liệu.
• D. Đặt VisibilityTimeout thành 20 giây — 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.

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ố | Phạm vi | Việc | |---|---|---| | ReceiveMessageWaitTimeSeconds | 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 |

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

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, còn MaxNumberOfMessages giảm số lần gọi khi hàng đợi có nhiều message.

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

B — CodeDeployDefault.ECSCanary10Percent15Minutes.

Vì sao đúng

Đề mô tả chính xác hành vi của canary, với hai con số cụ thể:

1. Đưa 10% traffic sang phiên bản mới
2. Sau 15 phút, chuyển toàn bộ phần còn lại

Tên cấu hình đọc thẳng ra hành vi đó:

CodeDeployDefault.ECSCanary10Percent15Minutes
                   │    │      │        │
                   │    │      │        └─ chờ 15 phút
                   │    │      └─ 10% traffic
                   │    └─ kiểu canary (hai bước)
                   └─ nền tảng ECS

aws deploy create-deployment \
  --application-name ung-dung-ecs \
  --deployment-group-name nhom-production \
  --deployment-config-name CodeDeployDefault.ECSCanary10Percent15Minutes \
  --revision file://appspec.json

Trong 15 phút đó, cả hai task set cùng tồn tại và bạn theo dõi metric của bản mới. Nếu có vấn đề, rollback chỉ là trỏ listener về task set cũ — gần như tức thì.

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

• A. ECSLinear10PercentEvery10Minutes — đúng nền tảng nhưng sai kiểu: linear chuyển traffic theo nhiều nấc đều nhau (10% → 20% → 30% → … → 100%), tổng cộng 100 phút. Đề mô tả đúng hai bước, đó là canary.
• C. LambdaLinear10PercentEvery1Minutes — sai nền tảng: tên có tiền tố Lambda, không dùng được cho ECS. Và cũng sai kiểu (linear thay vì canary).
• D. ECSAllAtOnce — chuyển 100% traffic ngay lập tức, không có giai đoạn 10% nào.

Ghi nhớ

Quy tắc đặt tên của cấu hình CodeDeploy — đọc tên là biết hành vi:

CodeDeployDefault.<NềnTảng><Kiểu><TỷLệ><ThờiGian>

Các cấu hình dựng sẵn cho ECS:

CodeDeployDefault.ECSAllAtOnce
CodeDeployDefault.ECSCanary10Percent5Minutes
CodeDeployDefault.ECSCanary10Percent15Minutes     ← câu này
CodeDeployDefault.ECSLinear10PercentEvery1Minutes
CodeDeployDefault.ECSLinear10PercentEvery3Minutes

Phân biệt ba kiểu chuyển traffic: | Kiểu | Số bước | Hành vi | |---|---|---| | AllAtOnce | 1 | 100% ngay — nhanh nhất, rủi ro cao nhất | | Canary | 2 | X% → chờ → 100% | | Linear | nhiều | +X% mỗi N phút |

Hai tầng khái niệm của CodeDeploy — đừng lẫn:

Deployment TYPE:   In-place | Blue/green      ← ECS chỉ có blue/green
Deployment CONFIG: AllAtOnce | Canary | Linear ← đây mới là thứ cần chọn

Hỗ trợ theo nền tảng: | Nền tảng | Type | |---|---| | EC2 / On-premises | in-place hoặc blue/green | | ECS | chỉ blue/green | | Lambda | chỉ blue/green |

Nên với ECS và Lambda, câu hỏi "chọn deployment type nào" luôn có sẵn đáp án — phần thực sự phải suy nghĩ là deployment configuration.

Và mẹo nhận dạng nhanh khi làm bài: đọc kỹ tiền tố nền tảng trong tên cấu hình — một nửa số phương án sai trong dạng bài này chỉ đơn giản là ghép nhầm Lambda với ECS.

Đáp án

B — Triển khai các phiên bản API thành các stage riêng biệt với endpoint riêng, và dùng stage variable để cung cấp thêm ngữ cảnh.

Vì sao đúng

Stage là cơ chế phiên bản hoá dựng sẵn của API Gateway. Mỗi stage là một bản triển khai độc lập với URL riêng:

https://abc123.execute-api.ap-southeast-1.amazonaws.com/v1
https://abc123.execute-api.ap-southeast-1.amazonaws.com/v2
https://abc123.execute-api.ap-southeast-1.amazonaws.com/test

Và stage variable là mảnh ghép còn lại — nó cho phép cùng một định nghĩa API trỏ tới backend khác nhau theo từng stage:

Integration URI: arn:aws:lambda:...:function:xu-ly:${stageVariables.alias}

Stage v1   → stageVariables.alias = "v1"
Stage v2   → stageVariables.alias = "v2"
Stage test → stageVariables.alias = "test"

Kết hợp với Lambda alias, mô hình trở nên rất gọn:

Lambda: xu-ly
├── alias "v1"   → version 3
├── alias "v2"   → version 7
└── alias "test" → $LATEST

Muốn phát hành phiên bản mới, chỉ cần trỏ alias sang version khác — không đụng gì tới cấu hình API.

Mỗi stage còn có cấu hình riêng: throttling, caching, mức log, WAF — nên môi trường test đặt log chi tiết mà production thì không.

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

• A. Tạo resource policy để cô lập phiên bản — resource policy kiểm soát AI được gọi API (theo IP, VPC endpoint, tài khoản AWS). Nó không phân tách phiên bản và không truyền ngữ cảnh nào xuống Lambda.
• D. Tạo Lambda authorizer để định tuyến client tới đúng phiên bản — sai chức năng: authorizer dùng để xác thực và uỷ quyền — nó trả về một IAM policy cho phép hoặc từ chối. Nó không định tuyến request tới backend khác nhau.
• C. Dùng header X-Version rồi truyền header đó xuống Lambda — chạy được nhưng là cách thủ công và kém hơn: bạn phải tự viết logic rẽ nhánh trong hàm Lambda, nên mọi phiên bản nằm chung một hàm và một bản triển khai. Mất hẳn khả năng cấu hình khác nhau cho từng phiên bản (throttling, caching, log), và rollback một phiên bản trở nên phức tạp.

Ghi nhớ

Ba cách phiên bản hoá API — trong thực tế thường kết hợp: | Cách | Ví dụ | |---|---| | Stage | /v1, /v2 — cơ chế dựng sẵn của API Gateway | | Đường dẫn trong resource | /v1/don-hang, /v2/don-hang | | Header | Accept: application/vnd.api.v2+json |

Những gì cấu hình riêng được cho từng stage: | Cấu hình | Ghi chú | |---|---| | Stage variables | truyền ngữ cảnh xuống backend | | Throttling | request/giây và burst | | Caching | tính tiền theo GIỜ — nhớ tắt ở stage test | | Logging và X-Ray | mức log, dataTrace | | WAF Web ACL | — | | Canary release | chia % traffic ngay trong một stage |

Stage variable dùng được ở nhiều nơi, không chỉ cho Lambda alias:

${stageVariables.alias}        → Lambda alias
${stageVariables.tenBang}      → tên bảng DynamoDB trong mapping template
${stageVariables.urlBackend}   → HTTP integration

Cảnh báo quan trọng khi integration dùng stage variable: API Gateway không tự thêm quyền vào resource-based policy của Lambda cho các alias động. Bạn phải tự cấp quyền cho MỌI alias có thể được gọi — thiếu là API trả về 500 mà không có thông báo gì hữu ích:

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

Đáp án nguồn

D — Dùng Amazon Macie để quét định kỳ và phát hiện PII trong log.

Ghi chú về chất lượng câu hỏi

Đáp án nguồn có hai vấn đề, và cần nói rõ cả hai.

Vấn đề 1 — Macie không quét CloudWatch Logs. Amazon Macie chỉ hỗ trợ Amazon S3. Nó không đọc được log group của CloudWatch. Muốn dùng Macie cho log, bạn phải xuất log sang S3 trước (bằng export task hoặc subscription filter qua Firehose) — một bước mà phương án không hề nhắc tới.

Vấn đề 2 — Macie là phát hiện, không phải phòng ngừa. Đề hỏi cách "đảm bảo PII KHÔNG bị ghi nhầm vào CloudWatch". Macie chỉ cho biết PII đã bị ghi rồi — dữ liệu nhạy cảm đã nằm trong log, có thể đã được sao chép sang hệ thống tập trung, và bạn chỉ biết sau khi quét.

Câu trả lời đúng hơn

Có hai cách thực sự giải quyết yêu cầu, và cả hai đều không nằm trong bộ phương án:

1. CloudWatch Logs data protection policy — đây là giải pháp AWS làm sẵn cho đúng bài toán này (ra mắt cuối 2022). Nó tự động phát hiện và CHE (mask) dữ liệu nhạy cảm ngay khi log được ghi:

aws logs put-data-protection-policy \
  --log-group-identifier /aws/lambda/xu-ly-pii \
  --policy-document '{
    "Name": "CheDuLieuNhayCam",
    "Statement": [
      {"Sid": "Audit", "DataIdentifier": [
         "arn:aws:dataprotection::aws:data-identifier/EmailAddress",
         "arn:aws:dataprotection::aws:data-identifier/CreditCardNumber",
         "arn:aws:dataprotection::aws:data-identifier/Ssn-US"],
       "Operation": {"Audit": {"FindingsDestination": {}}}},
      {"Sid": "Redact", "DataIdentifier": ["..."],
       "Operation": {"Deidentify": {"MaskConfig": {}}}}
    ]}'

Kết quả: người xem log thấy **** thay vì số thẻ, còn ai có quyền logs:Unmask mới xem được bản đầy đủ.

2. Kỷ luật ở tầng mã — chính là điều phương án A mô tả: chủ động viết lệnh log sao cho không bao giờ đưa PII vào:

# ✗ Nguy hiểm — ghi cả object chứa PII
logger.info(f"Xử lý khách hàng: {khach_hang}")

# ✓ An toàn — chỉ ghi định danh không nhạy cảm
logger.info(f"Xử lý khách hàng id={khach_hang.id} trạng thái={trang_thai}")

Nói gọn: A là phương án phòng ngừa duy nhất trong bộ đã cho, còn D chỉ là phát hiện sau khi sự việc đã xảy ra — và với một dịch vụ không đọc được CloudWatch Logs.

Vì sao B và C cũng sai

• B. Dùng Secrets Manager để "ghi log an toàn" — sai chức năng hoàn toàn: Secrets Manager lưu và xoay vòng bí mật (mật khẩu, khoá API). Nó không phải công cụ ghi log và không lọc gì.
• C. Dùng X-Ray cấu hình để lọc PII trước khi ghi log — X-Ray không có tính năng lọc PII. Nó theo dấu request qua các dịch vụ. Ngược lại, X-Ray còn có thể VÔ TÌNH ghi PII vào annotation hoặc metadata nếu bạn không cẩn thận.

Ghi nhớ

Bốn lớp bảo vệ PII trong log, theo thứ tự nên áp dụng: | Lớp | Cơ chế | Loại | |---|---|---| | 1. Không ghi PII ngay từ đầu | kỷ luật trong mã, code review | phòng ngừa | | 2. CloudWatch Logs data protection policy | tự che khi ghi | phòng ngừa | | 3. Mã hoá log group bằng KMS | bảo vệ at-rest | giảm thiểu | | 4. Macie quét log ĐÃ XUẤT SANG S3 | phát hiện | phát hiện |

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

Và với dữ liệu PII nói chung, ba nguyên tắc: thu thập ít nhất có thể, che ngay tại nguồn, và đặt retention ngắn cho log chứa dữ liệu nhạy cảm.

Đáp án

C — AWS::Serverless::Function.

Vì sao đúng

SAM cung cấp một tập loại tài nguyên rút gọn, và AWS::Serverless::Function là loại dành cho hàm Lambda:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  XuLyDonHang:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs20.x
      CodeUri: ./src
      MemorySize: 512
      Timeout: 30
      Environment:
        Variables:
          BANG: !Ref BangDonHang
      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref BangDonHang
      Events:
        ApiGet:
          Type: Api
          Properties: {Path: /don-hang/{id}, Method: get}

Điểm mạnh của SAM nằm ở chỗ một khối ngắn sinh ra rất nhiều tài nguyên thật: | Khai trong SAM | CloudFormation sinh ra | |---|---| | AWS::Serverless::Function | Lambda function | | | IAM execution role | | | CloudWatch log group | | Policies: | IAM policy đúng phạm vi | | Events: Type: Api | API Gateway REST API + resource + method + quyền gọi |

Phần Policies đặc biệt tiện: SAM policy template sinh ra IAM policy chuẩn mà không cần viết JSON tay — DynamoDBCrudPolicy, S3ReadPolicy, SQSPollerPolicy và hàng chục mẫu khác.

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

Ba phương án còn lại đều là loại tài nguyên SAM có thật, nhưng dành cho việc khác:

• B. AWS::Serverless::Api — khai API Gateway REST API. (Thường không cần khai tường minh: nếu hàm có Events kiểu Api như ví dụ trên, SAM tự tạo một API ngầm.)
• A. AWS::Serverless::LayerVersion — khai Lambda Layer để dùng chung thư viện.
• D. AWS::Serverless::Application — nhúng một ứng dụng lồng nhau, thường lấy từ Serverless Application Repository.

Ghi chú về chất lượng câu hỏi

Ba phương án A, B, C trong nguồn viết thiếu một dấu hai chấm: AWS::Serverless:Function thay vì AWS::Serverless::Function. Đó là lỗi chính tả khi nhập liệu, không phải một cú pháp khác.

Không làm sai đáp án — C vẫn là lựa chọn duy nhất cho Lambda — nhưng khi viết template thật phải đủ hai dấu hai chấm ở cả hai vị trí. Sai một dấu là CloudFormation báo "Unrecognized resource type".

Ghi nhớ

Các loại tài nguyên của SAM: | Loại | Sinh ra | |---|---| | AWS::Serverless::Function | Lambda + IAM role + log group | | AWS::Serverless::Api | API Gateway REST API | | AWS::Serverless::HttpApi | API Gateway HTTP API | | AWS::Serverless::SimpleTable | bảng DynamoDB đơn giản (chỉ partition key) | | AWS::Serverless::StateMachine | Step Functions | | AWS::Serverless::LayerVersion | Lambda Layer | | AWS::Serverless::Application | nested stack |

Hai dòng bắt buộc ở đầu mọi template SAM:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31    # ← thiếu là SAM không hoạt động

Và phần Globals đáng dùng để tránh lặp lại cấu hình chung cho nhiều hàm:

Globals:
  Function:
    Runtime: nodejs20.x
    Timeout: 30
    MemorySize: 512
    Tracing: Active

Ba lỗi hay gặp với template SAM: quên Transform, viết thiếu dấu hai chấm, và quên --capabilities CAPABILITY_IAM khi deploy (vì SAM tự tạo IAM role nên CloudFormation đòi xác nhận tường minh).