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

Đáp án

A — Theo dõi ConsumedReadCapacityUnits và ConsumedWriteCapacityUnits trong một khoảng thời gian.

Vì sao đúng

Câu hỏi của người quản lý là: năng lực đã cấp phát có đang bị lãng phí không? Muốn trả lời, phải so đã dùng bao nhiêu với đã cấp bao nhiêu:

ProvisionedReadCapacityUnits  = 1.000 RCU   ← đã trả tiền
ConsumedReadCapacityUnits     =   150 RCU   ← thực sự dùng
                                ─────────
                       Lãng phí: 85%

Hai metric Consumed* là con số thực tế tiêu thụ, nên chúng trả lời trực tiếp câu hỏi về tính hiệu quả chi phí.

aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB --metric-name ConsumedReadCapacityUnits \
  --dimensions Name=TableName,Value=BangCuaToi \
  --start-time 2026-07-01T00:00:00Z --end-time 2026-08-01T00:00:00Z \
  --period 3600 --statistics Sum Maximum

Một lưu ý quan trọng khi đọc số: metric này được ghi ở dạng tổng đơn vị tiêu thụ trong mỗi chu kỳ, nên muốn ra RCU mỗi giây thì phải chia cho số giây của chu kỳ:

Sum trong chu kỳ 300 giây = 45.000  →  45.000 / 300 = 150 RCU/giây

Bỏ qua bước này là ra con số lớn gấp hàng trăm lần và kết luận sai hoàn toàn.

Và nên xem cả Average lẫn Maximum: trung bình cho biết mức lãng phí, còn đỉnh cho biết bạn cần bao nhiêu để không bị throttle.

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

• D. Theo dõi ReadThrottleEvents và WriteThrottleEvents — đây là phương án gần nhất và cần phân biệt rõ: hai metric này cho biết năng lực có ĐỦ không (bị throttle nghĩa là thiếu). Nhưng chúng không cho biết đang dùng bao nhiêu — một bảng cấp 1.000 RCU mà chỉ dùng 50 sẽ có 0 throttle, trông hoàn hảo, trong khi thực tế đang lãng phí 95%. Chúng trả lời câu hỏi ngược lại với câu đề hỏi.
• B. CloudTrail và API DescribeLimits — sai hai chỗ: CloudTrail ghi lời gọi API quản trị, không ghi mức tiêu thụ; và DescribeLimits trả về hạn mức của tài khoản, không phải mức sử dụng của bảng.
• C. Dùng X-Ray để đo bảng DynamoDB qua subsegment — X-Ray theo dõi độ trễ và lỗi của từng lời gọi trong chuỗi dịch vụ. Nó cho biết truy vấn mất bao lâu, không tổng hợp được mức tiêu thụ RCU/WCU của cả bảng.

Ghi nhớ

Các metric quan trọng của DynamoDB, theo mục đích: | Mục đích | Metric | |---|---| | Đang dùng bao nhiêu | ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits | | Đã cấp bao nhiêu | ProvisionedReadCapacityUnits, ProvisionedWriteCapacityUnits | | Có bị thiếu không | ReadThrottleEvents, WriteThrottleEvents, ThrottledRequests | | Hiệu năng | SuccessfulRequestLatency | | Lỗi | SystemErrors, UserErrors |

Ba cách tối ưu chi phí sau khi đã đo: | Tình huống | Giải pháp | |---|---| | Tiêu thụ đều và dự đoán được | provisioned + reserved capacity (giảm tới ~50%) | | Tiêu thụ biến động theo chu kỳ | Auto Scaling cho provisioned | | Tiêu thụ thất thường hoặc rất thưa | on-demand mode |

Ngưỡng để quyết định giữa provisioned và on-demand: nếu mức tiêu thụ trung bình dưới khoảng 15–20% năng lực đỉnh, on-demand thường rẻ hơn dù đơn giá mỗi request cao hơn — vì bạn không phải trả cho phần năng lực nằm không.

Và AWS Cost Explorer cũng có báo cáo riêng cho DynamoDB, giúp đối chiếu con số metric với hoá đơn thật.

Đáp án

A — Sửa template CloudFormation để giữ lại (retain) security group đó, rồi xoá thủ công sau khi triển khai.

Vì sao đúng

Lỗi DELETE_FAILED với security group hầu như luôn có một nguyên nhân: security group vẫn đang được tài nguyên khác sử dụng — thường là ENI, instance, RDS, hoặc một security group khác tham chiếu tới nó trong rule.

CloudFormation không xoá được tài nguyên đang bị phụ thuộc, và stack rơi vào trạng thái DELETE_FAILED.

DeletionPolicy: Retain gỡ thế bí bằng cách bảo CloudFormation bỏ tài nguyên đó ra khỏi phạm vi quản lý thay vì cố xoá:

Resources:
  SecurityGroupUngDung:
    Type: AWS::EC2::SecurityGroup
    DeletionPolicy: Retain          # ← CloudFormation buông tài nguyên này ra
    Properties:
      GroupDescription: Cho ung dung web
      VpcId: !Ref VPC

Sau khi cập nhật stack với thuộc tính này, lệnh xoá stack sẽ thành công — security group vẫn tồn tại, và bạn xoá tay sau khi đã gỡ hết phụ thuộc.

Đây là cách xử lý đúng vì nó tách hai vấn đề: cho stack xoá xong (không để lại trạng thái hỏng), rồi mới xử lý phụ thuộc của security group một cách có kiểm soát.

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

• B. Xoá thủ công security group rồi chạy change set để ép xoá stack — thứ tự sai và cơ chế sai. Nếu security group đang bị phụ thuộc thì xoá thủ công cũng thất bại với đúng lý do đó. Và change set dùng để xem trước thay đổi khi CẬP NHẬT stack, nó không "ép xoá" stack. (Cơ chế đúng để bỏ qua tài nguyên khi xoá là delete-stack --retain-resources, không phải change set.)
• C. Thêm DependsOn cho tài nguyên đó — hiểu sai chức năng: DependsOn quy định THỨ TỰ tạo và xoá giữa các tài nguyên trong cùng một stack. Vấn đề ở đây là phụ thuộc từ tài nguyên bên ngoài stack, mà DependsOn không biết gì về chúng.
• D. Đổi logical ID của security group thành ARN của nó — logical ID là tên tài nguyên bên trong template (do bạn đặt), không liên quan gì tới ARN. Đổi logical ID còn khiến CloudFormation coi đó là một tài nguyên hoàn toàn mới — làm tình hình rối thêm.

Ghi nhớ

Ba giá trị của DeletionPolicy: | Giá trị | Hành vi khi xoá stack | |---|---| | Delete | xoá tài nguyên (mặc định cho hầu hết loại) | | Retain | giữ lại, gỡ khỏi quản lý của stack | | Snapshot | chụp snapshot rồi xoá — chỉ với RDS, EBS, ElastiCache, Redshift, Neptune, DocumentDB |

Và một thuộc tính anh em rất đáng biết: UpdateReplacePolicy — quyết định điều gì xảy ra khi một thay đổi buộc CloudFormation thay thế tài nguyên. Với CSDL production, nên đặt cả hai:

DeletionPolicy: Snapshot
UpdateReplacePolicy: Snapshot

Các cách xử lý khi stack kẹt ở DELETE_FAILED: | Cách | Khi nào | |---|---| | delete-stack --retain-resources <LogicalId> | bỏ qua đúng tài nguyên đang kẹt | | Gỡ phụ thuộc rồi thử xoá lại | khi biết rõ cái gì đang giữ | | Đặt DeletionPolicy: Retain rồi update trước | như phương án A |

aws cloudformation delete-stack --stack-name stack-cua-toi \
  --retain-resources SecurityGroupUngDung

Mẹo chẩn đoán: khi security group không xoá được, tìm thủ phạm bằng cách liệt kê ENI đang dùng nó — đây là nguyên nhân bị bỏ sót nhiều nhất, vì ENI của Lambda-trong-VPC hoặc của endpoint thường không hiện ra khi nhìn danh sách instance:

aws ec2 describe-network-interfaces --filters Name=group-id,Values=sg-11223344

Đáp án

A — Đặt ConsistentRead thành true khi gọi GetItem.

Vì sao đúng

Triệu chứng trong đề — instance thỉnh thoảng đọc phải dữ liệu cũ — là hành vi bình thường và được thiết kế của eventually consistent read, vốn là mặc định của DynamoDB.

Lý do: DynamoDB nhân bản mỗi item lên ba AZ. Sau khi ghi, việc lan truyền tới cả ba bản sao mất một khoảng rất ngắn (thường dưới 1 giây). Đọc kiểu eventually consistent lấy dữ liệu từ bất kỳ bản sao nào — nên có thể trúng bản chưa kịp cập nhật.

Ghi vào bản sao chính  →  lan truyền sang AZ-b, AZ-c
                            ↑
        Đọc rơi vào AZ-b ngay lúc này → nhận dữ liệu CŨ

Strongly consistent read đọc từ bản sao chính, nên luôn phản ánh mọi lần ghi đã hoàn tất trước đó:

response = table.get_item(
    Key={'id': 'KH-001'},
    ConsistentRead=True        # ← luôn dữ liệu mới nhất
)

Cái giá phải trả: | | Eventually consistent | Strongly consistent | |---|---|---| | Chi phí | 0,5 RCU / 4 KB | 1 RCU / 4 KB (gấp đôi) | | Độ trễ | thấp hơn | cao hơn một chút | | Đọc từ | bất kỳ bản sao nào | chỉ bản sao chính | | Khi AZ chính có sự cố | vẫn đọc được | có thể lỗi 500 |

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

