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

Tìm thấy 1356 câu.

Câu 91 Chọn nhiều đáp án Troubleshooting and Optimization

A data analytics company is processing real-time Internet-of-Things (IoT) data via Kinesis Producer Library (KPL) and sending the data to a Kinesis Data Streams driven application. The application has halted data processing because of a ProvisionedThroughputExceeded exception.

Which of the following actions would help in addressing this issue? (Select two)

  1. A

    Increase the number of shards within your data streams to provide enough capacity
  2. B

    Configure the data producer to retry with an exponential backoff
  3. C

    Use Amazon Kinesis Agent instead of Kinesis Producer Library (KPL) for sending data to Kinesis Data Streams
  4. D

    Use Amazon SQS instead of Kinesis Data Streams
  5. E

    Use Kinesis enhanced fan-out for Kinesis Data Streams
Xem giải thích

Đáp án

A và B.

  • A — Tăng số shard trong data stream để có đủ năng lực.
  • B — Cấu hình producer thử lại với exponential backoff.

Vì sao đúng

Lỗi ProvisionedThroughputExceeded nghĩa là vượt hạn mức của shard. Kinesis Data Streams (chế độ provisioned) đặt giới hạn cứng cho từng shard:

Chiều Giới hạn mỗi shard
Ghi 1 MB/giây hoặc 1.000 bản ghi/giây
Đọc 2 MB/giây, 5 lời gọi GetRecords/giây

Với dữ liệu IoT thời gian thực, chạm trần là chuyện tất yếu khi lưu lượng tăng.

A — tăng shard là cách chữa nguyên nhân gốc: năng lực của stream tỷ lệ thuận với số shard. Chia shard bằng SplitShard, hoặc dùng UpdateShardCount:

aws kinesis update-shard-count --stream-name iot-stream \
  --target-shard-count 8 --scaling-type UNIFORM_SCALING

B — retry với exponential backoff là cách xử lý triệu chứng tức thời: throttling thường mang tính tạm thời và cục bộ theo shard, nên chờ tăng dần rồi thử lại sẽ vượt qua được các đợt spike ngắn. KPL đã có sẵn cơ chế này, chỉ cần chỉnh RecordMaxBufferedTime và các tham số retry.

Hai biện pháp này bổ sung cho nhau: A giải quyết dài hạn, B giữ cho hệ thống không mất dữ liệu trong lúc chờ.

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

  • E. Enhanced fan-out — cải thiện phía đọc: cho mỗi consumer một đường 2 MB/giây riêng thay vì chia sẻ. Lỗi trong đề nằm ở phía ghi, nên không liên quan.
  • C. Dùng Kinesis Agent thay KPL — cả hai đều là công cụ đưa dữ liệu vào stream và chịu chung giới hạn shard. Đổi công cụ không tăng năng lực. (KPL thực ra còn tốt hơn cho thông lượng cao vì có gộp bản ghi — record aggregation.)
  • D. Dùng SQS thay Kinesis Data Streams — thay hẳn công nghệ, và mất những đặc tính đang cần: SQS không đảm bảo thứ tự (với standard queue), không cho nhiều consumer độc lập đọc cùng dữ liệu, và không phát lại được dữ liệu cũ.

Ghi nhớ

Ba cách xử lý throttling của Kinesis: | Cách | Khi nào | |---|---| | Tăng shard | tải tăng bền vững | | Retry + exponential backoff | spike ngắn, tạm thời | | On-demand mode | tải khó đoán — Kinesis tự co giãn, khỏi tính shard |

Và kiểm tra partition key: nếu key phân bố lệch, một shard sẽ nóng trong khi các shard khác nhàn rỗi — khi ấy tăng shard cũng không giúp được nhiều.

Câu 92 Troubleshooting and Optimization

A Developer is configuring Amazon EC2 Auto Scaling group to scale dynamically.

Which metric below is NOT part of Target Tracking Scaling Policy?

  1. A

    ALBRequestCountPerTarget
  2. B

    ASGAverageNetworkOut
  3. C

    ASGAverageCPUUtilization
  4. D

    ApproximateNumberOfMessagesVisible
