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

Đáp án

B — Dùng delay queue để hoãn việc giao message mới trong vài giây.

Vì sao đúng

Yêu cầu rất chính xác: hoãn việc giao MESSAGE MỚI cho consumer một khoảng thời gian.

Delay queue làm đúng nghĩa đen điều đó qua thuộc tính DelaySeconds:

aws sqs set-queue-attributes --queue-url <url> \
  --attributes DelaySeconds=15

Message vừa được gửi vào sẽ vô hình với mọi consumer trong 15 giây, rồi mới xuất hiện.

Đặt được ở hai mức: | Mức | Cách đặt | Áp dụng cho | |---|---|---| | Queue | thuộc tính DelaySeconds | mọi message mới | | Message | tham số DelaySeconds khi SendMessage | một message cụ thể |

Giới hạn: 0 – 900 giây (15 phút). Riêng FIFO queue chỉ đặt được ở mức queue, không đặt riêng cho từng message.

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

• D. Visibility timeout — đây là bẫy chính, và khác biệt rất quan trọng:

  	Delay queue	Visibility timeout
  Áp dụng cho	message MỚI, chưa ai nhận	message ĐÃ được nhận
  Tác dụng	hoãn lần xuất hiện đầu tiên	ẩn message trong lúc consumer xử lý
  Tối đa	15 phút	12 giờ

  Đề nói rõ "postpone the delivery of new messages" ⇒ delay queue.

• A. Dead-letter queue — nơi chứa message xử lý hỏng sau maxReceiveCount lần thử. Nó không hoãn gì cả.

• C. FIFO queue — đảm bảo thứ tự và xử lý đúng một lần. Không liên quan tới độ trễ giao message.

Ghi nhớ

Bốn tham số thời gian của SQS, phân biệt cho rõ: | Tham số | Nghĩa | Phạm vi | |---|---|---| | DelaySeconds | hoãn message MỚI | 0 – 15 phút | | VisibilityTimeout | ẩn message đã nhận | 0 – 12 giờ | | MessageRetentionPeriod | giữ trong queue | 60 giây – 14 ngày | | ReceiveMessageWaitTimeSeconds | long polling | 0 – 20 giây |

Lỗi phổ biến nhất trong cặp SQS + Lambda: VisibilityTimeout nhỏ hơn timeout của hàm — message bị phát lại trong khi hàm vẫn đang chạy, gây xử lý trùng. Khuyến nghị đặt gấp 6 lần timeout của hàm.

Đáp án

B — Hook ValidateService.

Vì sao đúng

Vòng đời deployment của CodeDeploy trên EC2/On-Premises có thứ tự cố định, và ValidateService là hook cuối cùng:

ApplicationStop → DownloadBundle → BeforeInstall → Install
→ AfterInstall → ApplicationStart → ValidateService   ← CUỐI CÙNG

Vì nó chạy sau khi ứng dụng đã khởi động, đây là đúng chỗ để kiểm tra deploy có thành công hay không:

# appspec.yml
hooks:
  ValidateService:
    - location: scripts/kiem-tra-suc-khoe.sh
      timeout: 300
      runas: root

#!/bin/bash
# scripts/kiem-tra-suc-khoe.sh
for i in {1..30}; do
  ma=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/health)
  [ "$ma" = "200" ] && exit 0
  sleep 5
done
exit 1     # thoát khác 0 → CodeDeploy đánh dấu THẤT BẠI và rollback

Script thoát với mã khác 0 thì CodeDeploy coi deployment là thất bại, và nếu đã bật auto-rollback thì nó tự deploy lại bản trước — đó là giá trị thật của hook này.

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

• A. ApplicationStart — chạy trước ValidateService, đúng là nơi để khởi động dịch vụ, không phải để kiểm tra. Lúc nó chạy xong, ứng dụng có thể còn đang khởi tạo.
• C. AfterInstall — chạy sau khi chép tệp nhưng trước khi khởi động ứng dụng. Dùng để đổi quyền tệp, sửa cấu hình. Lúc này chưa có gì để kiểm tra.
• D. AllowTraffic — đây là bẫy tinh vi: hook này chỉ tồn tại trong deployment blue/green, và bản thân AllowTraffic không phải hook viết được — nó do CodeDeploy tự thực hiện. Hai hook viết được quanh nó là BeforeAllowTraffic và AfterAllowTraffic. Đề nói về deploy thường lên EC2, nên không có bước này.