• D. "Đặt consistency thành strong khi gọi UpdateTable" — UpdateTable không có tham số nào như vậy, và về nguyên tắc thì tính nhất quán được chọn ở TỪNG LẦN ĐỌC, không phải cấu hình ở mức bảng. Cùng một bảng có thể phục vụ cả hai kiểu đọc tuỳ nhu cầu của từng truy vấn — đó là thiết kế cố ý, vì phần lớn truy vấn không cần strongly consistent.
• C. Tạo bảng DAX mới — làm tình hình TỆ HƠN: DAX là lớp cache, nên nó phục vụ dữ liệu có thể còn cũ hơn nữa. Và quan trọng: DAX không hỗ trợ strongly consistent read — request kiểu đó đi thẳng xuống DynamoDB, bỏ qua cache.
• B. Dùng GetShardIterator — thuộc về DynamoDB Streams, dùng để đọc luồng thay đổi của bảng. Không liên quan gì tới việc đọc item hiện tại.

Ghi nhớ

Nơi có và không có strongly consistent read: | Thao tác | Hỗ trợ strongly consistent | |---|---| | GetItem, BatchGetItem | ✅ ConsistentRead=True | | Query, Scan | ✅ ConsistentRead=True | | Query trên GSI | ❌ KHÔNG BAO GIỜ | | Query trên LSI | ✅ | | Qua DAX | ❌ (đi thẳng xuống bảng) | | Global Tables (xuyên Region) | ❌ luôn eventually consistent |

Hai hạn chế trong bảng trên rất hay bị hỏi: GSI luôn eventually consistent (vì nó được cập nhật bất đồng bộ sau khi ghi vào bảng gốc), và Global Tables cũng vậy (nhân bản giữa các Region là bất đồng bộ).

Khi nào thật sự cần strongly consistent: | Cần | Không cần | |---|---| | Số dư tài khoản, tồn kho | danh sách bài viết, hồ sơ người dùng | | Đọc lại ngay sau khi ghi để xác nhận | dữ liệu thống kê, gợi ý | | Kiểm tra điều kiện trước khi hành động | nội dung ít đổi |

Nguyên tắc thực dụng: giữ mặc định eventually consistent cho phần lớn truy vấn (rẻ hơn một nửa và nhanh hơn), rồi bật ConsistentRead=True có chọn lọc ở đúng những chỗ mà dữ liệu cũ gây hậu quả nghiệp vụ.

Đáp án

C — Dùng AWS Copilot để có template khởi chạy nhanh ứng dụng ECS trên AWS Fargate.

Vì sao đúng

Đề yêu cầu giảm gánh nặng bảo trì hạ tầng ở mức tối đa, và câu trả lời phải đúng cả hai vế: công cụ triển khai và nền tảng chạy.

Vế nền tảng — Fargate, không phải EC2: | | ECS trên EC2 | ECS trên Fargate | |---|---|---| | Instance để vá | bạn quản lý | không có | | Co giãn cụm | bạn cấu hình | tự động | | Chọn instance type | bạn phải tính | không cần | | Tính tiền | theo instance | theo CPU/RAM của task | | Gánh nặng vận hành | cao | thấp nhất |

Vế công cụ — AWS Copilot là CLI được AWS thiết kế riêng cho việc này. Nó dựng toàn bộ hạ tầng cần thiết từ một Dockerfile:

copilot init --app cua-hang --name web --type "Load Balanced Web Service"
copilot env init --name production
copilot deploy --env production

Ba lệnh đó tạo ra: VPC, subnet, ECS cluster, Fargate service, ALB, ECR repository, IAM role, log group, và service discovery — theo các thực hành tốt của AWS, mà không cần viết một dòng CloudFormation nào.

Copilot còn tự dựng được CI/CD pipeline:

copilot pipeline init && copilot pipeline deploy

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

• A. Copilot cho ECS trên EC2 — đúng công cụ nhưng sai nền tảng: bạn vẫn phải quản lý các EC2 instance của cụm — vá lỗi, giám sát, co giãn. Trái yêu cầu "reduce the burden of infrastructure maintenance".
• B. "Dùng Fargate để cung cấp template khởi chạy ECS trên EC2" — câu này tự mâu thuẫn: Fargate và EC2 là hai launch type loại trừ nhau, không thể chạy Fargate "trên EC2". Ngoài ra Fargate không phải công cụ tạo template — nó là nền tảng tính toán.
• D. "Dùng ECS để cung cấp template khởi chạy ứng dụng Fargate trên EC2" — cùng lỗi mâu thuẫn về launch type, và ECS cũng không phải công cụ sinh template.

Ghi nhớ

Các công cụ triển khai container của AWS, theo mức trừu tượng: | Công cụ | Đặc điểm | |---|---| | AWS Copilot | CLI đơn giản nhất cho ECS/Fargate — hợp với đội nhỏ, muốn nhanh | | AWS CDK | hạ tầng bằng ngôn ngữ lập trình, linh hoạt nhất | | CloudFormation | khai báo YAML/JSON, kiểm soát chi tiết | | ECS CLI | đã lỗi thời, Copilot thay thế | | App Runner | đơn giản hơn cả Copilot — chỉ cần repo hoặc image, nhưng ít kiểm soát |