Xem giải thích

Đáp án

D — ApproximateNumberOfMessagesVisible không phải metric dựng sẵn của target tracking scaling policy.

Vì sao đúng

Target tracking cho EC2 Auto Scaling có bốn metric dựng sẵn (predefined metric specification):

Metric dựng sẵn Đo
ASGAverageCPUUtilization CPU trung bình của nhóm
ASGAverageNetworkIn byte nhận trung bình
ASGAverageNetworkOut byte gửi trung bình
ALBRequestCountPerTarget số request mỗi target của ALB

ApproximateNumberOfMessagesVisible là metric của Amazon SQS, không phải của Auto Scaling. Nó không có trong danh sách predefined.

Điều đó không có nghĩa là không dùng được — nhưng phải khai dưới dạng customized metric specification, và trong thực tế nên tính thành backlog per instance trước:

backlogPerInstance = ApproximateNumberOfMessagesVisible / số instance đang chạy

Lý do phải chia: ApproximateNumberOfMessagesVisible là con số tuyệt đối, không phản ánh tải trên mỗi instance. Target tracking cần một chỉ số tỷ lệ nghịch với số instance thì mới hội tụ được — 1.000 message với 2 instance và 1.000 message với 50 instance là hai tình huống hoàn toàn khác nhau, nhưng metric thô cho cùng một giá trị.

Vì sao các phương án khác sai (tức là chúng đều là metric dựng sẵn)

  • A. ALBRequestCountPerTarget — rất hợp cho ứng dụng web đứng sau ALB.
  • B. ASGAverageNetworkOut — hợp cho workload nặng về truyền dữ liệu ra.
  • C. ASGAverageCPUUtilization — metric được dùng phổ biến nhất.

Ghi nhớ

Đặc điểm quan trọng của metric dùng cho target tracking: nó phải thay đổi tỷ lệ nghịch với số instance. Thêm instance thì giá trị phải giảm; bớt instance thì giá trị phải tăng.

Dùng được Không dùng được trực tiếp
CPU trung bình, request/target, backlog per instance tổng số message, tổng số request, dung lượng đĩa

Metric không có tính chất đó sẽ khiến chính sách không bao giờ hội tụ — nó cứ thêm instance mãi mà con số không đổi.

Câu 93 Troubleshooting and Optimization

The app development team at a social gaming mobile app wants to simplify the user sign up process for the app. The team is looking for a fully managed scalable solution for user management in anticipation of the rapid growth that the app foresees.

As a Developer Associate, which of the following solutions would you suggest so that it requires the LEAST amount of development effort?

  1. A

    Use Cognito User pools to facilitate sign up and user management for the mobile app
  2. B

    Use Cognito Identity pools to facilitate sign up and user management for the mobile app
  3. C

    Create a custom solution using Lambda and DynamoDB to facilitate sign up and user management for the mobile app
  4. D

    Create a custom solution using EC2 and DynamoDB to facilitate sign up and user management for the mobile app
Xem giải thích

Đáp án

A — Dùng Cognito User Pools cho việc đăng ký và quản lý người dùng.

Vì sao đúng

Yêu cầu: quản lý người dùng được quản lý hoàn toàn, có khả năng mở rộng, với ít công sức phát triển nhất.

Cognito user pool là thư mục người dùng được AWS quản lý, cho sẵn mọi thứ mà một ứng dụng di động cần:

Tính năng Có sẵn
Đăng ký, đăng nhập ✅
Xác minh email và SMS ✅
Quên mật khẩu, đổi mật khẩu ✅
MFA ✅
Đăng nhập qua Google, Facebook, Apple ✅
Hosted UI tuỳ biến được ✅
Phát và làm mới JWT ✅
Lambda trigger để chèn logic riêng ✅

Mở rộng: user pool hỗ trợ hàng triệu người dùng, không cần cấu hình gì thêm — đúng với "anticipation of rapid growth" trong đề.