Ghi nhớ

Bộ hook khác nhau theo nền tảng — chi tiết bị hỏi rất nhiều: | Nền tảng | Hook viết được | |---|---| | EC2/On-prem (in-place) | ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, ValidateService | | EC2 blue/green | thêm BeforeBlockTraffic, AfterBlockTraffic, BeforeAllowTraffic, AfterAllowTraffic | | ECS | BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, AfterAllowTraffic | | Lambda | chỉ BeforeAllowTraffic, AfterAllowTraffic |

Quy tắc nhớ nhanh: cần xác minh sau khi deploy xong ⇒ ValidateService (in-place) hoặc AfterAllowTestTraffic (blue/green).

Đáp án

B — Sinh khoá công khai từ khoá riêng, rồi import khoá đó vào từng Region.

Vì sao đúng

Sự thật nền tảng: EC2 key pair là tài nguyên theo Region. Key pair tạo ở ap-southeast-1 không tồn tại ở us-east-1.

Nhưng bản thân cặp khoá SSH thì không có khái niệm Region — nó chỉ là một cặp khoá mật mã. Nên cách tái sử dụng là import cùng một khoá công khai vào nhiều Region:

# 1. Sinh khoá công khai từ khoá riêng đang có
ssh-keygen -y -f khoa-cua-toi.pem > khoa-cua-toi.pub

# 2. Import vào từng Region
for r in ap-southeast-1 us-east-1 eu-west-1; do
  aws ec2 import-key-pair --region $r \
    --key-name khoa-chung \
    --public-key-material fileb://khoa-cua-toi.pub
done

Cách này còn có ưu điểm về bảo mật so với để AWS sinh khoá: khoá riêng không bao giờ đi qua AWS — bạn sinh nó tại chỗ, chỉ gửi lên phần công khai.

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

• C. "Không thể tái sử dụng key pair giữa các Region" — sai. Đúng là không sao chép key pair giữa các Region được bằng một lệnh, nhưng import cùng một khoá công khai vào nhiều Region thì hoàn toàn được, và đó là cách làm chuẩn.
• A. Mã hoá khoá riêng rồi cất trên S3 — hiểu nhầm vấn đề. Việc cất khoá riêng ở đâu không liên quan tới việc EC2 ở Region khác có nhận ra key pair đó hay không. EC2 chỉ biết những key pair đã được đăng ký trong Region của nó. Và cất khoá riêng trên S3 lại thêm một rủi ro bảo mật.
• D. "Lưu key pair trong AWS Trusted Advisor" — sai hoàn toàn về chức năng. Trusted Advisor là công cụ khuyến nghị về chi phí, hiệu năng, bảo mật và giới hạn dịch vụ. Nó không lưu trữ gì cả. (Điều thú vị: Trusted Advisor có một check cảnh báo khi phát hiện khoá bị lộ công khai — nhưng đó là việc hoàn toàn khác.)

Ghi nhớ

Phạm vi các tài nguyên hay bị nhầm: | Phạm vi | Tài nguyên | |---|---| | Toàn cầu | IAM, Route 53, CloudFront, S3 (tên bucket) | | Theo Region | EC2 key pair, AMI, security group, VPC, snapshot | | Theo AZ | Subnet, EBS volume, EC2 instance |

Và một khuyến nghị vận hành đáng giá hơn cả câu hỏi này: hãy bỏ hẳn SSH key pair và dùng SSM Session Manager. Nó không cần khoá, không cần mở cổng 22, phân quyền bằng IAM, và ghi vết mọi phiên trong CloudTrail — giải quyết tận gốc vấn đề "làm mất khoá riêng" mà đề mô tả.

Đáp án

B — DependentParameter không phải là kiểu parameter hợp lệ.

Vì sao đúng

CloudFormation có một danh sách hữu hạn các kiểu parameter, chia làm ba nhóm:

Nhóm 1 — kiểu cơ bản: | Kiểu | Ví dụ | |---|---| | String | "production" | | Number | 42 | | List<Number> | "1,2,3" | | CommaDelimitedList | "a,b,c" → ["a","b","c"] |

