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

Đáp án

D — Đổi thiết lập message retention của hàng đợi.

Vì sao đúng

MessageRetentionPeriod là thuộc tính quyết định message nằm trong hàng đợi bao lâu trước khi bị xoá tự động:

aws sqs set-queue-attributes --queue-url <url> \
  --attributes MessageRetentionPeriod=1209600      # 14 ngày = 1.209.600 giây

Yêu cầu trong đề là 12 ngày — nằm gọn trong giới hạn 14 ngày, nên chỉ cần đổi thuộc tính này.

Một lưu ý thực tế: đổi retention áp dụng cho cả message đang có trong hàng đợi, không chỉ message mới. Giảm retention có thể xoá ngay những message đã vượt ngưỡng mới.

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

• A. "Retention tối đa là 7 ngày nên 12 ngày là không thể" — sai con số. Giới hạn thật là 14 ngày, nên 12 ngày hoàn toàn cấu hình được. (7 ngày là giới hạn của pre-signed URL với SigV4 — dễ nhớ nhầm.)
• B. Dùng FIFO queue — FIFO đảm bảo thứ tự và xử lý đúng một lần. Retention của FIFO và standard giống hệt nhau (tối đa 14 ngày), nên đổi loại queue không giúp gì.
• C. Bật Long Polling — giảm số lời gọi API rỗng và giảm chi phí. Hoàn toàn không liên quan tới thời gian giữ message.

Ghi nhớ

Bốn tham số thời gian của SQS — nên thuộc cả bốn: | Tham số | Nghĩa | Phạm vi | Mặc định | |---|---|---|---| | MessageRetentionPeriod | giữ message trong queue | 60 giây – 14 ngày | 4 ngày | | VisibilityTimeout | ẩn message đã nhận | 0 – 12 giờ | 30 giây | | DelaySeconds | hoãn message mới | 0 – 15 phút | 0 | | ReceiveMessageWaitTimeSeconds | long polling | 0 – 20 giây | 0 |

Và một khuyến nghị vận hành quan trọng: đặt alarm trên ApproximateAgeOfOldestMessage. Message già đi nghĩa là consumer không theo kịp — và nếu nó chạm gần retention period thì bạn sắp mất dữ liệu mà không có cảnh báo nào khác.

Đáp án

B — Đặt thuộc tính DeleteOnTermination thành False bằng dòng lệnh.

Vì sao đúng

DeleteOnTermination là thuộc tính của block device mapping, và nó sửa được khi instance đang chạy — nhưng chỉ qua CLI hoặc API, không qua Console:

aws ec2 modify-instance-attribute \
  --instance-id i-1234567890abcdef0 \
  --block-device-mappings '[{
    "DeviceName": "/dev/xvda",
    "Ebs": {"DeleteOnTermination": false}
  }]'

Kiểm tra kết quả:

aws ec2 describe-instances --instance-ids i-xxx \
  --query 'Reservations[].Instances[].BlockDeviceMappings[].{Device:DeviceName,Delete:Ebs.DeleteOnTermination}'

Đây là một trong số ít thuộc tính có sự bất đối xứng đáng nhớ giữa Console và CLI:

Mặc định cũng khác nhau tuỳ loại volume: | Volume | DeleteOnTermination mặc định | |---|---| | Root volume | true — xoá cùng instance | | Volume phụ (thêm sau) | false — giữ lại |

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

• A. "Không sửa được khi instance đang chạy, phải dừng máy trước" — sai. modify-instance-attribute với block device mapping hoạt động ngay trên instance đang chạy.
• C. Bỏ tick trong Console — Console không có ô đó cho instance đang chạy. Tuỳ chọn Delete on Termination chỉ hiện ra ở màn hình tạo instance mới hoặc khi gắn volume mới.
• D. Đặt DisableApiTermination — thuộc tính khác hẳn: nó chống việc huỷ instance qua API/Console (termination protection), chứ không ảnh hưởng gì tới số phận của EBS volume khi instance bị huỷ bằng cách khác (ví dụ Auto Scaling).

Ghi nhớ