Về chi phí: 50.000 người dùng hoạt động hằng tháng đầu tiên miễn phí, nên với ứng dụng đang khởi đầu thì gần như không tốn gì.

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

  • B. Cognito Identity Pools — đây là bẫy chính. Identity pool không phải thư mục người dùng: nó không lưu ai cả, không có đăng ký, không có mật khẩu. Việc của nó là đổi một danh tính đã được xác thực ở nơi khác lấy thông tin xác thực AWS tạm thời. Nó là bước sau user pool, không thay thế được.
  • C. Tự viết bằng Lambda và DynamoDB — phải tự cài đặt toàn bộ: băm mật khẩu an toàn, luồng xác minh email, mã đặt lại mật khẩu có hạn, chống brute force, MFA, quản lý phiên, phát và xác minh token. Đây là hàng nghìn dòng mã bảo mật nhạy cảm phải bảo trì mãi — trái thẳng "LEAST amount of development effort".
  • D. Tự viết bằng EC2 và DynamoDB — mọi vấn đề của C, cộng thêm việc phải tự quản máy chủ, vá hệ điều hành và tự lo mở rộng.

Ghi nhớ

User Pool Identity Pool
Là gì thư mục người dùng bộ đổi danh tính
Cho phép sign up, sign in, MFA, quên mật khẩu truy cập trực tiếp S3, DynamoDB…
Phát ra JWT thông tin xác thực AWS tạm thời

Câu thần chú: nghe thấy "sign up" hoặc "user management" ⇒ User Pool. Nghe thấy "truy cập tài nguyên AWS trực tiếp" ⇒ Identity Pool.

Và về mặt an toàn: đừng bao giờ tự viết hệ xác thực khi đã có dịch vụ được quản lý — đó là nơi dễ để lọt lỗ hổng nghiêm trọng nhất.

Câu 94 Development with AWS Services

A development team is working on an AWS Lambda function that accesses DynamoDB. The Lambda function must do an upsert, that is, it must retrieve an item and update some of its attributes or create the item if it does not exist.

Which of the following represents the solution with MINIMUM IAM permissions that can be used for the Lambda function to achieve this functionality?

  1. A

    dynamodb:GetRecords, dynamodb:PutItem, dynamodb:UpdateTable
  2. B

    dynamodb:UpdateItem, dynamodb:GetItem, dynamodb:PutItem
  3. C

    dynamodb:AddItem, dynamodb:GetItem
  4. D

    dynamodb:UpdateItem, dynamodb:GetItem
Xem giải thích

Đáp án

D — Chỉ cần dynamodb:UpdateItem và dynamodb:GetItem.

Vì sao đúng

Đề đòi quyền tối thiểu cho thao tác upsert: lấy item, cập nhật vài thuộc tính, hoặc tạo mới nếu chưa có.

Điểm mấu chốt: UpdateItem của DynamoDB VỐN ĐÃ là một upsert. Nếu item chưa tồn tại, nó tự tạo mới:

table.update_item(
    Key={'user_id': 'u-123'},
    UpdateExpression='SET diem = :d, capnhat = :t',
    ExpressionAttributeValues={':d': 500, ':t': int(time.time())})
# Item chưa có → DynamoDB TẠO MỚI với khoá và các thuộc tính này

Nên PutItem là thừa — và không chỉ thừa mà còn nguy hiểm: PutItem ghi đè toàn bộ item, xoá sạch những thuộc tính không được nêu trong lời gọi. Đúng loại lỗi âm thầm làm mất dữ liệu.

GetItem cần cho vế "retrieve an item" mà đề nêu tường minh.

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

  • B. Thêm dynamodb:PutItem — quyền thừa. Đây là điểm phân biệt duy nhất giữa B và D, và tiêu chí của đề là minimum IAM permissions. Cấp thừa một quyền ghi đè toàn bộ item là vi phạm cả nguyên tắc đặc quyền tối thiểu lẫn an toàn dữ liệu.
  • A. GetRecords, PutItem, UpdateTable — sai cả ba. GetRecords thuộc DynamoDB Streams, không phải để đọc item. UpdateTable là thao tác quản trị bảng (đổi throughput, thêm GSI) — cấp nó cho một hàm ứng dụng là lỗi phân quyền nghiêm trọng.
  • C. dynamodb:AddItem — API này không tồn tại. DynamoDB có PutItem, UpdateItem, DeleteItem, GetItem, Query, Scan, BatchWriteItem, BatchGetItem, TransactWriteItems, TransactGetItems — không có AddItem.

