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

Đáp án

D — Cấu hình high-resolution CloudWatch alarm và dùng SNS để gửi cảnh báo.

Vì sao đúng

Ràng buộc quyết định nằm ở con số: phải được thông báo trong vòng 30 giây.

CloudWatch alarm thường có chu kỳ đánh giá tối thiểu 60 giây — nghĩa là kể cả trường hợp tốt nhất, bạn cũng không thể biết trong 30 giây. Nó không đáp ứng nổi yêu cầu về mặt vật lý.

High-resolution alarm đánh giá ở chu kỳ 10 giây hoặc 30 giây:

aws cloudwatch put-metric-alarm \
  --alarm-name ung-dung-khong-phan-hoi \
  --namespace UngDungCuaToi \
  --metric-name TinhSanSang \
  --period 10 \
  --evaluation-periods 2 \
  --threshold 1 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:ap-southeast-1:123456789012:canh-bao

Với --period 10 và --evaluation-periods 2, cảnh báo kích hoạt sau khoảng 20 giây — nằm trong yêu cầu 30 giây.

Điều kiện tiên quyết: metric phải là high-resolution custom metric, tức là đăng với StorageResolution=1:

aws cloudwatch put-metric-data --namespace UngDungCuaToi \
  --metric-data MetricName=TinhSanSang,Value=1,StorageResolution=1

Đề đã nói metric có độ chi tiết 1 giây, nên điều kiện này đã thoả.

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

• B. Dùng metric mặc định của CloudWatch — metric mặc định của EC2 có chu kỳ 5 phút (hoặc 1 phút với detailed monitoring). Chậm hơn yêu cầu hàng chục lần. Ngoài ra metric mặc định đo tình trạng máy, không đo tính sẵn sàng của ứng dụng như metric tuỳ chỉnh mà lập trình viên đã dựng.
• A. Chỉ định SNS topic ngay trong lệnh put-metric-data — put-metric-data không có tham số nào cho SNS. Nó chỉ gửi dữ liệu metric; việc cảnh báo hoàn toàn thuộc về alarm.
• C. Logs Insights + EventBridge rule — Logs Insights là truy vấn theo yêu cầu, phải có người chạy, không giám sát liên tục. Và metric ở đây là metric, không phải log — không có gì để truy vấn.

Ghi nhớ

Hai loại metric của CloudWatch: | | Standard resolution | High resolution | |---|---|---| | Chu kỳ | 60 giây | 1 giây | | Chu kỳ alarm cho phép | 60, 300, 900… giây | 10, 30, và bội số của 60 | | Chi phí | thường | cao hơn | | Đăng bằng | mặc định | StorageResolution=1 |

Thời gian lưu dữ liệu — dữ liệu cũ tự động được gộp lại: | Tuổi dữ liệu | Độ chi tiết còn giữ | |---|---| | 3 giờ đầu | 1 giây (nếu là high-res) | | 15 ngày | 60 giây | | 63 ngày | 5 phút | | 15 tháng | 1 giờ |

Nghĩa là dữ liệu 1 giây chỉ tồn tại 3 giờ — high-resolution dùng để phát hiện nhanh, không dùng để phân tích lịch sử.

Ba trạng thái của alarm: OK, ALARM, và INSUFFICIENT_DATA. Với high-resolution alarm, nếu ứng dụng ngừng gửi metric thì alarm rơi vào INSUFFICIENT_DATA chứ không phải ALARM — nên nhớ đặt --treat-missing-data breaching nếu "không có dữ liệu" cũng là dấu hiệu ứng dụng đã chết. Đây là chi tiết rất dễ bỏ sót và nó vô hiệu hoá toàn bộ cảnh báo đúng lúc cần nhất.

Đáp án

D — Dùng API Gateway với Lambda làm backend, và bật caching trong API Gateway.

Vì sao đúng

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

1. Prototype — bản thử nghiệm
2. Lưu lượng khiêm tốn, chủ yếu trong lúc kiểm thử
3. Chi phí thấp nhất

Với tải thấp và không đều, mô hình trả theo lượng dùng thắng tuyệt đối:

Và caching có sẵn ngay trong API Gateway — không cần thêm dịch vụ nào:

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations \
    op=replace,path=/cacheClusterEnabled,value=true \
    op=replace,path=/cacheClusterSize,value=0.5 \
    op=replace,path=/*/*/caching/ttlInSeconds,value=300