Nhóm 2 — kiểu AWS-specific (CloudFormation kiểm tra giá trị có tồn tại thật hay không trước khi tạo stack): | Kiểu | Kiểm | |---|---| | AWS::EC2::KeyPair::KeyName | key pair có tồn tại trong Region không | | AWS::EC2::VPC::Id | VPC ID hợp lệ | | AWS::EC2::Subnet::Id | subnet ID hợp lệ | | AWS::EC2::SecurityGroup::Id | security group ID | | AWS::EC2::Image::Id | AMI ID | | List<AWS::EC2::Subnet::Id> | danh sách subnet |

Nhóm 3 — SSM parameter type: AWS::SSM::Parameter::Value<String> — lấy giá trị thẳng từ Parameter Store lúc deploy.

DependentParameter không nằm trong bất kỳ nhóm nào. Nó là tên bịa.

Giá trị lớn nhất của kiểu AWS-specific: nó bắt lỗi sớm. Nhập sai tên key pair thì stack thất bại ngay ở bước validate, thay vì chạy nửa chừng rồi hỏng ở tài nguyên thứ mười.

Vì sao các phương án khác sai (tức là chúng đều hợp lệ)

• A. String — kiểu cơ bản, dùng nhiều nhất.
• C. AWS::EC2::KeyPair::KeyName — kiểu AWS-specific, đúng thứ đề đang nói tới ("AWS-specific parameter types to catch invalid values").
• D. CommaDelimitedList — kiểu cơ bản, tách chuỗi thành mảng.

Ghi nhớ

Vài thuộc tính hay dùng cùng parameter để ràng buộc giá trị:

Parameters:
  LoaiInstance:
    Type: String
    Default: t3.micro
    AllowedValues: [t3.micro, t3.small, t3.medium]   # chỉ cho phép 3 giá trị
    Description: Loại EC2 instance
  MatKhau:
    Type: String
    NoEcho: true                                      # che giá trị trong Console/API
    MinLength: 12
    AllowedPattern: "^[a-zA-Z0-9!@#$%]+$"

NoEcho: true là thuộc tính bắt buộc cho mọi parameter nhạy cảm — không có nó, giá trị hiện nguyên văn trong DescribeStacks và trong Console.

Đáp án

B và D.

• D — Container image phải hiện thực Lambda Runtime API thì mới triển khai lên Lambda được.
• B — Lambda không hỗ trợ container image đa kiến trúc (multi-architecture).

Vì sao đúng

D — Runtime API là bắt buộc. Lambda không chạy container như Docker thường; nó gọi container qua một giao thức riêng. Image phải có Runtime Interface Client (RIC) để nhận sự kiện và trả kết quả:

FROM public.ecr.aws/lambda/python:3.12    # base image của AWS đã có sẵn RIC
COPY app.py ${LAMBDA_TASK_ROOT}
CMD ["app.handler"]

Dùng base image của mình thì phải tự cài RIC:

FROM python:3.12-slim
RUN pip install awslambdaric
ENTRYPOINT ["python", "-m", "awslambdaric"]
CMD ["app.handler"]

B — không hỗ trợ multi-architecture. Image manifest phải trỏ tới một kiến trúc duy nhất — hoặc x86_64, hoặc arm64. Manifest list chứa cả hai (thứ docker buildx sinh ra mặc định) sẽ bị Lambda từ chối. Đây là chỗ vấp rất thực tế khi build bằng buildx.

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

• C. "Kích thước tối đa 15 GB" — sai con số. Giới hạn đúng là 10 GB.
• E. "Lambda hỗ trợ cả container Windows lẫn Linux" — sai. Lambda chỉ chạy container Linux. Không có runtime Windows cho Lambda ở bất kỳ dạng nào.
• A. "Kiểm thử container cục bộ bằng Lambda Runtime API" — câu này gần đúng nhưng sai tên thành phần. Thứ dùng để kiểm thử cục bộ là Runtime Interface Emulator (RIE), không phải Runtime API:

  docker run -p 9000:8080 ham-cua-toi:latest
  curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
  

  Runtime API là giao thức giữa Lambda và container lúc chạy thật; Runtime Interface Emulator là công cụ mô phỏng nó trên máy bạn. Base image của AWS có sẵn RIE.

Ghi nhớ

Bảng so sánh hai cách đóng gói Lambda: | | Zip | Container image | |---|---|---| | Kích thước tối đa | 50 MB (zip) / 250 MB (giải nén) | 10 GB | | Kiến trúc | x86_64 hoặc arm64 | một kiến trúc, không multi-arch | | Hệ điều hành | Linux | chỉ Linux | | Nơi lưu | S3 | ECR (cùng Region, cùng tài khoản) | | Cold start | nhanh hơn | chậm hơn với image lớn | | Layer | ✅ dùng được | ❌ không dùng được |

