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

Đáp án

B — AWS Elastic Beanstalk.

Vì sao đúng

Yêu cầu: triển khai ứng dụng web trên EC2, và lập trình viên chỉ muốn viết mã, không phải lo cung cấp máy chủ, cấu hình hay triển khai.

Elastic Beanstalk là dịch vụ PaaS của AWS, làm đúng việc đó: bạn đẩy mã lên, nó lo phần còn lại.

Nền tảng hỗ trợ sẵn: Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker. Triển khai chỉ là:

eb init && eb create moi-truong-production && eb deploy

Và điểm quan trọng: bản thân Beanstalk miễn phí — bạn chỉ trả tiền cho EC2, ELB và các tài nguyên bên dưới, những thứ dù sao cũng phải trả.

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

• A. Serverless Application Model (SAM) — framework cho ứng dụng serverless (Lambda, API Gateway, DynamoDB). Đề nói rõ ứng dụng chạy trên EC2, không phải serverless.
• C. CloudFormation — công cụ hạ tầng dưới dạng mã. Nó tạo được EC2, ALB, ASG, nhưng bạn phải tự khai từng tài nguyên và tự dựng cơ chế triển khai mã. Đây là nhiều việc hơn hẳn, trái với "không muốn lo server provisioning, configuration and deployment". (Thực tế Beanstalk dùng CloudFormation bên dưới — nó là lớp trừu tượng đặt lên trên.)
• D. CodeDeploy — chỉ lo triển khai mã lên máy đã có. Nó không cung cấp hạ tầng: bạn vẫn phải tự tạo EC2, ASG, ALB. Chỉ giải quyết một phần ba yêu cầu.

Ghi nhớ

Các mức trừu tượng để chạy ứng dụng trên AWS, từ nhiều việc nhất tới ít nhất: | Mức | Dịch vụ | Bạn quản gì | |---|---|---| | IaaS | EC2 | máy chủ, OS, runtime, ứng dụng | | Container | ECS/EKS trên EC2 | cluster, container | | Container serverless | Fargate | container | | PaaS | Elastic Beanstalk | chỉ mã ứng dụng | | Serverless | Lambda | chỉ hàm |

Nhận dạng nhanh: đề nói "chỉ muốn tập trung viết mã" + "chạy trên EC2" ⇒ Elastic Beanstalk. Nếu bỏ ràng buộc EC2 thì Lambda hoặc Fargate mới là câu trả lời.

Đáp án

D — Security Group là stateful nên chỉ cần mở inbound; Network ACL là stateless nên phải mở cả inbound lẫn outbound.

Vì sao đúng

Đội đã mở đúng cổng inbound ở cả hai lớp, nhưng vẫn không kết nối được. Nguyên nhân nằm ở khác biệt cơ bản giữa hai cơ chế:

Security Group — stateful. Nó ghi nhớ kết nối. Cho phép request đi vào thì phản hồi tự động được cho đi ra, bất kể rule outbound thế nào.

Network ACL — stateless. Nó xét từng gói tin độc lập, không nhớ gì cả. Gói đi vào và gói đi ra là hai chuyện hoàn toàn riêng biệt, mỗi chiều cần một rule.

Và đây là chỗ bị bỏ sót: phản hồi TCP không đi ra từ cổng 443 hay 80 — nó đi ra từ cổng nguồn của client, nằm trong dải ephemeral port:

Client:54321  ──→  Server:443     ← rule inbound cho phép ✅
Client:54321  ←──  Server:443     ← rule OUTBOUND phải cho phép cổng 1024–65535 ❗

Nên NACL phải có thêm:

Rule 100  Outbound  TCP  1024-65535  0.0.0.0/0  ALLOW

Dải ephemeral port khác nhau theo hệ điều hành: Linux thường 32768–60999, Windows 49152–65535, ELB và Lambda dùng 1024–65535. Nên cấu hình an toàn là mở 1024–65535.

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

• C. Nói ngược hoàn toàn — bảo NACL stateful và Security Group stateless. Đây là bẫy đối xứng, và là lỗi rất hay gặp khi học vội.
• B. "IAM Role trong Security Group khác IAM Role trong NACL" — vô nghĩa: cả Security Group lẫn NACL đều không có khái niệm IAM role. Chúng lọc theo IP, cổng và giao thức, không theo danh tính.
• A. "Không được sửa NACL từ dòng lệnh, sẽ gây hành vi thất thường" — bịa hoàn toàn. AWS CLI, Console, SDK và CloudFormation đều gọi cùng một API và cho kết quả như nhau.

