Ngân hàng đề — AWS Certified DevOps Engineer Professional
Tìm thấy 681 câu.
A retail company uses the open-source tool Jenkins on its on-premise infrastructure to perform CICD. It has decided to move to AWS and take advantage of the elasticity properties of the cloud provider to have more efficient workloads. It needs to ensure the Jenkins setup is highly available, fault-tolerant and also elastic to perform builds. The company has hired you as an AWS Certified DevOps Engineer Professional to build the most cost-effective solution for this requirement.
Which of the following solutions would you recommend?
-
A
Deploy Jenkins as a multi-master setup across multiple AZ. Create an Auto Scaling Group made of EC2 instances that are Jenkins slave. Configure Jenkins to launch build on these slaves
-
B
Deploy Jenkins as a multi-master setup across multiple AZ. Enable the CodeBuild Plugin for Jenkins so that builds are launched as CodeBuild builds
-
C
Deploy Jenkins as a multi-master setup across one AZ, managed by an Auto Scaling Group. Enable the CodeBuild Plugin for Jenkins so that builds are launched as CodeBuild builds
-
D
Deploy Jenkins as a multi-master setup across one AZ, managed by an Auto Scaling Group. Configure Jenkins to launch build on these slaves
Xem giải thích
Đáp án
B — Triển khai Jenkins ở chế độ multi-master trải trên nhiều AZ, và bật plugin CodeBuild để các bản dựng được chạy dưới dạng CodeBuild build
Vì sao đúng
Đề nêu bốn yêu cầu, và phương án này thoả cả bốn:
| Yêu cầu | Cách đáp ứng |
|---|---|
| Sẵn sàng cao và chịu lỗi | Multi-master trải trên nhiều AZ — mất một AZ vẫn còn master khác |
| Co giãn để chạy build | CodeBuild tự cấp phát năng lực cho từng bản dựng |
| Tiết kiệm nhất | CodeBuild tính tiền theo phút build thật sự, không có máy nào chạy không |
Vế cuối là chỗ quyết định. Với đội EC2 làm Jenkins slave, bạn trả tiền cho instance kể cả lúc không có build nào — và nếu để Auto Scaling co về 0 thì lại phải chờ máy khởi động. CodeBuild bỏ hẳn đánh đổi đó.
Vì sao các phương án khác sai
- A. Multi-master nhiều AZ nhưng dùng đội EC2 làm Jenkins slave — sẵn sàng cao thì đạt, nhưng kém tiết kiệm hơn vì phải nuôi đội slave. Đây là phương án nhiễu chính.
- C và *D. Multi-master trong một AZ — cả hai hỏng ở cùng chỗ: một AZ là một điểm hỏng duy nhất, nên không đạt yêu cầu chịu lỗi, dù có Auto Scaling. Chữ "across one AZ" là chỗ loại chúng.
A graphics design company is experimenting with a new feature for an API and the objective is to pass the field "color" in the JSON payload to enable this feature. The new Lambda function should treat "color": "none" as a request from an older client. The company would like to only have to manage one Lambda function in the back-end while being able to support both old and new clients. The API Gateway API is currently deployed on the v1 stage. Old clients include Android applications which may take time to be updated. The technical requirements mandate that the solution should support the old clients for years to come.
As an AWS Certified DevOps Engineer Professional, which of the following options would you recommend as the best fit for the given use-case?
-
A
Create a new Lambda function version and release it. Use API Gateway mapping documents to add a default value
"color": "none"to the JSON request being passed on your API Gateway stage -
B
Create a new Lambda function version and release it. Create a new API Gateway Stage and deploy it to the
v2stage. Both use the same Lambda function as a backing route for thev1andv2stages. Add a static mapping on thev1route to add"color": "none"on requests -
C
Enable API Gateway
v1API caching and delete thev1AWS Lambda function. Deploy av2API Gateway backed by a newly releasedv2AWS Lambda function. Add an API Gateway stage variable to enable the"color": "none"default value -
D
Create a new Lambda function version and release it as a separate
v2function. Create a new API Gateway Stage and deploy it to thev2stage. Thev1API gateway stage points to thev1Lambda function and thev2API Gateway stage to thev2Lambda function. Implement redirection from the Lambdav1function to the Lambdav2function when the request is missing the"color"field
Xem giải thích
Đáp án
B — Phát hành phiên bản Lambda mới, tạo stage v2 của API Gateway; cả hai stage v1 và v2 cùng trỏ tới một hàm Lambda, và dùng mapping để thêm giá trị mặc định cho stage v1
Vì sao đúng
Đề đặt ba ràng buộc, và chúng cùng nhau chỉ về đúng một kiến trúc:
- Chỉ quản lý một hàm Lambda ở backend — loại mọi phương án tạo hai hàm.
- Hỗ trợ cả client cũ lẫn mới — client Android cũ không gửi trường
color. - Hỗ trợ client cũ trong nhiều năm tới — nên giải pháp phải bền, không phải bản vá tạm.
Cách làm: hàm Lambda mới xử lý trường color, và coi "color": "none" là tín hiệu của client cũ. Phía API Gateway, mapping template ở stage v1 tự chèn "color": "none" vào mọi yêu cầu:
Client cũ → stage v1 → mapping thêm "color":"none" → Lambda (một hàm duy nhất)
Client mới → stage v2 → truyền nguyên payload →
Nhờ vậy client cũ không phải cập nhật gì mà vẫn chạy, và bạn chỉ bảo trì một hàm.
Vì sao các phương án khác sai
- D. Tạo hàm v2 riêng biệt, v1 stage trỏ tới hàm v1 và v2 stage trỏ tới hàm v2 — vi phạm ràng buộc chỉ quản lý một hàm; bạn sẽ phải vá lỗi ở hai nơi trong nhiều năm. Đây là phương án nhiễu chính.
- A. Chỉ dùng mapping trên stage hiện tại, không tạo stage v2 — không có đường cho client mới gửi giá trị
colorthật, vì mapping sẽ ghi đè nó. - C. Bật caching cho v1 rồi xoá hàm v1 — xoá backend của client cũ; chúng hỏng ngay.
The DevOps team at an analytics company is deploying an Apache Kafka cluster that contains 6 instances and is distributed across 3 Availability Zones (AZs). Apache Kafka is a stateful service and needs to store its data in an EBS volume. Therefore each instance must have the auto-healing capability and always attach the correct EBS volumes.
As an AWS Certified DevOps Engineer Professional, which of the following solutions would you suggest for the given requirement?
-
A
Create a CloudFormation template with an ASG of min/max capacity of 1, and an EBS volume. Tag the ASG and EBS volume. Create a User Data script that will acquire the EBS volume at boot time. Use a master CloudFormation template and reference the nested template 6 times
-
B
Create 6 EC2 instances using CloudFormation with EBS volumes. Define the attachments in the CloudFormation template. If the EC2 instance is terminated, launch a drift detection in CloudFormation and then use CloudFormation remediation
-
C
Create 6 EC2 instances using CloudFormation with EBS volumes. Define the attachments in the CloudFormation template. If the EC2 instance is terminated, it will be automatically re-created by CloudFormation with the correct EBS attachment
-
D
Create an Auto Scaling Group in CloudFormation with a min/max desired capacity of 6 instances spread across 3 AZs, and 6 EBS volumes also across the 3 AZs. Create a user data script so that instances launching from the ASG automatically acquire an available EBS volume in the corresponding AZ
Xem giải thích
Đáp án
A — Mỗi node là một Auto Scaling Group riêng với min/max = 1, kèm một EBS volume có gắn thẻ; user-data script tự tìm và gắn đúng volume lúc khởi động; dùng một template mẹ để tạo sáu bộ như vậy
Vì sao đúng
Đề đòi hai thứ cho một dịch vụ có trạng thái như Kafka: tự phục hồi và luôn gắn đúng EBS volume.
Mẫu "ASG một instance" là cách chuẩn để đạt điều đó:
ASG (min=1, max=1, desired=1) ← bảo đảm LUÔN có đúng một node
│ node chết → ASG tự tạo node mới
▼
User-data script khởi động:
1. Đọc thẻ của chính mình để biết mình là broker số mấy
2. Gọi API tìm EBS volume có thẻ tương ứng
3. Gắn volume đó vào
Vì sao phải một ASG cho mỗi node thay vì một ASG sáu node: Kafka broker không thay thế cho nhau được — mỗi broker có định danh riêng và dữ liệu riêng. Một ASG sáu node sẽ không biết node mới tạo ra phải thay cho broker nào, nên không gắn đúng volume được.
Ràng buộc kỹ thuật cần nhớ: EBS volume chỉ gắn được vào instance trong cùng Availability Zone, nên mỗi ASG phải bị khoá vào đúng một AZ.
Vì sao các phương án khác sai
- D. Một ASG với sáu instance trải trên ba AZ, kèm sáu volume — instance mới không biết mình phải lấy volume nào, và có thể được tạo ở AZ không có volume trống. Đây là phương án nhiễu chính.
- B và C. Tạo sáu EC2 instance thẳng trong CloudFormation — không có cơ chế tự phục hồi: instance bị kết thúc thì CloudFormation không tự tạo lại (drift detection chỉ phát hiện chứ không sửa).
A multi-national retail company has defined tagging guidelines and standard for all its resources in AWS and would like to create a dashboard to visualize the compliance of all the resources with the ability to find out the non-compliant resources. The company has hired you as an AWS Certified DevOps Engineer Professional to develop a solution for this requirement.
Which of the following options would you suggest to address the use-case?
-
A
Use SSM to track resource groups without tags. Export that data using SSM inventory into S3, and build a QuickSight dashboard
-
B
Use AWS Service Catalog to get an inventory of all the resources in your account. Use the integrated dashboard feature to track compliance
-
C
Track all your resources with AWS CloudTrail. Output the data in S3 and create a Quicksight dashboard
-
D
Use AWS Config to track resources in your account. Use SNS to stream changes to a Lambda function that writes to S3. Create a QuickSight dashboard on top of it
Xem giải thích
Đáp án
D — Dùng AWS Config theo dõi tài nguyên, đẩy thay đổi qua SNS tới một Lambda ghi vào S3, rồi dựng bảng điều khiển QuickSight trên đó
Vì sao đúng
Đề đòi hai thứ: bảng trực quan hoá mức tuân thủ về thẻ, và tìm ra được tài nguyên không tuân thủ.
AWS Config là công cụ đúng cho phần đánh giá: nó có Config Rule dựng sẵn required-tags, đánh giá liên tục mọi tài nguyên và đánh dấu cái nào thiếu thẻ theo chuẩn.
Phần còn lại là đường ống đưa dữ liệu sang QuickSight:
AWS Config (đánh giá tuân thủ)
▼ SNS
Lambda → ghi kết quả vào S3
▼
QuickSight (bảng điều khiển)
Bạn cần đường ống này vì QuickSight không đọc trực tiếp được từ Config; nó cần dữ liệu ở dạng truy vấn được (S3 kèm Athena, hoặc một cơ sở dữ liệu).
Với công ty đa quốc gia, Config còn có aggregator gom kết quả từ nhiều tài khoản và Region.
Vì sao các phương án khác sai
- C. Theo dõi tài nguyên bằng CloudTrail — CloudTrail ghi lời gọi API, tức là hành động đã xảy ra; nó không cho biết trạng thái hiện tại của tài nguyên. Muốn biết tài nguyên nào đang thiếu thẻ, bạn phải tự dựng lại trạng thái từ toàn bộ lịch sử API. Đây là phương án nhiễu chính.
- A. Dùng SSM Inventory — thu thập thông tin về phần mềm trên EC2 instance; phạm vi hẹp hơn nhiều so với "mọi tài nguyên".
- B. Dùng AWS Service Catalog để lấy inventory và theo dõi tuân thủ — Service Catalog quản lý danh mục sản phẩm được duyệt; nó không kiểm kê được tài nguyên tạo ngoài catalog.
As a DevOps Engineer at an IT company, you are looking to create a daily EBS backup workflow. That workflow must take an EBS volume, and create a snapshot from it. When the snapshot is created, it must be copied to another region. In case the other region is unavailable because of a disaster, then that backup should be copied to a third region. An email address must be notified of the final result. There's a requirement to keep an audit trail of all executions as well.
How can you implement this efficiently and in a fail-safe way?
-
A
Create a CloudWatch Event rule that gets triggered every day. It triggers a Lambda function written in Python that performs all the steps and logic outlined above. Analyze the history of execution using AWS Config
-
B
Create an AWS Step Function. Implement each step as a Lambda function and add failure logic between the steps to deal with conditional cases
-
C
Create an EC2 instance in the region where the EBS volume is. Create a CRON script that will invoke a Python script that performs all the steps and logic outlined above. For each step completion, write metadata to a DynamoDB table
-
D
Create an SSM Automation that will perform each action. Add failure logic between steps to deal with conditional cases
Xem giải thích
Đáp án
B — Dựng một AWS Step Functions state machine, mỗi bước là một hàm Lambda, và thêm logic xử lý lỗi giữa các bước để lo các nhánh điều kiện
Vì sao đúng
Đề mô tả một quy trình nhiều bước có nhánh điều kiện, kèm yêu cầu an toàn khi lỗi và có lịch sử kiểm toán:
Tạo snapshot từ EBS volume
▼
Chép sang Region 2
▼ nếu Region 2 không khả dụng
Chép sang Region 3
▼
Gửi email thông báo kết quả cuối
Step Functions là công cụ đúng vì nó cho ba thứ mà một script không có:
- Xử lý lỗi khai báo được —
Retryvới giãn cách tăng dần vàCatchđể rẽ nhánh, viết ngay trong định nghĩa state machine thay vì lồngtry/except. - Lịch sử thực thi đầy đủ — mỗi lần chạy được lưu lại từng bước một kèm đầu vào và đầu ra; đây chính là "audit trail" mà đề yêu cầu.
- Không có máy chủ nào và bạn thấy được sơ đồ trạng thái trực quan.
Vì sao các phương án khác sai
- A. Một hàm Lambda duy nhất làm hết mọi bước — hỏng ở hai chỗ: chép snapshot xuyên Region có thể mất hơn 15 phút (trần của Lambda), và logic thử lại phải tự viết. Phương án còn nói dùng AWS Config để xem lịch sử thực thi — sai dịch vụ. Đây là phương án nhiễu chính.
- C. Chạy cron script trên EC2 — máy chạy 24/7 cho một việc mỗi ngày, và bạn tự lo mọi thứ.
- D. Dùng SSM Automation — làm được các quy trình vận hành, nhưng khả năng rẽ nhánh và xử lý lỗi kém linh hoạt hơn Step Functions cho luồng có điều kiện như thế này.
The engineering team at a multi-national retail company is deploying its flagship web application onto an Auto Scaling Group (ASG) using CodeDeploy. The team has chosen a strategy of a rolling update so that instances are updated in small batches in the ASG. At the end of the deployment, the ASG has five instances running. It seems that three instances are running the new version of the application, while the other two are running the old version. CodeDeploy is reporting a successful deployment.
As a DevOps Engineer, what is the most likely reason that you would attribute for this issue?
-
A
A CloudWatch alarm has been triggered during the deployment
-
B
Two instances are having an IAM permissions issue and cannot download the new code revision from S3
-
C
Two new instances were created during the deployment due to an Auto Scaling scale out event
-
D
The auto-scaling group launch configuration has not been updated
Xem giải thích
Đáp án
C — Hai instance mới được tạo ra trong lúc triển khai do một sự kiện scale out của Auto Scaling
Vì sao đúng
Đây là hiện tượng đã biết khi kết hợp CodeDeploy với Auto Scaling group, và nó giải thích trọn vẹn ba dữ kiện của đề: ba máy chạy bản mới, hai máy chạy bản cũ, mà CodeDeploy vẫn báo thành công.
Chuỗi sự việc:
1. CodeDeploy bắt đầu triển khai lên 3 instance đang có
2. Giữa chừng, ASG scale out và tạo thêm 2 instance
3. Hai instance mới khởi chạy từ launch template với bản mã CŨ
4. CodeDeploy hoàn tất trên đúng 3 instance nó biết → báo THÀNH CÔNG
Điểm mấu chốt: CodeDeploy chỉ chịu trách nhiệm cho tập instance tại thời điểm bắt đầu; máy sinh ra sau đó nằm ngoài phạm vi lần triển khai đó.
Cách xử lý: tạm dừng tiến trình scale out của ASG trong lúc triển khai, hoặc dùng deployment group được cấu hình đúng để CodeDeploy tự triển khai lên instance mới sau khi xong.
Vì sao các phương án khác sai
- D. Launch configuration của ASG chưa được cập nhật — đây đúng là nguyên nhân sâu xa khiến máy mới mang mã cũ, nhưng nó không giải thích được vì sao CodeDeploy báo thành công. Đây là phương án nhiễu chính, và nó chỉ đúng một nửa.
- B. Hai instance gặp lỗi quyền IAM nên không tải được mã từ S3 — nếu vậy thì CodeDeploy sẽ báo thất bại cho hai instance đó.
- A. Một cảnh báo CloudWatch bị kích hoạt trong lúc triển khai — sẽ dẫn tới dừng hoặc quay lui, không dẫn tới báo thành công.
A social media company is running its flagship application via an Auto-Scaling group (ASG) which has 15 EC2 instances spanning across 3 Availability Zones (AZs). The current average CPU utilization of the group sits at 15% off-peak time. During peak time, it goes all the way to 45%, and these peak times happen predictably during business hours. The company has hired you as an AWS Certified DevOps Engineer Professional to build a solution for this requirement.
How can you improve the instance utilization while reducing cost and maintaining application availability?
-
A
Create a scaling policy that tracks the CPU utilization with a target of 75%. Create a scheduled action that invokes a Lambda function which will terminate 9 instances after peak times
-
B
Create a scaling policy that tracks the CPU utilization with a target of 75%. Create a scheduled action that increases the number of minimum instances to 6 during peak times and a second scheduled action that reduces the number of minimum instances to 3 off-peak times
-
C
Use a CloudFormation UpdatePolicy to define how the Auto Scaling Group should behave off and on peaks. Ensure the ASG invokes the CloudFormation using SNS notifications relay
-
D
Create a Lambda function that terminates 9 instances at the end of business hours. Create a second Lambda function that creates instances when peak time starts. Schedule the functions using CloudWatch Events
Xem giải thích
Đáp án
B — Tạo scaling policy theo dõi CPU với mục tiêu 75%, cộng hai scheduled action: tăng số instance tối thiểu lên 6 vào giờ cao điểm và giảm xuống ngoài giờ
Vì sao đúng
Vấn đề trong đề là cấp phát thừa nghiêm trọng: 15 instance mà CPU chỉ 15% ngoài giờ cao điểm và 45% lúc cao điểm. Nghĩa là phần lớn năng lực nằm không suốt ngày.
Phép tính cho thấy quy mô lãng phí:
15 instance × 45% CPU ≈ công việc thật của khoảng 9 instance chạy ở 75%
15 instance × 15% CPU ≈ công việc thật của khoảng 3 instance chạy ở 75%
Giải pháp kết hợp hai cơ chế, mỗi cơ chế lo một phần:
- Target tracking ở mức 75% — nâng mức sử dụng lên gần ngưỡng hợp lý, để Auto Scaling tự điều chỉnh số máy theo tải thật.
- Scheduled action — vì đề nói giờ cao điểm đoán trước được (theo giờ làm việc), việc nâng số tối thiểu trước bảo đảm năng lực đã sẵn sàng khi tải tới, thay vì phải chờ máy khởi động.
Chi tiết quan trọng: scheduled action điều chỉnh số instance tối thiểu, không phải huỷ máy trực tiếp — nên nó phối hợp được với target tracking thay vì đánh nhau với nó.
Vì sao các phương án khác sai
- *A. Scheduled action gọi Lambda để kết thúc 9 instance — can thiệp thẳng vào instance sẽ khiến ASG tạo lại chúng ngay để giữ đúng desired capacity. Hai cơ chế đánh nhau. Đây là phương án nhiễu chính.
- D. Dùng hai hàm Lambda tự tạo và huỷ instance theo lịch — bỏ qua hoàn toàn Auto Scaling, mất khả năng phản ứng với tải bất thường.
- C. Dùng CloudFormation UpdatePolicy để định nghĩa hành vi ASG theo giờ —
UpdatePolicyđiều khiển cách ASG được cập nhật khi stack thay đổi, không phải cơ chế co giãn theo lịch.
An e-commerce company is managing its entire application stack and infrastructure using AWS OpsWorks Stacks. The DevOps team at the company has noticed that a lot of instances have been automatically replaced in the stack and the team would henceforth like to be notified via Slack notifications when these events happen.
As an AWS Certified DevOps Engineer Professional, which of the following options would you implement to meet this requirement?
-
A
Create a CloudWatch Events rule for
aws.opsworksand set theinitiated_byfield toauto-healing. Target a Lambda function that will send notifications out to the Slack channel -
B
Create a CloudWatch Events rule for
aws.opsworksand set theinitiated_byfield toauto-scaling. Enable the CloudWatch Event Slack integration for sending out the notifications -
C
Create a CloudWatch Events rule for
aws.opsworksand set theinitiated_byfield toauto-scaling. Target a Lambda function that will send notifications out to the Slack channel -
D
Subscribe your OpsWorks auto-healing notifications to an SNS topic. Subscribe a Lambda function that will send notifications out to the Slack channel
Xem giải thích
Đáp án
A — Tạo CloudWatch Events rule cho aws.opsworks với trường initiated_by là auto-healing, nhắm tới một hàm Lambda gửi thông báo sang Slack
Vì sao đúng
Câu này kiểm tra hai chi tiết, và cả hai phải đúng.
Thứ nhất — giá trị của initiated_by. OpsWorks Stacks có tính năng auto-healing: khi một instance ngừng gửi tín hiệu tới dịch vụ trong khoảng năm phút, OpsWorks tự dừng và khởi chạy lại nó. Sự kiện sinh ra mang initiated_by = auto-healing.
Đây chính là hiện tượng đề mô tả — "nhiều instance bị thay thế tự động".
Thứ hai — cách gửi sang Slack. CloudWatch Events (nay là EventBridge) không có tích hợp Slack sẵn; bạn phải nhắm tới một hàm Lambda để gọi webhook của Slack.
Vì sao các phương án khác sai
- C. Cùng kiến trúc nhưng đặt
initiated_by = auto-scaling— sai giá trị: auto-scaling là sự kiện co giãn theo tải hoặc theo lịch, không phải thay thế instance hỏng. Đây là phương án nhiễu chính, và nó chỉ khác đáp án đúng ở một chuỗi ký tự. - B. Sai
initiated_byvà dùng "tích hợp Slack của CloudWatch Event" — sai cả hai vế; tích hợp đó không tồn tại. - D. Đăng ký thông báo auto-healing của OpsWorks vào một SNS topic — OpsWorks Stacks không phát thông báo trực tiếp ra SNS theo cách này; đường đi chuẩn là qua CloudWatch Events.
The DevOps team at a financial services company is deploying the flagship application in highly available mode using Elastic Beanstalk which has created an ASG and an ALB. The team has also specified a .ebextensions file to create an associated DynamoDB table. As a DevOps Engineer in the team, you would like to perform an update to the application but you need to make sure the DNS name won't change and that no new resources will be created. The application needs to remain available during the update.
Which of the following options would you suggest to address the given requirements?
-
A
Use immutable
-
B
Use in-place
-
C
Use a rolling update with 20% at a time
-
D
Use a blue/green deployment and swap CNAMEs
Xem giải thích
Đáp án
C — Dùng rolling update với 20% mỗi lần
Vì sao đúng
Đề đặt ba ràng buộc, và chúng cùng nhau loại hết các lựa chọn khác:
- Tên DNS không được đổi — loại Blue/Green.
- Không được tạo tài nguyên mới — loại immutable.
- Ứng dụng phải luôn sẵn sàng — loại in-place toàn bộ.
Rolling update là chiến lược duy nhất thoả cả ba: nó cập nhật lần lượt từng lô instance đang có, trong cùng environment. Không có instance mới nào được tạo, environment không đổi nên CNAME giữ nguyên, và luôn còn 80% số máy đang phục vụ.
Chi tiết .ebextensions tạo bảng DynamoDB trong đề càng củng cố: nếu tạo environment mới thì DynamoDB table cũng bị tạo mới, gây rắc rối về dữ liệu.
Vì sao các phương án khác sai
- A. Immutable — tạo một Auto Scaling group hoàn toàn mới với instance mới, rồi chuyển sang. Nó an toàn nhất nhưng vi phạm ràng buộc "không tạo tài nguyên mới". Đây là phương án nhiễu chính vì immutable thường là khuyến nghị mặc định.
- D. Blue/Green kèm hoán đổi CNAME — tạo hẳn environment thứ hai và đổi CNAME; vi phạm cả hai ràng buộc đầu.
- B. In-place — cập nhật tất cả instance cùng lúc, nên có khoảng thời gian ứng dụng không phục vụ được.
A media streaming solutions company has deployed an application that allows its customers to view movies in real-time. The application connects to an Amazon Aurora database, and the entire stack is currently deployed in the United States. The company has plans to expand to Europe and Asia for its operations. It needs the movies table to be accessible globally but needs the users and movies_watched table to be regional only.
As a DevOps Engineer, how would you implement this with minimal application refactoring?
-
A
Use a DynamoDB Global Table for the
moviestable and use Amazon Aurora for theusersandmovies_watchedtables -
B
Use an Amazon Aurora Global Database for the
moviestable and use DynamoDB for theusersandmovies_watchedtables -
C
Use an Amazon Aurora Global Database for the
moviestable and use Amazon Aurora for theusersandmovies_watchedtables -
D
Use a DynamoDB Global Table for the
moviestable and use DynamoDB for theusersandmovies_watchedtables
Xem giải thích
Đáp án
C — Dùng Aurora Global Database cho bảng movies, và Aurora thường cho bảng users và movies_watched
Vì sao đúng
Chữ khoá của đề là "ít phải viết lại ứng dụng nhất", và ứng dụng đã đang chạy trên Aurora. Giữ nguyên Aurora cho cả hai loại bảng nghĩa là không phải đổi driver, không phải viết lại câu truy vấn, không phải đổi mô hình dữ liệu.
Về phần phân bố địa lý:
| Bảng | Yêu cầu | Giải pháp |
|---|---|---|
movies |
Truy cập toàn cầu | Aurora Global Database — nhân bản sang tối đa 5 Region phụ, độ trễ dưới một giây |
users, movies_watched |
Chỉ trong Region | Aurora thường, mỗi Region một cụm riêng |
Aurora Global Database phù hợp với dữ liệu phim: ghi ít, đọc nhiều — Region chính nhận ghi, các Region phụ phục vụ đọc với độ trễ thấp cho người dùng địa phương.
Vì sao các phương án khác sai
- A và D. Dùng DynamoDB Global Table cho
movies— DynamoDB Global Table mạnh hơn về mặt ghi (ghi được ở mọi Region), nhưng nó là NoSQL: bạn phải viết lại toàn bộ tầng dữ liệu cho bảng đó, đổi từ SQL sang API của DynamoDB. Vi phạm thẳng ràng buộc "ít refactor nhất". A là phương án nhiễu chính. - B. Aurora Global Database cho
moviesnhưng DynamoDB cho hai bảng còn lại — cũng đòi viết lại, và còn dồn công vào đúng hai bảng lẽ ra không cần đụng tới.