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

Đáp án

B — Dùng task placement constraint.

Vì sao đúng

Yêu cầu là mỗi task phải nằm trên một container instance KHÁC NHAU — đó là một ràng buộc tuyệt đối, không phải một ưu tiên.

ECS phân biệt rất rõ hai khái niệm: | Khái niệm | Vai trò | |---|---| | Constraint | BỘ LỌC — instance nào ĐƯỢC PHÉP nhận task | | Strategy | ƯU TIÊN — trong số các instance hợp lệ, chọn cái nào |

Vì đề đòi một điều kiện phải được bảo đảm, câu trả lời là constraint — cụ thể là distinctInstance:

{
  "family": "ung-dung",
  "placementConstraints": [
    {"type": "distinctInstance"}
  ]
}

Hiệu lực rất dứt khoát: mỗi instance nhận tối đa MỘT task của service đó. Nếu không còn instance trống, task mới ở trạng thái PENDING thay vì được đặt chung máy — ECS không "cố gắng hết sức" mà tuân thủ tuyệt đối.

Đây là cấu hình hữu ích cho các workload cần cô lập tài nguyên hoặc chịu lỗi tối đa: một instance hỏng chỉ mất đúng một task.

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

• D. Dùng task placement strategy — đây là bẫy chính, và khác biệt rất quan trọng. Strategy spread với field: instanceId rải task đều giữa các instance, nhưng nó CHO PHÉP nhiều task trên cùng một instance khi cần. Nó là ưu tiên, không phải bảo đảm — nên không đáp ứng được yêu cầu "must be on a different instance".
• A. Tạo cluster với nhiều container instance — điều kiện cần nhưng không đủ: có nhiều máy không có nghĩa ECS sẽ đặt mỗi task một máy. Không có constraint, nó vẫn dồn được hai task lên cùng một instance.
• C. Tạo service trên Fargate — với Fargate, mỗi task đã chạy trên hạ tầng riêng biệt do AWS quản lý, nên vấn đề này không tồn tại. Nhưng đây là thay đổi hẳn kiến trúc, không phải câu trả lời cho "làm sao đạt được điều này" trên cụm EC2 hiện có. (Và với Fargate thì distinctInstance không dùng được — không có khái niệm instance.)

Ghi nhớ

Hai constraint của ECS (bộ lọc): | Type | Hành vi | |---|---| | distinctInstance | mỗi instance tối đa một task | | memberOf | chỉ instance thoả biểu thức |

memberOf dùng cú pháp truy vấn thuộc tính:

{"type": "memberOf", "expression": "attribute:ecs.instance-type =~ t3.*"}
{"type": "memberOf", "expression": "attribute:ecs.availability-zone in [ap-southeast-1a, ap-southeast-1c]"}

Ba strategy của ECS (ưu tiên): | Type | Mục tiêu | |---|---| | spread | rải đều — sẵn sàng cao | | binpack | dồn chặt — tiết kiệm chi phí | | random | ngẫu nhiên |

Thứ tự áp dụng: constraint chạy trước để thu hẹp tập ứng viên, rồi strategy mới chọn trong tập đó.

Cách nhớ nhanh khi làm bài: | Đề nói | Chọn | |---|---| | "must", "each task on a DIFFERENT instance" | constraint distinctInstance | | "distribute evenly", "high availability" | strategy spread | | "minimize number of instances", "reduce cost" | strategy binpack | | "only on instance type X", "only in AZ Y" | constraint memberOf |

Và lưu ý về hệ quả vận hành của distinctInstance: số task tối đa bị giới hạn bởi số instance. Nếu Auto Scaling group chỉ có 3 máy, service không bao giờ chạy quá 3 task — dù bạn đặt desiredCount cao hơn.

Đáp án

C — Amazon ElastiCache for Redis.

Vì sao đúng

Điểm quyết định nằm ở câu thứ hai của đề: nếu tầng cache hỏng thì việc nạp lại dữ liệu rất tốn thời gian, nên giải pháp phải tối đa hoá thời gian hoạt động (uptime).

Chỉ Redis có các cơ chế chống mất dữ liệu và chống gián đoạn:

Với Redis, một node hỏng thì replica tự lên thay trong vài chục giây và dữ liệu vẫn nguyên — không phải nạp lại gì cả:

aws elasticache create-replication-group \
  --replication-group-id cache-ung-dung \
  --engine redis --cache-node-type cache.r6g.large \
  --num-node-groups 2 --replicas-per-node-group 2 \
  --automatic-failover-enabled \
  --multi-az-enabled \
  --snapshot-retention-limit 7

