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

Đáp án

B — Tạo SNS topic và hàm Lambda, đăng ký hàm Lambda vào topic, rồi gửi sự kiện tới topic.

Vì sao đúng

Yêu cầu: ứng dụng serverless theo kiến trúc hướng sự kiện, tự động nhận và xử lý sự kiện.

Lambda là một loại đích đăng ký (subscription protocol) mà SNS hỗ trợ trực tiếp — không cần endpoint HTTP, không cần polling:

Bên sinh sự kiện → SNS topic → Lambda tự động được gọi

aws sns subscribe \
  --topic-arn arn:aws:sns:ap-southeast-1:123456789012:su-kien-don-hang \
  --protocol lambda \
  --notification-endpoint arn:aws:lambda:...:function:xu-ly-don-hang

# Cho phép SNS gọi hàm
aws lambda add-permission --function-name xu-ly-don-hang \
  --statement-id SNSInvoke --action lambda:InvokeFunction \
  --principal sns.amazonaws.com --source-arn <arn-topic>

Đây là push model: SNS chủ động gọi hàm ngay khi có message. Không có ai phải hỏi vòng, không có độ trễ do chu kỳ polling, và không có máy chủ nào chạy không.

Hàm nhận sự kiện theo định dạng chuẩn của SNS:

def lambda_handler(event, context):
    for ban_ghi in event['Records']:
        thong_diep = json.loads(ban_ghi['Sns']['Message'])
        xu_ly(thong_diep)

Và mô hình pub/sub cho phép mở rộng về sau mà không sửa bên sinh sự kiện: thêm một Lambda thứ hai, một hàng đợi SQS, hay một endpoint HTTP vào cùng topic là xong.

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

• A. Cấu hình HTTP endpoint trên hàm Lambda rồi đăng ký endpoint đó vào SNS — đường vòng không cần thiết: SNS đã hỗ trợ Lambda trực tiếp. Làm theo cách này bạn phải dựng thêm Function URL hoặc API Gateway, tự xử lý xác nhận đăng ký của SNS, và tự kiểm tra chữ ký của message để không ai giả mạo được. Nhiều việc hơn, nhiều chỗ hỏng hơn.
• C. SQS + EC2 poll hàng đợi — không serverless: EC2 phải chạy liên tục, phải vá, phải giám sát, và trả tiền cả khi không có message nào. Đây là pull model, trái với yêu cầu "automatically receive".
• D. "Tạo SQS topic và EC2, đăng ký instance vào SNS topic" — tự mâu thuẫn về thuật ngữ: SQS có queue, không có topic; SNS có topic. Ngoài ra EC2 không đăng ký được vào SNS topic như một subscriber, và cũng không serverless.

Ghi nhớ

Các giao thức đăng ký của SNS: | Protocol | Đích | |---|---| | lambda | hàm Lambda — push trực tiếp | | sqs | hàng đợi SQS | | http / https | webhook | | email / email-json | email | | sms | tin nhắn | | application | push cho thiết bị di động | | firehose | Kinesis Data Firehose |

So sánh hai mô hình: | | SNS (push) | SQS (pull) | |---|---|---| | Cách hoạt động | SNS gọi consumer | consumer hỏi hàng đợi | | Số consumer | nhiều (fan-out) | thường một nhóm | | Lưu trữ | không — không ai nhận là mất | giữ tới 14 ngày | | Thử lại | có, rồi vào DLQ | có, theo maxReceiveCount |

Và mẫu fan-out kết hợp cả hai là kiến trúc rất đáng biết:

Bên sinh sự kiện → SNS topic ─┬→ SQS queue A → Lambda A
                              ├→ SQS queue B → Lambda B
                              └→ Lambda C (trực tiếp)

Đặt SQS ở giữa cho hai lợi ích lớn: message không mất nếu consumer đang hỏng, và san phẳng đỉnh tải cho consumer xử lý chậm. Với hệ thống production, đây thường là lựa chọn tốt hơn việc đăng ký Lambda thẳng vào SNS.

Đáp án

A — Failure threshold (ngưỡng thất bại).

Vì sao đúng

FailureThreshold là tham số quy định bao nhiêu lần kiểm tra liên tiếp phải thất bại trước khi Route 53 chuyển endpoint sang trạng thái Unhealthy.

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

Với cấu hình trên: 3 lần thất bại liên tiếp × 30 giây = khoảng 90 giây thì endpoint mới bị đánh dấu là không lành.

Vì sao cần tham số này thay vì phản ứng ngay ở lần lỗi đầu tiên: một lần timeout đơn lẻ là chuyện bình thường trên Internet — gói tin rớt, mạng chập chờn, máy chủ bận trong một khoảnh khắc. Nếu chuyển traffic ngay ở lần đầu, hệ thống sẽ dao động liên tục giữa các endpoint (hiện tượng flapping), gây hại nhiều hơn lợi.