Container image hợp khi phụ thuộc quá lớn (thư viện ML, binary hệ thống); còn lại thì zip vẫn nhanh hơn.

Đáp án

B — Dùng AWS Step Functions để điều phối và quản lý các thành phần của quy trình.

Vì sao đúng

Đề mô tả một quy trình nghiệp vụ nhiều bước, tuần tự, có trạng thái: tạo đơn → cập nhật kho → giao hàng, và toàn bộ phải được theo dõi, quản lý và cập nhật tự động.

Step Functions sinh ra đúng cho việc này. Điểm khác biệt cốt lõi so với ba phương án còn lại: nó giữ trạng thái của cả quy trình.

{
  "StartAt": "TaoDonHang",
  "States": {
    "TaoDonHang":    {"Type": "Task", "Resource": "...tao-don", "Next": "KiemTraKho"},
    "KiemTraKho":    {"Type": "Task", "Resource": "...kiem-kho",
                      "Retry": [{"ErrorEquals": ["States.TaskFailed"], "MaxAttempts": 3}],
                      "Next": "ConHang?"},
    "ConHang?":      {"Type": "Choice",
                      "Choices": [{"Variable": "$.ton_kho", "NumericGreaterThan": 0,
                                   "Next": "GiaoHang"}],
                      "Default": "BaoHetHang"},
    "GiaoHang":      {"Type": "Task", "Resource": "...giao-hang", "End": true},
    "BaoHetHang":    {"Type": "Task", "Resource": "...bao-khach", "End": true}
  }
}

Bốn thứ có sẵn, không phải viết:

• Theo dõi trực quan — nhìn thấy đơn hàng đang ở bước nào, dữ liệu vào/ra từng bước
• Retry — thử lại đúng bước hỏng với exponential backoff
• Catch — rẽ nhánh xử lý lỗi, bồi hoàn (compensation)
• Choice — rẽ nhánh theo điều kiện nghiệp vụ

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

• C. SQS — chỉ truyền message giữa hai thành phần. Nó không biết quy trình có mấy bước, đang ở bước nào, hay bước nào đã hỏng. Muốn dựng quy trình bằng SQS thì phải tự viết toàn bộ phần điều phối và tự theo dõi trạng thái.
• D. SNS — phát tin cho nhiều người nhận cùng lúc (fan-out). Nó không có khái niệm thứ tự, không có trạng thái, không thử lại theo bước.
• A. EventBridge — định tuyến sự kiện theo mẫu, rất tốt cho kiến trúc hướng sự kiện lỏng lẻo. Nhưng nó cũng không giữ trạng thái quy trình: mỗi sự kiện là độc lập, không có cách nào hỏi "đơn hàng DH-123 đang ở đâu". (EventBridge và Step Functions thường dùng chung: EventBridge kích hoạt, Step Functions điều phối.)

Ghi nhớ

Hai loại workflow của Step Functions: Standard (chạy tới 1 năm, ghi đầy đủ lịch sử, tính tiền theo bước — hợp với quy trình nghiệp vụ như đề này) và Express (tối đa 5 phút, thông lượng rất cao, rẻ hơn nhiều — hợp với xử lý luồng dữ liệu).

Đáp án

A — 20 RCU.

Vì sao đúng

Phép tính RCU của DynamoDB có ba bước, và bước làm tròn là chỗ hay sai:

Bước 1 — làm tròn kích thước item lên bội số của 4 KB:

6 KB  →  làm tròn lên  →  8 KB

Bước 2 — tính RCU cho một lần đọc: | Loại đọc | Quy tắc | |---|---| | Strongly consistent | 1 RCU cho mỗi 4 KB | | Eventually consistent | 0,5 RCU cho mỗi 4 KB |

Đề yêu cầu strongly consistent:

8 KB ÷ 4 KB = 2 RCU cho mỗi lần đọc

Bước 3 — nhân với số lần đọc mỗi giây:

2 RCU × 10 lần/giây = 20 RCU

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