Ba tuỳ chọn cuối là những thứ đáp ứng yêu cầu của đề: failover tự động, trải nhiều AZ, và snapshot hằng ngày giữ 7 bản.

Với Memcached thì ngược lại: node hỏng là mất toàn bộ dữ liệu trên node đó, và ứng dụng phải nạp lại từ RDS — đúng kịch bản tốn thời gian mà đề muốn tránh.

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

• B. ElastiCache for Memcached — đúng dịch vụ nhưng sai engine: không có nhân bản, không có failover, không có lưu bền. Nó chỉ phù hợp khi mất cache là chuyện nhỏ — trái hẳn với đề.
• A. DynamoDB 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.
• D. Di trú CSDL sang Redshift — sai bản chất dịch vụ: Redshift là kho dữ liệu phân tích (OLAP), tối ưu cho quét hàng tỷ dòng trong truy vấn phức tạp. Nó không thay thế được CSDL giao dịch và càng không phải một tầng cache.

Ghi nhớ

So sánh hai engine của ElastiCache: | | Redis | Memcached | |---|---|---| | Nhân bản, Multi-AZ failover | ✅ | ❌ | | Lưu bền | ✅ snapshot, AOF | ❌ | | Mã hoá | ✅ at-rest + in-transit + AUTH | ❌ | | Cấu trúc dữ liệu | hash, list, set, sorted set, stream | chỉ chuỗi | | Pub/Sub, transaction, Lua | ✅ | ❌ | | Đa luồng | Redis 6+ có I/O đa luồng | ✅ đầy đủ | | Mở rộng | shard (cluster mode) | thêm node, đơn giản |

Quy tắc chọn rất gọn: hễ đề nhắc tới sẵn sàng cao, failover, mã hoá, 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 cơ chế lưu bền của Redis: | Cơ chế | Đặc điểm | |---|---| | Snapshot (RDB) | chụp toàn bộ theo lịch — khôi phục nhanh, có thể mất dữ liệu giữa hai lần chụp | | AOF | ghi lại từng lệnh — ít mất dữ liệu hơn, khôi phục chậm hơn |

Với bài toán trong đề (nạp lại cache rất tốn thời gian), nên bật snapshot hằng ngày kèm automatic failover — failover lo phần gián đoạn ngắn hạn, snapshot lo trường hợp mất cả cụm.

(Lưu ý: Valkey — bản fork mã nguồn mở của Redis — hiện cũng được ElastiCache hỗ trợ và thường rẻ hơn, với cùng bộ tính năng.)

Đáp án nguồn

B — Amazon Cognito.

Vì sao đúng (trong bối cảnh câu hỏi)

Đề mô tả đúng chức năng của Amazon Cognito Sync: đồng bộ dữ liệu người dùng giữa nhiều thiết bị, không cần dựng backend.

Cognito Sync hoạt động bằng cách gắn dữ liệu vào identity ID của người dùng — một định danh không phụ thuộc thiết bị:

Người dùng đăng nhập trên điện thoại → identity ID: ap-southeast-1:abc-123
Người dùng đăng nhập trên máy tính bảng → CÙNG identity ID
        ↓
    Dataset được đồng bộ tự động giữa hai thiết bị

Ba đặc điểm khớp với đề: | Đặc điểm | Chi tiết | |---|---| | Lưu cục bộ trên thiết bị | ứng dụng đọc ghi ngay, hoạt động cả khi offline | | Tự đồng bộ khi có mạng | SDK lo phần này | | Không cần backend | không phải viết API, không phải nuôi máy chủ |

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

• A. DynamoDB — là kho lưu trữ, không phải cơ chế đồng bộ. Bạn có thể dựng đồng bộ trên nền DynamoDB, nhưng phải tự viết toàn bộ backend — trái yêu cầu "without the need to create a backend application".
• C. AWS Lambda — dịch vụ tính toán. Nó là một phần của backend nếu bạn tự dựng, không phải giải pháp sẵn có.
• D. Amazon API Gateway — cửa ngõ API, cũng là một phần của backend tự dựng.

Ba phương án này có điểm chung: chúng đều là vật liệu để xây backend, trong khi đề yêu cầu một dịch vụ làm sẵn việc đồng bộ.

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

Cognito Sync đã bị AWS ngừng phát triển và không còn được khuyến nghị. Nó vẫn hoạt động cho các ứng dụng đang dùng, nhưng AWS đã hướng người dùng sang AWS AppSync từ nhiều năm nay và không bổ sung tính năng gì thêm.