Đây là một đánh đổi cần cân nhắc: | FailureThreshold | Hệ quả | |---|---| | Thấp (1–2) | phát hiện nhanh, nhưng dễ báo động giả | | Cao (5–10) | ổn định, nhưng sự cố kéo dài hơn trước khi chuyển |

Giá trị mặc định là 3, và phạm vi cho phép là 1 đến 10.

Một chi tiết ít biết: Route 53 kiểm tra từ nhiều vị trí trên toàn cầu (mặc định khoảng 15), và endpoint được coi là lành nếu hơn 18% số vị trí báo lành. Nên FailureThreshold áp cho kết quả tổng hợp đó, không phải cho một vị trí đơn lẻ.

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

• B. Fault tolerance — là một khái niệm kiến trúc (khả năng hệ thống tiếp tục hoạt động khi có thành phần hỏng), không phải tham số cấu hình của health check.
• C. Network response — không phải tên tham số nào của Route 53. Nghe hợp lý nhưng không tồn tại.
• D. Latency — Route 53 có đo độ trễ, nhưng cho mục đích khác: latency-based routing dùng nó để chọn Region nhanh nhất. Health check thì quyết định dựa trên thành công hay thất bại, không dựa trên độ trễ. (Có ngoại lệ nhỏ: bật MeasureLatency sẽ cho biểu đồ độ trễ trong CloudWatch, nhưng nó chỉ để quan sát, không tham gia vào quyết định lành/không lành.)

Ghi nhớ

Các tham số chính của Route 53 health check: | Tham số | Ý nghĩa | Giá trị | |---|---|---| | FailureThreshold | số lần lỗi liên tiếp để đánh dấu Unhealthy | 1–10, mặc định 3 | | RequestInterval | khoảng cách giữa hai lần kiểm tra | 10 hoặc 30 giây | | Type | giao thức | HTTP, HTTPS, TCP, và các biến thể _STR_MATCH | | ResourcePath | đường dẫn kiểm tra | /health | | SearchString | chuỗi phải có trong phản hồi | với kiểu _STR_MATCH | | Inverted | đảo ngược kết quả | cho các kịch bản đặc biệt |

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

Loại thứ ba giải quyết một hạn chế quan trọng: health check kiểu endpoint cần địa chỉ truy cập được từ Internet. Với tài nguyên trong private subnet, hãy dựng một CloudWatch alarm rồi tạo health check dựa trên alarm đó.

Và kiểu HTTP_STR_MATCH đáng dùng hơn HTTP thuần: nó kiểm tra nội dung phản hồi chứ không chỉ mã 200 — bắt được trường hợp máy chủ trả về 200 kèm trang lỗi.

Đáp án

D — Cache sẽ trở nên lớn và tốn kém vì cả dữ liệu ít được truy vấn cũng bị ghi vào cache.

Vì sao đúng

Đề mô tả write-through caching: cập nhật cache ngay sau mọi lần ghi vào CSDL chính.

def cap_nhat(khoa, gia_tri):
    csdl.update(khoa, gia_tri)
    cache.set(khoa, gia_tri)      # ghi vào cache ở MỌI lần ghi

Hệ quả trực tiếp: mọi dữ liệu được ghi đều nằm trong cache — kể cả những bản ghi sẽ không bao giờ có ai đọc.

100.000 bản ghi được ghi mỗi ngày
→ 100.000 mục trong cache
→ nhưng chỉ khoảng 5.000 trong số đó thực sự được đọc

⇒ 95% bộ nhớ cache đang chứa dữ liệu vô ích

Vì ElastiCache tính tiền theo kích thước node, cache phình to nghĩa là phải nâng lên node lớn hơn — trả tiền cho bộ nhớ chứa dữ liệu không ai dùng. Đó chính xác là nhược điểm mà đáp án D mô tả.

Cách giảm nhẹ: đặt TTL cho mọi mục, để dữ liệu không được đọc tự bị dọn:

cache.setex(khoa, 3600, gia_tri)     # write-through + tự hết hạn sau 1 giờ

Kết hợp với chính sách eviction phù hợp (allkeys-lru hoặc volatile-lru) để Redis tự loại bỏ mục ít dùng khi gần đầy.

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

• A. "Tải lên RDS sẽ TĂNG vì cache được cập nhật ở mỗi lần ghi" — sai chiều: việc ghi vào cache không tạo thêm tải cho RDS. Ngược lại, write-through giảm tải đọc cho RDS vì mọi truy vấn đều trúng cache. Thứ tăng lên là độ trễ của thao tác GHI (phải làm hai việc), không phải tải của CSDL.
• B. "Truy vấn đọc chậm đi vì cache được cập nhật khi không tìm thấy dữ liệu" — mô tả này thuộc về lazy loading, không phải write-through. Với write-through, dữ liệu đã có sẵn trong cache, nên đọc nhanh hơn, không chậm hơn.
• C. "Có cache miss penalty vì cache chỉ được cập nhật SAU một lần miss" — cũng là mô tả của lazy loading. Đây chính là điểm mạnh mà write-through giải quyết được: không có cache miss cho dữ liệu đã ghi.