Bốn loại service mà Copilot dựng sẵn: | Loại | Dùng cho | |---|---| | Load Balanced Web Service | API và web app công khai (có ALB) | | Backend Service | dịch vụ nội bộ, không phơi ra Internet | | Worker Service | consumer đọc từ SQS | | Scheduled Job | tác vụ định kỳ |

Nhận dạng nhanh trong đề: "reduce infrastructure maintenance", "no servers to manage" ⇒ Fargate. "launch quickly", "minimal configuration" ⇒ Copilot (hoặc App Runner nếu đề nhấn mạnh đơn giản tuyệt đối).

Khi nào vẫn nên chọn EC2 launch type: cần GPU, cần instance type đặc thù, cần Spot với kiểm soát chi tiết, hoặc chạy container mật độ rất cao mà chi phí Fargate trở nên cao hơn.

Đáp án

C — Người phụ trách cần có quyền gọi iam:CreateServiceLinkedRole.

Vì sao đúng

Service-linked role là loại IAM role đặc biệt, gắn trực tiếp với một dịch vụ AWS. MemoryDB dùng nó để tự thay bạn quản lý các tài nguyên nó cần (ENI, subnet group, tham số cụm…).

Điểm mấu chốt: service-linked role được tạo tự động ở lần đầu bạn dùng dịch vụ — nhưng chỉ khi danh tính của bạn có quyền tạo nó. Thiếu quyền iam:CreateServiceLinkedRole thì thao tác tạo cụm thất bại ngay từ bước đầu, với thông báo lỗi thường khá khó hiểu.

{
  "Effect": "Allow",
  "Action": "iam:CreateServiceLinkedRole",
  "Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
  "Condition": {
    "StringLike": {"iam:AWSServiceName": "memorydb.amazonaws.com"}
  }
}

Đây là điều kiện tiên quyết cần có trước khi làm bất cứ điều gì với quyền hạn của dịch vụ — đúng câu hỏi mà đề đặt ra ("what needs to be done prior to making this change").

Đặc điểm của service-linked role, giải thích vì sao nó cần quyền riêng: | Đặc điểm | Chi tiết | |---|---| | Do dịch vụ định nghĩa | bạn không sửa được policy gắn sẵn | | Không xoá được khi còn tài nguyên | phải xoá cụm trước | | Trust policy cố định | chỉ dịch vụ đó assume được | | Tên có tiền tố | AWSServiceRoleFor..., nằm trong đường dẫn /aws-service-role/ |

Vì bạn không sửa được policy của service-linked role, muốn dùng quyền hạn tuỳ chỉnh thì phải tạo policy riêng của mình — và bước đầu tiên vẫn là có quyền làm việc với service-linked role.

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

• B. Sửa policy mặc định tên AmazonMemoryDBFullAccess — không sửa được: đây là AWS managed policy, và AWS managed policy là bất biến với khách hàng. Muốn thu hẹp quyền thì phải sao chép nội dung sang một customer managed policy rồi sửa bản sao đó.
• A. Cần sự cho phép từ AWS Technical Account Manager — không có yêu cầu hành chính nào như vậy. Quyền trong AWS được cấp bằng IAM policy, không phải bằng phê duyệt từ nhân sự của AWS. (TAM là vai trò hỗ trợ khách hàng ở gói Enterprise Support, không tham gia vào việc cấp quyền.)
• D. Phải đăng nhập bằng root user — không cần và không nên. Bất kỳ danh tính IAM nào có quyền phù hợp đều làm được. AWS khuyến nghị không dùng root user cho công việc hằng ngày — chỉ dùng cho vài tác vụ bắt buộc (đổi phương thức thanh toán, đóng tài khoản, một số thay đổi ở cấp tổ chức).

Ghi nhớ

Ba loại role hay bị lẫn: | Loại | Ai tạo | Sửa được policy? | |---|---|---| | Service-linked role | dịch vụ tự tạo | ❌ | | Service role | bạn tạo và gán cho dịch vụ | ✅ | | Role cho danh tính | bạn tạo | ✅ |

Và ba loại policy: | Loại | Sửa được? | |---|---| | AWS managed | ❌ bất biến | | Customer managed | ✅ | | Inline | ✅ (nhưng không tái sử dụng được) |

Quy trình chuẩn khi muốn thu hẹp một AWS managed policy:

1. Mở policy trong Console, sao chép JSON
2. Tạo customer managed policy từ bản sao
3. Thu hẹp Action và Resource theo nhu cầu thật
4. Gỡ managed policy, gắn policy mới
5. Kiểm tra bằng IAM Access Analyzer hoặc chạy thử ở môi trường test

