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

Đáp án

D — Amazon SQS tự co giãn rất tốt và không cần can thiệp gì để xử lý khối lượng lớn dự kiến.

Vì sao đúng

Đây là đặc điểm nền tảng của SQS, và nó khiến ba phương án còn lại trở nên vô nghĩa: SQS là dịch vụ được quản lý hoàn toàn, tự co giãn, không có khái niệm "dung lượng" để cấu hình.

Cụ thể:

Bạn không đặt trước gì cả, không có nút nào để bấm. Đội marketing lo lắng là điều dễ hiểu, nhưng SQS chính là dịch vụ sinh ra để hấp thụ những đợt tăng đột biến như Black Friday.

Điểm cần lưu tâm thật sự không nằm ở SQS, mà ở phía consumer. Hàng đợi sẽ nhận hết đơn hàng, nhưng nếu consumer xử lý không kịp thì message tích lại và thời gian xử lý đơn kéo dài. Nên việc cần chuẩn bị là:

• Mở rộng consumer — Auto Scaling theo backlog per instance, hoặc Lambda với reserved concurrency đủ lớn
• Đặt alarm trên ApproximateAgeOfOldestMessage — message cũ nghĩa là consumer đang tụt lại
• Cấu hình DLQ để message hỏng không quay vòng làm nghẽn hàng đợi

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

• C. "Bật auto-scaling cho SQS queue" — không tồn tại. SQS không có thiết lập auto-scaling vì nó vốn đã tự co giãn.
• B. "Cấu hình trước để tăng dung lượng khi đạt ngưỡng" — cũng không tồn tại. Không có khái niệm dung lượng queue.
• A. Chuyển sang FIFO queue — đi ngược hướng. FIFO đảm bảo thứ tự và xử lý đúng một lần, nhưng đổi lại thông lượng thấp hơn nhiều: 300 message/giây (3.000 với batching), so với gần như không giới hạn của standard queue. Câu "message sẽ được xử lý nhanh hơn khi đã có thứ tự" cũng sai về mặt logic.

Ghi nhớ

Nguyên tắc chung: đừng chọn FIFO trừ khi nghiệp vụ thực sự đòi thứ tự. Đổi lấy thứ tự là đánh đổi thông lượng, và đó là cái giá lớn trong đợt cao điểm.

Đáp án

A — Dùng Cognito User Pools.

Vì sao đúng

Hai yêu cầu của đề, và cả hai đều chỉ về user pool:

1. Người dùng phải đăng ký trước khi truy cập API
2. Việc quản lý người dùng phải được quản lý hoàn toàn

Cognito user pool là thư mục người dùng được AWS quản lý, có sẵn mọi thứ một ứng dụng di động cần:

Và nó tích hợp trực tiếp với API Gateway qua Cognito user pool authorizer — không cần viết một dòng mã xác thực nào:

Client → đăng nhập user pool → nhận JWT
       → gọi API kèm header Authorization: <JWT>
       → API Gateway tự xác minh chữ ký và hạn của token

Về chi phí: 50.000 người dùng hoạt động hằng tháng đầu tiên miễn phí — rất phù hợp cho ứng dụng đang khởi đầu.

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

• B. Lambda Authorizer — cho phép cài đặt logic xác thực tuỳ ý, dùng khi hệ phân quyền nằm ở bên thứ ba. Nhưng nó không quản lý người dùng: bạn vẫn phải tự dựng nơi lưu tài khoản, tự xử lý đăng ký, tự phát token. Trái yêu cầu "fully managed".
• C. IAM permissions với SigV4 — đòi client có danh tính AWS và ký request. Không dùng được cho ứng dụng di động có người dùng tự đăng ký — bạn không thể tạo IAM user cho từng người dùng cuối (giới hạn cứng 5.000 IAM user mỗi tài khoản).
• D. "API Gateway User Pools" — không tồn tại. User pool là khái niệm của Cognito; API Gateway chỉ dùng nó làm authorizer.

Ghi nhớ

