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

Đáp án

A — X-Ray sampling là thứ KHÔNG giúp gỡ lỗi vấn đề này.

Vì sao đúng

Chú ý đây là câu hỏi phủ định: tìm thứ không hữu ích.

Triệu chứng: ứng dụng gửi được dữ liệu lên X-Ray từ máy cá nhân, nhưng không gửi được khi chạy trên EC2. Vì mã ứng dụng giống hệt nhau, khác biệt phải nằm ở môi trường:

Còn sampling thì sao? Sampling là cơ chế quyết định bao nhiêu phần trăm request được ghi lại — mặc định là request đầu tiên mỗi giây cộng 5% số còn lại. Nó là thiết lập giảm chi phí và giảm lưu lượng, chung cho cả hai môi trường. Nó có thể giải thích "ít trace hơn mong đợi", không giải thích được "không có trace nào từ EC2 trong khi máy cá nhân vẫn gửi được".

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

Như bảng trên: B, C và D đều là những chỗ thật sự khác nhau giữa hai môi trường, nên đều là điểm kiểm tra hợp lý.

Ghi nhớ

Kiến trúc X-Ray, cần nắm để chẩn đoán:

Ứng dụng (X-Ray SDK)
   ↓ UDP cổng 2000, gửi cục bộ
X-Ray daemon
   ↓ HTTPS, dùng thông tin xác thực từ IAM role
Dịch vụ AWS X-Ray

Danh sách kiểm khi "không có trace nào":

1. Daemon đã cài và đang chạy chưa?
2. IAM role có AWSXRayDaemonWriteAccess chưa?
3. UDP cổng 2000 có bị chặn không?
4. Instrumentation của SDK đã bật chưa?

(Với Lambda, ECS Fargate và Beanstalk thì daemon đã được tích hợp sẵn — chỉ cần bật tracing.)

Đáp án

D — Tạo app từ template do AWS CDK cung cấp → Thêm mã tạo tài nguyên trong stack → Build (tuỳ chọn) → Synthesize → Deploy.

Vì sao đúng

Câu này kiểm tra hai điều: template đến từ đâu và thứ tự các bước.

Điểm phân biệt 1 — template của CDK, không phải của CloudFormation. Lệnh khởi tạo là cdk init, dùng template do CDK cung cấp cho từng ngôn ngữ:

cdk init app --language typescript

Điều này loại thẳng A và B.

Điểm phân biệt 2 — build đứng TRƯỚC synth. Đây là điểm loại của C:

cdk init app --language typescript   # 1. tạo app từ template CDK
# 2. viết mã trong lib/*-stack.ts để khai tài nguyên
npm run build                        # 3. biên dịch TypeScript → JavaScript (TUỲ CHỌN)
cdk synth                            # 4. sinh ra template CloudFormation
cdk deploy                           # 5. triển khai lên tài khoản AWS

Lý do build phải trước synth rất đơn giản: cdk synth chạy mã của bạn để dựng cây construct. Mã TypeScript phải được biên dịch thành JavaScript trước thì mới chạy được. Bước này ghi là tuỳ chọn vì CDK CLI hiện đại tự gọi trình biên dịch qua ts-node, và với Python hay JavaScript thì không có bước biên dịch nào cả.

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

• A và B. "Template do AWS CloudFormation cung cấp" — sai nguồn. cdk init dùng template của CDK. (B còn thiếu hẳn bước build.)
• C. Đặt build sau deploy — vô lý về thứ tự: không thể triển khai thứ chưa được biên dịch và chưa được synth.

Ghi nhớ

Vòng đời một dự án CDK: | Lệnh | Làm gì | |---|---| | cdk init | tạo dự án từ template | | cdk bootstrap | chuẩn bị tài khoản/Region (bucket staging, role) — chỉ chạy một lần | | cdk synth | sinh template CloudFormation | | cdk diff | so sánh với stack đang chạy | | cdk deploy | triển khai | | cdk destroy | xoá stack |

Bước hay bị quên nhất trong thực tế là cdk bootstrap — chưa chạy thì cdk deploy báo lỗi thiếu staging bucket. Và luôn nhớ: CDK cuối cùng vẫn sinh ra CloudFormation; nó là lớp lập trình đặt lên trên, không phải một cơ chế triển khai khác.

Đáp án