Ghi nhớ

So sánh hai chiến lược cơ bản: | | Write-through | Lazy loading (cache-aside) | |---|---|---| | Ghi vào cache khi | mỗi lần ghi CSDL | sau một lần đọc bị miss | | Dữ liệu cũ | không | có, tới khi TTL hết | | Cache miss penalty | không | có ở lần đọc đầu | | Kích thước cache | lớn — chứa cả dữ liệu không ai đọc | nhỏ — chỉ chứa dữ liệu thật sự được đọc | | Độ trễ ghi | cao hơn | thấp | | Cache mới tạo | trống tới khi có lượt ghi | trống tới khi có lượt đọc |

Hai chiến lược này bù trừ cho nhau, và trong thực tế người ta thường kết hợp cả hai:

def doc(khoa):
    gt = cache.get(khoa)
    if gt is None:                      # lazy loading: nạp khi miss
        gt = csdl.get(khoa)
        cache.setex(khoa, 3600, gt)
    return gt

def ghi(khoa, gia_tri):
    csdl.update(khoa, gia_tri)
    cache.setex(khoa, 3600, gia_tri)    # write-through: giữ cache luôn mới

Cộng thêm TTL ở cả hai đường, bạn có: dữ liệu luôn mới (từ write-through), cache không phình vô hạn (từ TTL), và dữ liệu nguội tự biến mất.

Cách chọn khi làm bài:

• Đề nhấn mạnh "real-time", "dữ liệu phải mới" ⇒ write-through
• Đề nhấn mạnh "tiết kiệm bộ nhớ", "chỉ cache dữ liệu hay dùng" ⇒ lazy loading
• Đề hỏi nhược điểm của write-through ⇒ cache phình to và tốn kém

Đáp án

C và D.

• C — Nếu chứng chỉ đang được một dịch vụ AWS sử dụng và bản ghi CNAME do ACM cung cấp vẫn truy cập được qua DNS công khai, ACM coi tên miền là đã xác thực và tự động gia hạn.
• D — Nếu tên miền không được xác thực, ACM gửi Health event hoặc EventBridge event để báo cho chủ sở hữu trước khi hết hạn.

Vì sao đúng

Hai phương án này mô tả hai nhánh của cùng một quy trình mà ACM chạy trước khi chứng chỉ hết hạn.

C — nhánh thành công. ACM bắt đầu quy trình gia hạn từ khoảng 60 ngày trước khi hết hạn, và kiểm tra hai điều kiện:

Thoả cả hai thì việc gia hạn diễn ra hoàn toàn tự động và không gián đoạn — bạn không phải làm gì, và chứng chỉ mới được triển khai sang các dịch vụ đang dùng nó.

Đây là lý do bạn không được xoá bản ghi CNAME sau khi chứng chỉ đã cấp. Rất nhiều người dọn DNS sau khi thấy chứng chỉ đã "Issued", rồi 13 tháng sau website sập vì không gia hạn được.

D — nhánh thất bại. Nếu ACM không xác thực lại được (CNAME đã bị xoá, DNS đổi nhà cung cấp, tên miền hết hạn), nó không im lặng mà phát cảnh báo qua:

• AWS Health Dashboard
• Amazon EventBridge (detail-type: "ACM Certificate Approaching Expiration")

Bạn bắt được sự kiện này để tự động hoá cảnh báo:

{
  "source": ["aws.acm"],
  "detail-type": ["ACM Certificate Approaching Expiration"]
}

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

• B. "…ACM coi là đã xác thực và gửi Health event/EventBridge event để nhắc chủ sở hữu GIA HẠN" — nửa đầu đúng nhưng nửa sau sai: nếu xác thực thành công thì ACM TỰ GIA HẠN, không đi nhắc bạn làm việc đó. Đây là bẫy tinh vi nhất — nó lấy đúng điều kiện của C nhưng gắn vào kết quả của D.
• E. "…sẽ dùng SNS để gửi thông báo sắp hết hạn" — sai hai chỗ: ACM không gửi SNS trực tiếp (kênh chính thức là Health event và EventBridge), và trường hợp mô tả (DNS validation hợp lệ + đang được dịch vụ AWS dùng) là trường hợp tự gia hạn, nên không có gì để thông báo. (Bạn hoàn toàn có thể nối EventBridge sang SNS — nhưng đó là việc bạn cấu hình, không phải hành vi mặc định của ACM.)
• A. "Nếu chứng chỉ do bên thứ ba cấp, ACM sẽ gửi yêu cầu tới bên thứ ba để xác minh chủ sở hữu" — ACM không làm việc này. Chứng chỉ nhập từ bên ngoài (imported) không được ACM gia hạn dưới bất kỳ hình thức nào — bạn phải tự nhập lại bản mới. ACM chỉ thông báo khi nó sắp hết hạn.

Ghi nhớ