Giải pháp hiện hành cho đúng bài toán này là AWS AppSync + Amplify DataStore: | Tính năng | AppSync + DataStore | |---|---| | Lưu cục bộ, hoạt động offline | ✅ | | Tự đồng bộ khi có mạng | ✅ | | Giải quyết xung đột | ✅ có chiến lược cấu hình được | | Cập nhật thời gian thực | ✅ GraphQL subscription | | Không cần viết backend | ✅ (Amplify sinh sẵn) |

import { DataStore } from '@aws-amplify/datastore';
import { LichSuChoi } from './models';

// Ghi cục bộ, tự đồng bộ lên cloud khi có mạng
await DataStore.save(new LichSuChoi({ diem: 9500, man: 12 }));

// Đọc — luôn từ kho cục bộ, nên nhanh và dùng được offline
const lichSu = await DataStore.query(LichSuChoi);

Với kỳ thi thì đáp án vẫn là B (Amazon Cognito) — câu hỏi được viết ở thời điểm Cognito Sync còn là lựa chọn chính thức. Nhưng với dự án thật, đừng chọn Cognito Sync; hãy dùng AppSync với Amplify DataStore.

(Cognito nói chung thì vẫn rất sống động: user pool và identity pool là hai thành phần được dùng rộng rãi. Chỉ riêng Cognito Sync — tính năng đồng bộ dataset — là phần đã lỗi thời.)

Đáp án

D — Bật caching trong API Gateway.

Vì sao đúng

Đề nêu ba điều kiện, và chúng cùng chỉ về caching ở tầng API Gateway:

1. Dữ liệu thống kê cập nhật hằng ngày — thay đổi rất ít
2. Truy cập ẩn danh — mọi người nhận cùng một kết quả
3. Cần cải thiện tốc độ phản hồi

Đây là kịch bản lý tưởng cho cache: cùng một câu trả lời phục vụ được cho tất cả mọi người trong suốt cả ngày.

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/enabled,value=true \
    op=replace,path=/*/*/caching/ttlInSeconds,value=3600

Hiệu quả:

Trước: mọi request → Lambda chạy → truy vấn dữ liệu → 300 ms
Sau:   request trúng cache → trả lời ngay tại API Gateway → 10 ms

Và lợi ích không chỉ là tốc độ: Lambda gần như không được gọi nữa, nên chi phí giảm mạnh cùng lúc.

Vì sao đây là cách đơn giản nhất: caching là một thiết lập của stage, không cần thêm dịch vụ nào, không cần sửa một dòng mã nào.

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

• B. Cache kết quả trong cụm ElastiCache — hiệu quả nhưng phức tạp hơn nhiều: phải dựng và vận hành một cụm, đặt nó trong VPC, gắn Lambda vào VPC đó, và sửa mã Lambda để đọc/ghi cache. API Gateway làm sẵn tất cả bằng một thiết lập. (Và cache của API Gateway nằm trước Lambda, nên nó tránh được cả chi phí gọi hàm — ElastiCache thì không.)
• A. Thiết lập API key và usage plan — dùng để nhận diện và giới hạn tần suất cho từng khách hàng. Nó không cải thiện tốc độ, và còn mâu thuẫn với đề: dịch vụ này cho truy cập ẩn danh, không có khách hàng nào để cấp key.
• C. Thiết lập interface VPC endpoint cho API Gateway — dùng để truy cập API riêng tư từ bên trong VPC, không đi qua Internet. Với một API công khai cho người dùng ẩn danh, nó không áp dụng được và cũng không tăng tốc gì.

Ghi nhớ

Cache của API Gateway: | Thuộc tính | Giá trị | |---|---| | Bật ở mức | stage, ghi đè được ở mức method | | Kích thước | 0,5 GB đến 237 GB | | TTL | 0 – 3600 giây, mặc định 300 | | TTL = 0 | tắt cache | | Chi phí | tính theo GIỜ, không theo request | | Khoá cache | toàn bộ URL, tuỳ chỉnh được bằng cache key parameter |

Dòng chi phí rất đáng nhớ: cache tính tiền ngay cả khi không có request nào — nhớ tắt ở stage dev và test. Đây là khoản chi phí ẩn hay bị bỏ quên nhất.