Ghi nhớ

Nhớ nhanh: stateless ⇒ phải mở cả hai chiều, và đừng quên ephemeral port cho chiều về.

Đáp án

C — Amazon EFS volumes.

Vì sao đúng

Yêu cầu: các task Fargate trải trên nhiều AZ cần truy cập chung, bền vững, xuyên AZ vào cùng một tập dữ liệu.

Amazon EFS là lựa chọn duy nhất thoả cả ba:

Khai trong task definition:

"volumes": [{
  "name": "du-lieu-chung",
  "efsVolumeConfiguration": {
    "fileSystemId": "fs-0abc123",
    "transitEncryption": "ENABLED",
    "authorizationConfig": {"accessPointId": "fsap-0def456", "iam": "ENABLED"}
  }
}]

Ba điều kiện cần nhớ khi gắn EFS vào Fargate: platform version 1.4.0 trở lên, security group của mount target phải cho phép NFS cổng 2049 từ task, và nên dùng access point để giới hạn task vào đúng thư mục của nó.

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

• A. Bind mounts — gắn một thư mục từ host vào container. Với Fargate, "host" là một môi trường tạm do AWS quản lý, và dữ liệu mất khi task dừng. Nó chỉ dùng để chia sẻ giữa các container trong CÙNG một task, không xuyên task và càng không xuyên AZ.
• D. Docker volumes — chỉ hỗ trợ với EC2 launch type, không dùng được trên Fargate. Và chúng gắn với một host cụ thể, nên không chia sẻ xuyên AZ được.
• B. "AWS Gateway Storage volumes" — tên bị viết lộn của AWS Storage Gateway, và dịch vụ đó dùng để nối trung tâm dữ liệu on-premises với AWS, không phải để cấp volume chia sẻ cho container trong AWS.

Ghi nhớ

Các loại volume cho ECS: | Loại | Fargate | Bền vững | Chia sẻ xuyên task | |---|---|---|---| | Bind mount | ✅ | ❌ | ❌ (chỉ trong một task) | | Docker volume | ❌ chỉ EC2 | tuỳ driver | ❌ | | EFS | ✅ | ✅ | ✅ | | FSx for Windows | ❌ chỉ EC2 Windows | ✅ | ✅ |

Nhận dạng nhanh: đề nói "persistent", "shared", "cross-AZ" cho container ⇒ gần như luôn là EFS.

Đáp án

C — Lần deploy đã chạy ở chế độ immutable update hoặc traffic splitting.

Vì sao đúng

Cần hiểu burst balance là gì trước: các instance loại T (t2, t3, t4g) và volume gp2 tích luỹ credit khi chạy dưới mức cơ sở, rồi tiêu credit đó khi cần bùng lên. Credit được tích luỹ theo thời gian trên từng instance cụ thể — instance mới bắt đầu từ con số rất thấp.

Điểm mấu chốt: immutable update và traffic splitting đều dựng một fleet EC2 hoàn toàn mới:

Immutable / Traffic splitting:
  Fleet cũ (đã tích luỹ credit nhiều tuần)  →  bị huỷ, credit mất theo
  Fleet mới (credit bằng 0)                 →  phục vụ traffic

Vì instance cũ bị huỷ chứ không được cập nhật tại chỗ, mọi credit tích luỹ trên chúng biến mất cùng chúng. Fleet mới bắt đầu lại từ đầu.

Hệ quả thực tế đáng lưu ý: ngay sau một lần immutable deployment, ứng dụng có thể chậm bất thường vì instance mới chưa có credit để bùng lên khi tải tăng. Với workload phụ thuộc nhiều vào burst, đây là lý do nên cân nhắc instance không burstable (m, c, r) hoặc bật T unlimited mode.

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

• A. All at once và D. Rolling — cả hai đều cập nhật tại chỗ trên chính instance đang có. Không có instance nào bị thay thế, nên credit vẫn còn nguyên. Đây chính là điểm phân biệt cốt lõi giữa hai nhóm chính sách deploy.
• B. "Canary deployment thất bại thì reset burst balance về 0" — bịa. Elastic Beanstalk không có chính sách tên "canary" (thứ gần nhất là traffic splitting), và không có cơ chế nào reset credit khi deploy hỏng.

Ghi nhớ