Đúng vế "leverage AWS's caching features" trong đề, với đúng một dòng cấu hình.

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

• C. EC2 + ElastiCache — hai tài nguyên trả tiền theo giờ liên tục, kể cả khi prototype không có ai dùng. Đắt nhất trong bốn phương án, và còn phải tự vá hệ điều hành, tự lo sẵn sàng cao.
• A. ECS + ElastiCache — cũng hai tài nguyên chạy liên tục. Fargate đỡ hơn EC2 ở khoản vận hành, nhưng task vẫn tính tiền theo thời gian chạy, không phải theo request.
• B. Elastic Beanstalk + DynamoDB làm cache — sai hai chỗ. Beanstalk chạy trên EC2 nên vẫn trả tiền liên tục. Và DynamoDB không phải dịch vụ cache — nó là CSDL; dùng nó làm cache thì phải tự viết logic hết hạn và tự quản lý, trong khi DAX mới là lớp cache của DynamoDB. Ngoài ra đề nói "leverage AWS's caching features", hàm ý dùng tính năng có sẵn.

Ghi nhớ

Chi phí API Gateway cache — có một điểm rất dễ tốn tiền oan: | Kích thước | Ghi chú | |---|---| | 0,5 GB đến 237 GB | tính tiền THEO GIỜ, không theo request | | TTL 0 – 3600 giây | mặc định 300 | | TTL = 0 | tắt cache |

Cache tính tiền ngay cả khi không có request nào — nên với môi trường dev và test, nhớ tắt. Đây là khoản chi phí ẩn hay bị quên nhất của API Gateway.

Chọn dịch vụ theo dạng tải: | Dạng tải | Chọn | |---|---| | Thấp, thất thường, prototype | API Gateway + Lambda | | Cao và đều | ECS/EC2 thường rẻ hơn tính theo request | | Cần kiểm soát runtime, tác vụ chạy lâu | ECS/EC2 |

Và nếu muốn rẻ hơn nữa cho API đơn giản: HTTP API của API Gateway có giá thấp hơn khoảng 70% so với REST API. Đổi lại là mất một số tính năng, trong đó có cả caching — nên với đề bài này, REST API là lựa chọn đúng.

Đáp án

B — Tạo tệp ZIP chứa mã nguồn và toàn bộ thư viện phụ thuộc.

Vì sao đúng

Môi trường thực thi Lambda chỉ có sẵn thư viện chuẩn của runtime (cộng với AWS SDK ở Python và Node.js). Thư viện xử lý ảnh như Pillow, OpenCV, ImageMagick đều không có sẵn — nên phải đóng gói cùng mã.

Cấu trúc gói cho Python:

goi-trien-khai.zip
├── ham.py              ← mã nguồn
├── PIL/                ← thư viện
├── numpy/
└── ...

Cách dựng:

pip install -r requirements.txt -t ./goi/
cp ham.py ./goi/
cd goi && zip -r ../goi-trien-khai.zip .
aws lambda update-function-code --function-name xu-ly-anh \
  --zip-file fileb://goi-trien-khai.zip

Điểm cực kỳ quan trọng với thư viện xử lý ảnh: nhiều thư viện có phần mở rộng biên dịch sẵn theo hệ điều hành (.so). Cài trên macOS hay Windows rồi đóng gói sẽ lỗi khi chạy trên Lambda (vốn là Amazon Linux). Phải dựng gói trong môi trường tương thích:

docker run --rm -v "$PWD":/var/task public.ecr.aws/sam/build-python3.12 \
  pip install -r requirements.txt -t ./goi/

Đây là lỗi phổ biến nhất khi đóng gói Lambda có thư viện ảnh.

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

• C. ZIP chứa mã nguồn và script cài thư viện lúc chạy — sai vì nhiều lý do: /var/task chỉ đọc, thư mục ghi được duy nhất là /tmp; hàm có thể không có kết nối Internet (nhất là khi gắn vào VPC không có NAT); và việc cài đặt sẽ chạy lại ở mọi cold start, làm độ trễ tăng vọt.
• A. ZIP chứa mã nguồn và appspec.yml, khai thư viện trong đó — nhầm công cụ: appspec.yml là tệp của CodeDeploy, dùng để khai các bước triển khai. Nó không cài đặt thư viện và Lambda không đọc tệp này khi nạp mã.
• D. ZIP chứa mã nguồn và buildspec.yml để "cài thư viện trên Lambda" — cũng nhầm công cụ: buildspec.yml là tệp của CodeBuild, chạy trong lúc build, không phải trong môi trường Lambda. CodeBuild có thể dùng nó để dựng gói, nhưng gói kết quả vẫn phải chứa sẵn thư viện.