Bốn cơ chế uỷ quyền của API Gateway: | Cơ chế | Dùng khi | |---|---| | Cognito user pool | có người dùng cuối tự đăng ký | | IAM (SigV4) | client là dịch vụ AWS hoặc có danh tính AWS | | Lambda authorizer | logic tuỳ ý, IdP bên thứ ba | | JWT authorizer (HTTP API) | OIDC/OAuth2 chuẩn |

Và phân biệt lại cặp hay lẫn: user pool = thư mục người dùng, phát JWT; identity pool = đổi danh tính lấy thông tin xác thực AWS tạm thời. Nhiều ứng dụng dùng cả hai nối tiếp nhau.

Đáp án

A và C.

• A — RDS MySQL
• C — RDS PostgreSQL

Vì sao đúng

IAM Database Authentication cho phép đăng nhập vào CSDL bằng token xác thực do IAM sinh ra, thay vì mật khẩu. Nhưng nó chỉ hỗ trợ ba engine:

Cách dùng: sinh một token có hạn 15 phút rồi dùng nó thay mật khẩu:

TOKEN=$(aws rds generate-db-auth-token \
  --hostname csdl.abc123.ap-southeast-1.rds.amazonaws.com \
  --port 3306 --username app_user)
mysql --host=csdl... --user=app_user --password=$TOKEN --enable-cleartext-plugin

Ba lợi ích so với mật khẩu:

• Không có mật khẩu nào để lưu — token sinh ra lúc cần, hết hạn sau 15 phút
• Phân quyền bằng IAM policy — thu hồi quyền là sửa policy, hiệu lực ngay
• Kết nối bắt buộc dùng SSL

Điều kiện: phải bật tính năng trên DB instance, và tạo user trong CSDL với plugin tương ứng:

CREATE USER app_user IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';  -- MySQL
GRANT rds_iam TO app_user;                                              -- PostgreSQL

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

• B. RDS SQL Server, E. RDS Oracle, D. RDS Db2 — cả ba không hỗ trợ IAM Database Authentication. Chúng dùng cơ chế xác thực riêng của engine (SQL Server Authentication, Oracle wallet, Kerberos/Active Directory).

Ghi nhớ

Giới hạn quan trọng cần biết trước khi dùng: số kết nối mỗi giây bị giới hạn (khoảng 200/giây với instance nhỏ, tuỳ loại). IAM authentication không hợp với ứng dụng mở kết nối liên tục — nên dùng cùng connection pool hoặc RDS Proxy.

Ba cách quản lý thông tin đăng nhập CSDL trên AWS: | Cách | Đặc điểm | |---|---| | IAM Database Authentication | không có mật khẩu, token 15 phút, chỉ MySQL/PostgreSQL/MariaDB | | Secrets Manager | mật khẩu xoay vòng tự động, hỗ trợ mọi engine | | Parameter Store SecureString | mật khẩu mã hoá, không xoay vòng, miễn phí |

Đáp án

C — CodeDeploy Agent.

Vì sao đúng

Số bản revision được lưu lại trên instance là một thiết lập của CodeDeploy agent, khai trong tệp cấu hình của nó:

# /etc/codedeploy-agent/conf/codedeployagent.yml
---
:log_aws_wire: false
:log_dir: '/var/log/aws/codedeploy-agent/'
:max_revisions: 2                    # ← giữ tối đa 2 bản revision
:root_dir: '/opt/codedeploy-agent/deployment-root'

:max_revisions: kiểm soát số bản deploy cũ được giữ trong thư mục deployment-root. Agent tự xoá bản cũ nhất khi vượt quá con số này — chính xác điều đề cần để tiết kiệm dung lượng đĩa.

Vì sao thiết lập này quan trọng trong thực tế: mỗi bản revision là một bản sao đầy đủ của ứng dụng. Với ứng dụng vài trăm MB và deploy vài lần mỗi ngày, đĩa đầy rất nhanh — và khi đĩa đầy thì deploy tiếp theo thất bại, thường vào lúc bất tiện nhất.

Sửa xong nhớ khởi động lại agent:

sudo service codedeploy-agent restart

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

• B. Tích hợp CodePipeline — CodePipeline điều phối các stage (source → build → deploy). Nó không kiểm soát gì bên trong instance, kể cả việc dọn dẹp revision cũ.
• A. Đặt load balancer phía trước instance — phân phối traffic, không liên quan tới quản lý dung lượng đĩa hay số bản revision.
• D. CloudWatch Log Agent — thu thập log từ instance đẩy lên CloudWatch Logs. Nó quản lý log, không quản lý bản triển khai.