Ba tầng cache có thể đặt, tuỳ nhu cầu: | Tầng | Phù hợp khi | |---|---| | CloudFront | nội dung tĩnh, người dùng toàn cầu | | API Gateway | response API giống nhau cho mọi người ← câu này | | ElastiCache | kết quả truy vấn dùng lại bên trong ứng dụng |

Với dữ liệu cập nhật hằng ngày, đặt TTL 3600 giây (tối đa) là hợp lý, và bổ sung cơ chế làm mới khi có dữ liệu mới:

aws apigateway flush-stage-cache --rest-api-id abc123 --stage-name prod

Gọi lệnh này ngay sau job cập nhật dữ liệu hằng ngày là đủ — người dùng luôn thấy số liệu mới nhất mà vẫn hưởng trọn lợi ích của cache trong 24 giờ còn lại.

Đáp án

D — AWS CodeCommit.

Vì sao đúng

Đề nêu bốn yêu cầu, và chúng mô tả chính xác một hệ thống quản lý mã nguồn:

1. Cộng tác trong phát triển
2. Kho lưu trữ tập trung
3. Riêng tư
4. Nhận cập nhật từ nhiều nguồn — nhiều lập trình viên cùng push

CodeCommit là dịch vụ Git được quản lý, đáp ứng cả bốn:

# Nhiều người cùng làm việc trên một kho
git clone https://git-codecommit.ap-southeast-1.amazonaws.com/v1/repos/du-an
git checkout -b tinh-nang/thanh-toan
git push origin tinh-nang/thanh-toan
# rồi tạo pull request để review

Các đặc điểm của dịch vụ được quản lý: | Đặc điểm | Chi tiết | |---|---| | Riêng tư mặc định | không có kho công khai — mọi truy cập qua IAM | | Mã hoá | at-rest (KMS) và in-transit, tự động | | Bền, sẵn sàng cao | lưu trữ dư thừa đa AZ | | Không giới hạn dung lượng | không lo kho phình to | | Pull request, code review | bình luận theo dòng |

Điểm đáng chú ý về vế "riêng tư": khác với GitHub — nơi bạn phải nhớ đặt kho ở chế độ private — CodeCommit không có khái niệm kho công khai. Không thể vô tình để lộ mã nguồn.

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

• A. AWS CodePipeline — điều phối quy trình CI/CD: nó lấy mã từ nơi khác rồi chạy build và deploy. Không lưu trữ mã.
• B. AWS CodeDeploy — triển khai mã đã đóng gói lên EC2, on-premises, ECS, Lambda. Nó lấy gói từ S3 hoặc GitHub.
• C. AWS CodeBuild — biên dịch và chạy test. Cũng lấy mã từ nơi khác.

Ba dịch vụ này có điểm chung: chúng tiêu thụ mã nguồn, không lưu trữ nó.

Ghi nhớ

Vai trò từng dịch vụ trong pipeline:

CodeCommit → CodeBuild → CodeDeploy
 (lưu mã)    (build+test)  (triển khai)
      └────── CodePipeline điều phối ──────┘

Nhận dạng nhanh: đề nói "repository", "source code", "version control", "collaborate" ⇒ CodeCommit.

Bốn cách xác thực với CodeCommit: | Cách | Giao thức | |---|---| | Git credentials (IAM) | HTTPS — đơn giản nhất | | SSH key | SSH | | git-remote-codecommit | HTTPS — dùng được với role, SSO, MFA | | Credential helper | HTTPS — trên EC2, CodeBuild |

(Ghi chú thời sự: từ 25/7/2024, AWS ngừng cho khách hàng mới tạo repository trên CodeCommit; tài khoản đã dùng vẫn hoạt động bình thường và AWS cam kết tiếp tục vận hành. Với dự án mới, dùng GitHub, GitLab hoặc Bitbucket — nối vào CodePipeline qua CodeStar Connections. Câu hỏi này vẫn nằm trong phạm vi kỳ thi, nhưng đừng chọn CodeCommit cho hệ thống mới.)

Đáp án

D — AWS CodeDeploy.

Vì sao đúng

Đề có một yêu cầu rất đặc thù: triển khai cả lên EC2 instance LẪN máy chủ ảo tại chỗ (on-premises).

CodeDeploy là dịch vụ duy nhất của AWS làm được cả hai — đó là điểm phân biệt của câu hỏi này:

Để triển khai lên máy chủ tại chỗ, quy trình gồm ba bước:

# 1. Đăng ký máy chủ với CodeDeploy
aws deploy register-on-premises-instance \
  --instance-name may-chu-01 \
  --iam-user-arn arn:aws:iam::123456789012:user/CodeDeployOnPrem