Hành vi gia hạn theo nguồn gốc chứng chỉ: | Nguồn | Tự gia hạn | |---|---| | ACM cấp + DNS validation + đang dùng bởi dịch vụ AWS | ✅ hoàn toàn tự động | | ACM cấp + email validation | ❌ phải bấm xác nhận thủ công | | ACM cấp nhưng không được dịch vụ nào dùng | ❌ (ACM gửi cảnh báo) | | Chứng chỉ nhập từ bên ngoài | ❌ phải tự nhập lại | | Chứng chỉ từ AWS Private CA | ✅ nếu dùng qua ACM |

Ba việc nên làm để không bao giờ bị bất ngờ:

1. Luôn dùng DNS validation thay vì email — đây là khác biệt lớn nhất giữa "không bao giờ phải lo" và "phải nhớ mỗi năm".
2. Giữ nguyên bản ghi CNAME của ACM vĩnh viễn.
3. Đặt EventBridge rule bắt sự kiện sắp hết hạn rồi gửi sang SNS hoặc Slack — kể cả khi mọi thứ đang tự động, đây là lưới an toàn rẻ tiền.

Và với chứng chỉ nhập từ ngoài, hãy đặt lịch nhắc trước ít nhất 30 ngày — ACM có phát cảnh báo, nhưng nếu không ai đọc Health Dashboard thì cảnh báo đó vô nghĩa.

Đáp án

A — Tạo Docker image chạy X-Ray daemon, đẩy lên registry, rồi triển khai vào ECS cluster.

Vì sao đúng

X-Ray SDK trong ứng dụng không gửi thẳng dữ liệu tới dịch vụ X-Ray — nó gửi các segment qua UDP cổng 2000 tới một tiến trình trung gian gọi là X-Ray daemon, và daemon mới gom lô rồi gửi lên AWS.

Nên trong môi trường container, daemon cũng phải chạy dưới dạng container:

Task ECS
├── Container ứng dụng  ──UDP 2000──→ Container X-Ray daemon ──HTTPS──→ Dịch vụ X-Ray

Cách triển khai chuẩn là sidecar trong cùng task definition:

{
  "containerDefinitions": [
    {
      "name": "ung-dung",
      "image": "...ecr.../app:v1",
      "environment": [{"name": "AWS_XRAY_DAEMON_ADDRESS", "value": "xray-daemon:2000"}],
      "links": ["xray-daemon"]
    },
    {
      "name": "xray-daemon",
      "image": "amazon/aws-xray-daemon",
      "cpu": 32, "memoryReservation": 256,
      "portMappings": [{"containerPort": 2000, "protocol": "udp"}]
    }
  ]
}

(Với network mode awsvpc — bắt buộc trên Fargate — hai container chia sẻ network namespace, nên ứng dụng gọi daemon qua 127.0.0.1:2000 và không cần links.)

Đừng quên task role cần quyền:

{"Effect": "Allow",
 "Action": ["xray:PutTraceSegments", "xray:PutTelemetryRecords"],
 "Resource": "*"}

AWS cung cấp sẵn image chính thức amazon/aws-xray-daemon trên Docker Hub và ECR Public, nên "tạo Docker image" ở đây thường chỉ là dùng lại image đó.

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

• D. Cài X-Ray daemon trên từng ECS instance — cách này chỉ áp dụng được với EC2 launch type, và nó đi ngược tinh thần container hoá: bạn phải quản lý phần mềm trên host, phải bảo đảm mọi instance mới đều có daemon (qua user data hoặc AMI tuỳ chỉnh), và hoàn toàn không dùng được với Fargate — nơi bạn không có quyền truy cập host.
• B. Cài daemon trên một EC2 instance riêng rồi đo đạc microservice bằng X-Ray SDK — vế SDK thì đúng, nhưng đặt daemon ở một máy riêng tạo ra điểm hỏng đơn lẻ và buộc phải gửi UDP qua mạng (UDP không đảm bảo tới nơi — mất segment mà không có lỗi nào). Sidecar trong cùng task tránh hẳn cả hai vấn đề.
• C. Cài CloudWatch agent và đăng custom metric — sai công cụ cho mục đích: metric cho biết có bao nhiêu và bao lâu ở mức tổng hợp, nhưng đề cần trace information between the microservices — tức là theo dấu từng request qua nhiều dịch vụ. Chỉ X-Ray làm được việc đó.

Ghi nhớ

Kiến trúc của X-Ray:

Ứng dụng (X-Ray SDK) --UDP 2000--> X-Ray daemon --HTTPS--> Dịch vụ X-Ray

Nơi chạy daemon theo từng môi trường: | Môi trường | Cách | |---|---| | ECS / EKS | container sidecar | | EC2 | cài như dịch vụ hệ thống, hoặc qua user data | | Lambda | AWS tự chạy daemon — chỉ cần bật TracingConfig: Active | | Elastic Beanstalk | bật bằng option setting |

Dòng Lambda giải thích vì sao với Lambda bạn không bao giờ phải nghĩ tới daemon — AWS lo sẵn. Với container thì không, và đó là chi tiết mà câu hỏi này kiểm tra.

