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

Tìm thấy 1356 câu.

Câu 341 Troubleshooting and Optimization

You are working with a t2.small instance bastion host that has the AWS CLI installed to help manage all the AWS services installed on it. You would like to know the security group and the instance id of the current instance.

Which of the following will help you fetch the needed information?

  1. A

    Query the metadata at http://169.254.169.254/latest/meta-data
  2. B

    Query the user data at http://254.169.254.169/latest/meta-data
  3. C

    Query the user data at http://169.254.169.254/latest/user-data
  4. D

    Create an IAM role and attach it to your EC2 instance that helps you perform a 'describe' API call
Xem giải thích

Đáp án

A — Truy vấn metadata tại http://169.254.169.254/latest/meta-data.

Vì sao đúng

Instance metadata service (IMDS) là một endpoint HTTP nội bộ, chỉ truy cập được từ chính instance đó, cung cấp thông tin về máy đang chạy:

# IMDSv2 — cần lấy token trước (khuyến nghị)
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/security-groups

Những gì lấy được từ metadata: | Đường dẫn | Nội dung | |---|---| | instance-id | ID của instance | | security-groups | tên các security group | | instance-type, ami-id | loại máy, AMI | | local-ipv4, public-ipv4 | địa chỉ IP | | placement/availability-zone | AZ | | iam/security-credentials/<role> | thông tin xác thực tạm thời của instance role |

Địa chỉ 169.254.169.254 là link-local address — nó không đi ra mạng, chỉ tồn tại trong phạm vi instance.

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

  • B. http://254.169.254.169/latest/meta-data — địa chỉ bị đảo ngược. Đúng là 169.254.169.254. Bẫy đánh vần điển hình.
  • C. Truy vấn user-data — user data là script hoặc cấu hình BẠN cung cấp lúc tạo instance. Nó không chứa thông tin về instance như ID hay security group.
  • D. Tạo IAM role rồi gọi describe API — làm được, nhưng vòng vo và kém hiệu quả: phải cấp quyền ec2:DescribeInstances, gọi API qua mạng, và bạn vẫn cần biết instance ID của chính mình — mà thông tin đó lại phải lấy từ metadata.

Ghi nhớ

Metadata User data
Là gì thông tin VỀ instance script/cấu hình BẠN cung cấp
Đường dẫn /latest/meta-data/ /latest/user-data
Ghi được ❌ ✅ (khi instance đã dừng)

Và cảnh báo bảo mật rất quan trọng: metadata endpoint chứa thông tin xác thực tạm thời của instance role. Một lỗ hổng SSRF trong ứng dụng có thể bị lợi dụng để lấy chúng. Cách phòng là bắt buộc IMDSv2 (yêu cầu token qua PUT, mà SSRF thường không thực hiện được):

aws ec2 modify-instance-metadata-options --instance-id i-xxx \
  --http-tokens required --http-put-response-hop-limit 1

hop-limit 1 còn ngăn container trên máy truy cập metadata của host.

Câu 342 Troubleshooting and Optimization

Applications running on EC2 instances process messages from an SQS queue but sometimes they experience errors due to messages not being processed.

To isolate the messages, which option will help with further debugging?

  1. A

    Increase the VisibilityTimeout
  2. B

    Implement a Dead Letter Queue
  3. C

    Use DeleteMessage
  4. D

    Reduce the VisibilityTimeout
Xem giải thích

Đáp án

B — Triển khai Dead Letter Queue (DLQ).

Vì sao đúng

Yêu cầu: cô lập những message xử lý hỏng để gỡ lỗi thêm.

Không có DLQ thì message hỏng quay vòng vô hạn: consumer nhận, xử lý thất bại, hết visibility timeout, message quay lại hàng đợi, và lặp lại cho tới khi hết MessageRetentionPeriod rồi biến mất không dấu vết. Trong lúc đó nó còn chiếm chỗ và làm chậm việc xử lý các message khoẻ mạnh.

Redrive policy đặt một ngưỡng: sau maxReceiveCount lần nhận không thành công, SQS chuyển message sang DLQ:

aws sqs set-queue-attributes --queue-url <url-chinh> \
  --attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"arn:aws:sqs:...:dlq\",\"maxReceiveCount\":\"3\"}"}'

Hai lợi ích đúng với đề:

  • Message hỏng được giữ nguyên vẹn để đọc, phân tích, tái hiện lỗi
  • Hàng đợi chính không còn bị nghẽn bởi message không bao giờ xử lý được

Sửa mã xong thì dùng redrive to source đẩy chúng ngược về hàng đợi chính xử lý lại.

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

  • A. Tăng VisibilityTimeout — cho consumer nhiều thời gian hơn để xử lý mỗi message. Hữu ích khi message bị phát lại vì xử lý chậm, nhưng message hỏng thật thì vẫn hỏng, chỉ hỏng chậm hơn. Và nó không cô lập gì cả.
  • D. Giảm VisibilityTimeout — đi ngược lại: message được phát lại nhanh hơn, quay vòng dày đặc hơn, làm tình hình tệ hơn.
  • C. Dùng DeleteMessage — xoá vĩnh viễn message. Nó "giải quyết" vấn đề nghẽn nhưng phá huỷ chính thứ cần điều tra — trái thẳng yêu cầu "isolate the messages for further debugging".

Ghi nhớ

Quy tắc về DLQ: | Quy tắc | Chi tiết | |---|---| | Cùng kiểu queue | FIFO → DLQ phải FIFO; standard → DLQ phải standard | | maxReceiveCount | thường đặt 3–5 | | Retention của DLQ | nên dài hơn hàng đợi chính | | Alarm | bắt buộc — đặt trên ApproximateNumberOfMessagesVisible của DLQ |

Điểm cuối quan trọng nhất về mặt vận hành: DLQ không có alarm thì cũng vô dụng như không có DLQ — message vào đó rồi nằm im, không ai biết.

(Lambda cũng có cơ chế tương tự cho lời gọi bất đồng bộ: on-failure destination — tốt hơn DLQ vì nó kèm cả ngữ cảnh lỗi và stack trace, không chỉ payload trần.)

Câu 343 Development with AWS Services

A media analytics company has built a streaming application on Lambda using Serverless Application Model (SAM).

As a Developer Associate, which of the following would you identify as the correct order of execution to successfully deploy the application?

  1. A

    Develop the SAM template locally => upload the template to Lambda => deploy your application to the cloud
  2. B

    Develop the SAM template locally => upload the template to S3 => deploy your application to the cloud
  3. C

    Develop the SAM template locally => upload the template to CodeCommit => deploy your application to CodeDeploy
  4. D

    Develop the SAM template locally => deploy the template to S3 => use your application in the cloud
Xem giải thích

Đáp án

B — Viết SAM template tại máy → tải lên S3 → triển khai ứng dụng lên cloud.

Vì sao đúng

Quy trình triển khai SAM có ba bước, và bước giữa là điểm phân biệt:

1. Viết template tại máy — khai hàm Lambda, API, bảng bằng cú pháp SAM rút gọn.

2. Đóng gói và tải lên S3 — bước bắt buộc, vì CloudFormation không đọc được đường dẫn cục bộ:

sam package --template-file template.yaml \
  --s3-bucket kho-artifact \
  --output-template-file packaged.yaml

Lệnh này nén mã, tải lên S3, và sinh ra template mới trong đó CodeUri: ./src đã thành CodeUri: s3://kho-artifact/a1b2c3....

3. Triển khai:

sam deploy --template-file packaged.yaml --stack-name ung-dung --capabilities CAPABILITY_IAM

S3 là điểm trung chuyển bắt buộc — đó là toàn bộ nội dung của câu hỏi.

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

  • A. "Tải template lên Lambda" — sai đối tượng. Lambda nhận mã hàm, không nhận template CloudFormation. Template được xử lý bởi CloudFormation, và mã nguồn phải nằm trên S3.
  • C. "Tải lên CodeCommit rồi deploy tới CodeDeploy" — nhầm vai trò cả hai dịch vụ. CodeCommit lưu mã nguồn (một hệ quản lý phiên bản), không phải nơi CloudFormation đọc artifact. Và CodeDeploy triển khai ứng dụng, không phải nơi nhận SAM template.
  • D. "Deploy template tới S3 → dùng ứng dụng trên cloud" — thiếu hẳn bước triển khai thật. Tải template lên S3 không tạo ra tài nguyên nào; phải có deploy để CloudFormation dựng stack.