# 2. Gắn tag để deployment group nhận diện
aws deploy add-tags-to-on-premises-instances \
  --instance-names may-chu-01 --tags Key=MoiTruong,Value=production

# 3. Cài CodeDeploy agent trên máy đó và cấu hình credential

Sau đó một deployment group duy nhất triển khai được lên cả hai loại máy, dùng cùng một AppSpec và cùng một quy trình:

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/ung-dung
hooks:
  ApplicationStop:  [{location: scripts/dung.sh}]
  AfterInstall:     [{location: scripts/cai-dat.sh}]
  ApplicationStart: [{location: scripts/khoi-dong.sh}]
  ValidateService:  [{location: scripts/kiem-tra.sh}]

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

• B. AWS CodePipeline — điều phối quy trình CI/CD, nó không tự triển khai. Nó gọi CodeDeploy làm việc đó. (Trong pipeline thật thì bạn dùng cả hai — nhưng câu hỏi hỏi dịch vụ nào thực hiện việc triển khai.)
• C. AWS Elastic Beanstalk — nền tảng chạy ứng dụng, và nó chỉ triển khai lên hạ tầng do chính nó tạo trong AWS. Không triển khai được lên máy chủ on-premises.
• A. "AWS CloudBuild" — không tồn tại dịch vụ nào tên như vậy. Tên đúng là CodeBuild, và nó biên dịch mã chứ không triển khai.

Ghi nhớ

Bảng nền tảng đích của CodeDeploy — và định dạng gói tương ứng: | Nền tảng | Gói triển khai | |---|---| | EC2 / On-premises | ZIP, tar, tar.gz + appspec.yml (bắt buộc YAML) | | ECS | appspec.yaml trỏ tới task definition | | Lambda | appspec.yaml trỏ tới version của hàm |

Kiểu triển khai được hỗ trợ: | Nền tảng | Type | |---|---| | EC2 / On-premises | in-place hoặc blue/green | | ECS | chỉ blue/green | | Lambda | chỉ blue/green |

Điều kiện để một máy nhận được triển khai:

1. Đã cài CodeDeploy agent
2. Có credential hợp lệ — instance profile với EC2, IAM user hoặc IAM Roles Anywhere với máy on-premises
3. Được gắn tag khớp với deployment group

Và nguồn gói triển khai chỉ có hai: | Nguồn | Hỗ trợ | |---|---| | Amazon S3 | ✅ | | GitHub | ✅ | | Bitbucket, GitLab | ❌ (phải qua CodePipeline) | | File system tại chỗ | ❌ |

Nhận dạng nhanh: đề nhắc tới "on-premises" kèm triển khai phần mềm ⇒ gần như luôn là CodeDeploy, vì không dịch vụ triển khai nào khác của AWS vươn ra ngoài đám mây được.

Đáp án

A — Service Control Policy (SCP).

Vì sao đúng

Đề mô tả chính xác chức năng của SCP: quản trị viên của tài khoản quản lý (master account) muốn giới hạn những dịch vụ, tài nguyên và API action mà người dùng trong một tài khoản thành viên được phép dùng.

SCP là "rào chắn" (guardrail) ở cấp tổ chức — nó đặt trần quyền tối đa cho toàn bộ tài khoản:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ChiChoDungRegionChoPhep",
      "Effect": "Deny",
      "NotAction": ["iam:*", "organizations:*", "cloudfront:*", "route53:*", "support:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {"aws:RequestedRegion": ["ap-southeast-1", "us-east-1"]}
      }
    },
    {
      "Sid": "CamXoaCloudTrail",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail"],
      "Resource": "*"
    }
  ]
}

Điểm mấu chốt và cũng là điều mạnh nhất của SCP: nó áp cho MỌI danh tính trong tài khoản đó — kể cả root user. Không IAM policy nào trong tài khoản thành viên có thể vượt qua nó.

Quyền hiệu lực = SCP  ∩  IAM policy  ∩  permissions boundary  ∩  session policy

Cần hiểu đúng bản chất: SCP KHÔNG CẤP quyền, nó chỉ GIỚI HẠN. Người dùng vẫn cần IAM policy cho phép — SCP chỉ quyết định điều gì là không thể, bất kể IAM nói gì.

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