Ghi nhớ

Ba cách đưa thư viện vào Lambda: | Cách | Giới hạn | Dùng khi | |---|---|---| | ZIP kèm thư viện | 50 MB nén / 250 MB giải nén | mặc định | | Lambda Layer | 5 layer, tổng vẫn 250 MB | dùng chung cho nhiều hàm | | Container image | 10 GB | thư viện rất nặng (OpenCV, ML) |

Với xử lý ảnh, Layer thường là lựa chọn tốt nhất: tách thư viện khỏi mã, nên mỗi lần sửa mã chỉ phải tải lên vài KB thay vì vài chục MB — vòng lặp phát triển nhanh hơn hẳn:

aws lambda publish-layer-version --layer-name thu-vien-anh \
  --zip-file fileb://layer.zip \
  --compatible-runtimes python3.12

Còn nếu thư viện vượt quá 250 MB (rất hay gặp với OpenCV đầy đủ hoặc mô hình học máy), container image là lối thoát duy nhất — hạn mức lên tới 10 GB.

Các giới hạn khác cần thuộc: gói tải trực tiếp tối đa 50 MB, tải qua S3 thì tối đa 250 MB (đã giải nén), và /tmp có 512 MB tới 10 GB tuỳ cấu hình.

Đáp án

D — Composite primary key với supplierId làm partition key và transactionTime làm sort key.

Vì sao đúng

Có hai tiêu chí phải thoả, và chỉ D thoả cả hai.

1. Tính duy nhất — điều kiện bắt buộc. Trong DynamoDB, cặp (partition key, sort key) phải là duy nhất; ghi một cặp đã tồn tại sẽ ghi đè bản ghi cũ.

Xét từng lựa chọn với dữ liệu giao dịch mua hàng: | Cặp khoá | Trùng được không? | |---|---| | supplierId + transactionTime | rất khó trùng — một nhà cung cấp khó có hai giao dịch cùng mốc thời gian tới mili giây | | supplierId + unitCost | trùng liên tục — mua cùng một món giá 50.000đ hai lần là mất một bản ghi | | supplierId + item | trùng liên tục — mua lại cùng món là ghi đè | | supplierId một mình | trùng ngay — mỗi nhà cung cấp chỉ lưu được một giao dịch |

2. Hợp với mẫu truy vấn. Sort key quyết định bạn truy vấn được gì hiệu quả, và với dữ liệu nhật ký giao dịch thì thời gian là chiều tự nhiên:

# Giao dịch của một nhà cung cấp trong tháng 8
table.query(
    KeyConditionExpression=Key('supplierId').eq('NCC-001') &
                           Key('transactionTime').between('2026-08-01', '2026-08-31'),
    ScanIndexForward=False        # mới nhất trước
)

Sort key hỗ trợ =, <, <=, >, >=, BETWEEN, begins_with — tất cả đều có nghĩa với thời gian, và kết quả tự động được sắp xếp.

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

• A. supplierId + unitCost — mất dữ liệu do trùng khoá. Ngoài ra truy vấn "các giao dịch có đơn giá trong khoảng X" hầu như không phải nhu cầu thật, còn "các giao dịch trong khoảng thời gian" thì có.
• C. supplierId + item — cũng mất dữ liệu: mỗi nhà cung cấp chỉ giữ được giao dịch gần nhất của mỗi mặt hàng. Toàn bộ lịch sử mua hàng biến mất một cách âm thầm.
• B. Chỉ supplierId — tệ nhất: mỗi nhà cung cấp chỉ tồn tại đúng một bản ghi. Mỗi giao dịch mới xoá sạch giao dịch trước.

Ghi nhớ

Hai loại primary key: | Loại | Thành phần | Tính duy nhất | |---|---|---| | Simple | partition key | partition key phải duy nhất | | Composite | partition key + sort key | cặp phải duy nhất |

Ba nguyên tắc chọn khoá:

1. Partition key nên có nhiều giá trị phân bố đều — tránh hot partition. supplierId tốt nếu có nhiều nhà cung cấp; nếu chỉ có 3 nhà cung cấp thì đây lại là thiết kế kém.
2. Sort key nên là chiều bạn hay lọc và sắp xếp theo — thời gian là lựa chọn phổ biến nhất cho dữ liệu nhật ký.
3. Kiểm tra tính duy nhất trước tiên — đây là bước loại nhanh nhất khi làm bài.

Mẹo hữu ích: nếu lo hai giao dịch trùng mốc thời gian, dùng sort key ghép:

transactionTime#transactionId  →  "2026-08-05T10:30:00.123Z#GD-98765"

Vẫn sắp xếp đúng theo thời gian, mà đảm bảo tuyệt đối không trùng. Đây là mẫu thiết kế rất hay dùng trong thực tế.

Đáp án

C — Tạo customer managed policy với quyền chỉ đọc DynamoDB và chỉ định ARN của bảng trong phần tử Resource, rồi gắn policy đó vào group.

Vì sao đúng

Yêu cầu là đặc quyền tối thiểu, và điều đó đòi hỏi thu hẹp trên cả hai trục:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "dynamodb:GetItem",
      "dynamodb:BatchGetItem",
      "dynamodb:Query",
      "dynamodb:Scan",
      "dynamodb:DescribeTable"
    ],
    "Resource": [
      "arn:aws:dynamodb:ap-southeast-1:123456789012:table/BangCuaToi",
      "arn:aws:dynamodb:ap-southeast-1:123456789012:table/BangCuaToi/index/*"
    ]
  }]
}

Chú ý dòng ARN thứ hai: nếu bảng có GSI hoặc LSI và lập trình viên cần truy vấn qua chúng, phải cấp quyền cho index — chỉ cấp cho bảng là Query trên index sẽ bị từ chối.

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

• D. Gắn AWS managed policy AmazonDynamoDBReadOnlyAccess — đây là phương án gần nhất và cần phân biệt kỹ. Nó đúng về action (chỉ đọc) nhưng sai về resource: managed policy này áp cho Resource: "*", tức là MỌI bảng DynamoDB trong tài khoản. Lập trình viên sẽ đọc được cả bảng của các đội khác. Đây là vi phạm đặc quyền tối thiểu.
• A. Customer managed policy với quyền đọc/ghi cho mọi tài nguyên — sai cả hai trục: thừa quyền ghi (có thể sửa và xoá dữ liệu) và không giới hạn tài nguyên.
• B. Gắn AWSLambdaDynamoDBExecutionRole — sai hoàn toàn về mục đích: policy này dành cho execution role của hàm Lambda đọc DynamoDB Streams (GetRecords, GetShardIterator, DescribeStream). Nó không cấp quyền đọc dữ liệu trong bảng, và cũng không dành cho người dùng.

Ghi nhớ

Ba loại policy trong IAM: | Loại | Ai quản | Đặc điểm | |---|---|---| | AWS managed | AWS | tiện, nhưng thường rộng hơn mức cần | | Customer managed | bạn | thu hẹp được đúng nhu cầu, tái sử dụng được | | Inline | bạn | gắn chặt vào một danh tính, không tái sử dụng |

Quy tắc thực hành: AWS managed policy hợp để bắt đầu nhanh, nhưng gần như luôn quá rộng cho production. Khi đề bài nhắc tới "least privilege", đáp án hầu như luôn là customer managed policy với ARN cụ thể.

Action đọc và ghi của DynamoDB: | Đọc | Ghi | |---|---| | GetItem, BatchGetItem | PutItem, UpdateItem, DeleteItem | | Query, Scan | BatchWriteItem | | DescribeTable, ListTables | TransactWriteItems |

Và một kỹ thuật thu hẹp sâu hơn nữa — giới hạn tới từng dòng và từng cột:

"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:userid}"],
    "dynamodb:Attributes": ["id", "ten", "email"]
  }
}

Cách này cho phép mỗi người chỉ đọc dòng của chính mình và chỉ vài cột được phép — hữu ích khi nhiều người dùng chia sẻ một bảng.

Đáp án

B — Thêm một listener vào ALB, và cập nhật AppSpec để gắn hàm Lambda vào hook BeforeAllowTraffic.

Vì sao đúng

Có hai quyết định trong câu này.