Ghi nhớ

Hai bộ lệnh tương đương: | AWS CLI | SAM CLI | |---|---| | aws cloudformation package | sam package | | aws cloudformation deploy | sam deploy |

Trong thực tế, sam deploy --guided gộp cả hai và tự hỏi tham số cần thiết, rồi lưu vào samconfig.toml cho lần sau:

sam deploy --guided
# Hỏi: stack name, region, S3 bucket (tự tạo nếu chưa có), capabilities...

Và cho vòng lặp phát triển nhanh, dùng sam sync --watch thay vì deploy — nó gọi thẳng API của Lambda khi chỉ đổi mã, nhanh hơn hàng chục lần. (Chỉ dùng cho môi trường dev — nó làm stack bị drift.)

Câu 344 Development with AWS Services

You would like your Elastic Beanstalk environment to expose an HTTPS endpoint instead of an HTTP endpoint to get in-flight encryption between your clients and your web servers.

What must be done to set up HTTPS on Beanstalk?

  1. A

    Use a separate CloudFormation template to load the SSL certificate onto the Load Balancer
  2. B

    Create a config file in the .ebextensions folder to configure the Load Balancer
  3. C

    Configure Health Checks
  4. D

    Open up the port 80 for the security group
Xem giải thích

Đáp án

B — Tạo tệp .config trong thư mục .ebextensions để cấu hình Load Balancer.

Vì sao đúng

Trong Elastic Beanstalk, TLS được kết thúc ở Load Balancer — đó là mẫu chuẩn: load balancer giải mã, rồi chuyển traffic tới instance. Nhờ đó CPU của instance không phải làm việc mã hoá, và chứng chỉ quản lý ở một chỗ.

Cách cấu hình chính thống là qua .ebextensions:

# .ebextensions/https-listener.config
option_settings:
  aws:elbv2:listener:443:
    Protocol: HTTPS
    SSLCertificateArns: arn:aws:acm:ap-southeast-1:123456789012:certificate/xxxx
    SSLPolicy: ELBSecurityPolicy-TLS13-1-2-2021-06
  aws:elbv2:listener:80:
    Protocol: HTTP
    Rules: redirect-to-https        # chuyển hướng HTTP sang HTTPS

Ba đặc điểm khiến .ebextensions là cách đúng: | Đặc điểm | Chi tiết | |---|---| | Nằm trong mã nguồn | version control được, review được | | Tự áp dụng ở mọi lần deploy | không phải nhớ cấu hình lại | | Áp cho môi trường mới | dựng lại môi trường là có ngay |

Chứng chỉ lấy từ ACM — miễn phí cho chứng chỉ công cộng và tự gia hạn, bỏ hẳn nguy cơ sập vì quên gia hạn.

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

  • A. Dùng một CloudFormation template riêng để nạp chứng chỉ — vòng vo và dễ lệch: Beanstalk vốn đã chạy trên CloudFormation bên dưới, và nó quản lý stack của mình. Sửa từ ngoài bằng một template riêng sẽ bị ghi đè ở lần cập nhật môi trường tiếp theo. (Muốn thêm tài nguyên CloudFormation thì cũng khai ngay trong .ebextensions bằng khoá Resources.)
  • C. Cấu hình Health Checks — health check quyết định instance nào được coi là lành. Hoàn toàn không liên quan tới TLS.
  • D. Mở cổng 80 cho security group — cổng 80 là HTTP, không phải HTTPS. HTTPS dùng cổng 443. (Thực tế nên mở cả hai — 443 cho traffic thật, 80 để chuyển hướng — nhưng bản thân việc mở cổng không cấu hình được TLS.)

Ghi nhớ

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

Ba quy tắc về vị trí: thư mục phải tên đúng .ebextensions, nằm ở gốc gói mã nguồn, tệp phải có đuôi .config. Chúng chạy theo thứ tự bảng chữ cái — nên hay đánh số ở đầu tên.