Ba cơ chế bảo vệ hay bị lẫn: | Thuộc tính | Bảo vệ | |---|---| | DeleteOnTermination | volume EBS khi instance bị huỷ | | DisableApiTermination | instance khỏi bị huỷ qua API/Console | | DisableApiStop | instance khỏi bị dừng qua API/Console |

Lưu ý quan trọng: DisableApiTermination không ngăn Auto Scaling huỷ instance — ASG dùng cơ chế riêng (instance scale-in protection). Đây là nguồn của nhiều sự cố "tôi đã bật termination protection mà máy vẫn bị xoá".

Đáp án

B — CodeDeploy Deployment Groups.

Vì sao đúng

Yêu cầu: triển khai lên các tập EC2 instance khác nhau vào những thời điểm khác nhau, để chuyển đổi mượt mà.

Deployment group là khái niệm đúng cho việc đó — nó đại diện cho một tập hạ tầng cụ thể, và mỗi group có cấu hình riêng:

CodeDeploy application "ung-dung-web"
 ├── Deployment group "canary"     → tag Env=canary      (deploy trước)
 ├── Deployment group "staging"    → tag Env=staging     (deploy sau)
 └── Deployment group "production" → tag Env=production  (deploy cuối)

Mỗi group cấu hình độc lập: | Thiết lập riêng cho từng group | |---| | Tập instance (theo tag hoặc Auto Scaling group) | | Deployment configuration (OneAtATime, HalfAtATime, AllAtOnce) | | Load balancer | | CloudWatch alarm để auto rollback | | Trigger thông báo |

Nhờ vậy bạn deploy vào từng group vào thời điểm mình chọn — thường là canary trước, quan sát, rồi mới tới production. Đó chính là "smooth transition" mà đề mô tả.

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

• D. Định nghĩa nhiều CodeDeploy Application — thừa: application đại diện cho phần mềm, và ở đây chỉ có một ứng dụng. Tạo nhiều application nghĩa là nhân bản cấu hình, và mỗi lần sửa quy tắc phải sửa ở nhiều chỗ.
• A. CodeDeploy Agent — phần mềm chạy trên instance để nhận lệnh và thực thi deployment. Nó là thành phần thực thi, không phải cơ chế phân nhóm hay lên lịch.
• C. CodeDeploy Hooks — các lifecycle event (BeforeInstall, ApplicationStart, ValidateService…) cho phép chèn script vào từng bước trong một lần deploy. Chúng kiểm soát cách deploy diễn ra, không kiểm soát deploy tới đâu và khi nào.

Ghi nhớ

Phân cấp của CodeDeploy: | Khái niệm | Là gì | |---|---| | Application | phần mềm cần triển khai | | Deployment group | một tập hạ tầng (môi trường, cụm máy) | | Deployment | một lần chạy cụ thể | | Revision | phiên bản mã + appspec.yml |

Quy tắc thực dụng: một application cho một ứng dụng; một deployment group cho mỗi môi trường hoặc mỗi cụm hạ tầng riêng biệt.

Và nhớ hai cách chọn instance cho deployment group: theo EC2 tag (linh hoạt nhất) hoặc theo Auto Scaling group (tự động phủ cả instance mới được tạo).

Đáp án

B và D.

• D — Xoá một object rồi đọc ngay ⇒ S3 không trả về dữ liệu (object đã bị xoá).
• B — Xoá một bucket rồi liệt kê ngay ⇒ bucket có thể vẫn xuất hiện trong danh sách.

Vì sao đúng

Từ tháng 12/2020, S3 cung cấp strong read-after-write consistency cho mọi thao tác trên object, ở mọi Region, không tính thêm phí và không cần đổi mã.

D đúng vì đó là biểu hiện trực tiếp của nhất quán mạnh: DeleteObject xong thì lệnh GetObject ngay sau đó chắc chắn trả về 404, không bao giờ trả về dữ liệu cũ.

B đúng vì một ngoại lệ quan trọng: nhất quán mạnh áp dụng cho object, nhưng thao tác ở MỨC BUCKET vẫn là eventually consistent:

Đó là lý do bucket vừa xoá vẫn có thể hiện trong ListBuckets thêm một lúc.

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

Ba phương án còn lại đều mô tả hành vi CŨ của S3 trước tháng 12/2020, khi thao tác ghi đè và xoá còn là eventually consistent:

• A. "Xoá object rồi liệt kê khoá, object có thể còn hiện thêm vài phút" — với nhất quán mạnh, ListObjects phản ánh ngay việc xoá.
• C. "Xoá object rồi đọc, S3 có thể trả về dữ liệu vì việc xoá chưa lan hết" — trái với D, và trái với nhất quán mạnh.
• E. "Ghi đè object rồi đọc, S3 có thể trả về dữ liệu cũ" — đây từng là hành vi thật và là nguồn của rất nhiều lỗi khó chịu. Nay không còn đúng.

Ghi nhớ

Tóm tắt mô hình nhất quán của S3 hiện nay: | Thao tác | Nhất quán | |---|---| | Ghi object mới → đọc | mạnh | | Ghi đè object → đọc | mạnh | | Xoá object → đọc | mạnh | | Liệt kê object | mạnh | | Metadata bucket, danh sách bucket | eventual |

Hai hệ quả thực tế đáng giá của thay đổi này:

• Không cần cơ chế chờ/retry tự viết sau khi ghi — trước đây rất nhiều ứng dụng phải làm vậy
• Đường ống dữ liệu đơn giản hơn — ghi xong là đọc được ngay, không cần hàng đợi trung gian để đợi propagation

Đáp án

A — Lời gọi ghi dữ liệu bị từ chối với ngoại lệ ProvisionedThroughputExceeded.

Vì sao đúng

Kinesis Data Streams đặt giới hạn cứng cho từng shard:

Với một shard như trong đề, vượt qua bất kỳ ngưỡng nào ở trên sẽ khiến PutRecord hoặc PutRecords bị từ chối với ProvisionedThroughputExceededException.

Điểm quan trọng: dữ liệu KHÔNG bị mất một cách âm thầm — lời gọi thất bại và trả về lỗi rõ ràng, nên producer biết và xử lý được. Trách nhiệm nằm ở phía producer:

for lan in range(5):
    try:
        kinesis.put_record(StreamName='thiet-bi', Data=du_lieu, PartitionKey=key)
        break
    except kinesis.exceptions.ProvisionedThroughputExceededException:
        time.sleep((2 ** lan) + random.uniform(0, 1))   # backoff + jitter

Và với PutRecords (API theo lô) thì còn một đặc điểm nữa: nó trả về HTTP 200 kể cả khi một phần bản ghi thất bại — phải kiểm FailedRecordCount và chỉ gửi lại phần hỏng.

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

• C. "Bị từ chối với AccessDeniedException" — sai mã lỗi. AccessDenied là lỗi phân quyền IAM, hoàn toàn khác với vượt hạn mức throughput.
• D. "Dữ liệu mất trừ khi đổi partition key" — sai hai chỗ. Thứ nhất, dữ liệu không mất âm thầm — lời gọi trả về lỗi. Thứ hai, với một shard duy nhất thì đổi partition key không giúp gì: mọi bản ghi đều vào cùng shard đó.
• B. "Liên hệ AWS Support để xin tăng số shard" — không cần support: tăng shard là thao tác tự làm được bằng API:

  aws kinesis update-shard-count --stream-name thiet-bi \
    --target-shard-count 4 --scaling-type UNIFORM_SCALING
  

Ghi nhớ

Ba cách xử lý throttling của Kinesis: | Cách | Khi nào | |---|---| | Tăng shard (UpdateShardCount / SplitShard) | tải tăng bền vững | | Retry + exponential backoff | spike ngắn, tạm thời | | On-demand mode | tải khó đoán — Kinesis tự co giãn, khỏi tính shard |

Và luôn kiểm phân bố partition key: nếu khoá lệch, một shard sẽ nóng trong khi các shard khác nhàn rỗi — khi ấy tăng shard cũng không giúp được nhiều.

Đáp án

A và E.

• A — CloudFront luôn định tuyến mọi request tới origin chính, kể cả khi request trước đó đã failover sang origin phụ.
• E — CloudFront chỉ failover khi phương thức HTTP của viewer request là GET, HEAD hoặc OPTIONS.

Vì sao đúng