• D. Organizational Unit (OU) — là cách nhóm các tài khoản lại trong cây tổ chức. Nó là nơi bạn GẮN SCP vào, nhưng bản thân nó không giới hạn quyền gì cả.
• B. Tag Policy — chuẩn hoá cách đặt tag (khoá và giá trị hợp lệ) trên toàn tổ chức. Nó phục vụ việc phân loại chi phí và quản lý tài nguyên, không kiểm soát quyền truy cập.
• C. Consolidated Billing account — cơ chế gộp hoá đơn của các tài khoản thành viên về một chỗ. Chỉ liên quan tới thanh toán.

Ghi nhớ

Các loại policy trong AWS Organizations: | Loại | Việc | |---|---| | Service Control Policy (SCP) | giới hạn quyền tối đa | | Tag Policy | chuẩn hoá tag | | Backup Policy | chính sách sao lưu tập trung | | AI Services Opt-out Policy | từ chối cho AWS dùng dữ liệu để cải thiện dịch vụ |

Bốn cơ chế giới hạn quyền — bảng này rất đáng thuộc: | Cơ chế | Phạm vi | Áp cho root user? | |---|---|---| | SCP | tài khoản hoặc OU | ✅ CÓ | | Permissions boundary | một IAM user/role | ❌ | | IAM policy | danh tính cụ thể | ❌ | | Session policy | một phiên tạm thời | ❌ |

Dòng "áp cho root user" là điều làm SCP khác biệt — nó là cách duy nhất để ngăn chặn ngay cả người có toàn quyền trong tài khoản thành viên.

Ba lưu ý quan trọng khi dùng SCP:

1. SCP không áp cho tài khoản quản lý (management account) — kể cả khi bạn gắn nó vào gốc tổ chức. Đây là lý do AWS khuyến nghị không chạy workload trong tài khoản quản lý.
2. Chính sách mặc định là FullAWSAccess — cho phép mọi thứ. Gắn SCP hạn chế mà quên gỡ chính sách này thì với kiểu Allow list, hiệu lực có thể không như mong đợi.
3. Dùng Deny cho guardrail. Danh sách Allow rất khó bảo trì vì AWS liên tục thêm dịch vụ mới; Deny các hành động nguy hiểm là cách bền vững hơn.

Các guardrail hay dùng: chặn tắt CloudTrail, chặn tắt GuardDuty, chặn xoá log, giới hạn Region được phép, và chặn tạo IAM user (ép dùng SSO).

Đáp án

A — Dùng Amazon Cognito với web identity federation.

Vì sao đúng

Đề nêu hai yêu cầu, và Cognito với web identity federation đáp ứng cả hai:

1. Người dùng đăng nhập bằng tài khoản Amazon, Facebook, Google
2. Ứng dụng cho họ xem ảnh trong S3 bucket

Web identity federation là cơ chế đổi token của nhà cung cấp danh tính lấy credential AWS tạm thời:

Người dùng đăng nhập Google → nhận token
        ↓
  Cognito Identity Pool → sts:AssumeRoleWithWebIdentity
        ↓
  Credential AWS TẠM THỜI (access key, secret, session token)
        ↓
  Gọi thẳng s3:GetObject

const credentials = fromCognitoIdentityPool({
  identityPoolId: 'ap-southeast-1:xxxx-xxxx',
  logins: { 'accounts.google.com': googleIdToken }
});
const s3 = new S3Client({ credentials, region: 'ap-southeast-1' });

Và điểm mạnh nhất: phân quyền tới từng người dùng bằng biến thay thế, chỉ với một policy duy nhất:

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

Biến đó được thay bằng ID thật của người đăng nhập ngay lúc đánh giá policy — nên mỗi người chỉ xem được ảnh của chính mình, dù có hàng triệu người dùng.

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

• C. Cognito với SAML-based identity federation — đúng dịch vụ nhưng sai loại liên kết: SAML dùng cho danh tính doanh nghiệp (Active Directory, Okta, ADFS). Google, Facebook và Amazon dùng OAuth 2.0 / OpenID Connect, tức là web identity federation.
• B. Nhúng IAM access/secret key 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 web ai cũng đọc được — chỉ cần mở DevTools. Access key dài hạn nằm trong đó là bị lộ hoàn toàn, và thu hồi thì phải cập nhật ứng dụng cho mọi người dùng.
• D. Dùng sts:AssumeRole trong mã ứng dụng — AssumeRole (thường) đòi người gọi đã có credential AWS, mà người dùng cuối thì không có. Và để gọi được nó, ứng dụng lại phải nhúng credential — quay về đúng vấn đề của phương án B. (API đúng cho tình huống này là AssumeRoleWithWebIdentity, và đó chính là thứ Cognito gọi bên dưới.)