Câu 345 Development with AWS Services

Your organization has a single Amazon Simple Storage Service (S3) bucket that contains folders labeled with customer names. Several administrators have IAM access to the S3 bucket and versioning is enabled to easily recover from unintended user actions.

Which of the following statements about versioning is NOT true based on this scenario?

  1. A

    Any file that was unversioned before enabling versioning will have the 'null' version
  2. B

    Overwriting a file increases its versions
  3. C

    Deleting a file is a recoverable operation
  4. D

    Versioning can be enabled only for a specific folder
Xem giải thích

Đáp án

Câu hỏi tìm phát biểu KHÔNG đúng — đáp án là D: "Versioning chỉ bật được cho một thư mục cụ thể."

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

S3 versioning là thiết lập ở MỨC BUCKET, không phải mức thư mục hay mức object:

aws s3api put-bucket-versioning --bucket kho-khach-hang \
  --versioning-configuration Status=Enabled

Bật là áp cho toàn bộ bucket — mọi object, mọi prefix. Không có cách nào bật cho khach-hang-a/ mà không bật cho khach-hang-b/.

Ngoài ra, "thư mục" trong S3 không tồn tại thật — chúng chỉ là prefix trong tên khoá. khach-hang-a/hop-dong.pdf là một object với khoá đầy đủ như vậy, không phải một tệp nằm trong một thư mục.

Muốn phân biệt hành vi theo prefix thì dùng lifecycle rule (có Filter.Prefix), nhưng versioning thì không.

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

  • A. "Tệp chưa có phiên bản trước khi bật versioning sẽ có version ID là null" — đúng. Object đã tồn tại được gán version ID đặc biệt null. Ghi đè chúng sau đó sẽ tạo version ID thật, và bản null vẫn giữ lại.
  • B. "Ghi đè một tệp làm tăng số phiên bản" — đúng. Mỗi lần PutObject cùng khoá tạo ra một version ID mới, và bản cũ vẫn còn.
  • C. "Xoá một tệp là thao tác khôi phục được" — đúng, và đây là điểm mạnh nhất của versioning: DeleteObject không xoá thật, nó đặt một delete marker lên trên. Xoá delete marker đó là object hiện trở lại.

Ghi nhớ

Ba trạng thái versioning của bucket — và một điểm không thể đảo ngược: | Trạng thái | Chi tiết | |---|---| | Unversioned | mặc định, trạng thái ban đầu | | Enabled | mọi thay đổi tạo version mới | | Suspended | KHÔNG quay lại unversioned được — version cũ vẫn giữ, version mới nhận ID null |

Vài lưu ý thực tế về chi phí và an toàn:

  • Mọi version đều tính tiền lưu trữ — nên luôn kèm lifecycle rule xoá version cũ sau N ngày
  • MFA Delete (chỉ root bật được) chống xoá vĩnh viễn version
  • Versioning là điều kiện bắt buộc cho S3 Replication và Object Lock
Câu 346 Security

You were assigned to a project that requires the use of the AWS CLI to build a project with AWS CodeBuild. Your project's root directory includes the buildspec.yml file to run build commands and would like your build artifacts to be automatically encrypted at the end.

How should you configure CodeBuild to accomplish this?

  1. A

    Use an AWS Lambda Hook
  2. B

    Use In Flight encryption (SSL)
  3. C

    Specify a KMS key to use
  4. D

    Use the AWS Encryption SDK
Xem giải thích

Đáp án

C — Chỉ định một KMS key để dùng.

Vì sao đúng

CodeBuild có thiết lập mã hoá artifact dựng sẵn — chỉ cần khai KMS key trong cấu hình project:

aws codebuild update-project --name du-an \
  --artifacts type=S3,location=kho-artifact,encryptionDisabled=false \
  --encryption-key arn:aws:kms:ap-southeast-1:123456789012:key/xxxx

Hoặc trong CloudFormation:

Resources:
  DuAn:
    Type: AWS::CodeBuild::Project
    Properties:
      EncryptionKey: !GetAtt KhoaMaHoa.Arn
      Artifacts:
        Type: S3
        Location: !Ref KhoArtifact
        EncryptionDisabled: false