Ghi nhớ

Phân biệt hai thao tác ghi hay bị lẫn: | | PutItem | UpdateItem | |---|---|---| | Item chưa có | tạo mới | tạo mới | | Item đã có | GHI ĐÈ TOÀN BỘ — mất thuộc tính không nêu | chỉ sửa thuộc tính được nêu | | Dùng khi | thay hẳn item | cập nhật một phần (upsert) |

Quy tắc thực dụng: mặc định dùng UpdateItem. Chỉ dùng PutItem khi thực sự muốn thay toàn bộ item.

Câu 95 Development with AWS Services

As an AWS certified developer associate, you are working on an AWS CloudFormation template that will create resources for a company's cloud infrastructure. Your template is composed of three stacks which are Stack-A, Stack-B, and Stack-C. Stack-A will provision a VPC, a security group, and subnets for public web applications that will be referenced in Stack-B and Stack-C.

After running the stacks you decide to delete them, in which order should you do it?

  1. A

    Stack A, then Stack B, then Stack C
  2. B

    Stack A, Stack C then Stack B
  3. C

    Stack C then Stack A then Stack B
  4. D

    Stack B, then Stack C, then Stack A
Xem giải thích

Đáp án

D — Xoá theo thứ tự: Stack B → Stack C → Stack A.

Vì sao đúng

Stack-A xuất ra VPC, security group và subnet; Stack-B và Stack-C import những giá trị đó. Quan hệ phụ thuộc là:

Stack A (xuất VPC, SG, subnet)
   ↑ import      ↑ import
Stack B        Stack C

CloudFormation có một cơ chế bảo vệ rất cụ thể:

Không thể xoá một stack đang có output được stack khác import.

Nếu thử xoá Stack A trước, lệnh thất bại ngay với thông báo:

Export ABC cannot be deleted as it is in use by Stack-B, Stack-C

Nên nguyên tắc là: xoá các stack tiêu thụ trước, stack cung cấp sau cùng — tức là ngược lại với thứ tự tạo.

Giữa B và C thì thứ tự không quan trọng, vì chúng độc lập với nhau (cả hai chỉ phụ thuộc vào A). Nên "B rồi C" hay "C rồi B" đều đúng; phương án D chỉ nêu một thứ tự hợp lệ.

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

  • A. A → B → C và B. A → C → B — cả hai bắt đầu bằng Stack A, và bước đầu tiên đã thất bại.
  • C. C → A → B — xoá C được, nhưng Stack A vẫn không xoá được vì Stack B còn đang import.

Ghi nhớ

Ba ràng buộc của cross-stack reference: | Ràng buộc | Chi tiết | |---|---| | Không xoá được khi đang bị import | phải gỡ mọi stack tiêu thụ trước | | Không sửa được giá trị export đang bị import | phải bỏ import ở stack kia trước | | Phạm vi | cùng tài khoản + Region, không xuyên Region |

Ràng buộc thứ hai vừa là bảo vệ vừa là phiền toái: nó ngăn bạn vô tình phá hỏng stack khác, nhưng cũng khiến tái cấu trúc trở nên khó. Với dữ liệu cần chia sẻ linh hoạt hoặc xuyên Region, dùng SSM Parameter Store thay cho export/import.

So sánh với nested stack: ở đó quan hệ là cha–con, xoá stack cha là xoá cả cây — không có ràng buộc thứ tự nào vì CloudFormation tự lo.

Câu 96 Troubleshooting and Optimization

Recently in your organization, the AWS X-Ray SDK was bundled into each Lambda function to record outgoing calls for tracing purposes. When your team leader goes to the X-Ray service in the AWS Management Console to get an overview of the information collected, they discover that no data is available.