Và một mẹo hữu ích cho bước 3: dùng IAM Access Advisor để xem dịch vụ nào thật sự được gọi trong 400 ngày qua — nó cho thấy rất nhiều quyền được cấp mà chưa bao giờ dùng tới.

Đáp án

D — Dùng Route 53 với latency-based routing, tạo latency record ở nhiều Region.

Vì sao đúng

Yêu cầu: độ trễ tối thiểu cho người dùng ở cả bờ đông lẫn bờ tây nước Mỹ.

Muốn giảm độ trễ do khoảng cách địa lý, chỉ có một cách: triển khai ứng dụng ở nhiều Region rồi đưa mỗi người dùng tới Region nhanh nhất với họ. Đó chính là latency-based routing:

Người dùng ở New York  → Route 53 đo → us-east-1 nhanh hơn → trả về IP của us-east-1
Người dùng ở Seattle   → Route 53 đo → us-west-2 nhanh hơn → trả về IP của us-west-2

Điểm quan trọng: Route 53 không định tuyến theo khoảng cách địa lý mà theo độ trễ mạng thực đo được. AWS liên tục đo độ trễ giữa các vị trí người dùng và các Region, nên kết quả phản ánh tình trạng mạng thật — đôi khi Region gần hơn về địa lý lại không phải Region nhanh nhất.

aws route53 change-resource-record-sets --hosted-zone-id Z123 --change-batch '{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "ung-dung.example.com",
      "Type": "A",
      "SetIdentifier": "bo-dong",
      "Region": "us-east-1",
      "AliasTarget": {"DNSName": "alb-dong...elb.amazonaws.com",
                      "HostedZoneId": "Z35SXDOTRQ7X7K",
                      "EvaluateTargetHealth": true}
    }
  }]
}'

(Rồi tạo bản ghi tương tự với SetIdentifier: "bo-tay" và Region: us-west-2.)

Đặt EvaluateTargetHealth: true để Route 53 tự bỏ qua Region đang có sự cố — kết hợp được cả tối ưu độ trễ lẫn khả năng chịu lỗi.

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

• A. Route 53 định tuyến theo health check — failover routing giải quyết tính sẵn sàng, không phải độ trễ: nó gửi toàn bộ traffic tới endpoint chính và chỉ chuyển sang dự phòng khi endpoint chính hỏng. Người dùng bờ tây vẫn phải nói chuyện với máy chủ bờ đông.
• B. Dùng CloudWatch theo dõi đỉnh traffic để mở rộng theo chiều ngang — mở rộng ngang giải quyết năng lực xử lý, không giải quyết khoảng cách vật lý. Thêm bao nhiêu instance ở một Region cũng không rút ngắn được đường truyền xuyên lục địa.
• C. Dùng CloudTrail để theo dõi request đến từ đâu — CloudTrail ghi lời gọi API quản trị, không ghi traffic của người dùng cuối. Muốn biết người dùng đến từ đâu thì dùng CloudFront access log, ALB access log, hoặc VPC Flow Logs. Và bản thân việc "biết họ ở đâu" cũng chưa phải giải pháp.

Ghi nhớ

Các chính sách định tuyến của Route 53: | Chính sách | Chọn endpoint theo | |---|---| | Simple | một bản ghi duy nhất | | Latency-based | độ trễ mạng ĐO ĐƯỢC | | Geolocation | vị trí địa lý của người dùng | | Geoproximity | khoảng cách địa lý, có điều chỉnh bằng bias | | Failover | chủ động – dự phòng | | Weighted | tỷ lệ % — canary, A/B testing | | Multivalue answer | trả nhiều IP kèm health check |

Ba chính sách nghe giống nhau nhưng khác hẳn: | | Chọn theo | Dùng khi | |---|---|---| | Latency-based | tốc độ mạng | muốn NHANH NHẤT | | Geolocation | quốc gia/châu lục của người dùng | tuân thủ pháp lý, nội dung theo vùng | | Geoproximity | khoảng cách + bias | muốn dịch chuyển tải giữa các Region |

Nhận dạng nhanh: đề nói "minimal latency", "optimal performance", "fastest" ⇒ latency-based. Đề nói "người dùng ở nước X phải được phục vụ nội dung Y" ⇒ geolocation.

Một lựa chọn khác đáng biết cho cùng bài toán: AWS Global Accelerator — nó cho hai IP anycast tĩnh và đưa traffic vào mạng backbone của AWS ngay tại edge gần nhất. So với latency-based routing, nó chuyển hướng nhanh hơn khi có sự cố (vài giây, không phụ thuộc TTL của DNS) và cải thiện độ trễ ổn định hơn — nhưng tốn phí cố định hàng tháng.

Đáp án

C — Biểu tượng ổ khoá trên thanh địa chỉ.

Vì sao đúng

Câu hỏi rất trực tiếp: trình duyệt hiển thị gì để báo cho người dùng biết kết nối là an toàn và đáng tin?