A — Gọi PutObject với header x-amz-server-side-encryption: AES256, và dùng bucket policy từ chối mọi upload không có header đó.

Vì sao đúng

Hai vế phải đúng cả hai:

Vế 1 — giá trị header đúng cho SSE-S3 là AES256.

Đề yêu cầu rõ SSE-S3, nên giá trị phải là AES256.

Vế 2 — bucket policy phải DENY, không phải chỉ khuyến khích. Chữ "guarantee" trong đề nghĩa là phải chặn cứng:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::kho-du-lieu/*",
  "Condition": {
    "StringNotEquals": {"s3:x-amz-server-side-encryption": "AES256"}
  }
}

Kèm theo nên có một statement thứ hai chặn trường hợp hoàn toàn không gửi header ("Null": {"s3:x-amz-server-side-encryption": "true"}) — vì StringNotEquals không khớp khi khoá điều kiện vắng mặt.

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

• B. Giá trị aws:kms — đó là SSE-KMS, không phải SSE-S3. Đề chỉ định rõ SSE-S3 (không có chi phí KMS, không cần quản lý khoá).
• C. Giá trị sse:s3 — giá trị này không tồn tại. S3 sẽ từ chối request với lỗi giá trị header không hợp lệ.
• D. "Đặt khoá mã hoá SSE-S3 trong header của mỗi request" — hiểu sai bản chất SSE-S3: khoá hoàn toàn do S3 quản lý, bạn không bao giờ cung cấp khoá. Việc gửi khoá trong header là đặc trưng của SSE-C (customer-provided keys), một cơ chế khác hẳn.

Ghi nhớ

Ba kiểu server-side encryption của S3: | | Ai quản lý khoá | Header | |---|---|---| | SSE-S3 | S3 | x-amz-server-side-encryption: AES256 | | SSE-KMS | bạn, qua KMS | x-amz-server-side-encryption: aws:kms | | SSE-C | bạn, gửi kèm mỗi request | x-amz-server-side-encryption-customer-* |

Ghi chú thời sự: từ đầu năm 2023, S3 mã hoá mặc định bằng SSE-S3 cho mọi object mới — nhưng bucket policy dạng deny vẫn cần khi bạn phải chứng minh cho kiểm toán rằng không upload nào lách được, hoặc khi muốn bắt buộc dùng SSE-KMS.

Đáp án

A — Rolling.

Vì sao đúng

Hai ràng buộc của đề: một số instance chạy bản cũ trong khi số khác chạy bản mới (tức là hai phiên bản cùng tồn tại trong lúc deploy), và không phát sinh chi phí thêm.

Rolling cập nhật theo từng lô trên chính các instance đang có:

Lô 1 (25%): cập nhật  →  bản mới    ┐
Lô 2 (25%): bản cũ                  │ hai phiên bản cùng phục vụ
Lô 3 (25%): bản cũ                  │
Lô 4 (25%): bản cũ                  ┘

Vì không dựng thêm instance nào, chi phí không đổi. Đổi lại, năng lực phục vụ giảm trong lúc mỗi lô đang được cập nhật.

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

• B. All at once — cập nhật tất cả cùng một lúc, nên không có lúc nào hai phiên bản cùng tồn tại. Nó cũng gây thời gian chết.
• C. Rolling with additional batch — có hai phiên bản cùng tồn tại, nhưng nó dựng thêm một lô instance mới để giữ nguyên 100% năng lực. Lô thêm đó phát sinh chi phí — vi phạm ràng buộc "without incurring additional costs".
• D. Immutable — dựng một fleet hoàn toàn mới song song với fleet cũ, tức là nhân đôi chi phí hạ tầng trong suốt quá trình deploy. Đắt nhất trong bốn phương án.

Ghi nhớ

Bốn chính sách deploy của Elastic Beanstalk, xếp theo chi phí thêm: | Chính sách | Thời gian chết | Chi phí thêm | Hai phiên bản cùng lúc | |---|---|---|---| | All at once | có | không | ❌ | | Rolling | không | không | ✅ (năng lực giảm) | | Rolling with additional batch | không | +1 lô | ✅ (giữ 100% năng lực) | | Immutable | không | gấp đôi | ✅ |

Từ khoá phân biệt: "without additional cost" ⇒ Rolling; "không được giảm năng lực" ⇒ Rolling with additional batch.

Đáp án

D — Bật timeout cho CodeBuild.

Vì sao đúng

Vấn đề: build chạy quá lâu vì kẹt ở khâu tải phụ thuộc từ bên thứ ba, và cần ngăn chuyện đó lặp lại.

CodeBuild có sẵn thiết lập timeoutInMinutes ở mức project: hết thời gian đó, build tự động bị dừng và đánh dấu thất bại.

aws codebuild update-project --name du-an-cua-toi --timeout-in-minutes 20

Ba cái lợi: không trả tiền cho những phút build đã vô vọng, pipeline nhận tín hiệu thất bại sớm thay vì treo, và đội biết ngay có vấn đề thay vì chờ tới khi ai đó để ý.

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

• A. CloudWatch Events — dùng để phản ứng với sự kiện build (ví dụ gửi thông báo khi build hỏng). Nó không dừng được một build đang chạy quá lâu; muốn vậy thì phải viết thêm Lambda gọi StopBuild — làm lại bằng tay thứ CodeBuild đã có sẵn.
• B. VPC Flow Logs — ghi metadata lưu lượng mạng trong VPC. Nó có thể cho thấy kết nối tới máy chủ bên thứ ba đang chậm, nhưng đó là công cụ chẩn đoán, không phải cơ chế ngăn chặn. Và với build không chạy trong VPC thì nó không thấy gì cả.
• C. AWS Lambda — quá chung chung. Viết Lambda để theo dõi rồi gọi StopBuild là làm thủ công đúng việc mà một dòng cấu hình đã lo được.

Ghi nhớ

Nguyên tắc chung: mọi tiến trình tự động chạy dài đều phải có trần thời gian. AWS đặt sẵn giới hạn ở nhiều nơi: | Dịch vụ | Timeout | |---|---| | CodeBuild | mặc định 60 phút, tối đa 8 giờ | | Lambda | mặc định 3 giây, tối đa 15 phút | | CodeDeploy lifecycle hook | mặc định 1 giờ | | CodePipeline manual approval | 7 ngày |

Trước khi nghĩ tới việc tự viết cơ chế giám sát, hãy kiểm xem dịch vụ đã có sẵn thiết lập đó chưa.

Đáp án

A — DynamoDB với khoá chính gồm name (partition key) và version number (sort key), kèm một GSI có category làm partition key.

Vì sao đúng

Đề có ba đặc điểm, và cả ba đều chỉ về DynamoDB với thiết kế khoá cụ thể này:

Đặc điểm 1 — thuộc tính không nhất quán giữa các game. Mỗi game có thêm những thông tin khác nhau về nền tảng và thông số kỹ thuật. Đây là lược đồ linh hoạt, thứ mà CSDL quan hệ xử lý rất tệ (phải để nhiều cột NULL hoặc dựng bảng phụ) còn NoSQL xử lý tự nhiên.

Đặc điểm 2 — tra cứu theo tên game. Đặt name làm partition key thì GetItem hoặc Query theo tên là thao tác nhanh nhất có thể.

Đặc điểm 3 — nhiều phiên bản cho một game. Đặt version number làm sort key cho phép nhiều item cùng name, và còn sắp xếp sẵn theo phiên bản:

table.query(KeyConditionExpression=Key('name').eq('space-race'),
            ScanIndexForward=False, Limit=1)   # lấy phiên bản mới nhất

GSI theo category mở thêm một kiểu truy vấn hoàn toàn khác — "liệt kê mọi game thể loại thể thao" — mà không phải quét toàn bảng.

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

• C. Đảo ngược: category làm partition key, name trong GSI — thiết kế sai ở hai điểm. Thứ nhất, category là khoá phân vùng rất tệ: chỉ có vài giá trị (sports, puzzles, strategy…), nên dữ liệu dồn vào ít phân vùng — đây là hot partition kinh điển. Thứ hai, tra cứu theo tên game (thao tác chính) phải đi qua GSI thay vì bảng gốc.
• B. RDS MySQL với name làm khoá chính — hai vấn đề. Lược đồ cứng không hợp với thuộc tính không nhất quán. Và name làm khoá chính nghĩa là mỗi game chỉ có một dòng, không lưu được nhiều phiên bản.
• D. ElastiCache for Memcached — đề nói "permanently store", mà Memcached là cache trong bộ nhớ, không bền vững: không snapshot, không sao chép, mất node là mất sạch dữ liệu.

Ghi nhớ

Nguyên tắc chọn partition key cho DynamoDB: | Tốt | Xấu | |---|---| | Nhiều giá trị khác nhau (user_id, order_id) | Ít giá trị (category, status, country) | | Truy cập trải đều | Truy cập dồn vào vài khoá |

Và nhớ: partition key quyết định phân bố dữ liệu; sort key quyết định thứ tự và cho phép nhiều item cùng một partition key.

Đáp án

A — .ebextensions/<mysettings>.config

Vì sao đúng

Elastic Beanstalk đọc cấu hình mở rộng từ một quy ước rất chặt về đường dẫn và tên tệp:

ung-dung.zip
├── .ebextensions/
│   ├── 01-goi-phan-mem.config
│   ├── 02-bien-moi-truong.config
│   └── 03-tai-nguyen.config
├── application.py
└── requirements.txt

Ví dụ nội dung:

# .ebextensions/01-goi-phan-mem.config
packages:
  yum:
    git: []
option_settings:
  aws:elasticbeanstalk:application:environment:
    MOI_TRUONG: production
container_commands:
  01_migrate:
    command: "python manage.py migrate"
    leader_only: true

Đặt số thứ tự ở đầu tên tệp là mẹo phổ biến để kiểm soát thứ tự chạy.

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

• B. .ebextensions_<mysettings>.config — dùng dấu gạch dưới thay vì dấu gạch chéo, tức là một tệp phẳng, không phải thư mục. Beanstalk không tìm thấy.
• C. .config_<mysettings>.ebextensions và D. .config/<mysettings>.ebextensions — đảo ngược tên thư mục và phần mở rộng. Beanstalk tìm thư mục .ebextensions và tệp .config, không phải ngược lại.

Ghi nhớ

Các khoá chính dùng được trong tệp .config: | Khoá | Làm gì | |---|---| | packages | cài gói qua yum, rpm, apt | | files | tạo tệp trên instance | | commands | chạy lệnh trước khi ứng dụng được cài | | container_commands | chạy lệnh sau khi cài, trước khi deploy — dùng leader_only: true cho migration | | option_settings | cấu hình môi trường Beanstalk | | Resources | thêm tài nguyên CloudFormation tuỳ ý |

container_commands với leader_only: true là cách chuẩn để chạy migration CSDL đúng một lần thay vì trên mọi instance.

Đáp án

Câu hỏi tìm phát biểu KHÔNG đúng — đáp án là A và E.

• A — "Auto Scaling group chỉ chứa được EC2 trong một AZ duy nhất của Region" — SAI.
• E — "ASG trải trên nhiều Region cần được bật cho mọi Region" — SAI.

Vì sao hai phát biểu này sai

A sai vì Auto Scaling group được thiết kế để trải trên nhiều AZ, và đó chính là giá trị cốt lõi của nó. Đặt ASG trong một AZ duy nhất là bỏ đi khả năng chịu lỗi — AZ đó sập là ứng dụng chết hoàn toàn. AWS khuyến nghị tối thiểu hai AZ.

E sai vì một sự thật cứng: Auto Scaling group là tài nguyên theo Region, KHÔNG trải xuyên Region được. Một ASG chỉ hoạt động trong một Region, chỉ dùng được các AZ của Region đó. Muốn có nhiều Region thì phải tạo ASG riêng ở mỗi Region rồi định tuyến bằng Route 53 hoặc Global Accelerator.

Bản thân đề bài cũng đã cài sẵn cái bẫy này ở câu mở đầu: "EC2 instances spread across different AZs and Regions".

Vì sao ba phát biểu còn lại đúng

• B. ASG chứa được instance ở một hoặc nhiều AZ trong cùng Region — đúng, đây là mô tả chính xác.
• C. Với ASG trong VPC, instance được tạo trong các subnet — đúng. Bạn khai danh sách subnet, và AZ được suy ra từ subnet.
• D. EC2 Auto Scaling cố gắng phân bố đều giữa các AZ đã bật — đúng. Nó cũng tự cân bằng lại (AZ rebalance) khi phân bố bị lệch.

Ghi nhớ

Phạm vi của các tài nguyên AWS — bị hỏi rất nhiều: | Phạm vi | Ví dụ | |---|---| | Toàn cầu | IAM, Route 53, CloudFront, WAF (cho CloudFront) | | Theo Region | Auto Scaling group, ELB, VPC, S3 bucket, DynamoDB table | | Theo AZ | Subnet, EBS volume, EC2 instance |

Muốn kiến trúc nhiều Region thì không có tài nguyên nào tự trải xuyên Region ngoài vài ngoại lệ được thiết kế riêng (DynamoDB Global Tables, S3 CRR, Aurora Global Database).

Đáp án

A và C.

• A — Visibility timeout của queue tính bằng giây, mặc định 30 giây.
• C — Không đổi được kiểu queue sau khi tạo.

Vì sao đúng

A — visibility timeout mặc định 30 giây. Đây là khoảng thời gian một message bị ẩn khỏi các consumer khác sau khi được nhận. Consumer phải xử lý xong và gọi DeleteMessage trong khoảng đó, nếu không message quay lại hàng đợi và được phát cho consumer khác.

C — không đổi được kiểu queue. Standard hay FIFO là quyết định vĩnh viễn tại thời điểm CreateQueue. Muốn đổi thì phải tạo queue mới và di trú. (FIFO queue còn bắt buộc có hậu tố .fifo trong tên.)

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

• B. "Queue tag không phân biệt hoa thường" — sai. Tag của SQS PHÂN BIỆT chữ hoa chữ thường (case-sensitive), giống tag của mọi dịch vụ AWS khác. Environment và environment là hai tag khác nhau.
• D. "DLQ của standard queue có thể là standard hoặc FIFO" — sai ở vế sau. Quy tắc là DLQ phải cùng kiểu với queue nguồn: FIFO → DLQ phải FIFO; standard → DLQ phải standard. Vế đầu của phương án đúng, vế sau sai — kiểu bẫy nửa đúng nửa sai.
• E. "Độ trễ giao message cấu hình bằng MessageRetentionPeriod" — nhầm thuộc tính. Độ trễ dùng DelaySeconds; MessageRetentionPeriod là thời gian giữ message trong queue trước khi nó bị xoá tự động.

Ghi nhớ

Và nhớ quy tắc vàng của cặp SQS + Lambda: VisibilityTimeout phải lớn hơn timeout của hàm (khuyến nghị gấp 6 lần), nếu không message bị phát lại trong khi hàm vẫn đang chạy.

Đáp án

B — !FindInMap [ MapName, TopLevelKey, SecondLevelKey ]

Vì sao đúng

Fn::FindInMap nhận đúng ba tham số, tương ứng với cấu trúc hai tầng của section Mappings:

Mappings:
  RegionMap:                      # ← MapName
    ap-southeast-1:               # ← TopLevelKey
      HVM64: ami-0abcdef1234      # ← SecondLevelKey : giá trị
      HVMG2: ami-0fedcba4321
    us-east-1:
      HVM64: ami-0123456789a
      HVMG2: ami-0987654321b

Resources:
  MayChu:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !FindInMap [ RegionMap, !Ref "AWS::Region", HVM64 ]

Đây chính là mẫu dùng phổ biến nhất của Mappings: AMI ID khác nhau ở mỗi Region, nên dùng pseudo parameter AWS::Region làm TopLevelKey để template tự chọn đúng AMI ở bất kỳ Region nào — đúng nhu cầu trong đề.

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

• A. Bốn tham số (thêm ThirdLevelKey) — Mappings chỉ hỗ trợ hai tầng khoá, không có tầng thứ ba. Cú pháp này gây lỗi validate template.
• D. Hai tham số và C. Một tham số — thiếu tham số. FindInMap cần đủ cả ba để định vị được một giá trị cụ thể; thiếu là lỗi.

Ghi nhớ

Ràng buộc của section Mappings:

• Đúng hai tầng khoá, không hơn
• Giá trị phải là chuỗi hoặc danh sách chuỗi — không dùng được hàm bên trong Mappings
• Khoá phải là giá trị tĩnh, biết trước khi deploy

Các pseudo parameter hay dùng làm khoá tra cứu: | Pseudo parameter | Giá trị | |---|---| | AWS::Region | Region đang deploy | | AWS::AccountId | ID tài khoản | | AWS::StackName | tên stack | | AWS::Partition | aws, aws-cn, aws-us-gov |

(Ngày nay AMI mới nhất thường lấy bằng SSM Parameter Store public parameter thay vì Mappings — sạch hơn và không phải cập nhật bảng thủ công.)