1. Listener thêm vào ALB, không phải vào deployment group. Blue/green trên ECS cần hai listener: | Listener | Vai trò | |---|---| | Production listener | phục vụ người dùng thật | | Test listener | kiểm thử task set mới TRƯỚC KHI chuyển traffic |

Đề nói hiện chỉ có một listener và hai target group — nên phải thêm listener thứ hai vào ALB. Deployment group tham chiếu tới các listener của ALB, chứ không sở hữu chúng; không có thao tác "gắn listener vào deployment group".

2. Hook BeforeAllowTraffic, vì việc kiểm tra phải xảy ra TRƯỚC. Đề nói rõ: "validation BEFORE deployment" — tức trước khi người dùng thật bị ảnh hưởng.

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:...:task-definition/ung-dung:5"
        LoadBalancerInfo:
          ContainerName: "web"
          ContainerPort: 80
Hooks:
  - BeforeAllowTraffic: "arn:aws:lambda:...:function:kiem-thu-truoc"
  - AfterAllowTraffic:  "arn:aws:lambda:...:function:kiem-thu-sau"

Nếu hook BeforeAllowTraffic báo Failed, triển khai bị huỷ và traffic không bao giờ chuyển sang — người dùng không hề bị ảnh hưởng. Đó là toàn bộ giá trị của hook này.

Hàm hook phải báo kết quả về:

cd.put_lifecycle_event_hook_execution_status(
    deploymentId=event['DeploymentId'],
    lifecycleEventHookExecutionId=event['LifecycleEventHookExecutionId'],
    status='Succeeded' if kiem_thu_ok() else 'Failed')

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

• A. Thêm listener vào ALB nhưng dùng hook AfterAllowTraffic — đúng nửa đầu, sai thời điểm: hook này chạy sau khi traffic đã chuyển sang task mới. Nếu bản mới có lỗi, người dùng thật đã gặp lỗi rồi — CodeDeploy chỉ có thể rollback sau đó. Trái yêu cầu "validation before deployment".
• D. "Gắn listener vào deployment group" + BeforeAllowTraffic — hook đúng, nhưng listener là tài nguyên của ALB. Deployment group chỉ khai tham chiếu tới listener đã có.
• C. "Gắn listener vào deployment group" + AfterAllowTraffic — sai cả hai vế.

Ghi nhớ

Năm hook của CodeDeploy cho ECS, theo đúng thứ tự: | Hook | Thời điểm | |---|---| | BeforeInstall | trước khi tạo task set mới | | AfterInstall | sau khi tạo task set mới | | AfterAllowTestTraffic | sau khi test listener trỏ vào task set mới | | BeforeAllowTraffic | TRƯỚC khi chuyển traffic production | | AfterAllowTraffic | sau khi chuyển traffic production |

Hai hook dùng để kiểm thử, và chúng khác nhau về phạm vi: | Hook | Kiểm thử qua | |---|---| | AfterAllowTestTraffic | test listener — kiểm thử sâu, chưa ai bị ảnh hưởng | | BeforeAllowTraffic | chốt cuối cùng trước khi mở cho người dùng |

So sánh với Lambda — chỉ có hai hook (BeforeAllowTraffic, AfterAllowTraffic), vì Lambda không có bước cài đặt và không có test listener.

Nguyên tắc chung đáng nhớ: mọi việc kiểm tra có thể chặn được triển khai đều phải nằm TRƯỚC khi traffic chuyển. Hook sau khi chuyển chỉ dùng để phát hiện và rollback — tức là đã có người dùng gặp lỗi.

Đáp án

B — Amazon ElastiCache for Redis ở chế độ cluster.

Vì sao đúng

Đề nêu bốn yêu cầu, và chỉ Redis đáp ứng đủ:

Cluster mode chia dữ liệu thành shard, mỗi shard có primary và replica riêng:

Shard 1: primary + 2 replica (khác AZ)
Shard 2: primary + 2 replica
Shard 3: primary + 2 replica

Một node hỏng ⇒ replica trong shard đó tự lên thay — dịch vụ không gián đoạn.

Bật mã hoá:

aws elasticache create-replication-group \
  --replication-group-id cache-ung-dung \
  --engine redis --cache-node-type cache.r6g.large \
  --num-node-groups 3 --replicas-per-node-group 2 \
  --at-rest-encryption-enabled \
  --transit-encryption-enabled \
  --auth-token "chuoi-bi-mat-dai" \
  --automatic-failover-enabled \
  --multi-az-enabled