Câu trả lời là biểu tượng ổ khoá — quy ước hiển thị chung của mọi trình duyệt hiện đại. Nó xuất hiện khi ba điều kiện đồng thời thoả:

Chứng chỉ công cộng từ ACM thoả cả ba: nó được cấp bởi Amazon Trust Services, một CA nằm sẵn trong kho tin cậy của mọi trình duyệt phổ biến.

Bấm vào ổ khoá, người dùng xem được chi tiết: ai cấp, cấp cho tên miền nào, hiệu lực tới khi nào.

(Ghi chú thời sự: các trình duyệt đang giảm dần độ nổi bật của ổ khoá — Chrome từ phiên bản 117 đã đổi sang biểu tượng "tune"/thanh trượt, vì HTTPS giờ là mặc định chứ không còn là điều đặc biệt. Ý tưởng vẫn nguyên: có biểu tượng ở vị trí đó = kết nối an toàn, còn cảnh báo "Not secure" = có vấn đề.)

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

• A. DNS validation — đây là phương thức chứng minh quyền sở hữu tên miền khi xin cấp chứng chỉ: ACM yêu cầu bạn thêm một bản ghi CNAME vào DNS. Nó là bước trong quy trình cấp phát, xảy ra trước khi chứng chỉ tồn tại, và người dùng cuối không bao giờ thấy nó.
• B. Thuật toán khoá ECDSA và D. Thuật toán khoá RSA — đây là thuật toán mã hoá bên trong chứng chỉ. Chúng là chi tiết kỹ thuật, xem được nếu bấm vào để khảo sát chứng chỉ, nhưng chúng không phải tín hiệu tin cậy hiển thị cho người dùng. Và bản thân việc dùng RSA hay ECDSA không nói lên chứng chỉ có đáng tin hay không.

Ghi nhớ

Hai phương thức xác thực khi xin chứng chỉ từ ACM: | Phương thức | Cách làm | Đặc điểm | |---|---|---| | DNS validation | thêm bản ghi CNAME do ACM cung cấp | khuyến nghị — TỰ ĐỘNG GIA HẠN | | Email validation | ACM gửi thư tới địa chỉ quản trị của tên miền | phải thao tác tay ở mỗi lần gia hạn |

Khác biệt này rất quan trọng trong thực tế: chứng chỉ xác thực bằng DNS và đang được dịch vụ AWS sử dụng sẽ được ACM tự gia hạn vô thời hạn — bạn không bao giờ phải nghĩ tới nó nữa. Với email validation, bạn phải bấm xác nhận mỗi 13 tháng, và quên là website sập.

Các đặc điểm của ACM cần nhớ: | Đặc điểm | Chi tiết | |---|---| | Chứng chỉ công cộng | miễn phí | | Tự gia hạn | ✅ nếu dùng DNS validation và đang được dịch vụ AWS dùng | | Xuất private key | ❌ không được với chứng chỉ công cộng | | Dùng được với | ELB, CloudFront, API Gateway, AppSync, Cognito — không dùng trực tiếp trên EC2 | | Region cho CloudFront | bắt buộc us-east-1 |

Điểm cuối cùng là lỗi cấu hình phổ biến nhất với ACM: cấp chứng chỉ ở sai Region thì Console đơn giản là không hiện nó trong danh sách của CloudFront, không có thông báo nào giải thích vì sao.

Đáp án

B — Dùng pseudo parameter AWS::Region.

Vì sao đúng

CloudFormation cung cấp sẵn một nhóm pseudo parameter — các biến do chính CloudFormation cấp giá trị lúc triển khai, không cần khai báo gì:

Resources:
  KhoTepTin:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "du-lieu-${AWS::Region}-${AWS::AccountId}"

Outputs:
  RegionHienTai:
    Value: !Ref AWS::Region

AWS::Region tự động mang giá trị Region nơi stack đang được tạo. Cùng một template chạy ở us-east-1 cho ra du-lieu-us-east-1-123456789012, chạy ở ap-southeast-1 cho ra du-lieu-ap-southeast-1-123456789012.

Đây là cách hiệu quả nhất vì: | Lợi ích | Chi tiết | |---|---| | Không cần cấu hình gì | có sẵn trong mọi template | | Không thể sai | CloudFormation tự điền, người dùng không nhập được giá trị lệch | | Không tốn lời gọi API | không phải tra cứu ở đâu cả |

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

• D. Yêu cầu người dùng nhập Region làm input parameter — chạy được nhưng dở: thừa một bước thủ công, và cho phép nhập sai. Ai đó có thể triển khai vào ap-southeast-1 nhưng khai parameter là us-east-1, tạo ra stack với cấu hình lệch mà không có lỗi nào cảnh báo.
• C. Tách Region từ AWS::StackId bằng Fn::Split — về kỹ thuật thì làm được (stack ID là một ARN có chứa Region), nhưng đây là đường vòng phức tạp cho việc mà AWS::Region làm sẵn:

  # Cách phức tạp không cần thiết
  !Select [3, !Split [":", !Ref "AWS::StackId"]]
  

  Nhiều bước hơn, khó đọc hơn, và dễ hỏng nếu định dạng ARN thay đổi.