Ghi nhớ

Các thiết lập đáng biết trong codedeployagent.yml: | Thiết lập | Tác dụng | |---|---| | :max_revisions: | số bản revision giữ lại trên đĩa | | :log_dir: | nơi ghi log của agent | | :root_dir: | thư mục chứa các bản deploy | | :proxy_uri: | proxy nếu instance không ra Internet trực tiếp |

Và nơi cần biết khi gỡ lỗi CodeDeploy: /var/log/aws/codedeploy-agent/codedeploy-agent.log — đây là chỗ đầu tiên nên xem khi deploy thất bại mà console không nói rõ lý do.

Đáp án

A — Người dùng bị từ chối truy cập, vì một trong hai policy có Deny tường minh.

Vì sao đúng

Đây là quy tắc nền tảng và tuyệt đối của IAM:

Deny tường minh luôn thắng mọi Allow, bất kể ở policy nào và bất kể thứ tự.

Logic đánh giá của IAM chạy theo ba bước cố định:

1. Có Deny tường minh nào không?  →  CÓ  →  TỪ CHỐI (dừng, không xét gì thêm)
                                  →  KHÔNG ↓
2. Có Allow tường minh nào không? →  CÓ  →  CHO PHÉP
                                  →  KHÔNG ↓
3. Deny ngầm định (mặc định)      →  TỪ CHỐI

Trong đề: policy 1 có Deny mọi hành động EC2, policy 2 có Allow cho ec2:Describe*. Bước 1 tìm thấy Deny và dừng ngay — người dùng bị từ chối.

Đây cũng là lý do Deny là công cụ rất mạnh: đặt một Deny ở permissions boundary hoặc SCP thì không policy nào bên dưới lách được.

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

• B. "Thứ tự policy quyết định" — IAM policy KHÔNG có thứ tự. Tất cả policy áp dụng cho một principal đều được hợp nhất và đánh giá cùng lúc. Đây là khác biệt lớn so với NACL (đánh giá theo số thứ tự) và WAF rule (theo priority).
• C. "Được phép vì có Allow tường minh" — bỏ qua quy tắc Deny thắng. Sai về nguyên lý cơ bản nhất của IAM.
• D. "IAM user ở trạng thái không hợp lệ vì policy mâu thuẫn" — IAM không coi đây là mâu thuẫn. Việc kết hợp Allow rộng với Deny hẹp là mẫu thiết kế phổ biến và được khuyến nghị (ví dụ: cho toàn quyền S3 nhưng deny bucket production).

Ghi nhớ

Thứ tự đánh giá đầy đủ khi có nhiều loại policy:

1. Deny tường minh (bất kỳ đâu)         → TỪ CHỐI
2. SCP (Organizations)                   → phải Allow
3. Resource-based policy                 → có thể Allow trực tiếp
4. Permissions boundary                  → phải Allow
5. Session policy                        → phải Allow
6. Identity-based policy                 → phải Allow
7. Không có Allow nào                    → TỪ CHỐI ngầm định

Ba cơ chế chỉ giới hạn, không bao giờ cấp quyền: SCP, permissions boundary, session policy. Chúng là "trần"; quyền thật vẫn phải đến từ identity policy hoặc resource policy.

Và nhớ so sánh: IAM không có thứ tự rule; NACL và WAF thì có.

Đáp án

A — Tạo high-resolution custom metric và đẩy dữ liệu bằng script chạy mỗi 10 giây.

Vì sao đúng

Yêu cầu là theo dõi CPU mỗi 10 giây, và con số đó vượt qua mọi thứ CloudWatch cung cấp sẵn cho EC2:

Nên để có dữ liệu 10 giây, bắt buộc phải tự đo và tự đẩy dưới dạng high-resolution custom metric:

# Chạy mỗi 10 giây trên từng instance
CPU=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}')
aws cloudwatch put-metric-data \
  --namespace "UngDung/EC2" \
  --metric-name "CPUUtilization" \
  --dimensions InstanceId=$(curl -s http://169.254.169.254/latest/meta-data/instance-id) \
  --value "$CPU" \
  --storage-resolution 1        # ← high resolution

Tham số --storage-resolution 1 là thứ quyết định: nó cho phép lưu điểm dữ liệu ở độ phân giải giây, và cho phép alarm đánh giá nhanh nhất 10 giây thay vì tối thiểu 60 giây.

Cảnh báo về chi phí — đáng cân nhắc với 100 instance: high-resolution metric đắt hơn, và PutMetricData tính tiền theo lời gọi. Nên gộp nhiều điểm dữ liệu vào một lời gọi (tối đa 1.000 điểm) hoặc dùng CloudWatch Agent với metrics_collection_interval: 10.

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

• C. Bật EC2 detailed monitoring — đây là bẫy chính. Detailed monitoring chỉ xuống tới 1 phút, không thể xuống 10 giây. Nó cũng không thêm metric mới nào, chỉ đổi chu kỳ.
• B. "Lấy thẳng từ CloudWatch Metrics" — metric mặc định của EC2 là 5 phút; kể cả bật detailed monitoring cũng chỉ được 1 phút. Không có cách nào lấy 10 giây từ metric dựng sẵn.
• D. Mở support ticket với AWS — chu kỳ metric không phải service quota để xin nâng. Đây là giới hạn thiết kế của dịch vụ.

Ghi nhớ

Và nhớ ba metric không có sẵn trên EC2, luôn cần CloudWatch Agent: bộ nhớ, dung lượng đĩa còn trống, và swap.

Đáp án

A và D.

• D — Dùng Amazon Cognito để quản lý người dùng và xử lý luồng đăng nhập/đăng ký.
• A — Dùng Amazon Cognito để bật MFA khi người dùng đăng nhập.

Vì sao đúng

Yêu cầu: hệ quản lý người dùng có khả năng mở rộng, hỗ trợ đăng ký/đăng nhập và MFA, với ít công sức phát triển nhất.

Cognito user pool cho tất cả những thứ đó dưới dạng cấu hình, không phải mã:

Bật MFA chỉ là một lời gọi cấu hình:

aws cognito-idp set-user-pool-mfa-config \
  --user-pool-id ap-southeast-1_xxxxx \
  --mfa-configuration ON \
  --software-token-mfa-configuration Enabled=true

Với ứng dụng y tế xử lý dữ liệu sức khoẻ, đây cũng là lựa chọn đúng về mặt tuân thủ: Cognito đủ điều kiện HIPAA, và adaptive authentication tự đòi thêm xác thực khi thấy dấu hiệu bất thường.

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

• C và E. Tự viết bằng Lambda + RDS hoặc Lambda + DynamoDB — phải cài đặt toàn bộ: băm mật khẩu an toàn, luồng xác minh email, mã đặt lại có hạn, chống brute force, sinh và xác minh mã TOTP, quản lý phiên. Đây là hàng nghìn dòng mã bảo mật nhạy cảm phải bảo trì mãi — trái thẳng "LEAST amount of development effort". Và với dữ liệu y tế, tự viết hệ xác thực là rủi ro rất lớn.
• B. Dùng SNS gửi mã MFA qua SMS — SNS chỉ là kênh gửi tin nhắn. Nó không sinh mã, không lưu mã, không xác minh mã, không quản lý thời hạn. Bạn vẫn phải tự viết toàn bộ logic MFA — mà Cognito đã làm sẵn. (Bản thân Cognito dùng SNS bên dưới để gửi SMS, nhưng đó là chi tiết nội bộ.)

Ghi nhớ

Các hình thức MFA mà Cognito hỗ trợ: | Loại | Chi tiết | |---|---| | SMS MFA | mã gửi qua tin nhắn (dùng SNS bên dưới) | | TOTP (software token) | Google Authenticator, Authy… — an toàn hơn SMS | | Adaptive authentication | tự đòi MFA khi đăng nhập bất thường (IP lạ, thiết bị mới) |

Cấu hình MFA có ba mức: OFF, OPTIONAL (người dùng tự chọn), ON (bắt buộc mọi người).

Nguyên tắc lớn hơn, đặc biệt với dữ liệu nhạy cảm: đừng bao giờ tự viết hệ xác thực khi đã có dịch vụ được quản lý. Đó là nơi dễ để lọt lỗ hổng nghiêm trọng nhất.

Đáp án

A — Tăng minimum capacity của Auto Scaling group lên 2.

Vì sao đúng

Phân tích tình huống: min = 1, trải trên 3 AZ. Trong giai đoạn tải thấp, ASG thu về đúng một instance, và instance đó nằm ở một AZ duy nhất:

AZ-A: 1 instance   ← toàn bộ ứng dụng nằm ở đây
AZ-B: 0
AZ-C: 0

AZ-A sập ⇒ ứng dụng chết hoàn toàn. Việc ASG được cấu hình cho 3 AZ không giúp gì khi chỉ có một instance — nó chỉ nói rằng instance có thể được đặt ở bất kỳ AZ nào trong ba, không phải đang ở cả ba.

Đặt min = 2 thì Auto Scaling phân bố instance đều giữa các AZ:

AZ-A: 1 instance
AZ-B: 1 instance   ← AZ-A sập, ứng dụng vẫn sống
AZ-C: 0

ASG cũng sẽ tự tạo instance thay thế ở AZ còn khoẻ khi phát hiện AZ kia hỏng.

Đây là nguyên tắc chung: tính sẵn sàng cao đòi tối thiểu hai instance ở hai AZ. Một instance là một điểm hỏng đơn lẻ, bất kể ASG được cấu hình thế nào.

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

• B. Đổi metric của scaling policy sang network bytes — thay đổi cách quyết định khi nào scale, không thay đổi số lượng tối thiểu. Trong giai đoạn tải thấp, mọi metric đều thấp và ASG vẫn thu về 1 instance.
• C. Bật RDS Multi-AZ — cải thiện tính sẵn sàng của tầng CSDL, hoàn toàn không liên quan tới việc tầng ứng dụng chỉ có một instance. Nên làm, nhưng không phải câu trả lời cho sự cố này.
• D. "Cấu hình ASG fast failover" — không tồn tại. Auto Scaling không có thiết lập nào tên như vậy.

Ghi nhớ

Danh sách kiểm cho tính sẵn sàng cao của tầng ứng dụng: | Việc | Vì sao | |---|---| | Min capacity ≥ 2 | một instance là điểm hỏng đơn lẻ | | Trải trên ≥ 2 AZ | AZ sập vẫn còn AZ kia | | Health check type = ELB | ASG biết ứng dụng hỏng, không chỉ máy hỏng | | Load balancer đã bật đủ các AZ | thiếu bước này thì instance ở AZ mới không nhận traffic |

Cân nhắc chi phí: min = 2 nghĩa là luôn trả tiền cho hai instance, kể cả lúc 3 giờ sáng không ai truy cập. Đó là cái giá của tính sẵn sàng — và với ứng dụng production thì thường đáng.

Đáp án

D — Bật X-Ray sampling.

Vì sao đúng

Vấn đề: quá nhiều dữ liệu vào X-Ray, chi phí tăng vọt, và cần giữ được xu hướng trong khi ít gián đoạn nhất.

Sampling là cơ chế dựng sẵn của X-Ray cho đúng bài toán đó: nó chỉ ghi lại một phần request thay vì tất cả, nhưng phần đó vẫn đủ để thấy xu hướng thống kê.

Quy tắc mặc định của X-Ray:

1 request đầu tiên mỗi giây (reservoir)  +  5% số request còn lại

Và bạn tạo được sampling rule tuỳ chỉnh theo từng đường dẫn hoặc dịch vụ:

{
  "rules": [
    {"description": "Thanh toan - lay mau nhieu hon",
     "service_name": "*", "http_method": "POST", "url_path": "/thanh-toan/*",
     "fixed_target": 10, "rate": 0.5},          // 10/giây + 50% còn lại
    {"description": "Health check - bo qua",
     "url_path": "/health", "fixed_target": 0, "rate": 0.0}
  ],
  "default": {"fixed_target": 1, "rate": 0.05}
}

Đây là cách chỉnh ít gián đoạn nhất: sampling rule cấu hình ở phía dịch vụ X-Ray, các agent tự nhận về — không phải sửa mã, không phải deploy lại bất cứ thứ gì.

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

• C. Dùng Filter Expression trong console X-Ray — filter expression lọc những trace ĐÃ được thu thập và ĐÃ tính tiền để hiển thị. Nó chỉ ảnh hưởng tới cái bạn nhìn thấy, không giảm lượng dữ liệu nạp vào và không giảm chi phí một đồng nào.
• A. Cấu hình tuỳ chỉnh cho X-Ray agent — mơ hồ, và nếu hiểu là sửa cấu hình daemon trên từng máy thì đó là nhiều gián đoạn hơn hẳn: phải chạm vào mọi instance, trong khi sampling rule đặt tập trung một chỗ.
• B. "Network sampling rule" — không tồn tại. X-Ray có sampling rule cho trace, không có khái niệm sampling ở tầng mạng.

Ghi nhớ

Cách X-Ray tính tiền — hiểu để tối ưu đúng chỗ: | Hạng mục | Tính theo | |---|---| | Trace ghi lại | số trace được nạp vào | | Trace truy xuất/quét | số trace đọc ra khi truy vấn |

Nên cách giảm chi phí thật sự là giảm lượng nạp vào — tức là sampling.

Mẹo thực dụng: đặt sampling rule loại bỏ hẳn health check và các endpoint tần suất cao ít giá trị (rate: 0.0), và tăng tỷ lệ cho các đường dẫn quan trọng (thanh toán, đăng nhập). Xu hướng vẫn thấy được, mà chi phí giảm mạnh.

Đáp án

A — EBS volume hỗ trợ cả mã hoá lúc truyền lẫn mã hoá lúc lưu bằng KMS.

Vì sao đúng

Đây là câu hỏi về phạm vi bảo vệ của EBS encryption, và điểm hay bị bỏ sót là vế "lúc truyền".

Khi bật mã hoá cho một EBS volume, AWS bảo vệ dữ liệu ở ba nơi:

Vế "lúc truyền" tồn tại vì EBS là lưu trữ gắn qua mạng, không phải đĩa cắm trực tiếp vào máy. Dữ liệu thực sự đi qua hạ tầng mạng của AWS giữa host EC2 và hệ thống lưu trữ EBS — và đường đó được mã hoá.

Cơ chế hoạt động: EBS dùng envelope encryption. KMS sinh một data key, host EC2 giữ nó trong bộ nhớ để mã hoá/giải mã, và toàn bộ diễn ra trong suốt với hệ điều hành — không cần cấu hình gì trong ứng dụng.

Về hiệu năng: ảnh hưởng không đáng kể. Với yêu cầu 14.000 IOPS trong đề, mã hoá không phải rào cản.

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

• C. "Không hỗ trợ mã hoá lúc truyền, chỉ mã hoá lúc lưu" — bẫy chính, và nó bỏ sót đúng vế đặc biệt của EBS. Nhiều người mặc định "at rest thì có, in transit thì không" vì quen với các loại lưu trữ khác.
• B. "Hỗ trợ lúc truyền nhưng không hỗ trợ lúc lưu" — đảo ngược. Mã hoá at rest là tính năng chính và nổi tiếng nhất của EBS encryption.
• D. "EBS không hỗ trợ mã hoá gì cả" — sai hoàn toàn.

Ghi nhớ

Vài quy tắc cứng về mã hoá EBS: | Quy tắc | Chi tiết | |---|---| | Không mã hoá volume tại chỗ được | phải qua snapshot → copy có mã hoá → tạo volume mới | | Volume từ snapshot đã mã hoá | luôn được mã hoá, không tắt được | | Encryption by default | bật ở mức tài khoản + Region, mọi volume mới tự mã hoá | | Chia sẻ chéo tài khoản | bắt buộc customer-managed key (khoá mặc định không sửa được key policy) | | Hiệu năng | ảnh hưởng không đáng kể |

Khuyến nghị vận hành: bật "EBS encryption by default" cho mọi Region đang dùng — một lần cấu hình, và không bao giờ vô tình tạo volume không mã hoá nữa.