Hai khái niệm nên phân biệt khi dùng X-Ray: | | Annotation | Metadata | |---|---|---| | Được đánh chỉ mục | ✅ lọc trace theo nó được | ❌ | | Dùng cho | user_id, order_id, environment | dữ liệu chi tiết để đọc |

Muốn tìm trace của một đơn hàng cụ thể thì phải ghi nó làm annotation — ghi vào metadata sẽ không tìm được.

Đáp án

C — Xem trạng thái health check ngay trên bảng điều khiển Route 53.

Vì sao đúng

Câu hỏi rất cụ thể: tổ chức đã tạo health check nhưng chưa cấu hình CloudWatch alarm — vậy làm sao biết endpoint có vấn đề?

Câu trả lời đơn giản: Route 53 Console luôn hiển thị trạng thái của mọi health check, bất kể có alarm hay không.

Route 53 Console → Health checks
┌──────────────────┬──────────┬─────────────────────────────┐
│ Tên              │ Trạng thái│ Chi tiết                    │
├──────────────────┼──────────┼─────────────────────────────┤
│ web-bo-dong      │ Healthy  │ 15/15 vị trí báo lành       │
│ web-bo-tay       │ Unhealthy│ 3/15 vị trí báo lành        │
└──────────────────┴──────────┴─────────────────────────────┘

Console còn cho xem kết quả từ từng vị trí kiểm tra và lý do thất bại cụ thể (timeout, mã trạng thái sai, lỗi TLS, không khớp chuỗi tìm kiếm) — thường là manh mối chẩn đoán nhanh nhất.

Xem bằng CLI cũng được:

aws route53 get-health-check-status --health-check-id abc-123-def

Nói cách khác: CloudWatch alarm là để được BÁO ĐỘNG chủ động, còn Console là để XEM khi bạn muốn biết. Thiếu alarm thì mất tính chủ động, nhưng thông tin thì vẫn luôn có sẵn.

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

• B. Đăng ký SNS topic để nhận thông báo — không hoạt động nếu chưa có alarm. Route 53 health check không phát thông báo SNS trực tiếp; đường đi bắt buộc là:

  Health check → metric HealthCheckStatus trong CloudWatch → CloudWatch alarm → SNS
  

  Mà đề nói rõ alarm chưa được cấu hình — nên mắt xích ở giữa bị thiếu và SNS không nhận được gì.
• A. Xem trạng thái health check trên Shield dashboard — AWS Shield là dịch vụ chống DDoS. Bảng điều khiển của nó hiển thị các sự kiện tấn công, không hiển thị health check của Route 53.
• D. Tạo alarm bằng CloudTrail rồi nhận thông báo SNS — CloudTrail không tạo được alarm: nó ghi lời gọi API quản trị, không phát metric để đặt ngưỡng. Muốn có alarm thì phải dùng CloudWatch.

Ghi nhớ

Hai cách theo dõi health check, và mỗi cách phù hợp với một nhu cầu: | Cách | Đặc điểm | |---|---| | Route 53 Console / CLI | luôn có sẵn, nhưng PHẢI CHỦ ĐỘNG XEM | | CloudWatch alarm + SNS | tự động báo cho bạn |

Cách thiết lập cảnh báo đầy đủ — nên làm ngay sau khi tạo health check:

aws cloudwatch put-metric-alarm \
  --alarm-name canh-bao-endpoint-hong \
  --namespace AWS/Route53 --metric-name HealthCheckStatus \
  --dimensions Name=HealthCheckId,Value=abc-123-def \
  --statistic Minimum --period 60 --evaluation-periods 1 \
  --threshold 1 --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:canh-bao

Hai chi tiết dễ vấp:

1. Metric của Route 53 chỉ có ở Region us-east-1 — tạo alarm ở Region khác sẽ không tìm thấy metric. Đây là lỗi cấu hình phổ biến nhất với health check alarm.
2. HealthCheckStatus là 1 (lành) hoặc 0 (hỏng) — nên điều kiện cảnh báo là nhỏ hơn 1, không phải lớn hơn.

Các metric của Route 53 health check: | Metric | Ý nghĩa | |---|---| | HealthCheckStatus | 1 = lành, 0 = hỏng | | HealthCheckPercentageHealthy | % số vị trí kiểm tra báo lành | | ConnectionTime | thời gian thiết lập kết nối | | TimeToFirstByte | độ trễ tới byte đầu tiên |

Hai metric cuối chỉ có khi bật MeasureLatency, và chúng hữu ích để phát hiện endpoint đang chậm dần trước khi nó thật sự hỏng.

Đáp án

A — Tạo alias và version trong AWS Lambda.

Vì sao đúng

Vấn đề: mỗi lần đẩy mã mới, hàm Lambda có version mới — và nếu API Gateway trỏ thẳng vào một version cụ thể thì phải cập nhật cấu hình API ở mỗi lần triển khai.

Alias giải quyết bằng cách thêm một lớp gián tiếp: nó là con trỏ có tên, cập nhật được, trỏ tới một version bất biến.