What is the most likely reason for this issue?

  1. A

    X-Ray only works with AWS Lambda aliases
  2. B

    Enable X-Ray sampling
  3. C

    Change the security group rules
  4. D

    Fix the IAM Role
Xem giải thích

Đáp án

D — Sửa IAM Role của hàm Lambda.

Vì sao đúng

Hàm Lambda có SDK X-Ray nhúng sẵn, nhưng không có dữ liệu nào tới X-Ray. Với Lambda, nguyên nhân gần như luôn nằm ở quyền của execution role.

Với Lambda, X-Ray daemon đã có sẵn trong môi trường thực thi — bạn không phải cài gì. Nhưng hàm vẫn cần quyền ghi segment lên dịch vụ X-Ray:

{
  "Effect": "Allow",
  "Action": ["xray:PutTraceSegments", "xray:PutTelemetryRecords"],
  "Resource": "*"
}

Cách nhanh nhất là gắn policy dựng sẵn AWSXRayDaemonWriteAccess.

Ngoài ra còn phải bật active tracing cho hàm — đây là bước thứ hai hay bị quên:

aws lambda update-function-configuration --function-name xu-ly \
  --tracing-config Mode=Active

# Hoặc trong SAM
Properties:
  Tracing: Active

Triệu chứng đặc trưng của việc thiếu quyền: hàm chạy bình thường, không lỗi gì (X-Ray SDK nuốt lỗi để không làm hỏng ứng dụng), nhưng console X-Ray trống trơn.

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

  • B. "Bật X-Ray sampling" — sampling quyết định bao nhiêu phần trăm request được ghi lại (mặc định: request đầu tiên mỗi giây + 5% số còn lại). Nó có thể giải thích "ít trace hơn mong đợi", nhưng không giải thích được "không có trace nào" — mặc định luôn lấy mẫu ít nhất một request mỗi giây.
  • C. Sửa rule của security group — chỉ liên quan khi hàm chạy trong VPC và cần đường ra tới endpoint X-Ray. Đề không nói gì về VPC, và đây không phải nguyên nhân phổ biến với Lambda.
  • A. "X-Ray chỉ hoạt động với Lambda alias" — bịa hoàn toàn. X-Ray theo dấu hàm bất kể được gọi qua $LATEST, qua version hay qua alias.

Ghi nhớ

Danh sách kiểm khi X-Ray không có dữ liệu, theo nền tảng: | Nền tảng | Cần | |---|---| | Lambda | IAM role có quyền X-Ray + bật Tracing: Active | | EC2 | cài daemon + instance profile có quyền | | ECS/Fargate | sidecar container chạy daemon + task role | | Beanstalk | bật X-Ray trong cấu hình môi trường |

Với Lambda, daemon đã có sẵn — nên hai thứ duy nhất cần kiểm là quyền và cờ tracing.

Câu 97 Troubleshooting and Optimization

An Accounting firm extensively uses Amazon EBS volumes for persistent storage of application data of Amazon EC2 instances. The volumes are encrypted to protect the critical data of the clients. As part of managing the security credentials, the project manager has come across a policy snippet that looks like the following:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Allow for use of this Key",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:role/UserRole"
            },
            "Action": [
                "kms:GenerateDataKeyWithoutPlaintext",
                "kms:Decrypt"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow for EC2 Use",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:role/UserRole"
            },
            "Action": [
                "kms:CreateGrant",
                "kms:ListGrants",
                "kms:RevokeGrant"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                "kms:ViaService": "ec2.us-west-2.amazonaws.com"
            }
        }
    ]
}

Which of the following options are correct regarding the policy?

  1. A

    The second statement in this policy provides the security group (mentioned in first statement of the policy), the ability to create, list, and revoke grants for Amazon EC2
  2. B

    The first statement provides the security group the ability to generate a data key and decrypt that data key from the CMK when necessary
  3. C

    The first statement provides a specified IAM principal the ability to generate a data key and decrypt that data key from the CMK when necessary
  4. D

    The second statement in the policy mentions that all the resources stated in the first statement can take the specified role which will provide the ability to create, list, and revoke grants for Amazon EC2