• C. 10 — quên nhân với 2, tức là bỏ qua việc item 6 KB chiếm hai đơn vị 4 KB.
• D. 30 — có thể do làm tròn 6 KB lên 12 KB (3 × 4 KB) thay vì 8 KB.
• B. 60 — nhầm sang cách tính khác hẳn, có lẽ dùng 6 KB × 10 rồi chia sai.

Ghi nhớ

Hai công thức cần thuộc, và chúng không đối xứng:

RCU — làm tròn lên bội số 4 KB:

Strongly consistent : ceil(kích_thước / 4 KB)      × số_lần_đọc
Eventually consistent: ceil(kích_thước / 4 KB) / 2 × số_lần_đọc
Transactional read  : ceil(kích_thước / 4 KB) × 2 × số_lần_đọc

WCU — làm tròn lên bội số 1 KB:

Ghi thường       : ceil(kích_thước / 1 KB)     × số_lần_ghi
Transactional ghi: ceil(kích_thước / 1 KB) × 2 × số_lần_ghi

Ba điểm dễ sai nhất:

1. RCU dùng 4 KB, WCU dùng 1 KB — hai con số khác nhau
2. Luôn làm tròn LÊN — item 4,1 KB tốn như item 8 KB
3. Eventually consistent rẻ một nửa, transactional đắt gấp đôi

(Ghi chú: với chế độ on-demand, bạn không phải tính RCU/WCU — DynamoDB tự co giãn và tính tiền theo request thực tế. Nhưng công thức này vẫn cần cho chế độ provisioned và cho đề thi.)

Đáp án

A — Amazon ElastiCache (kèm S3 làm backup) KHÔNG phải đích được Kinesis Data Firehose hỗ trợ.

Vì sao đúng

Firehose là dịch vụ nạp dữ liệu vào đích lưu trữ và phân tích. Danh sách đích được hỗ trợ khá cụ thể, và ElastiCache không nằm trong đó:

Vì sao ElastiCache không có mặt. ElastiCache là cache trong bộ nhớ — thứ dùng để tăng tốc đọc cho ứng dụng, không phải kho lưu trữ để nạp dữ liệu vào. Nó cũng không bền vững (Memcached mất sạch khi node hỏng), nên hoàn toàn ngược với mục đích của Firehose.

Chi tiết trong đề — "với S3 làm backup" — càng cho thấy phương án này được viết ra để nghe giống các đích thật (Redshift và OpenSearch đều có tuỳ chọn backup sang S3).

Vì sao các phương án khác sai (tức là chúng đều được hỗ trợ)

• B. S3 làm đích trực tiếp — đích cơ bản nhất; Firehose gom lô, nén, chuyển sang Parquet/ORC và phân vùng động.
• C. Redshift kèm S3 — Firehose luôn ghi qua S3 trước rồi mới COPY vào Redshift. Bucket S3 ở đây là bắt buộc, không phải tuỳ chọn.
• D. OpenSearch kèm tuỳ chọn backup S3 — mô tả chính xác: chọn được backup tất cả bản ghi hoặc chỉ bản ghi thất bại.

Ghi nhớ

Vài đặc điểm của Firehose đáng nhớ: buffer theo kích thước hoặc theo thời gian (tối thiểu ~60 giây), nên không phải thời gian thực thật — cần độ trễ dưới giây thì phải dùng Data Streams.

Đáp án

D — Đẩy custom metric độ phân giải cao (high-resolution) lên CloudWatch ghi lại số lần API thanh toán thất bại, rồi tạo CloudWatch alarm gửi thông báo qua SNS topic có sẵn.

Vì sao đúng

Điểm mấu chốt: CloudWatch không tự biết gì về API của nhà cung cấp bên ngoài. Đó là lời gọi HTTP ra ngoài AWS, nên không có metric dựng sẵn nào theo dõi tỷ lệ lỗi của nó.

Cách duy nhất là ứng dụng tự đo và tự báo cáo:

def goi_api_thanh_toan(don_hang):
    try:
        kq = requests.post(API_URL, json=don_hang, timeout=10)
        kq.raise_for_status()
        dat_metric('ThanhCong', 1)
    except Exception:
        dat_metric('ThatBai', 1)
        raise

def dat_metric(ten, gia_tri):
    cloudwatch.put_metric_data(
        Namespace='ThanhToan',
        MetricData=[{'MetricName': ten, 'Value': gia_tri,
                     'Unit': 'Count', 'StorageResolution': 1}])   # high resolution