API Gateway → alias "prod" → version 5
                    ↓ (sau khi triển khai mã mới)
              alias "prod" → version 6

API Gateway KHÔNG ĐỔI GÌ CẢ

Integration URI của API trỏ vào alias, và nó không bao giờ phải sửa:

arn:aws:lambda:ap-southeast-1:123456789012:function:xu-ly:prod
                                                            └─ alias

Quy trình triển khai chỉ còn hai bước:

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

Và vì đề nói lập trình viên duy trì nhiều nhánh mã, mô hình alias khớp rất tự nhiên:

$LATEST                    ← nơi phát triển
version 1, 2, 3, 4, 5, 6   ← bất biến, không bao giờ đổi
alias "dev"  → $LATEST
alias "test" → version 6
alias "prod" → version 5

Alias còn hỗ trợ weighted routing cho canary deployment:

aws lambda update-alias --function-name xu-ly --name prod \
  --function-version 6 \
  --routing-config AdditionalVersionWeights={"5"=0.9}
# 10% traffic sang version 6, 90% ở lại version 5

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

• D. Tạo nhiều stage và deployment (của API Gateway) — giải quyết bên sai: stage tách các môi trường của API, nhưng mỗi stage vẫn phải trỏ tới một đích Lambda cụ thể. Khi mã Lambda cập nhật, bạn vẫn phải sửa integration của stage đó — trừ khi dùng alias. (Mẫu đầy đủ trong thực tế kết hợp cả hai: stage variable trỏ tới tên alias, khi đó stage prod tự dùng alias prod. Nhưng nền tảng của cơ chế vẫn là alias.)
• B. Tạo nhiều private API endpoint và dùng CNAME — phức tạp và sai hướng: nó nhân bản chính API Gateway thay vì giải quyết vấn đề trỏ tới mã Lambda nào. Nhiều hạ tầng hơn, nhiều thứ phải bảo trì hơn.
• C. Tạo tag khác nhau cho mỗi hàm — tag chỉ là nhãn siêu dữ liệu dùng để phân loại và theo dõi chi phí. Nó không ảnh hưởng tới việc gọi hàm và không thể dùng làm đích của integration.

Ghi nhớ

Ba điều cần nhớ về alias:

1. Alias có ARN riêng — dùng nó ở mọi nơi trỏ tới hàm (API Gateway, event source, quyền).
2. Resource-based policy phải cấp cho từng alias — cấp quyền cho hàm mà không nêu qualifier sẽ không đủ, và lỗi hiện ra dưới dạng 500 không nói gì:

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

3. Provisioned concurrency đặt trên alias hoặc version, không đặt trên $LATEST — nên muốn loại bỏ cold start cho production thì buộc phải dùng alias.

Nguyên tắc chung: mọi thứ trỏ tới Lambda trong production đều nên trỏ vào alias, không bao giờ trỏ vào $LATEST hay một số version cụ thể.

Đáp án

A và D.

• A — Dùng Amazon Cognito với authenticated role và unauthenticated role.
• D — Dùng IAM, để ứng dụng assume role khác nhau tuỳ loại người dùng.

Vì sao đúng

Bối cảnh: 30.000 người dùng thuộc hai loại (đã đăng ký và khách), cần quyền đọc S3 khác nhau.

A — Cognito identity pool có sẵn đúng mô hình hai loại người dùng này. Đây là tính năng dựng riêng cho tình huống đó:

Người dùng ĐÃ ĐĂNG NHẬP  → authenticated role   → đọc được s3://kho/premium/*
Người dùng KHÁCH         → unauthenticated role → chỉ đọc s3://kho/cong-khai/*

// Khách — không cần đăng nhập gì
const cred = fromCognitoIdentityPool({ identityPoolId: 'ap-southeast-1:xxxx' });

// Người dùng đã đăng ký
const cred = fromCognitoIdentityPool({
  identityPoolId: 'ap-southeast-1:xxxx',
  logins: { 'cognito-idp.ap-southeast-1.amazonaws.com/ap-southeast-1_yyy': idToken }
});

Identity pool tự chọn role tương ứng và trả về credential AWS tạm thời — ứng dụng không phải viết logic phân loại.

D — cơ chế nền tảng bên dưới chính là IAM assume role. Điều mà Cognito làm là gọi sts:AssumeRoleWithWebIdentity. Phương án D mô tả cùng nguyên lý ở mức tổng quát: hai role, ứng dụng assume role phù hợp theo loại người dùng.

Hai phương án này không mâu thuẫn — chúng là hai cách diễn đạt của cùng một kiến trúc đúng, và điểm chung là quyền gắn với ROLE, không gắn với từng người dùng.

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