Ghi nhớ

Ba API của STS, và chọn đúng theo nguồn danh tính: | API | Dùng khi | |---|---| | AssumeRole | người gọi đã có danh tính AWS | | AssumeRoleWithWebIdentity | Google, Facebook, Amazon, OIDC | | AssumeRoleWithSAML | Active Directory, Okta, ADFS |

Hai thành phần của Cognito: | | User Pool | Identity Pool | |---|---|---| | Là gì | thư mục người dùng | bộ đổi danh tính lấy credential AWS | | Phát ra | JWT | credential AWS tạm thời | | Gọi thẳng S3/DynamoDB | ❌ | ✅ | | Người dùng khách | ❌ | ✅ |

Nhận dạng nhanh: đề nói "truy cập trực tiếp dịch vụ AWS" ⇒ identity pool. Đề nói "đăng ký, đăng nhập, quản lý người dùng" ⇒ user pool. Kiến trúc đầy đủ thường dùng cả hai.

Ba việc cần làm khi cấu hình:

1. Đăng ký ứng dụng ở phía nhà cung cấp (Google Cloud Console, Facebook Developers) để lấy client ID.
2. Khai nhà cung cấp trong identity pool với client ID đó.
3. Cấu hình hai role: authenticated và unauthenticated. Nhớ giữ role thứ hai ở mức tối thiểu tuyệt đối — bất kỳ ai trên Internet cũng lấy được credential đó.

Đáp án

B — Dùng ElastiCache for Memcached để lưu session, và RDS for MySQL để lưu dữ liệu ứng dụng.

Vì sao đúng

Đề chỉ rõ nút thắt: session lưu trong bộ nhớ máy chủ web, và khi tải cao thì bộ nhớ cạn kiệt gây chậm nghiêm trọng.

Đó cũng là vấn đề chặn hẳn việc dùng Auto Scaling: instance mới không có session của người dùng, và instance bị thu hồi làm mất session. Nói cách khác, tầng web chưa phi trạng thái thì mở rộng ngang không hoạt động đúng.

Giải pháp là tách hai loại dữ liệu ra hai kho phù hợp:

Client → ALB → EC2 (phi trạng thái, Auto Scaling)
                 ├─ session ──→ ElastiCache (trong bộ nhớ, rất nhanh)
                 └─ đơn hàng ─→ RDS MySQL (bền, có quan hệ)

Kết quả: bộ nhớ của EC2 được giải phóng, mọi instance phục vụ được mọi người dùng, và Auto Scaling hoạt động đúng như thiết kế.

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

• D. Dùng Memcached cho cả session lẫn dữ liệu ứng dụng — sai ở vế thứ hai: Memcached không bền — không có nhân bản, không có lưu bền, node hỏng là mất dữ liệu. Không bao giờ dùng nó làm kho chính cho dữ liệu đơn hàng.
• A. Dùng instance store cho session — sai nghiêm trọng nhất: instance store là ổ đĩa tạm gắn vật lý vào máy chủ. Dữ liệu mất khi instance dừng hoặc bị huỷ, và không máy nào khác đọc được — nên nó giữ nguyên vấn đề gốc (session vẫn cục bộ) chứ không giải quyết gì.
• C. Lưu cả session lẫn dữ liệu vào MySQL trên một EC2 instance — hai vấn đề: CSDL tự quản trên EC2 (phải tự vá, tự sao lưu, tự lo failover), và CSDL quan hệ không phải nơi tốt để lưu session — độ trễ cao hơn hẳn kho trong bộ nhớ, mà session bị đọc ở mọi request.

Ghi nhớ

Nguyên tắc nền tảng: tầng tính toán phải phi trạng thái. Mọi trạng thái đẩy ra kho ngoài.

Các lựa chọn lưu session: | Kho | Độ trễ | Bền | Chọn khi | |---|---|---|---| | ElastiCache Redis | thấp nhất | vừa (có nhân bản, snapshot) | cần nhanh + chịu lỗi | | ElastiCache Memcached | thấp nhất | ❌ | cache đơn giản, chấp nhận mất | | DynamoDB | mili giây | rất bền, đa AZ | cần bền, có TTL, không quản lý |

Với đề này, cả Redis lẫn Memcached đều dùng được cho session — nhưng trong thực tế Redis thường là lựa chọn tốt hơn vì có nhân bản và tự động failover, nên mất một node không làm toàn bộ người dùng bị đăng xuất.