Xem giải thích

Đáp án

C — Statement thứ nhất cấp cho một IAM principal cụ thể khả năng sinh data key và giải mã data key đó bằng CMK.

Vì sao đúng

Đọc kỹ statement thứ nhất:

{
  "Sid": "Allow for use of this Key",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/UserRole"},   ← IAM ROLE
  "Action": ["kms:GenerateDataKeyWithoutPlaintext", "kms:Decrypt"],
  "Resource": "*"
}
Thành phần Ý nghĩa
Principal arn:...:role/UserRole — một IAM role, tức là một IAM principal
GenerateDataKeyWithoutPlaintext sinh data key (chỉ trả về bản mã, dùng cho envelope encryption)
Decrypt giải mã data key đó khi cần đọc dữ liệu

Đây chính là bộ quyền tối thiểu để EBS mã hoá volume: sinh data key lúc tạo volume, giải mã nó mỗi khi gắn volume vào instance.

Statement thứ hai bổ sung CreateGrant, ListGrants, RevokeGrant với điều kiện kms:ViaService: ec2.us-west-2.amazonaws.com — nghĩa là các quyền grant đó chỉ dùng được khi lời gọi đi qua dịch vụ EC2, không dùng trực tiếp được. Đây là mẫu bảo vệ rất hay: thu hẹp quyền theo dịch vụ trung gian.

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

  • B. "Cấp cho security group khả năng sinh data key" — sai đối tượng. Principal là một IAM role, không phải security group. Security group là cơ chế lọc mạng, hoàn toàn không xuất hiện trong IAM/KMS policy.
  • A. "Statement thứ hai cấp cho security group... khả năng tạo grant cho EC2" — cùng lỗi: không có security group nào trong policy này.
  • D. "Statement thứ hai nói rằng mọi tài nguyên nêu ở statement đầu có thể nhận role đó" — hiểu sai cấu trúc. Hai statement độc lập với nhau, cùng cấp quyền cho cùng một principal. Resource: "*" trong ngữ cảnh key policy nghĩa là chính CMK này, không phải "mọi tài nguyên ở statement trên".

Ghi nhớ

Hai chi tiết đáng giá trong policy này:

1. GenerateDataKey và GenerateDataKeyWithoutPlaintext: | API | Trả về | |---|---| | GenerateDataKey | bản rõ + bản mã của data key | | GenerateDataKeyWithoutPlaintext | chỉ bản mã — dùng khi chưa cần mã hoá ngay |

2. Điều kiện kms:ViaService — giới hạn việc dùng khoá chỉ qua một dịch vụ AWS cụ thể. Rất hữu ích: role có thể dùng khoá để EC2 mã hoá volume, nhưng không thể tự gọi KMS để giải mã bất cứ thứ gì khác.

Câu 98 Chọn nhiều đáp án Troubleshooting and Optimization

While troubleshooting, a developer realized that the Amazon EC2 instance is unable to connect to the Internet using the Internet Gateway.

Which conditions should be met for Internet connectivity to be established? (Select two)

  1. A

    The instance's subnet is not associated with any route table
  2. B

    The instance's subnet is associated with multiple route tables with conflicting configurations
  3. C

    The route table in the instance’s subnet should have a route to an Internet Gateway
  4. D

    The network ACLs associated with the subnet must have rules to allow inbound and outbound traffic
  5. E

    The subnet has been configured to be Public and has no access to the internet
Xem giải thích

Đáp án

C và D.

  • C — Route table của subnet phải có route trỏ tới Internet Gateway.
  • D — Network ACL của subnet phải có rule cho phép traffic cả vào lẫn ra.

Vì sao đúng

Để một EC2 instance ra được Internet qua Internet Gateway, cần bốn điều kiện — và câu hỏi nêu hai trong số đó:

Điều kiện Chi tiết
1. Route table có route 0.0.0.0/0 → igw-xxxxx ← C
2. Network ACL cho phép inbound và outbound ← D
3. Security group cho phép traffic cần thiết
4. Địa chỉ IP công khai public IP hoặc Elastic IP