• B. Tạo một IAM user cho mỗi người dùng — bất khả thi: giới hạn cứng là 5.000 IAM user mỗi tài khoản, mà đề có 30.000 người dùng. Kể cả nếu vừa, việc tạo/xoá user cho mỗi lần đăng ký là gánh nặng vận hành khổng lồ. IAM user dành cho nhân sự và ứng dụng, không dành cho người dùng cuối — đây là nguyên tắc quan trọng nhất rút ra từ câu này.
• C. Dùng bucket policy giới hạn quyền đọc theo từng IAM user cụ thể — cùng vấn đề, cộng thêm một giới hạn nữa: bucket policy tối đa 20 KB. Liệt kê 30.000 người dùng trong đó là không thể.
• E. Nhúng access key cho hai loại người dùng vào mã ứng dụng — sai lầm bảo mật nghiêm trọng nhất: mã của ứng dụng client (web, mobile) ai cũng đọc được — chỉ cần mở DevTools hoặc giải nén file APK. Access key dài hạn nằm trong đó là bị lộ hoàn toàn, và không thể thu hồi mà không cập nhật ứng dụng cho mọi người dùng.

Ghi nhớ

Nguyên tắc phân quyền cho người dùng cuối: | Số lượng người dùng | Cơ chế | |---|---| | Vài chục nhân sự nội bộ | IAM user hoặc IAM Identity Center | | Hàng nghìn tới hàng triệu người dùng cuối | Cognito + role | | Ứng dụng chạy trên AWS | IAM role (instance profile, task role, execution role) |

Các giới hạn cứng của IAM đáng nhớ: | Đối tượng | Giới hạn | |---|---| | IAM user | 5.000 mỗi tài khoản | | IAM role | 1.000 mỗi tài khoản | | IAM group | 300 | | Group cho mỗi user | 10 | | Bucket policy | 20 KB |