• A. Tra cứu động từ SSM Parameter Store — thêm hẳn một phụ thuộc bên ngoài cho một giá trị mà CloudFormation đã biết sẵn. Ngoài ra bạn phải tạo và duy trì parameter đó ở mỗi Region — chính là việc mà pseudo parameter giúp bạn tránh.

Ghi nhớ

Các pseudo parameter, dùng được trong mọi template: | Tên | Giá trị | |---|---| | AWS::Region | Region đang triển khai | | AWS::AccountId | ID tài khoản | | AWS::StackName | tên stack | | AWS::StackId | ARN đầy đủ của stack | | AWS::Partition | aws, aws-cn, hoặc aws-us-gov | | AWS::URLSuffix | amazonaws.com (hoặc amazonaws.com.cn) | | AWS::NoValue | bỏ hẳn một thuộc tính (dùng với Fn::If) |

Hai cái ít biết nhưng rất hữu ích:

AWS::Partition — cần khi template phải chạy được ở cả AWS thường lẫn AWS China hoặc GovCloud, vì ARN ở đó có tiền tố khác:

Resource: !Sub "arn:${AWS::Partition}:s3:::kho-du-lieu/*"

AWS::NoValue — cách duy nhất để bỏ hẳn một thuộc tính thay vì đặt nó bằng chuỗi rỗng:

SnapshotIdentifier: !If [KhoiPhucTuSnapshot, !Ref IdSnapshot, !Ref "AWS::NoValue"]

Nguyên tắc chung khi làm bài: nếu CloudFormation đã cung cấp sẵn một giá trị, thì phương án nào đi tra cứu nó ở nơi khác đều là đường vòng — và đề hỏi "MOST efficient" thì đường vòng luôn sai.

Đáp án

A — Đặt API Cache ở chế độ full request caching và điều chỉnh thiết lập mã hoá cả at-rest lẫn in-transit.

Vì sao đúng

Đề có hai yêu cầu phải thoả cùng lúc:

1. Tuân thủ HIPAA — dữ liệu phải được mã hoá
2. Tối ưu hiệu năng, giảm độ trễ tối đa

Vế hiệu năng — full request caching. AppSync có hai chế độ cache, và chúng khác nhau về mức độ triệt để:

Với full request caching, một truy vấn trúng cache được trả lời ngay tại tầng cache — không gọi Lambda, không truy vấn DynamoDB. Đó là độ trễ thấp nhất có thể.

Vế tuân thủ — phải bật mã hoá TƯỜNG MINH. Đây là điểm mấu chốt của câu hỏi: mã hoá của AppSync cache KHÔNG bật theo mặc định, và chỉ đặt được lúc TẠO cache:

aws appsync create-api-cache \
  --api-id abc123 \
  --ttl 3600 \
  --api-caching-behavior FULL_REQUEST_CACHING \
  --type LARGE \
  --at-rest-encryption-enabled \
  --transit-encryption-enabled

Hai cờ cuối là thứ HIPAA đòi hỏi, và không sửa được sau khi cache đã tạo — muốn đổi thì phải xoá cache rồi tạo lại.

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

• B. Full request caching nhưng giữ thiết lập mã hoá mặc định — đúng vế hiệu năng, trượt vế tuân thủ: mặc định không bật mã hoá cho cache, nên dữ liệu bệnh nhân sẽ nằm trong cache ở dạng không được mã hoá. Vi phạm HIPAA.
• D. Per-resolver caching, giữ mã hoá mặc định — trượt cả hai vế: chậm hơn full request caching (vẫn phải chạy qua tầng resolver) và không có mã hoá.
• C. Đặt cache thành "None" nhưng bật mã hoá — tự mâu thuẫn: không có cache thì không có gì để mã hoá ở tầng cache, và quan trọng hơn — không có cải thiện hiệu năng nào. Trượt yêu cầu "optimize performance and reduce latency".

Ghi nhớ

Cache của AWS AppSync: | Thuộc tính | Giá trị | |---|---| | Chế độ | FULL_REQUEST_CACHING hoặc PER_RESOLVER_CACHING | | TTL | 1 – 3600 giây | | Kích thước | SMALL đến 8X_LARGE | | Mã hoá at-rest | phải bật tường minh, chỉ lúc tạo | | Mã hoá in-transit | phải bật tường minh, chỉ lúc tạo | | Bên dưới | ElastiCache Redis do AWS quản lý |

Cách chọn chế độ cache: | Tình huống | Chọn | |---|---| | Dữ liệu giống nhau cho mọi người dùng | full request caching | | Một số trường thay đổi theo người dùng | per-resolver caching | | Dữ liệu thay đổi liên tục, không lặp lại | không dùng cache |