CodeBuild tự mã hoá artifact khi ghi ra S3, hoàn toàn trong suốt — không phải viết mã, không phải thêm bước nào vào buildspec.yml.

Hai chi tiết đáng biết:

  • CodeBuild mặc định đã mã hoá artifact bằng AWS managed key (aws/s3). Chỉ định CMK riêng khi cần kiểm soát khoá và có vết CloudTrail cho từng lần dùng.
  • Service role của CodeBuild phải có quyền kms:GenerateDataKey và kms:Decrypt trên khoá đó — thiếu là build thất bại ở bước cuối.

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

  • D. Dùng AWS Encryption SDK — thư viện để ứng dụng tự mã hoá dữ liệu. Nó đòi viết mã trong buildspec để mã hoá artifact trước khi xuất — tự làm lại thứ CodeBuild đã có sẵn.
  • B. Dùng in-flight encryption (SSL) — bảo vệ dữ liệu khi truyền, không phải khi lưu. Và HTTPS vốn đã là mặc định của mọi endpoint AWS.
  • A. "Dùng AWS Lambda Hook" — CodeBuild không có khái niệm Lambda hook. Nó có phase trong buildspec (install, pre_build, build, post_build) và khối finally, không có hook gọi Lambda.

Ghi nhớ

Các thiết lập mã hoá của CodeBuild: | Thiết lập | Tác dụng | |---|---| | EncryptionKey | KMS key mã hoá artifact | | EncryptionDisabled | đặt true để tắt mã hoá (hiếm khi nên dùng) | | Cache trên S3 | cũng được mã hoá bằng cùng khoá | | CloudWatch Logs | mã hoá riêng qua associate-kms-key |

Và quyền tối thiểu mà mọi CodeBuild project cần: CloudWatch Logs (CreateLogGroup, CreateLogStream, PutLogEvents), S3 (đọc nguồn, ghi artifact), và KMS (GenerateDataKey, Decrypt) nếu dùng CMK.

Câu 347 Troubleshooting and Optimization

A developer is configuring the redirect actions for an Application Load Balancer. The developer stumbled upon the following snippet of code.

Which of the following is an example of a query string condition that the developer can use on AWS CLI?

  1. A 
    [
  {
      "Field": "query-string",
      "PathPatternConfig": {
          "Values": ["/img/*"]
      }
  }
]
  2. B 
    [
  {
      "Field": "query-string",
      "StringHeaderConfig": {
          "Values": ["*.example.com"]
      }
  }
]
  3. C 
    [
  {
      "Type": "redirect",
      "RedirectConfig": {
          "Protocol": "HTTPS",
          "Port": "443",
          "Host": "#{host}",
          "Path": "/#{path}",
          "Query": "#{query}",
          "StatusCode": "HTTP_301"
      }
  }
]
  4. D 
    [
  {
      "Field": "query-string",
      "QueryStringConfig": {
          "Values": [
            {
                "Key": "version",
                "Value": "v1"
            },
            {
                "Value": "*example*"
            }
          ]
      }
  }
]
Xem giải thích

Đáp án

D — Điều kiện dùng QueryStringConfig với danh sách cặp Key/Value.

Vì sao đúng

ALB có năm loại điều kiện định tuyến, và mỗi loại có một khối cấu hình riêng với tên tương ứng:

Field Khối cấu hình
host-header HostHeaderConfig
path-pattern PathPatternConfig
http-header HttpHeaderConfig
http-request-method HttpRequestMethodConfig
query-string QueryStringConfig
source-ip SourceIpConfig

Nên với "Field": "query-string", khối bắt buộc là QueryStringConfig.

Và cấu trúc của nó đặc biệt hơn các loại khác: Values là mảng các đối tượng với Key và Value, không phải mảng chuỗi:

[{
  "Field": "query-string",
  "QueryStringConfig": {
    "Values": [
      {"Key": "version", "Value": "v1"},    ← khớp ?version=v1
      {"Value": "*example*"}                 ← khớp giá trị bất kỳ chứa "example"
    ]
  }
}]