Và để phân quyền tới từng người dùng mà vẫn chỉ dùng hai role, dùng biến thay thế trong policy:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::kho/${cognito-identity.amazonaws.com:sub}/*"
}

Một policy duy nhất phục vụ cả 30.000 người, và không ai chạm được vào dữ liệu của người khác.

Cảnh báo về unauthenticated role: nó cấp credential cho bất kỳ ai trên Internet. Hãy giữ nó ở mức tối thiểu tuyệt đối, và bật Cognito basic (classic) flow hoặc kiểm tra kỹ nếu không thật sự cần truy cập khách.

Đáp án

A và E.

• A — Phải nhập một chứng chỉ mới vào ACM.
• E — Phải xin cấp một chứng chỉ mới từ ACM.

Vì sao đúng

Chi tiết quyết định nằm ở một chữ trong đề: chứng chỉ được NHẬP (imported) từ nhà cung cấp khác, không phải do ACM cấp.

Và quy tắc là dứt khoát: ACM KHÔNG BAO GIỜ tự gia hạn chứng chỉ nhập từ bên ngoài.

Lý do rất dễ hiểu: ACM không sở hữu CA đã cấp chứng chỉ đó, và không có private key trong tay để yêu cầu cấp mới. Nó chỉ đóng vai trò kho lưu trữ và phân phối cho các dịch vụ AWS.

Nên khi chứng chỉ sắp hết hạn (đề nói đã 11 tháng, tức gần hết hạn kỳ 13 tháng), bạn có đúng hai lựa chọn — và đó chính là hai đáp án:

A — tiếp tục dùng nhà cung cấp cũ:

# Xin cấp mới từ CA bên ngoài, rồi nhập lại vào CÙNG một ARN
aws acm import-certificate \
  --certificate-arn arn:aws:acm:...:certificate/abc-123 \
  --certificate fileb://chung-chi.pem \
  --private-key fileb://khoa-rieng.pem \
  --certificate-chain fileb://chuoi.pem

Nhập vào cùng ARN cũ là mẹo quan trọng: các dịch vụ đang tham chiếu tới ARN đó (ELB, CloudFront) tự dùng chứng chỉ mới mà không cần cấu hình lại.

E — chuyển sang chứng chỉ do ACM cấp:

aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names "*.example.com" \
  --validation-method DNS

Đây là lựa chọn nên cân nhắc nghiêm túc: chứng chỉ công cộng của ACM miễn phí và tự gia hạn vĩnh viễn nếu dùng DNS validation — bạn sẽ không bao giờ phải làm lại việc này nữa.

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

• B. "Chứng chỉ mới sẽ tự động được tạo trước khi hết hạn ở tháng 12" và C. "…ở tháng 13" — ACM không tự tạo chứng chỉ thay thế cho chứng chỉ nhập từ ngoài. Con số 13 tháng trong C là thời hạn điển hình của chứng chỉ do ACM cấp, nhưng nó không áp cho chứng chỉ nhập vào — thời hạn đó do CA bên ngoài quyết định.
• D. "Chứng chỉ mới sẽ tự động được nhập vào ACM" — không có cơ chế nào tự nhập. Việc nhập luôn là thao tác chủ động của bạn.

Ghi nhớ

Bảng hành vi gia hạn của ACM — điểm quan trọng nhất của câu này: | Nguồn chứng chỉ | Tự gia hạn | |---|---| | ACM cấp + DNS validation + đang dùng bởi dịch vụ AWS | ✅ hoàn toàn tự động | | ACM cấp + email validation | ❌ phải xác nhận thủ công | | Nhập từ bên ngoài | ❌ PHẢI TỰ NHẬP LẠI | | AWS Private CA qua ACM | ✅ |

Đặc điểm của chứng chỉ nhập vào ACM: | Đặc điểm | Chi tiết | |---|---| | Định dạng | PEM, gồm certificate, private key, và chuỗi CA | | Gia hạn | thủ công hoàn toàn | | Cảnh báo hết hạn | ACM phát Health event / EventBridge event | | Xuất private key | ❌ (bạn đã có sẵn, vì chính bạn nhập vào) | | Chi phí | miễn phí (bạn trả tiền cho CA bên ngoài) |

Việc nên làm ngay khi nhập chứng chỉ từ ngoài — đặt EventBridge rule cảnh báo trước:

{
  "source": ["aws.acm"],
  "detail-type": ["ACM Certificate Approaching Expiration"]
}

Sự kiện này phát ra từ 45 ngày trước khi hết hạn. Nối nó với SNS hoặc Slack, vì không ai mở AWS Health Dashboard hằng ngày.

Và lời khuyên thực dụng: nếu không có ràng buộc bắt buộc phải dùng CA cụ thể (một số yêu cầu tuân thủ hoặc EV certificate), hãy chuyển sang chứng chỉ do ACM cấp. Miễn phí, tự gia hạn, và loại bỏ hẳn một loại sự cố ngừng dịch vụ.

Đáp án

B — Đặt route selection expression thành $request.body.action.

Vì sao đúng

WebSocket API của API Gateway định tuyến message bằng route selection expression — một biểu thức chỉ ra chỗ nào trong message chứa tên route.

Với payload JSON như đề mô tả:

{"action": "guiTinNhan", "noiDung": "Xin chào"}

biểu thức $request.body.action bảo API Gateway: lấy giá trị của trường action trong body và dùng nó làm tên route.

{"action": "guiTinNhan"}  → route "guiTinNhan"  → Lambda A
{"action": "thamGia"}     → route "thamGia"     → Lambda B
{"action": "roiPhong"}    → route "roiPhong"    → Lambda C

Cấu hình chỉ gồm một thiết lập ở mức API, cộng với các route:

aws apigatewayv2 create-api \
  --name chat-realtime --protocol-type WEBSOCKET \
  --route-selection-expression '$request.body.action'

aws apigatewayv2 create-route --api-id abc123 --route-key guiTinNhan
aws apigatewayv2 create-route --api-id abc123 --route-key thamGia

Đây đúng là "LEAST amount of configuration": một biểu thức, rồi mỗi giá trị action chỉ cần một route. Không có mã định tuyến nào phải viết.

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

• C. Đặt route selection expression thành $default — nhầm hai khái niệm. $default là TÊN của một route dự phòng, không phải một biểu thức chọn route. Đặt nó làm biểu thức nghĩa là mọi message đều đi vào cùng một chỗ — bạn sẽ phải tự viết logic phân loại action trong Lambda, tức là nhiều cấu hình và nhiều mã hơn, không phải ít hơn.
• A. Tạo một stage riêng cho mỗi giá trị của action — hiểu sai vai trò của stage: stage là môi trường triển khai (dev, test, prod), mỗi stage có URL riêng. Client sẽ phải kết nối tới URL khác nhau tuỳ hành động — hoàn toàn không khả thi với WebSocket, vốn là một kết nối bền duy trì lâu dài.
• D. Tạo mapping template để ánh xạ action sang integration request — mapping template biến đổi ĐỊNH DẠNG dữ liệu, nó không chọn đích đến. Việc chọn route đã xảy ra trước khi mapping template chạy.

Ghi nhớ

Ba route đặc biệt của WebSocket API — luôn có sẵn, không do bạn đặt tên: | Route | Kích hoạt khi | |---|---| | $connect | client mở kết nối — nơi đặt xác thực và lưu connectionId | | $disconnect | client ngắt kết nối — nơi dọn dẹp | | $default | message không khớp route nào |

Mẫu route selection expression hay dùng: | Biểu thức | Lấy tên route từ | |---|---| | $request.body.action | trường action trong JSON body | | $request.body.type | trường type | | $request.body.message.action | trường lồng nhau |

Để gửi message ngược lại cho client, dùng Management API với connectionId đã lưu ở $connect:

apigw = boto3.client('apigatewaymanagementapi',
                     endpoint_url='https://abc123.execute-api.ap-southeast-1.amazonaws.com/prod')
apigw.post_to_connection(ConnectionId=conn_id, Data=json.dumps({'tin': 'xin chào'}))

Hai lưu ý thực dụng:

1. Lưu connectionId vào DynamoDB ở $connect và xoá ở $disconnect — đó là cách duy nhất để biết ai đang kết nối.
2. $disconnect là best-effort — nếu client mất mạng đột ngột, sự kiện này có thể không tới. Nên đặt TTL trên bảng connection để dọn các bản ghi mồ côi.