Lưu ý quan trọng: mã hoá chỉ bật được lúc TẠO cluster — không bật thêm cho cluster đang chạy. Muốn có thì phải tạo mới và chuyển sang.

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

• D. ElastiCache for Memcached — điểm loại rất dứt khoát: Memcached không hỗ trợ mã hoá (không at-rest, không in-transit), không có nhân bản, và không có tự động failover. Nó trượt hai trong bốn yêu cầu. Node hỏng là mất toàn bộ dữ liệu trên node đó.
• C. DynamoDB Accelerator (DAX) — DAX chỉ hoạt động với DynamoDB. Nó không đứng trước được RDS; giao diện API của nó là API DynamoDB.
• A. CloudFront với nhiều origin — CloudFront là CDN cache nội dung HTTP ở edge. Nó không cache kết quả truy vấn CSDL và không đứng giữa ứng dụng với RDS.

Ghi nhớ

Quy tắc chọn: hễ đề nhắc tới mã hoá, sẵn sàng cao, failover, hay bền vững ⇒ Redis. Memcached chỉ thắng ở tình huống rất hẹp: cache đơn giản, cần tận dụng nhiều lõi CPU, và chấp nhận mất dữ liệu.

Hai chế độ của Redis: | | Cluster mode DISABLED | Cluster mode ENABLED | |---|---|---| | Shard | một | nhiều (tới 500) | | Mở rộng | chỉ dọc (node lớn hơn) | ngang — thêm shard | | Dữ liệu | toàn bộ trên mỗi node | chia theo slot |

Với dữ liệu vượt quá bộ nhớ một node, hoặc cần thông lượng ghi cao, cluster mode enabled là bắt buộc.

Đáp án

B — Dùng lệnh MSCK REPAIR TABLE để cập nhật metadata trong catalog.

Vì sao đúng

MSCK REPAIR TABLE quét cấu trúc thư mục trên S3 và đăng ký hàng loạt partition vào Glue Data Catalog trong một lệnh duy nhất:

MSCK REPAIR TABLE don_hang;

Nó hoạt động với dữ liệu theo định dạng Hive — đúng như đề mô tả (Hive-compatible partitions):

s3://kho/don-hang/nam=2026/thang=08/ngay=05/
s3://kho/don-hang/nam=2026/thang=08/ngay=06/
                  └──────┬──────┘
              MSCK tự nhận ra và đăng ký

Nếu partition chưa được đăng ký trong catalog, Athena không biết chúng tồn tại — truy vấn hoặc không trả về dữ liệu, hoặc buộc phải quét rộng hơn cần thiết. Chạy MSCK REPAIR TABLE sau khi nạp dữ liệu mới là bước bảo trì tiêu chuẩn.

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

• A. ALTER TABLE ADD PARTITION "để cập nhật tên cột" — mô tả trong phương án sai về chức năng: ALTER TABLE ADD PARTITION thêm partition, nó không đụng gì tới tên cột. Đổi tên cột phải dùng ALTER TABLE ... CHANGE COLUMN hoặc tạo lại bảng.
• C. Xuất dữ liệu sang DynamoDB — sai công cụ hoàn toàn: DynamoDB là CSDL NoSQL khoá–giá trị, không chạy SQL phân tích và không thay thế được Athena. Ngoài ra việc di chuyển hàng terabyte dữ liệu để tránh một lệnh bảo trì là hoàn toàn không tương xứng.
• D. Xuất sang JSON để "làm sạch lỗi" rồi tải lại lên S3 — đề không nói dữ liệu bị lỗi, mà nói truy vấn bị timeout. Ngoài ra JSON là định dạng dòng, không nén, không phải cột — chuyển sang nó sẽ làm truy vấn chậm hơn và đắt hơn, ngược hẳn mục tiêu.

Ghi nhớ

Ba cách quản lý partition trong Athena: | Cách | Đặc điểm | |---|---| | MSCK REPAIR TABLE | quét toàn bộ S3, đăng ký hàng loạt — tiện nhưng chậm dần khi số partition lớn | | ALTER TABLE ADD PARTITION | thêm từng partition, nhanh và có kiểm soát; dùng được cả với đường dẫn không theo chuẩn Hive | | Partition projection | không cần đăng ký gì cả — Athena tự suy ra partition từ cấu hình |