Cảnh báo quan trọng với dữ liệu y tế: full request caching có thể phục vụ dữ liệu của người này cho người khác nếu khoá cache không bao gồm danh tính người dùng. Với AppSync, hãy đưa $context.identity.sub vào caching key để tách cache theo từng người:

Caching keys: $context.identity.sub, $context.arguments.maBenhAn

Bỏ sót chi tiết này là một sự cố rò rỉ dữ liệu, không chỉ là lỗi hiệu năng.

Và với HIPAA nói chung: AppSync là dịch vụ đủ điều kiện HIPAA, nhưng bạn vẫn phải ký BAA với AWS và tự đảm bảo mọi lớp trong kiến trúc (cache, DynamoDB, Lambda, log) đều được cấu hình mã hoá.

Đáp án

B — Đặt các hàm Lambda trong CÙNG VPC với RDS instance và cấu hình security group cho phép truy cập.

Vì sao đúng

Bối cảnh: cả ứng dụng lẫn CSDL đều nằm trong private subnet. Lambda mặc định chạy ngoài VPC của bạn, nên nó không có đường nào tới một RDS trong private subnet.

Gắn hàm vào VPC là cách đúng, và nó vẫn giữ được tính riêng tư:

{
  "VpcConfig": {
    "SubnetIds": ["subnet-private-a", "subnet-private-b"],
    "SecurityGroupIds": ["sg-lambda"]
  }
}

Rồi mở đường ở tầng security group — và cách mở đúng là tham chiếu security group, không phải dải IP:

aws ec2 authorize-security-group-ingress \
  --group-id sg-rds \
  --protocol tcp --port 5432 \
  --source-group sg-lambda

Cách này an toàn hơn hẳn việc mở theo CIDR: nếu subnet được mở rộng hay có thêm tài nguyên, quyền vẫn chỉ áp cho đúng những gì mang sg-lambda.

Kết quả: traffic hoàn toàn nằm trong VPC, không đi qua Internet, không cần IP công khai.

Ba lưu ý khi gắn Lambda vào VPC: | Lưu ý | Chi tiết | |---|---| | Mất truy cập Internet | cần NAT Gateway nếu hàm phải gọi API bên ngoài | | Cần VPC endpoint | để gọi S3, DynamoDB, Secrets Manager mà không qua NAT | | Chọn ≥ 2 subnet khác AZ | để chịu được sự cố một AZ |

(Ghi chú: từ 2019, AWS đã cải tiến hẳn cơ chế mạng của Lambda-trong-VPC — ENI được tạo sẵn và dùng chung, nên cold start không còn bị phạt hàng chục giây như trước. Đây là thông tin cũ vẫn hay bị nhắc lại.)

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

• A. Kết nối trực tiếp qua địa chỉ IP công khai của RDS — sai hai chỗ: RDS nằm trong private subnet nên không có IP công khai, và kể cả có thì phơi CSDL ra Internet là vi phạm nghiêm trọng yêu cầu "securely".
• C. Triển khai AWS App Runner trong VPC để "host các hàm Lambda" — App Runner không host hàm Lambda. Nó là dịch vụ chạy ứng dụng container hoặc mã nguồn web, hoàn toàn tách biệt với Lambda. Phương án ghép hai dịch vụ không liên quan.
• D. Thiết lập AWS Direct Connect giữa Lambda và RDS — hiểu sai chức năng: Direct Connect là đường truyền vật lý riêng giữa trung tâm dữ liệu TẠI CHỖ và AWS. Ở đây cả hai đầu đều đã nằm trong AWS, thậm chí trong cùng một VPC — không có gì để nối cả.

Ghi nhớ

Lambda và mạng: | Cấu hình | Truy cập được | |---|---| | Không gắn VPC (mặc định) | Internet và dịch vụ AWS công khai; KHÔNG vào được private subnet | | Gắn VPC, private subnet, không NAT | tài nguyên trong VPC; không ra Internet | | Gắn VPC + NAT Gateway | cả hai — nhưng tốn phí NAT | | Gắn VPC + VPC endpoint | tài nguyên VPC + dịch vụ AWS qua đường riêng, rẻ hơn NAT |

Với hàm cần cả CSDL lẫn vài dịch vụ AWS, VPC endpoint thường là lựa chọn tốt hơn NAT Gateway: rẻ hơn đáng kể và traffic không rời khỏi mạng AWS. Gateway endpoint (S3, DynamoDB) thì miễn phí hoàn toàn.

Và với cặp Lambda + RDS, đừng quên vấn đề đã bàn ở nhiều câu khác: cạn kiệt kết nối. Mỗi môi trường thực thi mở một kết nối riêng, nên khi Lambda mở rộng mạnh, CSDL sẽ chạm max_connections. Giải pháp là RDS Proxy — nó cũng nằm trong VPC, và hàm trỏ vào endpoint của proxy thay vì trỏ thẳng vào CSDL.