Rồi dùng metric math để tính tỷ lệ lỗi và đặt alarm ở ngưỡng 5%:

(ThatBai / (ThatBai + ThanhCong)) * 100 > 5

Vế "near real-time" là lý do chọn high-resolution: metric độ phân giải 1 giây cho phép alarm đánh giá nhanh nhất 10 giây, thay vì tối thiểu 60 giây của metric thường.

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

• B. "Bật detailed monitoring cho các lời gọi API bên ngoài" — không tồn tại. Detailed monitoring là tính năng của EC2 (đổi metric từ 5 phút xuống 1 phút). Nó không áp dụng cho lời gọi HTTP tới dịch vụ bên thứ ba.
• A và C. Ghi log rồi dùng Logs Insights hoặc metric filter, và "để Lambda tự kiểm tra" — cả hai đều vòng vèo hơn cần thiết. Ghi log rồi phân tích ngược lại thêm độ trễ, và cả hai đều kết thúc bằng việc Lambda tự kiểm tra ngưỡng rồi tự gọi SNS — tức là tự viết lại CloudWatch alarm bằng mã. (Metric filter ở phương án C là công cụ hợp lệ, nhưng metric sinh ra từ nó là standard resolution, khó đạt "near real-time".)

Ghi nhớ

Và nhớ hai công cụ hay đi cùng nhau:

• Metric math — tính toán giữa các metric ((e1/(e1+e2))*100), rất hợp cho tỷ lệ phần trăm
• put_metric_data theo lô — gửi tối đa 1.000 điểm dữ liệu mỗi lời gọi, tránh tốn phí API khi lưu lượng lớn

Đáp án

C — Triển khai Dead-Letter Queue (DLQ).

Vì sao đúng

Yêu cầu: cô lập những message xử lý hỏng để điều tra và xử lý tiếp.

Không có DLQ thì với SQS, message xử lý hỏng quay lại hàng đợi sau khi hết visibility timeout, và được thử lại vô hạn cho tới khi hết MessageRetentionPeriod (tối đa 14 ngày) rồi biến mất không dấu vết. Trong lúc đó nó còn chiếm chỗ và làm chậm việc xử lý các message khoẻ mạnh.

Redrive policy đặt một ngưỡng: sau maxReceiveCount lần nhận không thành công, SQS chuyển message sang DLQ:

aws sqs set-queue-attributes --queue-url <url-hang-doi-chinh> \
  --attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"arn:aws:sqs:...:dlq\",\"maxReceiveCount\":\"3\"}"}'

Hai lợi ích cùng lúc:

• Message hỏng được giữ nguyên vẹn để đọc và tái hiện lỗi
• Hàng đợi chính không còn bị nghẽn bởi message không bao giờ xử lý được

Sửa mã xong thì dùng redrive to source đẩy chúng ngược về hàng đợi chính để xử lý lại.

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

• A. Tăng VisibilityTimeout — chỉ cho consumer nhiều thời gian hơn để xử lý mỗi message. Hữu ích khi message bị phát lại vì hàm chạy chậm, nhưng message hỏng thật thì vẫn hỏng, chỉ hỏng chậm hơn.
• D. Giảm VisibilityTimeout — đi ngược lại: message được phát lại nhanh hơn, nên nó quay vòng dày đặc hơn và làm tình hình tệ hơn.
• B. Dùng DeleteMessage — xoá vĩnh viễn message. Nó "giải quyết" vấn đề nghẽn hàng đợi nhưng phá huỷ chính thứ cần điều tra — trái thẳng yêu cầu "isolated for further processing and troubleshooting".

Ghi nhớ

Quy tắc về DLQ: | Quy tắc | Chi tiết | |---|---| | Cùng kiểu queue | FIFO → DLQ phải FIFO; standard → DLQ phải standard | | maxReceiveCount | thường đặt 3–5 | | Retention của DLQ | nên dài hơn hàng đợi chính để có thời gian điều tra | | Alarm | luôn đặt alarm trên ApproximateNumberOfMessagesVisible của DLQ |

Điểm cuối cùng quan trọng nhất về mặt vận hành: DLQ không có alarm thì cũng vô dụng như không có DLQ — message vào đó rồi nằm im, không ai biết.

(Lambda cũng có cơ chế tương tự: on-failure destination hoặc DLQ cho lời gọi bất đồng bộ.)