Partition projection là giải pháp tốt nhất cho bảng có rất nhiều partition, vì nó bỏ hẳn bước tra cứu metadata:

ALTER TABLE don_hang SET TBLPROPERTIES (
  'projection.enabled' = 'true',
  'projection.ngay.type' = 'date',
  'projection.ngay.range' = '2020-01-01,NOW',
  'projection.ngay.format' = 'yyyy-MM-dd',
  'storage.location.template' = 's3://kho/don-hang/${ngay}/'
);

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

Đề bài mô tả tình huống là "đang chạy truy vấn bằng DDL và gặp timeout", rồi hỏi cách hiệu quả nhất để ngăn chuyện đó tái diễn. Với cách đọc đó thì đáp án B đáng ngờ, vì trong tài liệu của AWS, MSCK REPAIR TABLE CHÍNH LÀ lệnh hay bị timeout nhất — nó quét toàn bộ đường dẫn S3, nên với bảng hàng chục nghìn partition thì nó vượt giới hạn 30 phút của Athena. Khuyến nghị chính thức khi gặp timeout là chuyển sang ALTER TABLE ADD PARTITION hoặc partition projection.

Đáp án B chỉ hợp lý nếu đọc đề theo hướng khác: lập trình viên đang thêm partition thủ công từng cái một và tiến trình đó quá lâu, thì gom lại bằng một lệnh MSCK là gọn hơn.

Phương án A lẽ ra là ứng viên mạnh cho cách đọc thứ nhất, nhưng nó tự mô tả sai chức năng của chính lệnh mình nêu ("update the column names"), nên không chọn được. Nói cách khác: bộ phương án không chứa câu trả lời tốt cho tình huống timeout thật sự. Với kỳ thi, hãy nhớ B; với công việc thật, hãy nhớ partition projection.

Đáp án

C — binpack.

Vì sao đúng

Đề yêu cầu giảm thiểu số instance được sử dụng — và đó chính xác là định nghĩa của binpack.

binpack đặt task vào instance đã có ít tài nguyên rảnh nhất nhưng vẫn đủ chỗ, tức là lấp đầy từng máy trước khi động tới máy tiếp theo:

"placementStrategy": [
  {"field": "memory", "type": "binpack"}
]

So sánh trực quan với 6 task và 3 instance:

binpack:  instance1 [████████] 4 task
          instance2 [████    ] 2 task
          instance3 [        ] 0 task  ← có thể tắt đi, tiết kiệm tiền

spread:   instance1 [████    ] 2 task
          instance2 [████    ] 2 task
          instance3 [████    ] 2 task  ← cả ba đều phải chạy

Đây là chiến lược tối ưu chi phí: ít instance chạy hơn nghĩa là hoá đơn thấp hơn, và nếu dùng ECS capacity provider với managed scaling, những instance rỗng sẽ được tự động thu hồi.

Chọn field theo tài nguyên là nút thắt của bạn: | field | Dồn theo | |---|---| | memory | bộ nhớ — phổ biến nhất | | cpu | đơn vị CPU |

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

• B. spread — mục tiêu ngược lại: rải task đều để tăng tính sẵn sàng. Nó dùng nhiều instance nhất có thể, đúng thứ đề muốn tránh.
• A. random — đặt ngẫu nhiên, không tối ưu gì cả. Kết quả trung bình sẽ dàn trải, không dồn chặt.
• D. weighted — không phải placement strategy của ECS. Ba type hợp lệ chỉ có binpack, spread, random. ("Weighted" là khái niệm ở nơi khác: weighted routing policy của Route 53, hoặc weighted target group của ALB.)

Ghi nhớ

Ba chiến lược và mục tiêu của chúng: | Type | Mục tiêu | |---|---| | binpack | ít instance nhất — TIẾT KIỆM CHI PHÍ | | spread | phân tán đều — SẴN SÀNG CAO | | random | không mục tiêu cụ thể |

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

• "minimize the number of instances", "reduce cost" ⇒ binpack
• "high availability", "even distribution", "across AZs" ⇒ spread

Đánh đổi cần cân nhắc trong thực tế: binpack tập trung rủi ro. Nếu instance đang chứa 4 task hỏng, bạn mất 4 task cùng lúc — trong khi với spread chỉ mất 1–2.

Cách dung hoà là kết hợp cả hai theo thứ tự ưu tiên: rải đều giữa các AZ trước (giữ khả năng chịu lỗi AZ), rồi dồn chặt trong mỗi AZ (tiết kiệm máy):