Phân nhóm các chính sách deploy của Beanstalk theo việc có thay instance hay không: | Chính sách | Thay instance? | Burst balance | |---|---|---| | All at once | ❌ tại chỗ | giữ nguyên | | Rolling | ❌ tại chỗ | giữ nguyên | | Rolling with additional batch | một phần | phần mới mất | | Immutable | ✅ fleet mới | mất hết | | Traffic splitting | ✅ fleet mới | mất hết |

Đây cũng là lý do nên theo dõi metric CPUCreditBalance sau mỗi lần deploy immutable.

Đáp án

B — AWS::Serverless::UserPool KHÔNG phải là loại tài nguyên serverless hợp lệ.

Vì sao đúng

SAM định nghĩa một danh sách hữu hạn các loại tài nguyên với tiền tố AWS::Serverless::, và user pool không nằm trong đó:

Muốn tạo Cognito user pool trong template SAM thì dùng loại tài nguyên CloudFormation thường:

Resources:
  HamXuLy:
    Type: AWS::Serverless::Function     # ← tài nguyên SAM
  KhoNguoiDung:
    Type: AWS::Cognito::UserPool        # ← tài nguyên CloudFormation thường

Điều này hoàn toàn hợp lệ: SAM là phần mở rộng của CloudFormation, nên trộn hai loại trong cùng một template là chuyện bình thường.

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

• A. AWS::Serverless::Api — định nghĩa API Gateway, thường được sinh ngầm khi hàm có event kiểu Api; khai tường minh khi cần cấu hình sâu (CORS, authorizer, OpenAPI).
• C. AWS::Serverless::Function — loại tài nguyên trung tâm của SAM.
• D. AWS::Serverless::SimpleTable — bảng DynamoDB rút gọn, chỉ khai được khoá chính. Cần sort key, GSI, LSI hay stream thì phải dùng AWS::DynamoDB::Table.

Ghi nhớ

Mẹo phân biệt nhanh: SAM chỉ có tài nguyên cho các thành phần serverless mà nó rút gọn được đáng kể — Lambda, API Gateway, DynamoDB đơn giản, Step Functions, layer. Mọi thứ khác (Cognito, S3, SNS, SQS, IAM…) dùng loại tài nguyên CloudFormation thường.

Và nhớ dòng bắt buộc mở đầu mọi template SAM: Transform: AWS::Serverless-2016-10-31.

Đáp án

A — AWS Serverless Application Repository (SAR).

Vì sao đúng

Yêu cầu: dùng ứng dụng serverless dựng sẵn để rút ngắn thời gian phát triển, với giải pháp dễ nhất.

SAR là kho ứng dụng serverless được đóng gói sẵn dưới dạng template SAM. Bạn tìm, xem mã, rồi triển khai thẳng vào tài khoản của mình bằng vài cú bấm — hoặc nhúng luôn vào template của mình:

Resources:
  UngDungCoSan:
    Type: AWS::Serverless::Application
    Properties:
      Location:
        ApplicationId: arn:aws:serverlessrepo:us-east-1:123456789012:applications/xu-ly-anh
        SemanticVersion: 1.2.0
      Parameters:
        KichThuocAnh: 800

Ba đặc điểm đáng chú ý:

• Ứng dụng được triển khai vào chính tài khoản bạn, không phải dịch vụ do người khác vận hành — nên bạn kiểm soát hoàn toàn
• Xem được mã nguồn trước khi triển khai
• Chia sẻ được riêng tư trong tổ chức hoặc công khai

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

• D. AWS Marketplace — kho phần mềm thương mại: AMI, container image, gói SaaS, mô hình ML. Nó không chuyên về ứng dụng serverless đóng gói bằng SAM, và phần lớn là sản phẩm có phí.
• C. AWS Service Catalog — công cụ để tổ chức tự tạo danh mục sản phẩm được duyệt cho nhân viên dùng. Nó là cơ chế quản trị nội bộ, không phải nơi tìm ứng dụng dựng sẵn từ bên ngoài. Bạn vẫn phải tự viết template rồi đưa vào danh mục.
• B. AWS AppSync — dịch vụ GraphQL được quản lý, dùng để xây API. Nó là một thành phần kiến trúc, không phải kho ứng dụng.

Ghi nhớ

Lưu ý bảo mật khi dùng SAR công khai: luôn đọc template và mã nguồn trước khi triển khai — ứng dụng chạy trong tài khoản bạn với quyền mà template khai, nên hãy soi kỹ phần IAM.

Đáp án

A — AWS CodeCommit.

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều là mô tả của một hệ quản lý phiên bản Git:

CodeCommit là dịch vụ lưu trữ repository Git riêng tư được quản lý. Vì nó nói đúng giao thức Git, mọi công cụ đang dùng đều hoạt động không cần sửa gì:

git clone https://git-codecommit.ap-southeast-1.amazonaws.com/v1/repos/du-an
git commit -m "them tinh nang" && git push

Ưu điểm so với tự dựng Git server: không quản máy chủ, mã hoá tự động (KMS lúc lưu, HTTPS/SSH lúc truyền), phân quyền bằng IAM, và tích hợp sẵn với CodeBuild, CodePipeline, CodeDeploy.

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

• B. AWS CodeBuild — dịch vụ build và test: biên dịch mã, chạy kiểm thử, tạo artifact. Nó đọc mã từ repository nhưng không lưu trữ và không quản lý phiên bản.
• C. AWS CodePipeline — dịch vụ điều phối nối các stage source → build → deploy. Nó cũng chỉ tiêu thụ mã từ nguồn, không lưu trữ.
• D. S3 bucket có bật versioning — đây là bẫy đáng chú ý. S3 versioning có giữ nhiều phiên bản của một object, nhưng nó thiếu toàn bộ mô hình làm việc của Git: không có branch, không có merge, không có pull request, không có lịch sử commit có ý nghĩa, và không tương thích với công cụ Git — mà đó là yêu cầu tường minh trong đề.

Ghi nhớ

Bộ công cụ "Code" của AWS: | Dịch vụ | Vai trò | |---|---| | CodeCommit | lưu trữ mã (Git) | | CodeBuild | biên dịch, kiểm thử, tạo artifact | | CodeDeploy | triển khai lên EC2, ECS, Lambda, on-premises | | CodePipeline | điều phối toàn chuỗi | | CodeArtifact | kho gói phụ thuộc (npm, Maven, pip) |

Ghi chú thời sự: AWS đã ngừng nhận khách hàng mới cho CodeCommit từ giữa 2024 (tài khoản đang dùng vẫn hoạt động). Với dự án mới, GitHub, GitLab hoặc Bitbucket là lựa chọn phổ biến hơn — cả ba đều tích hợp được với CodePipeline.

Đáp án

A — AWS Security Token Service (STS) KHÔNG phải cơ chế xác thực với API Gateway.

Vì sao đúng

API Gateway hỗ trợ đúng bốn cơ chế uỷ quyền, và STS không nằm trong danh sách:

Vai trò thật của STS. STS là dịch vụ phát thông tin xác thực AWS tạm thời — AssumeRole, AssumeRoleWithWebIdentity, GetSessionToken. Nó đứng trước bước gọi API: client dùng STS để lấy access key tạm thời, rồi dùng khoá đó ký request bằng SigV4.

Nói cách khác, STS là nguồn cấp thông tin xác thực, không phải cơ chế xác thực của API Gateway. API Gateway không bao giờ "nói chuyện" với STS; nó chỉ xác minh chữ ký SigV4.

Client → STS (AssumeRole) → nhận khoá tạm thời
       → ký request bằng SigV4 → API Gateway xác minh chữ ký (đây mới là cơ chế IAM)

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

• B. IAM role và policy — cơ chế uỷ quyền chính thức, phù hợp khi client là dịch vụ AWS hoặc có danh tính AWS.
• C. Cognito User Pools — authorizer dựng sẵn, xác minh JWT do user pool phát ra.
• D. Lambda Authorizer — cho phép cài đặt logic xác thực tuỳ ý, dùng khi phân quyền do bên thứ ba lo.

Ghi nhớ

Cách chọn cơ chế uỷ quyền cho API Gateway: | Bối cảnh | Chọn | |---|---| | Client là dịch vụ AWS hoặc có danh tính AWS | IAM (SigV4) | | Dùng thư mục người dùng của AWS | Cognito user pool | | Hệ phân quyền của bên thứ ba, logic tuỳ biến | Lambda authorizer | | OIDC/OAuth2 chuẩn, không muốn viết mã | JWT authorizer (HTTP API) |

Và nhớ lại một lần nữa: API key không phải cơ chế xác thực — nó chỉ để định danh và đo lường theo usage plan.

Đáp án

D — Một instance được tính theo giá Reserved Instance, hai instance còn lại tính theo giá On-Demand.

Vì sao đúng

Cần hiểu đúng bản chất của Reserved Instance: RI không phải là một máy chủ — nó là một khoản giảm giá được áp lên hoá đơn.

Cách hoạt động:

1. Bạn cam kết trả tiền cho một cấu hình cụ thể (loại instance, Region, nền tảng) trong 1 hoặc 3 năm
2. AWS áp billing discount cho tối đa số lượng instance đang chạy khớp cấu hình đó
3. Instance vượt quá số RI đã mua thì tính giá On-Demand đầy đủ

Áp vào đề:

Đã mua : 1 × m4.xlarge Reserved Instance
Đang chạy: 3 × m4.xlarge trong 1 giờ
─────────────────────────────────────
Instance 1  →  giá RI (đã trả trước hoặc trả theo cam kết)
Instance 2  →  giá On-Demand
Instance 3  →  giá On-Demand

Điểm cần nhớ: bạn không chọn được instance nào hưởng giảm giá — AWS tự áp cho những instance khớp, và nó là thao tác trên hoá đơn, không phải thao tác trên hạ tầng.

Hệ quả quan trọng khác: RI vẫn tính tiền kể cả khi bạn không chạy instance nào. Cam kết là cam kết.

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

• A. "Cả ba đều tính giá RI" — bạn chỉ mua một RI, nên chỉ một instance được giảm giá.
• C. "Cả ba tính giá On-Demand" — bỏ qua RI đã mua. RI tự động áp khi có instance khớp, không cần cấu hình gì.
• B. Đảo ngược đúng chỗ quan trọng nhất (một On-Demand, hai RI) và còn ghi "hai giờ" trong khi đề nói chạy một giờ.

Ghi nhớ

Ngày nay Savings Plans thường được ưa dùng hơn RI vì linh hoạt hơn nhiều với cùng mức giảm giá.

Đáp án

A và E.

• A — Chuyển nội dung tĩnh từ EC2 sang Amazon S3.
• E — Dựng CloudFront distribution cache nội dung tĩnh với S3 làm origin.

Vì sao đúng

Hai manh mối trong đề khoanh vùng rất chặt:

1. Vấn đề là nội dung tĩnh tải chậm
2. Chậm kể cả ngoài giờ cao điểm ⇒ không phải vấn đề năng lực

Vế thứ hai loại thẳng mọi giải pháp về mở rộng: nếu chậm cả lúc vắng thì thêm máy hay máy mạnh hơn cũng không giúp gì. Nguyên nhân thật là khoảng cách địa lý — người dùng toàn cầu đang tải nội dung từ một Region duy nhất.

A — đưa nội dung tĩnh sang S3. Ảnh, CSS, JavaScript, video không cần EC2 phục vụ. S3 rẻ hơn, bền hơn (11 số 9), và quan trọng nhất là làm origin chuẩn cho CloudFront.

E — đặt CloudFront phía trước. Đây là phần giải quyết vấn đề gốc: nội dung được cache tại hơn 600 edge location trên toàn thế giới, nên người dùng tải từ điểm gần họ nhất thay vì đi nửa vòng trái đất.

Trước:  Người dùng Brazil → (hàng trăm ms) → EC2 ở Singapore
Sau  :  Người dùng Brazil → (vài chục ms)  → CloudFront edge ở São Paulo

Kết hợp thêm Origin Access Control (OAC) để bucket đóng hoàn toàn với Internet, chỉ CloudFront đọc được.

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

• B. Nâng CPU và RAM cho EC2 — vấn đề không phải năng lực máy chủ (chậm cả lúc vắng). Nâng cấu hình không rút ngắn được khoảng cách địa lý.
• C. Gấp đôi desired capacity của Auto Scaling group — cùng lý do, và còn nhân đôi chi phí mà không giải quyết gì.
• D. Chuyển ứng dụng sang Lambda — cuộc tái kiến trúc lớn, không liên quan tới vấn đề. Lambda cũng chạy trong một Region cụ thể, nên độ trễ cho người dùng ở xa vẫn nguyên.

Ghi nhớ

Chẩn đoán độ trễ theo triệu chứng: | Triệu chứng | Nguyên nhân | Cách chữa | |---|---|---| | Chậm cả lúc vắng, chậm ở xa | khoảng cách địa lý | CloudFront / Global Accelerator | | Chỉ chậm lúc cao điểm | thiếu năng lực | Auto Scaling, cache, tối ưu truy vấn | | Chậm đều ở mọi nơi mọi lúc | mã hoặc CSDL chậm | tối ưu ứng dụng |

Và nhớ mẫu chuẩn: nội dung tĩnh → S3 + CloudFront; nội dung động → ALB + EC2, cũng đặt sau CloudFront được.