A — không có "sticky failover". Origin group không ghi nhớ trạng thái: mỗi request được thử với origin chính trước, và chỉ chuyển sang origin phụ khi origin chính trả về mã lỗi đã cấu hình.

Hệ quả thực tế: nếu origin chính hỏng kéo dài, mọi request đều phải chờ nó thất bại rồi mới sang origin phụ — nên có thêm độ trễ. Đây là đánh đổi có chủ đích: CloudFront tự động dùng lại origin chính ngay khi nó khoẻ lại, không cần ai can thiệp.

E — chỉ failover với phương thức đọc. Đây là giới hạn quan trọng và rất hợp lý: PUT, POST, DELETE, PATCH KHÔNG failover. Lý do là an toàn dữ liệu — thử lại một thao tác ghi trên origin khác có thể gây ghi trùng hoặc trạng thái không nhất quán.

Cấu hình:

{
  "OriginGroups": {"Items": [{
    "Id": "nhom-failover",
    "FailoverCriteria": {"StatusCodes": {"Items": [500, 502, 503, 504, 403, 404]}},
    "Members": {"Items": [{"OriginId": "s3-chinh"}, {"OriginId": "s3-phu"}]}
  }]}
}

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

• B. "Trong origin group, tất cả origin đều là primary để tự động failover" — sai. Origin group có đúng một primary và đúng một secondary, thứ tự rõ ràng.
• C. "Phải có ít nhất ba origin" — sai con số. Origin group nhận đúng hai origin, không hơn không kém.
• D. "Khi có cache hit, CloudFront định tuyến request tới origin chính" — mâu thuẫn nội tại: cache hit nghĩa là CloudFront phục vụ từ cache và KHÔNG gọi origin nào cả. Chỉ cache miss mới dẫn tới origin.

Ghi nhớ

Đặc điểm của CloudFront Origin Group: | Đặc điểm | Chi tiết | |---|---| | Số origin | đúng 2 (primary + secondary) | | Mã lỗi kích hoạt failover | 400, 403, 404, 416, 500, 502, 503, 504 (chọn được) | | Phương thức HTTP | chỉ GET, HEAD, OPTIONS | | Trạng thái | không nhớ — mỗi request thử primary trước | | Gắn vào | cache behavior (default hoặc riêng) |

Và phân biệt với hai cơ chế hay bị lẫn: | Cơ chế | Mục đích | |---|---| | Origin group | failover khi origin lỗi | | Nhiều cache behavior | định tuyến theo đường dẫn tới các origin khác nhau | | Route 53 failover | failover ở tầng DNS, chậm hơn vì TTL |

Đáp án

A — Triển khai phiên bản mới sang một môi trường riêng theo mô hình Blue/Green, rồi hoán đổi để chuyển traffic sang môi trường mới.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai đều chỉ về blue/green:

1. Thời gian chết tối thiểu
2. Rollback nhanh nếu deploy hỏng

Blue/Green với swap CNAME là cơ chế duy nhất của Beanstalk cho rollback tức thì:

1. Môi trường xanh lam đang phục vụ production
2. Dựng môi trường xanh lá, deploy bản mới, kiểm thử trên URL riêng của nó
3. SWAP — hai môi trường đổi CNAME cho nhau
4. Hỏng? SWAP LẠI — vài giây, không deploy lại gì cả

aws elasticbeanstalk swap-environment-cnames \
  --source-environment-name app-prod-xanh-lam \
  --destination-environment-name app-prod-xanh-la

Điểm mấu chốt: môi trường cũ vẫn còn nguyên vẹn. Đó là thứ mà mọi chính sách deploy nội bộ khác không có — chúng đều thay đổi môi trường hiện tại, nên rollback nghĩa là deploy lại một lần nữa.

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

• B. Rolling with additional batch — giữ được 100% năng lực trong lúc deploy, nhưng khi hỏng thì để lại trạng thái hỗn hợp (một số lô bản mới, còn lại bản cũ) và phải deploy thêm một lượt nữa để dọn.
• D. Rolling — giảm năng lực trong lúc deploy, và rollback cũng phải deploy lại.
• C. All at once — có thời gian chết, và deploy hỏng thì cả môi trường hỏng. Tệ nhất theo cả hai tiêu chí.

Ghi nhớ