Vì sao C. Đây là thứ định nghĩa một subnet là "public": route table gắn với nó có đường ra Internet Gateway:

Destination      Target
10.0.0.0/16      local
0.0.0.0/0        igw-0abc123      ← thiếu dòng này thì subnet là private

Vì sao D — và tại sao phải nhấn mạnh "cả hai chiều". NACL là stateless: nó xét từng gói tin độc lập, không ghi nhớ kết nối. Gói đi ra cần rule outbound, và gói phản hồi đi vào cần rule inbound trên dải ephemeral port (1024–65535). Chỉ mở một chiều là kết nối không bao giờ hoàn tất.

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

  • A. "Subnet không được gắn với route table nào" — không thể xảy ra. Mọi subnet luôn được gắn với một route table; nếu không gắn tường minh thì nó dùng main route table của VPC. AWS không cho phép subnet "mồ côi".
  • B. "Subnet gắn với nhiều route table có cấu hình mâu thuẫn" — cũng không thể xảy ra. Một subnet chỉ gắn được với đúng một route table tại một thời điểm. (Ngược lại thì được: một route table dùng chung cho nhiều subnet.)
  • E. "Subnet đã được cấu hình là Public nhưng không có truy cập Internet" — câu này tự mâu thuẫn: theo định nghĩa, subnet public là subnet có route tới Internet Gateway. Nó cũng không phải một "điều kiện cần được thoả" mà là một mô tả trạng thái.

Ghi nhớ

Security Group Network ACL
Mức ENI / instance subnet
Trạng thái stateful — nhớ kết nối stateless — xét từng gói
Rule chỉ Allow Allow và Deny
Đánh giá tất cả rule cộng lại theo số thứ tự, dừng ở rule khớp đầu tiên

Danh sách kiểm khi instance không ra được Internet: route table → NACL (cả hai chiều) → security group → có IP công khai chưa.

Câu 99 Security

A university has created a student portal that is accessible through a smartphone app and web application. The smartphone app is available in both Android and IOS and the web application works on most major browsers. Students will be able to do group study online and create forum questions. All changes made via smartphone devices should be available even when offline and should synchronize with other devices.

Which of the following AWS services will meet these requirements?

  1. A

    Cognito Identity Pools
  2. B

    Cognito User Pools
  3. C

    Cognito Sync
  4. D

    BeanStalk
Xem giải thích

Đáp án theo nguồn

C — Amazon Cognito Sync.

Vì sao nguồn chọn phương án này

Đề nêu ba yêu cầu rất đặc thù: dữ liệu người dùng phải dùng được khi ngoại tuyến, và phải tự đồng bộ giữa các thiết bị (Android, iOS, web) khi có mạng trở lại.

Cognito Sync là dịch vụ được thiết kế đúng cho mô hình đó:

  • Lưu dữ liệu người dùng dưới dạng dataset gồm các cặp khoá–giá trị (tối đa 1 MB mỗi dataset, 20 dataset mỗi danh tính)
  • SDK cache dữ liệu cục bộ trên thiết bị, nên ứng dụng đọc ghi bình thường khi không có mạng
  • Khi có mạng trở lại, SDK tự đồng bộ và giải quyết xung đột (mặc định: bản ghi mới nhất thắng, hoặc dùng Lambda tuỳ chỉnh)
  • Push synchronization báo cho các thiết bị khác của cùng người dùng biết có dữ liệu mới

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

  • B. Cognito User Pools — là thư mục người dùng: đăng ký, đăng nhập, MFA, phát JWT. Nó lưu thuộc tính hồ sơ của người dùng, nhưng không có cơ chế đồng bộ ngoại tuyến và không lưu dữ liệu ứng dụng.
  • A. Cognito Identity Pools — đổi danh tính đã xác thực lấy thông tin xác thực AWS tạm thời. Nó là điều kiện tiên quyết để dùng Cognito Sync (Sync gắn dữ liệu vào identity ID), nhưng bản thân nó không lưu và không đồng bộ dữ liệu.
  • D. Elastic Beanstalk — nền tảng triển khai ứng dụng, hoàn toàn không liên quan tới đồng bộ dữ liệu trên thiết bị.