Bỏ Key thì ALB khớp giá trị ở bất kỳ tham số nào. Ký tự đại diện * và ? dùng được ở cả Key lẫn Value.

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

  • A. "Field": "query-string" nhưng dùng PathPatternConfig — không khớp: PathPatternConfig chỉ đi với "Field": "path-pattern". ALB sẽ từ chối cấu hình.
  • B. "Field": "query-string" với StringHeaderConfig — khối này không tồn tại. Tên đúng cho header là HttpHeaderConfig.
  • C. — đây không phải một condition mà là một action ("Type": "redirect" với RedirectConfig). Nó là phần "làm gì", không phải phần "khi nào". Đề hỏi về condition.

Ghi nhớ

Cấu trúc một listener rule của ALB gồm ba phần:

{
  "Priority": 10,
  "Conditions": [ ... ],     ← KHI NÀO áp dụng
  "Actions":    [ ... ]      ← LÀM GÌ
}

Các action dùng được: forward (tới target group), redirect (301/302), fixed-response (trả nội dung tĩnh), authenticate-cognito, authenticate-oidc.

Mẹo nhớ tên khối: tên Field viết theo kiểu gạch nối, tên khối viết theo kiểu CamelCase với hậu tố Config — path-pattern → PathPatternConfig, query-string → QueryStringConfig.

Và biến thay thế trong RedirectConfig cũng đáng biết: #{protocol}, #{host}, #{path}, #{query}, #{port}.

Câu 348 Chọn nhiều đáp án Development with AWS Services

A new recruit is trying to understand the nuances of EC2 Auto Scaling. As an AWS Certified Developer Associate, you have been asked to mentor the new recruit.

Can you identify and explain the correct statements about Auto Scaling to the new recruit? (Select two).

  1. A

    You cannot use Amazon EC2 Auto Scaling for health checks (to replace unhealthy instances) if you are not using Elastic Load Balancing (ELB)
  2. B

    Every time you create an Auto Scaling group from an existing instance, it creates a new AMI (Amazon Machine Image)
  3. C

    EC2 Auto Scaling groups are regional constructs. They span across Availability Zones and AWS regions
  4. D

    Amazon EC2 Auto Scaling cannot add a volume to an existing instance if the existing volume is approaching capacity
  5. E

    Amazon EC2 Auto Scaling works with both Application Load Balancers and Network Load Balancers
Xem giải thích

Đáp án

D và E.

  • D — EC2 Auto Scaling không thể thêm volume vào instance đang tồn tại khi volume hiện tại sắp đầy.
  • E — EC2 Auto Scaling hoạt động với cả Application Load Balancer lẫn Network Load Balancer.

Vì sao đúng

D — Auto Scaling chỉ mở rộng theo chiều ngang. Đây là điểm hay bị hiểu nhầm: Auto Scaling thêm hoặc bớt INSTANCE, nó không sửa đổi instance đang chạy:

Auto Scaling làm được Không làm được
Thêm/bớt instance thêm dung lượng EBS cho máy đang chạy
Thay instance không lành đổi instance type của máy đang chạy
Phân bố giữa các AZ thêm bộ nhớ hay CPU

Muốn xử lý đĩa sắp đầy thì phải dùng công cụ khác: EBS Elastic Volumes (mở rộng volume tại chỗ, không dừng máy) hoặc CloudWatch alarm + SSM Automation để tự động mở rộng.

