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

Đáp án

C — Bật S3 TRANSFER ACCELERATION cho bucket.

Vì sao đúng

Đề có đủ ba dấu hiệu đặc trưng: TẢI LÊN, người dùng ở xa trên toàn cầu, và tệp PDF (thường khá lớn).

⚠ Điểm mấu chốt — tăng tốc bằng đường trục riêng của AWS:

Không có Transfer Acceleration
        ↓
    Người dùng ở châu Á → internet công cộng →
    bucket ở us-east-1
        ↓
    Nhiều chặng, nhiều nhà mạng, mất gói
    → cửa sổ TCP thu hẹp → tải lên chậm

Có Transfer Acceleration
        ↓
    Người dùng → EDGE LOCATION gần nhất
      (vài chục mili giây)
        ↓
    Edge → bucket qua ĐƯỜNG TRỤC RIÊNG của AWS
        ↓
    → đường tối ưu, ít mất gói
    → nhanh hơn 50-500% với tệp lớn đi xa

⚠ Bật xong phải ĐỔI ENDPOINT:

Endpoint thường:
    ten-bucket.s3.us-east-1.amazonaws.com

Endpoint tăng tốc:
    ten-bucket.s3-accelerate.amazonaws.com
        ↓
    Bật tính năng CHƯA ĐỦ
    → ứng dụng PHẢI gọi endpoint mới
        ↓
    Yêu cầu: tên bucket KHÔNG CÓ DẤU CHẤM

⚠ Và AWS có công cụ đo trước khi quyết:

Speed Comparison tool (công khai)
        ↓
    Đo thử từ chính vị trí của bạn
        ↓
    → chỉ trả tiền khi thực sự nhanh hơn
      (AWS không tính phí nếu không cải thiện)

Xem thêm câu #11841 (lô 128): gần như cùng một câu hỏi, cùng đáp án Transfer Acceleration và cũng cùng chữ cái C. Khoá nhất quán.

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

• D (tạo accelerator trong AWS Global Accelerator) — đây là phương án gần nhất vì cũng dùng mạng edge của AWS, nhưng Global Accelerator hoạt động ở tầng 4 cho TCP/UDP tới ALB, NLB, EC2 hoặc Elastic IP — nó không phục vụ S3. Với S3 thì đúng công cụ là Transfer Acceleration.

• A (tạo S3 access point ở các Region gần người dùng) — access point là một điểm truy cập có chính sách riêng cho CÙNG một bucket, không đặt dữ liệu gần người dùng hơn và không tăng tốc đường truyền.

• B (bật cross-Region replication) — CRR nhân bản dữ liệu SAU KHI đã tải lên, nên không giúp gì cho tốc độ TẢI LÊN. Lại tốn thêm chi phí lưu trữ.

Ghi nhớ

⚠ Bốn cách tăng tốc S3 — bảng phải thuộc: | Vấn đề | Giải pháp | |---|---| | TẢI LÊN chậm từ xa | Transfer Acceleration | | TẢI XUỐNG chậm, nội dung lặp lại | CloudFront (có cache) | | Tệp rất lớn (>100 MB) | Multipart Upload — song song, thử lại từng phần | | Người đọc ở Region khác thường xuyên | Cross-Region Replication | | Hàng chục TB trở lên | Snowball / DataSync |

Từ khoá nhận diện:

"tải LÊN chậm từ xa" → Transfer Acceleration "tải XUỐNG chậm" → CloudFront "TCP/UDP tới ALB hay EC2" → Global Accelerator — không phải cho S3 "tệp vài GB" → Multipart Upload (bắt buộc trên 5 GB) "503 SlowDown" → chia nhiều prefix, và dùng CloudFront

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có nhanh hơn thật không | công cụ Speed Comparison của AWS | | Đã bật chưa | get-bucket-accelerate-configuration | | Ứng dụng có dùng endpoint mới không | bắt log request, tìm s3-accelerate |

Và một chi tiết dễ làm mất công vô ích: bật Transfer Acceleration mà không sửa endpoint trong ứng dụng thì không có gì thay đổi cả — bucket vẫn nhận request qua endpoint thường, tốc độ y như cũ, và bạn cũng không bị tính thêm phí. Khi kiểm chứng, hãy nhìn vào chính chuỗi endpoint mà SDK đang gọi, đừng chỉ nhìn công tắc trên console.

Đáp án

C và E — Bật S3 DEFAULT ENCRYPTION, VÀ dùng BUCKET POLICY để từ chối đối tượng không mã hoá.