Ghi nhớ về chất lượng câu hỏi

Câu này đã lỗi thời. AWS đã ngừng phát triển Cognito Sync và khuyến nghị chuyển sang AWS AppSync, vốn làm được mọi thứ Cognito Sync làm và nhiều hơn hẳn:

Cognito Sync AWS AppSync
Ngoại tuyến + đồng bộ ✅ ✅ (Amplify DataStore)
Giải quyết xung đột cơ bản cấu hình được nhiều chiến lược
Truy vấn dữ liệu chỉ khoá–giá trị GraphQL đầy đủ
Cập nhật thời gian thực push notification GraphQL subscription
Nguồn dữ liệu dataset riêng DynamoDB, RDS, Lambda, OpenSearch…

Với dự án mới, câu trả lời đúng là AppSync + Amplify DataStore. Hãy nhớ bài toán (ngoại tuyến + đồng bộ đa thiết bị) và nhận ra Cognito Sync khi gặp trong đề thi, nhưng đừng chọn nó cho thiết kế thật.

Câu 100 Troubleshooting and Optimization

As an AWS Certified Developer Associate, you have been hired to work with the development team at a company to create a REST API using the serverless architecture.

Which of the following solutions will you choose to move the company to the serverless architecture paradigm?

  1. A

    Public-facing Application Load Balancer with ECS on Amazon EC2
  2. B

    Route 53 with EC2 as backend
  3. C

    Fargate with Lambda at the front
  4. D

    API Gateway exposing Lambda Functionality
Xem giải thích

Đáp án

D — API Gateway phơi bày chức năng của Lambda.

Vì sao đúng

Yêu cầu: tạo REST API theo kiến trúc serverless.

API Gateway + Lambda là cặp serverless kinh điển, và cả hai đều thoả định nghĩa serverless đúng nghĩa:

Tiêu chí API Gateway + Lambda
Không quản máy chủ ✅
Tự co giãn về 0 ✅ không request thì không tốn tiền
Trả tiền theo lượng dùng thực ✅ theo request và theo GB-giây
Tự lo tính sẵn sàng cao ✅ đa AZ mặc định 
Client → API Gateway (định tuyến, xác thực, throttling) → Lambda (logic) → DynamoDB

API Gateway lo phần "API": định tuyến theo path và method, xác thực (Cognito/IAM/Lambda authorizer), throttling, cache, versioning qua stage. Lambda lo phần logic. Không có máy chủ nào trong toàn bộ đường đi.

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

  • A. ALB + ECS trên EC2 — không serverless: bạn phải quản cụm EC2 (vá, scale, giám sát), và trả tiền theo giờ instance kể cả khi không có request nào.
  • B. Route 53 với EC2 làm backend — càng xa serverless hơn: EC2 tự quản hoàn toàn, và Route 53 chỉ là DNS chứ không phải tầng API.
  • C. "Fargate với Lambda ở phía trước" — kiến trúc lộn ngược và vô lý. Fargate có bỏ được việc quản máy chủ, nhưng đặt Lambda làm cửa ngõ cho Fargate là dùng sai vai trò: Lambda không phải bộ định tuyến HTTP, không có throttling, không có quản lý stage, và có trần 15 phút. Nếu muốn container thì mô hình đúng là ALB → Fargate.

Ghi nhớ

Bộ dịch vụ serverless của AWS theo tầng: | Tầng | Dịch vụ | |---|---| | API | API Gateway, AppSync, Lambda Function URL | | Tính toán | Lambda, Fargate (gần serverless) | | Dữ liệu | DynamoDB, Aurora Serverless v2, S3 | | Nhắn tin | SQS, SNS, EventBridge | | Điều phối | Step Functions |

Hai lựa chọn API cần phân biệt: REST API (nhiều tính năng: cache, usage plan, request validation, WAF) và HTTP API (đơn giản hơn, rẻ hơn ~70%, độ trễ thấp hơn). Không cần tính năng nâng cao thì HTTP API là lựa chọn tốt hơn.