Bảng đầy đủ các chính sách deploy của Elastic Beanstalk: | Chính sách | Thời gian chết | Năng lực | Chi phí thêm | Rollback | |---|---|---|---|---| | All at once | có | 0% | không | deploy lại | | Rolling | không | giảm | không | deploy lại | | Rolling + additional batch | không | 100% | +1 lô | deploy lại | | Immutable | không | 100% | gấp đôi | huỷ fleet mới | | Blue/Green | không | 100% | gấp đôi | swap ngược — tức thì |

Lưu ý khi dùng blue/green: CSDL phải nằm NGOÀI môi trường, nếu không hai môi trường sẽ có hai CSDL riêng và swap xong người dùng rơi vào CSDL trống. Và swap CNAME vẫn vướng TTL của DNS ở phía client — nên đặt TTL thấp trước khi swap.

Đáp án

B — IAM permission sai cho CodeBuild service role.

Vì sao đúng

Bước cuối của pipeline là đẩy Docker image lên ECR, và nó thất bại với lỗi phân quyền. CodeBuild chạy dưới một service role, nên mọi lời gọi AWS — bao gồm đẩy image — dùng quyền của role đó.

Đẩy image lên ECR cần một bộ quyền cụ thể:

{
  "Effect": "Allow",
  "Action": [
    "ecr:GetAuthorizationToken",        ← BẮT BUỘC, phải có Resource: "*"
    "ecr:BatchCheckLayerAvailability",
    "ecr:InitiateLayerUpload",
    "ecr:UploadLayerPart",
    "ecr:CompleteLayerUpload",
    "ecr:PutImage"
  ],
  "Resource": "*"
}

ecr:GetAuthorizationToken là quyền hay bị bỏ sót nhất, và nó có đặc điểm riêng: bắt buộc Resource: "*" vì nó không gắn với repository cụ thể nào. Thiếu nó thì ngay bước docker login đã thất bại.

Buildspec điển hình:

phases:
  pre_build:
    commands:
      - aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_URI
  build:
    commands:
      - docker build -t $ECR_URI:$TAG .
  post_build:
    commands:
      - docker push $ECR_URI:$TAG

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

• A. "ECS instance thiếu cấu hình trong /etc/ecs/ecs.config" — sai giai đoạn. Tệp đó cấu hình ECS agent trên container instance, dùng khi chạy container. Lỗi đang xảy ra ở bước đẩy image lên registry, trước cả khi có ECS nào tham gia.
• C. "ECR repository bị hỏng, phải xoá và tạo lại" — không có khái niệm "repository stale" trong ECR. Và lỗi được mô tả là authorization, không phải lỗi trạng thái repository.
• D. "CodeBuild không nói chuyện được với ECR vì security group" — vấn đề mạng sẽ cho lỗi timeout hoặc connection refused, không phải lỗi phân quyền. (Vấn đề này chỉ phát sinh khi CodeBuild chạy trong VPC và thiếu VPC endpoint — nhưng khi ấy triệu chứng khác hẳn.)

Ghi nhớ

Quyền tối thiểu mà mọi CodeBuild project cần: | Nhóm | Action | |---|---| | CloudWatch Logs | CreateLogGroup, CreateLogStream, PutLogEvents | | S3 | đọc nguồn, ghi artifact | | ECR (đẩy image) | GetAuthorizationToken + các action upload layer + PutImage | | ECR (kéo image) | GetAuthorizationToken, BatchGetImage, GetDownloadUrlForLayer |

Mẹo chẩn đoán: CloudWatch Logs của build luôn có thông báo lỗi cụ thể kèm ARN của role đang thiếu quyền — đó là chỗ đầu tiên nên xem, thay vì đoán.

Đáp án

D — movie_id.

Vì sao đúng

Partition key quyết định cách DynamoDB phân bố dữ liệu trên các partition vật lý, nên tiêu chí quan trọng nhất là độ phân tán (cardinality):

movie_id là duy nhất cho mỗi phim, nên dữ liệu trải đều tuyệt đối trên các partition — không có hot partition, không có throttle cục bộ.

Và nó cũng đúng về mặt truy vấn: ứng dụng liệt kê phim cho công chúng xem, nên tra cứu theo id là thao tác chính.