Vì sao đúng

Hai biện pháp này bổ sung nhau, và đề hỏi hai cách nên chọn cả hai.

⚠ Cách thứ nhất — Default Encryption bảo đảm không lọt tệp nào:

S3 Default Encryption
        ↓
    Client tải lên KHÔNG khai mã hoá
        ↓
    → S3 TỰ MÃ HOÁ trước khi lưu
        ↓
    → không có đối tượng nào nằm ở dạng thô
    → và client KHÔNG cần biết gì cả
        ↓
    (Từ đầu 2023, S3 mã hoá SSE-S3 mặc định
     cho mọi bucket — nhưng vẫn nên khai rõ
     loại mã hoá muốn dùng, nhất là SSE-KMS)

⚠ Cách thứ hai — Bucket policy TỪ CHỐI request không mã hoá:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::ten-bucket/*",
  "Condition": {
    "Null": {
      "s3:x-amz-server-side-encryption": "true"
    }
  }
}

    → request không khai mã hoá bị TỪ CHỐI
    → client nhận lỗi 403
        ↓
    Muốn ép ĐÚNG MỘT LOẠI:
      "StringNotEquals": {
        "s3:x-amz-server-side-encryption": "aws:kms"
      }

⚠ Vì sao nên dùng CẢ HAI:

Default Encryption
        ↓
    → bảo đảm KHÔNG CÓ tệp nào chưa mã hoá
    → nhưng ÂM THẦM, không ai biết ứng dụng
      đang gửi sai cách

Bucket policy Deny
        ↓
    → PHÁT HIỆN được ứng dụng nào gửi sai
      (nó nhận 403 rõ ràng)
    → và chứng minh được với kiểm toán viên
      rằng có cơ chế TỪ CHỐI
        ↓
    → hai lớp phủ hai khoảng trống khác nhau

Xem thêm câu #11824 (lô 127): cùng chủ đề, ở đó đề hỏi một cách và khoá là bucket policy vì yêu cầu là "TỪ CHỐI request không mã hoá". Ở đây đề hỏi hai cách nên gồm cả Default Encryption. Khoá nhất quán, không mâu thuẫn.

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

• D (luật AWS Config định nghĩa một S3 bucket ACL để ép mã hoá mặc định) — đây là phương án gần nhất vì Config có luật kiểm tra mã hoá thật (s3-bucket-server-side-encryption-enabled), nhưng Config chỉ PHÁT HIỆN, không ÉP, và ACL hoàn toàn không liên quan tới mã hoá.

• A (dùng Object ACL để từ chối đối tượng không mã hoá) — S3 ACL là cơ chế cũ chỉ cấp quyền đọc/ghi, không có luật Deny và không có khái niệm mã hoá.

• B (dùng server access log, kích hoạt Lambda để XOÁ các đối tượng không mã hoá) — phản ứng SAU khi dữ liệu đã nằm ở dạng thô trong bucket, và XOÁ dữ liệu của người dùng là hành vi rất nguy hiểm.

Ghi nhớ

⚠ Hai cách ép mã hoá S3 — bảng phải thuộc: | | Default Encryption | Bucket policy Deny | |---|---|---| | Cơ chế | âm thầm mã hoá nếu client không khai | TỪ CHỐI request không khai | | Client biết không | không | có — nhận 403 | | Ép loại khoá cụ thể | có (chọn SSE-KMS) | có, chặt chẽ hơn | | Dùng khi | bảo đảm mọi thứ được mã hoá | tuân thủ đòi TỪ CHỐI | | Thực hành tốt | dùng CẢ HAI | |

Từ khoá nhận diện:

"ÉP mã hoá, phải TỪ CHỐI nếu không có" → bucket policy với Null hoặc StringNotEquals "bảo đảm mọi thứ được mã hoá" → Default Encryption "ép HTTPS" → aws:SecureTransport: false → Deny "ép đúng một khoá KMS" → s3:x-amz-server-side-encryption-aws-kms-key-id "phát hiện bucket chưa mã hoá" → Config rule — chỉ phát hiện, không ép

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách có chặn đúng không | thử put-object không kèm header — phải 403 | | Bucket dùng mã hoá gì | get-bucket-encryption | | Còn tệp cũ chưa mã hoá không | S3 Inventory |

Và một điểm cần lưu ý khi viết bucket policy loại này: Resource phải có /*. s3:PutObject là thao tác trên đối tượng, nên một chính sách khai arn:aws:s3:::bucket mà thiếu /* sẽ không khớp với bất kỳ request nào — nó tồn tại trên console, trông hoàn toàn đúng, và không chặn được gì cả.

Đáp án

D — Bật KUBERNETES CLUSTER AUTOSCALER và đặt mục tiêu theo mức dùng CPU.

Vì sao đúng

Đề cần chịu được đợt tăng tải lớn với ít công quản trị nhất, và Cluster Autoscaler là cơ chế co giãn tiêu chuẩn của EKS.

⚠ Điểm mấu chốt — hai tầng co giãn trong Kubernetes:

TẦNG POD — Horizontal Pod Autoscaler (HPA)
        ↓
    Tăng SỐ LƯỢNG POD theo CPU hoặc chỉ số tuỳ chỉnh
        ↓
    Nhưng pod cần CHỖ để chạy
        ↓
TẦNG NODE — Cluster Autoscaler
        ↓
    Khi có pod ở trạng thái PENDING
      vì không đủ tài nguyên
        ↓
    → THÊM NODE vào node group (qua ASG)
        ↓
    Khi node nhàn rỗi kéo dài
        ↓
    → GỠ NODE ra, tiết kiệm chi phí
        ↓
    → cụm tự lớn lên khi cần, tự thu lại khi hết

⚠ Vì sao đây là cách ít công nhất:

Không phải dựng cụm mới
Không phải chuyển sang dịch vụ khác
Không phải canh chừng bằng tay
        ↓
    → cài một lần, hoạt động mãi
    → và nó dùng chính Auto Scaling group
      của node group, nên tích hợp sẵn với EC2

⚠ Phân biệt ba bộ autoscaler của Kubernetes:

HPA — Horizontal Pod Autoscaler
        ↓
    THÊM POD (mở rộng NGANG ở tầng pod)

VPA — Vertical Pod Autoscaler
        ↓
    TĂNG CPU/RAM CHO MỖI POD
    → thường phải KHỞI ĐỘNG LẠI pod
    → KHÔNG thêm năng lực tổng thể

Cluster Autoscaler
        ↓
    THÊM NODE (mở rộng ở tầng máy)  ← đề này
        ↓
Karpenter (mới hơn, AWS khuyến nghị)
        ↓
    Chọn loại instance tối ưu, khởi chạy nhanh hơn

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

• B (bật Vertical Pod Autoscaler và đặt ngưỡng CPU mục tiêu) — đây là phương án gần nhất và là một autoscaler có thật, nhưng VPA điều chỉnh tài nguyên CHO TỪNG POD, không thêm pod và không thêm node. Với một đợt tăng tải lớn, nó không tạo ra thêm năng lực tổng thể, và còn khởi động lại pod để áp giá trị mới.

• C (dựng thêm một cụm EKS và chia đều tải giữa hai cụm) — rất nhiều công: phải quản hai cụm, đồng bộ cấu hình, dựng cơ chế phân phối lưu lượng. Trái thẳng yêu cầu "ít công quản trị nhất".

• A (tạm chuyển ứng dụng từ EKS sang ECS rồi chuyển ngược lại) — công sức khổng lồ và rủi ro rất cao cho một đợt tăng tải tạm thời.

Ghi nhớ

⚠ Ba bộ autoscaler của Kubernetes — bảng phải thuộc: | Bộ | Co giãn cái gì | |---|---| | HPA | SỐ LƯỢNG POD — theo CPU, bộ nhớ, hoặc chỉ số tuỳ chỉnh | | VPA | TÀI NGUYÊN của mỗi pod — thường cần khởi động lại pod | | Cluster Autoscaler | SỐ LƯỢNG NODE — phản ứng với pod Pending | | Karpenter | node, nhưng thông minh hơn — chọn loại instance tối ưu | | Thực tế | HPA + Cluster Autoscaler dùng chung là mô hình phổ biến nhất |

Từ khoá nhận diện:

"cụm cần thêm năng lực, ít công nhất" → Cluster Autoscaler "pod nhiều lên khi tải cao" → HPA "pod thiếu bộ nhớ, cần chỉnh right-size" → VPA "khởi chạy node nhanh hơn, chọn loại tối ưu" → Karpenter "không muốn quản node nào cả" → Fargate cho EKS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có pod nào Pending không | kubectl get pods --all-namespaces \| grep Pending | | Autoscaler đang làm gì | kubectl logs -n kube-system deployment/cluster-autoscaler | | Node có tăng không | kubectl get nodes, và tab Activity của ASG |

Và một việc rất nên kiểm tra trước đợt tăng tải, ngoài chính autoscaler: hạn mức vCPU của tài khoản trong Region đó. Cluster Autoscaler có thể muốn thêm ba mươi node, nhưng nếu hạn mức chỉ đủ cho mười thì mọi node còn lại sẽ thất bại với InstanceLimitExceeded — và điều đó xảy ra đúng vào lúc lưu lượng đang lên đỉnh.

Đáp án

A — Tạo S3 GATEWAY ENDPOINT và cấu hình route table cho private subnet.

Vì sao đúng

Đề đã loại sẵn một nghi phạm: IAM role đã có đủ quyền. Nên vấn đề không nằm ở quyền, mà ở đường mạng.

⚠ Điểm mấu chốt — private subnet không có đường ra:

Máy ở PRIVATE subnet
        ↓
    Route table KHÔNG có tuyến 0.0.0.0/0
        ↓
    → gói tin tới S3 không biết đi đâu
    → kết nối TIMEOUT
        ↓
    IAM role đúng nhưng không dùng tới được
      vì request không bao giờ tới nơi

⚠ Gateway endpoint mở đường mà KHÔNG mở internet:

Tạo S3 gateway endpoint
        ↓
    Gắn vào route table của private subnet
        ↓
    Tự thêm tuyến:
      prefix list của S3  →  vpce-xxxxx
        ↓
    → lưu lượng đi trong mạng AWS
    → KHÔNG qua IGW, KHÔNG qua NAT
    → subnet vẫn hoàn toàn private
        ↓
    Và gateway endpoint MIỄN PHÍ

⚠ Vì sao đây là cách AN TOÀN NHẤT:

NAT Gateway (phương án C)
        ↓
    → mở đường ra TOÀN BỘ internet
    → máy gọi được mọi nơi, không chỉ S3
    → tăng bề mặt rủi ro
    → và tốn phí giờ + phí dữ liệu

Gateway endpoint
        ↓
    → chỉ mở đúng đường tới S3 CÙNG REGION
    → không mở gì thêm
    → miễn phí
        ↓
    → đề hỏi "MOST SECURELY" → chọn endpoint

Xem thêm câu #11884 (lô 129), #11971 (CÙNG LÔ) và #11852 (lô 128): cùng giải pháp gateway endpoint cho S3 từ private subnet. Khoá nhất quán ở cả bốn câu.

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

• C (tạo NAT gateway trong private subnet và cập nhật route table) — đây là phương án gần nhất và về kỹ thuật thì máy sẽ gọi được S3, nhưng nó mở đường ra toàn bộ internet — kém an toàn hơn hẳn, và tốn phí. (Ngoài ra NAT Gateway phải đặt ở PUBLIC subnet, không phải private — nó cần tuyến ra IGW để hoạt động.)

• B (thêm tuyến tới internet gateway trong route table của private subnet) — làm vậy biến private subnet thành public subnet, và máy không có IP công cộng thì vẫn không ra được. Kém an toàn nhất.

• D (thêm bucket policy cho phép IAM role truy cập) — đề đã nói role có đủ quyền. Thêm bucket policy không mở được đường mạng, nên kết nối vẫn timeout.

Ghi nhớ

⚠ Chẩn đoán "máy private không gọi được dịch vụ AWS" — bảng phải thuộc: | Triệu chứng | Nguyên nhân | Cách chữa | |---|---|---| | TIMEOUT | không có đường mạng | VPC endpoint, hoặc NAT | | AccessDenied | thiếu quyền | IAM policy, bucket policy, key policy | | Sai Region | endpoint không phục vụ | tạo endpoint đúng Region | | DNS không phân giải | enableDnsSupport tắt | bật DNS cho VPC |

Từ khoá nhận diện:

"private subnet cần gọi S3, an toàn nhất" → gateway endpoint "cần ra internet nói chung" → NAT Gateway "mạng tại chỗ cũng cần" → interface endpoint "giảm phí NAT" → gateway endpoint cho S3 và DynamoDB — MIỄN PHÍ "chỉ VPC này được truy cập bucket" → bucket policy + aws:sourceVpce

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint đã vào route table chưa | describe-route-tables, tìm vpce- | | Máy gọi được S3 chưa | trên máy: aws s3 ls s3://bucket | | Máy có ra internet được không | curl https://example.com — phải timeout |

Và một cách kiểm chứng gọn cho cam kết "máy không ra internet": chạy cả hai lệnh trên chính máy đó. Nếu aws s3 ls chạy được mà curl https://example.com treo rồi timeout, thì bạn đã có đúng thứ muốn — một máy tiếp cận được dữ liệu cần thiết mà không có đường nào ra thế giới bên ngoài.

Đáp án

D — Tạo MỘT gateway VPC endpoint dùng chung cho tất cả bucket và thêm nó vào route table của VPC.

Vì sao đúng

Đề có hai ràng buộc: miễn phí và mạng riêng. Gateway endpoint thoả cả hai, và quan trọng hơn — một endpoint phục vụ MỌI bucket S3 trong cùng Region.

⚠ Điểm mấu chốt — endpoint không gắn với từng bucket:

Gateway endpoint cho S3
        ↓
    Thêm một tuyến vào route table:
      prefix list của S3  →  vpce-xxxxx
        ↓
    Prefix list chứa TOÀN BỘ dải IP của S3
    trong Region đó
        ↓
    → mọi request tới BẤT KỲ bucket nào
      cùng Region đều đi qua endpoint này
        ↓
    → 100 bucket cũng chỉ cần MỘT endpoint

⚠ Và nó MIỄN PHÍ — đúng yêu cầu "cost-free":

Gateway endpoint (S3, DynamoDB)
        ↓
    Không phí theo giờ
    Không phí theo dữ liệu
        ↓
Interface endpoint
        ↓
    → CÓ phí giờ + phí GB
    → nên loại ngay khi đề nói "miễn phí"

Xem thêm câu #11884 (lô 129), #11971 và #11977 (lô 130): cùng giải pháp gateway endpoint cho S3 từ VPC. Khoá nhất quán ở cả bốn câu.

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

• B (tạo một gateway endpoint cho MỖI bucket, gắn vào từng subnet) — đây là phương án gần nhất và đúng loại endpoint, nhưng endpoint không tạo theo từng bucket: nó tạo theo dịch vụ (com.amazonaws.<region>.s3). Và gateway endpoint gắn vào route table, không phải vào subnet.

• A và C (interface endpoint) — có phí theo giờ và theo dữ liệu, vi phạm yêu cầu miễn phí. (Phương án C còn sai thêm: interface endpoint tạo ENI trong subnet, không thêm vào route table.)

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Chi phí | MIỄN PHÍ | phí giờ + phí GB | | Cơ chế | tuyến trong route table | ENI có IP riêng trong subnet | | Phạm vi | MỘT endpoint phục vụ MỌI bucket cùng Region | theo từng dịch vụ | | Từ mạng tại chỗ | KHÔNG | được qua VPN/DX |

Từ khoá nhận diện:

"S3 riêng tư, MIỄN PHÍ" → gateway endpoint "mạng tại chỗ cũng cần" → interface endpoint "chỉ VPC này được truy cập bucket" → bucket policy + aws:sourceVpce "giảm phí NAT" → gateway endpoint cho S3 và DynamoDB "bucket ở Region khác" → gateway endpoint KHÔNG phục vụ được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint đã vào route table chưa | describe-route-tables, tìm vpce- | | Máy gọi được S3 chưa | trên máy: aws s3 ls s3://bucket | | Lưu lượng có ra internet không | VPC Flow Logs |

Và một chi tiết đáng nhớ về cách endpoint hoạt động: nó nằm ở tầng ĐỊNH TUYẾN, không ở tầng tài nguyên. Đó là lý do một endpoint duy nhất phục vụ được cả trăm bucket — và cũng là lý do bạn không bao giờ thấy tuỳ chọn "chọn bucket" khi tạo nó.

Đáp án

C — PrivateDnsName không đặt được từ mẫu CloudFormation

Vì sao đúng

PrivateDnsName là thuộc tính chỉ đọc do AWS sinh ra khi tạo network interface hoặc instance — nó suy ra từ địa chỉ IP riêng được cấp. Khai nó như một thuộc tính đầu vào trong mẫu sẽ khiến CloudFormation từ chối ngay ở bước kiểm tra và stack không tạo được.

Đọc được giá trị đó thì dùng Fn::GetAtt sau khi tài nguyên đã tạo xong; ghi vào thì không.

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

• A. Thiếu mục Outputs — Outputs là tuỳ chọn; thiếu nó stack vẫn tạo bình thường.
• B. Thiếu mục Parameters — cũng tuỳ chọn.
• D. Không khai VPC — nhiều tài nguyên suy ra VPC từ subnet, nên thiếu khai VPC tường minh không nhất thiết làm hỏng stack.

Nhớ nhanh

Trong CloudFormation, chỉ có Resources là bắt buộc. Mọi mục khác đều tuỳ chọn.

Đáp án

D — Network ACL của subnet không cho lưu lượng đi ra

Vì sao đúng

Điểm mấu chốt vẫn là NACL không giữ trạng thái. Yêu cầu từ mạng nội bộ đi vào đã tới được instance, nghĩa là chiều vào đã thông. Nhưng gói trả lời đi ra dùng cổng tạm (thường trong dải 1024–65535), và nếu NACL chưa có luật cho chiều ra ở dải cổng đó thì phản hồi bị chặn — ứng dụng trông như treo chứ không báo lỗi rõ ràng.

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

• A. Security group của EC2 thiếu luật cho chiều vào — nếu vậy thì gói đã không tới được instance ngay từ đầu.
• B. Security group của NLB — Network Load Balancer không có security group theo cách như ALB; lưu lượng được đánh giá ở security group của target.
• C. ACL phía mạng nội bộ chặn — chiều đi đã thông nên phía đó không phải vấn đề.

Đáp án

A — Quy tắc EventBridge lọc sự kiện và dùng API destination làm đích

Vì sao đúng

Đề cần đưa sự kiện sang hệ thống của một công ty khác, tức là một endpoint HTTP nằm ngoài AWS. API destination của EventBridge sinh ra đúng cho việc này: bạn khai endpoint bên ngoài cùng thông tin xác thực (lưu trong Secrets Manager), và EventBridge tự gọi tới đó khi có sự kiện khớp mẫu, kèm thử lại và giới hạn tốc độ.

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

• B. Kinesis data stream làm đích — luồng nằm trong AWS; hệ thống bên kia vẫn phải tự viết consumer để đọc.
• C. Amazon SNS làm đích — SNS gửi được tới endpoint HTTP, nhưng thiếu phần quản lý xác thực và thử lại mà API destination lo sẵn.
• D. Step Functions làm đích — điều phối quy trình bên trong AWS, thêm một tầng không cần thiết.

Đáp án

D và E — mô tả load balancer, và gọi hàm Lambda

Vì sao đúng

Khi đọc một chính sách IAM để suy ra hành động nào được phép, quy tắc là: hành động phải khớp cả tên hành động lẫn tài nguyên lẫn điều kiện trong một câu Allow, và không bị câu Deny nào chạm tới.

Hai hành động này thoả cả hai vế. Đáng chú ý là elasticloadbalancing:Describe* thuộc nhóm chỉ đọc và không hỗ trợ giới hạn theo tài nguyên — nó luôn phải khai Resource: "*", điều khiến nhiều người tưởng chính sách viết sai.

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

• A. Tạo Storage Gateway, B. Tạo vai IAM cho Lambda, C. Xoá hàng đợi SQS — mỗi hành động này hoặc không có câu Allow nào phủ tới, hoặc bị Deny chặn.

Nhớ nhanh

iam:CreateRole là quyền rất mạnh — nó cho phép người dùng tự nâng quyền cho mình, nên hầu như luôn bị tách riêng khỏi các quyền vận hành thông thường.

Đáp án

B và E — bật chuyển tiếp cookie ở CloudFront, và cho ALB dùng cookie theo ứng dụng

Vì sao đúng

Ứng dụng có trạng thái nên phiên làm việc phụ thuộc vào cookie, và bị đăng xuất sớm nghĩa là cookie phiên không tới được đúng máy chủ. Hai chỗ phải sửa nằm ở hai tầng:

• B. CloudFront chuyển tiếp cookie — mặc định CloudFront không chuyển tiếp cookie xuống origin; thiếu cấu hình này thì ALB không bao giờ thấy cookie phiên.
• E. Cookie theo ứng dụng ở ALB — cho phép thời hạn phiên do chính ứng dụng quyết định, thay vì bị cookie theo thời lượng của ALB cắt ngang trước hạn 15 phút.

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

• A. Đổi sang thuật toán ít yêu cầu tồn đọng nhất — cách phân phối tải, không liên quan tới việc giữ phiên.
• C. Đặt tên cookie theo thời lượng là AWSALB — đó là tên do ALB tự đặt, không phải thứ bạn khai.
• D. Cho ALB dùng header cookie hết hạn — không phải một tuỳ chọn cấu hình có thật.