"placementStrategy": [
  {"field": "attribute:ecs.availability-zone", "type": "spread"},
  {"field": "memory", "type": "binpack"}
]

Cấu hình này rất hay dùng trong thực tế — nó lấy phần lớn lợi ích chi phí của binpack mà vẫn không đặt tất cả trứng vào một AZ.

Đáp án

B — Thêm chuỗi kết nối để dùng read replica của Amazon RDS cho các truy vấn đọc.

Vì sao đúng

Đề nói rõ hai điều: tải rất nặng về đọc, và đội phát triển sẵn sàng sửa mã ứng dụng để đạt hiệu năng đọc tối ưu.

Read replica là câu trả lời cho tải đọc, và RDS cung cấp cho mỗi replica một endpoint riêng:

csdl-chinh.abc123.ap-southeast-1.rds.amazonaws.com          ← đọc + ghi
csdl-chinh-replica-1.abc123.ap-southeast-1.rds.amazonaws.com ← chỉ đọc

Việc "re-factor application code" chính là tách hai luồng kết nối:

ghi = psycopg2.connect(host=ENDPOINT_CHINH)      # INSERT, UPDATE, DELETE
doc  = psycopg2.connect(host=ENDPOINT_REPLICA)   # SELECT

Nhiều framework hỗ trợ sẵn việc này (Django database router, Rails connects_to, Spring AbstractRoutingDataSource), nên thay đổi thường nhỏ hơn vẻ ngoài.

Đặc điểm của read replica MySQL trên RDS: | Đặc điểm | Chi tiết | |---|---| | Số lượng | tối đa 15 | | Nhân bản | bất đồng bộ — có độ trễ (thường dưới một giây) | | Vị trí | cùng AZ, khác AZ, hoặc khác Region | | Nâng cấp | promote thành CSDL độc lập được |

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

• D. RDS với triển khai Multi-AZ — đây là bẫy hay nhất trong câu này, và khác biệt rất đáng nhớ: Multi-AZ là cơ chế SẴN SÀNG CAO, không phải mở rộng đọc. Bản standby ở AZ khác không phục vụ truy vấn nào — nó chỉ nằm chờ để tiếp quản khi primary hỏng. Bật Multi-AZ không tăng năng lực đọc một chút nào. (Ngoại lệ: cấu hình Multi-AZ DB cluster mới hơn có hai replica đọc được — nhưng đó là loại triển khai khác, và phương án chỉ nói "multi-AZ deployment".)
• A. Thêm retry và mở rộng dọc (vertical scaling) — mở rộng dọc có tăng năng lực, nhưng nó có trần (kích cỡ instance lớn nhất), tốn kém, và đòi khởi động lại. Với tải đọc nặng, read replica là cách mở rộng ngang rẻ và linh hoạt hơn. Retry thì không liên quan gì tới hiệu năng.
• C. Read replica trên một instance EC2 — nghĩa là tự cài MySQL trên EC2 và tự cấu hình replication. Mất hết lợi ích của dịch vụ được quản lý: bạn phải tự vá, tự sao lưu, tự giám sát độ trễ nhân bản, tự xử lý khi replication đứt.

Ghi nhớ

Phân biệt hai tính năng hay bị lẫn của RDS — đây là một trong những câu hỏi kinh điển nhất: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | sẵn sàng cao / khôi phục sau sự cố | mở rộng đọc | | Nhân bản | đồng bộ | bất đồng bộ | | Standby/replica đọc được? | ❌ KHÔNG | ✅ CÓ | | Failover | tự động | thủ công (promote) | | Số lượng | 1 standby | tối đa 15 | | Xuyên Region | ❌ (trong Region) | ✅ |

Câu thần chú: Multi-AZ = tính sẵn sàng. Read replica = hiệu năng đọc. Đề hỏi "high availability" thì chọn Multi-AZ; hỏi "read performance" hay "read-heavy" thì chọn read replica.

Và lưu ý khi refactor: vì nhân bản là bất đồng bộ, ứng dụng có thể đọc phải dữ liệu cũ ngay sau khi ghi. Với thao tác kiểu "ghi xong đọc lại ngay để hiển thị", nên đọc từ primary — đây là bẫy thực tế phổ biến nhất khi tách đọc/ghi.