Ba thứ không bao giờ dùng làm kho session: | Không dùng | Vì sao | |---|---| | Bộ nhớ/ổ đĩa cục bộ của instance | mất khi instance được thay | | Instance store | mất khi instance dừng | | Sticky session làm giải pháp duy nhất | instance hỏng là mất session |

Và một cải tiến nữa cho kiến trúc trong đề: sau khi tách session ra, có thể thêm read replica cho RDS để phân tải đọc cho phần danh mục sản phẩm — bước tiếp theo tự nhiên khi lưu lượng tiếp tục tăng.

Đáp án

C — Vô hiệu hoá (invalidate) phiên bản cũ của ảnh trên các edge cache.

Vì sao đúng

Nguyên nhân rất rõ: CloudFront đang phục vụ bản cũ từ cache ở edge location, và cache đó chưa hết hạn.

Invalidation buộc CloudFront xoá đối tượng khỏi mọi edge cache, nên request tiếp theo phải lấy bản mới từ origin:

aws cloudfront create-invalidation \
  --distribution-id E1ABCDEFGHIJKL \
  --paths "/anh/logo.png" "/anh/banner.jpg"

# Hoặc toàn bộ một thư mục
aws cloudfront create-invalidation \
  --distribution-id E1ABCDEFGHIJKL --paths "/anh/*"

Chú ý cụm "trên các edge cache" trong đáp án — đó là điểm phân biệt với phương án D. Nội dung được cache ở hơn 400 edge location trên toàn cầu, không phải ở origin. Invalidation là lệnh gửi tới CloudFront để dọn các bản sao đó.

Việc lan truyền mất vài phút (thường 3–5 phút), và bạn theo dõi được:

aws cloudfront get-invalidation --distribution-id E1ABCDEFGHIJKL --id I2J3K4L5M6N7O8

Về chi phí: 1.000 đường dẫn đầu tiên mỗi tháng là miễn phí, sau đó khoảng 0,005 USD mỗi đường dẫn. Dùng /* chỉ tính là một đường dẫn.

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

• D. Vô hiệu hoá phiên bản cũ trên origin — sai nơi: origin (S3 hoặc máy chủ web) không cache gì cả — nó luôn có bản mới nhất. Vấn đề nằm ở bản sao trong edge cache. Đây là bẫy tinh vi nhất, chỉ khác đáp án đúng một từ.
• A. "Ép cập nhật cache" — không có thao tác nào tên như vậy. Cơ chế đúng gọi là invalidation, và nó xoá chứ không "cập nhật".
• B. Xoá ảnh khỏi origin rồi lưu bản mới lên — không có tác dụng: CloudFront vẫn phục vụ bản đã cache cho tới khi TTL hết hạn. Nó không hề biết origin đã thay đổi. Tệ hơn, trong khoảng thời gian ảnh bị xoá mà cache đã hết hạn, người dùng sẽ nhận lỗi 404.

Ghi nhớ

Ba cách làm mới nội dung trên CloudFront: | Cách | Đặc điểm | |---|---| | Invalidation | tức thì (vài phút), có phí sau 1.000 đường dẫn/tháng | | Versioned URL | logo-v2.png — MIỄN PHÍ, khuyến nghị | | Chờ TTL hết hạn | miễn phí, nhưng chậm |

Versioned URL là cách được khuyến nghị nhất cho quy trình triển khai thường xuyên:

<!-- Thay vì invalidate mỗi lần đổi -->
<img src="/anh/logo.png">

<!-- Dùng tên có phiên bản hoặc mã băm -->
<img src="/anh/logo-a1b2c3.png">

Cách này miễn phí, có hiệu lực ngay lập tức, và còn cho phép quay lại bản cũ vì cả hai phiên bản đều tồn tại.

Các tham số TTL của CloudFront: | Tham số | Việc | |---|---| | MinTTL | thời gian tối thiểu giữ trong cache | | DefaultTTL | dùng khi origin không gửi Cache-Control (mặc định 86.400 giây) | | MaxTTL | trần, kể cả khi origin yêu cầu lâu hơn |

Origin điều khiển được thời gian cache bằng header:

Cache-Control: max-age=31536000, immutable    # tài nguyên có phiên bản
Cache-Control: no-cache                        # luôn kiểm tra lại với origin

Lời khuyên thực dụng: dùng versioned URL cho tài nguyên tĩnh (CSS, JS, ảnh) với TTL rất dài, và để dành invalidation cho các tình huống khẩn cấp — như phải gỡ ngay một nội dung đăng nhầm.