Nhắc lại công thức để thấy vì sao độ phân tán quan trọng:

Throughput mỗi partition = tổng throughput ÷ số partition

Nếu 90% request đổ vào một giá trị khoá, thì 90% tải dồn vào một partition — bị throttle dù bảng còn dư throughput rất nhiều.

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

• B. movie_language — tệ nhất: chỉ vài chục ngôn ngữ, và phân bố cực lệch (phim tiếng Anh chiếm đa số). Đây là ví dụ kinh điển của hot partition.
• C. lead_actor_name — độ phân tán khá hơn nhưng vẫn lệch nặng: một diễn viên ngôi sao có hàng chục phim, trong khi phần lớn diễn viên chỉ có một hai phim.
• A. producer_name — cùng vấn đề: các hãng lớn sản xuất hàng trăm phim, dồn vào cùng một khoá.

Ghi nhớ

Nguyên tắc chọn partition key: | Tốt | Xấu | |---|---| | Nhiều giá trị khác nhau (id, UUID, user_id) | Ít giá trị (status, country, type, language) | | Truy cập trải đều | dồn vào vài khoá | | Là thứ bạn tra cứu chính | không dùng để tra cứu |

Và nếu vẫn cần truy vấn theo những thuộc tính kia (liệt kê phim theo ngôn ngữ, theo diễn viên), cách đúng là tạo GSI với chúng làm partition key — chứ không đưa chúng vào khoá của bảng gốc.

(Với GSI cũng nên chú ý độ phân tán — GSI có capacity riêng và cũng bị hot partition như bảng gốc.)

Đáp án

D — Ghi đè một object rồi đọc ngay ⇒ S3 LUÔN trả về phiên bản mới nhất.

Vì sao đúng

Từ tháng 12/2020, S3 cung cấp strong read-after-write consistency cho MỌI thao tác trên object, ở mọi Region, không tính thêm phí và không cần đổi mã.

Nghĩa là:

PutObject (ghi đè) hoàn tất  →  GetObject ngay sau đó  →  LUÔN nhận bản MỚI

Không còn khái niệm "chờ propagation" cho object nữa.

Với tình huống trong đề — ứng dụng ghi đè tệp log rồi đọc lại gần thời gian thực — điều này có nghĩa là không có data discrepancy nào cả: mọi lần đọc đều thấy nội dung mới nhất.

Trước tháng 12/2020, hành vi khác hẳn: ghi đè và xoá là eventually consistent, nên đọc ngay sau khi ghi có thể trả về bản cũ. Đó là nguồn của rất nhiều lỗi khó tái hiện, và các đường ống dữ liệu phải tự dựng cơ chế chờ hoặc retry để đối phó.

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

• C. "Cho tới khi thay đổi lan hết, S3 có thể trả về dữ liệu TRƯỚC ĐÓ" — đây là hành vi cũ, đúng trước 2020 nhưng nay không còn. Đây là phương án nhiễu chính của câu hỏi.
• B. "…có thể trả về dữ liệu mới" — chữ "might" (có thể) làm câu này sai: với nhất quán mạnh thì đó không phải "có thể" mà là chắc chắn.
• A. "…S3 không trả về dữ liệu nào" — sai hẳn. Object vẫn tồn tại (chỉ bị ghi đè), nên GetObject luôn trả về nội dung — và là nội dung mới.

Ghi nhớ

Mô hình nhất quán của S3 hiện nay: | Thao tác | Nhất quán | |---|---| | Ghi object mới → đọc | mạnh | | Ghi đè object → đọc | mạnh | | Xoá object → đọc | mạnh | | ListObjects | mạnh | | Metadata bucket (policy, ACL, CORS), ListBuckets | eventual |

Ngoại lệ ở dòng cuối rất đáng nhớ: thao tác ở mức bucket vẫn là eventually consistent — đổi bucket policy hay xoá bucket có thể mất một lúc mới phản ánh.

Hai hệ quả thực tế của thay đổi này:

• Không cần cơ chế chờ/retry tự viết sau khi ghi
• Đường ống dữ liệu đơn giản hơn — ghi xong đọc được ngay, không cần hàng đợi trung gian để đợi propagation