E — hỗ trợ cả ALB và NLB. Auto Scaling gắn được với mọi loại load balancer: Classic Load Balancer (qua LoadBalancerNames), và ALB / NLB / Gateway Load Balancer (qua TargetGroupARNs). Đây là mô tả đúng và đầy đủ.

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

  • C. "Auto Scaling group trải qua nhiều AZ VÀ nhiều Region" — sai vế Region. ASG là tài nguyên theo Region: nó trải được trên nhiều AZ trong cùng một Region, nhưng không bao giờ xuyên Region. Muốn có nhiều Region thì tạo ASG riêng ở mỗi nơi rồi định tuyến bằng Route 53 hoặc Global Accelerator.
  • A. "Không dùng được health check để thay instance nếu không có ELB" — sai. Auto Scaling có health check type EC2 (mặc định), dựa trên status check của EC2 — hoạt động hoàn toàn độc lập với ELB. Health check type ELB chỉ là tuỳ chọn bổ sung, nhạy hơn vì nó phát hiện được cả lỗi ứng dụng.
  • B. "Mỗi lần tạo ASG từ một instance có sẵn thì nó tạo một AMI mới" — sai. Tạo ASG từ instance có sẵn sẽ sinh ra một launch configuration hoặc launch template dựa trên cấu hình của instance đó, không tạo AMI mới — nó dùng chính AMI mà instance đang chạy.

Ghi nhớ

Phạm vi các tài nguyên hay bị nhầm: | Phạm vi | Ví dụ | |---|---| | Toàn cầu | IAM, Route 53, CloudFront | | Theo Region | Auto Scaling group, ELB, VPC, AMI, key pair | | Theo AZ | Subnet, EBS volume, EC2 instance |

Và hai loại health check của ASG: | Loại | Kiểm tra | Mặc định | |---|---|---| | EC2 | status check của EC2 — máy có chạy không | ✅ | | ELB | health check của load balancer — ứng dụng có phục vụ không | phải bật |

Với health check mặc định, ứng dụng chết mà máy vẫn bật thì ASG coi là khoẻ mạnh — nên production nên đổi sang ELB.

Câu 349 Security

An analytics company is using Kinesis Data Streams (KDS) to process automobile health-status data from the taxis managed by a taxi ride-hailing service. Multiple consumer applications are using the incoming data streams and the engineers have noticed a performance lag for the data delivery speed between producers and consumers of the data streams.

As a Developer Associate, which of the following options would you suggest for improving the performance for the given use-case?

  1. A

    Use Enhanced Fanout feature of Kinesis Data Streams
  2. B

    Swap out Kinesis Data Streams with SQS Standard queues
  3. C

    Swap out Kinesis Data Streams with Kinesis Data Firehose
  4. D

    Swap out Kinesis Data Streams with SQS FIFO queues
Xem giải thích

Đáp án

A — Dùng tính năng Enhanced Fan-Out của Kinesis Data Streams.

Vì sao đúng

Manh mối quyết định: nhiều ứng dụng consumer cùng đọc stream, và có độ trễ giữa producer và consumer.

Nguyên nhân nằm ở cách consumer tiêu chuẩn hoạt động: mọi consumer CHIA CHUNG 2 MB/giây mỗi shard:

Shard: 2 MB/giây tổng cộng
  ├─ Consumer A: ~0,67 MB/giây
  ├─ Consumer B: ~0,67 MB/giây
  └─ Consumer C: ~0,67 MB/giây     ← càng nhiều consumer càng chậm

Và 5 lời gọi GetRecords/giây cũng chia chung — với 3 consumer thì mỗi bên chỉ gọi được ~1,6 lần/giây, tức là độ trễ khoảng 600 ms trở lên.

Enhanced Fan-Out cho mỗi consumer một đường 2 MB/giây RIÊNG:

Shard
  ├─ Consumer A: 2 MB/giây riêng
  ├─ Consumer B: 2 MB/giây riêng
  └─ Consumer C: 2 MB/giây riêng

Và nó đổi hẳn mô hình truyền: từ polling (GetRecords) sang push qua HTTP/2 (SubscribeToShard), nên độ trễ giảm từ ~200 ms xuống khoảng 70 ms.

aws kinesis register-stream-consumer \
  --stream-arn arn:aws:kinesis:...:stream/xe-taxi \
  --consumer-name ung-dung-phan-tich

Đánh đổi: có phí thêm theo consumer-shard-giờ và theo dữ liệu đọc ra. Tối đa 20 consumer đăng ký mỗi stream.

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

  • C. Thay bằng Kinesis Data Firehose — Firehose nạp vào một đích (S3, Redshift, OpenSearch) và gom theo lô ~60 giây. Nó không cho nhiều consumer độc lập và chậm hơn, không nhanh hơn.
  • B. Thay bằng SQS Standard queue — mỗi message chỉ tới một consumer; không thể có nhiều ứng dụng cùng đọc toàn bộ dữ liệu. Và không phát lại được.
  • D. Thay bằng SQS FIFO queue — cùng vấn đề với B, cộng thêm thông lượng thấp hơn nhiều (300 msg/giây).

Ghi nhớ

Consumer tiêu chuẩn Enhanced Fan-Out
Băng thông 2 MB/giây CHIA CHUNG 2 MB/giây MỖI consumer
Mô hình polling (GetRecords) push (SubscribeToShard)
Độ trễ ~200 ms ~70 ms
Số consumer không giới hạn (nhưng chia nhau) tối đa 20
Chi phí không thêm có phí

Nhận dạng nhanh: nhiều consumer + độ trễ ⇒ Enhanced Fan-Out. Một consumer duy nhất mà chậm ⇒ vấn đề nằm ở chỗ khác (số shard, partition key lệch, hoặc consumer xử lý chậm).

Câu 350 Troubleshooting and Optimization

An e-commerce company uses Amazon SQS queues to decouple their application architecture. The development team has observed message processing failures for an edge case scenario when a user places an order for a particular product ID, but the product ID is deleted, thereby causing the application code to fail.

As a Developer Associate, which of the following solutions would you recommend to address such message failures?

  1. A

    Use a temporary queue to handle message processing failures
  2. B

    Use a dead-letter queue to handle message processing failures
  3. C

    Use long polling to handle message processing failures
  4. D

    Use short polling to handle message processing failures
Xem giải thích

Đáp án

B — Dùng dead-letter queue để xử lý các message thất bại.

Vì sao đúng

Tình huống trong đề là ví dụ hoàn hảo của poison message: một message mà mã ứng dụng không bao giờ xử lý được — sản phẩm đã bị xoá nên tra cứu luôn thất bại.

Không có DLQ, message đó quay vòng vô hạn:

Nhận → xử lý thất bại → hết visibility timeout → quay lại hàng đợi → lặp lại
... cho tới khi hết MessageRetentionPeriod (tối đa 14 ngày) rồi biến mất

Trong suốt thời gian đó nó chiếm chỗ và làm chậm việc xử lý các đơn hàng bình thường.

Redrive policy cắt vòng lặp đó:

aws sqs set-queue-attributes --queue-url <url-don-hang> \
  --attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"arn:aws:sqs:...:don-hang-dlq\",\"maxReceiveCount\":\"3\"}"}'

Sau 3 lần thất bại, message chuyển sang DLQ — hàng đợi chính thông thoáng trở lại, và message hỏng được giữ nguyên vẹn để đội phát triển phân tích.

Với edge case như trong đề, DLQ còn cho một thứ quý: danh sách cụ thể những trường hợp mã chưa xử lý được — dữ liệu đầu vào rất tốt để sửa lỗi.

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

  • A. "Dùng temporary queue" — Temporary Queue Client của SQS là thư viện dựng hàng đợi ngắn hạn cho mẫu request-response, tự xoá khi không dùng. Nó không liên quan gì tới việc xử lý message hỏng.
  • C. Long polling — giảm số lời gọi API rỗng và giảm chi phí. Nó không ảnh hưởng gì tới việc message có xử lý được hay không.
  • D. Short polling — hành vi mặc định, còn tốn kém hơn long polling. Cũng không liên quan tới message hỏng.

Ghi nhớ

Quy tắc về DLQ: | Quy tắc | Chi tiết | |---|---| | Cùng kiểu queue | FIFO → DLQ phải FIFO; standard → DLQ phải standard | | maxReceiveCount | thường 3–5 | | Retention của DLQ | nên dài hơn hàng đợi chính | | Alarm trên DLQ | bắt buộc — không có thì message vào đó rồi nằm im | | Redrive to source | đẩy ngược về hàng đợi chính sau khi sửa mã |

Nguyên tắc lớn hơn: mọi hàng đợi production đều phải có DLQ. Không có nó, một message hỏng có thể làm nghẽn cả hệ thống, và bạn mất luôn bằng chứng để gỡ lỗi.