MLA-C01 · Question #51
A company has deployed an ML model that detects fraudulent credit card transactions in real time in a banking application. The model uses Amazon SageMaker Asynchronous Inference. Consumers are reporti
The correct answer is A. Use SageMaker real-time inference for inference. Use SageMaker Model Monitor for notifications. Option A is correct because fraud detection in banking is a latency-sensitive, real-time use case - SageMaker Real-Time Inference provides synchronous, low-latency responses (milliseconds), which directly fixes the consumer-reported delays. SageMaker Model Monitor continuously ev
Question
A company has deployed an ML model that detects fraudulent credit card transactions in real time in a banking application. The model uses Amazon SageMaker Asynchronous Inference. Consumers are reporting delays in receiving the inference results. An ML engineer needs to implement a solution to improve the inference performance. The solution also must provide a notification when a deviation in model quality occurs. Which solution will meet these requirements?
Options
- AUse SageMaker real-time inference for inference. Use SageMaker Model Monitor for notifications
- BUse SageMaker batch transform for inference. Use SageMaker Model Monitor for notifications
- CUse SageMaker Serverless Inference for inference. Use SageMaker Inference Recommender for
- DKeep using SageMaker Asynchronous Inference for inference. Use SageMaker Inference
How the community answered
(39 responses)- A82% (32)
- B3% (1)
- C10% (4)
- D5% (2)
Explanation
Option A is correct because fraud detection in banking is a latency-sensitive, real-time use case - SageMaker Real-Time Inference provides synchronous, low-latency responses (milliseconds), which directly fixes the consumer-reported delays. SageMaker Model Monitor continuously evaluates data quality and model quality against a baseline and triggers notifications (via CloudWatch/SNS) when drift or deviations are detected, satisfying the second requirement.
Option B is wrong because Batch Transform is designed for offline, large-scale bulk processing - it has no concept of a live request/response cycle and would make delays far worse, not better.
Option C is wrong because while Serverless Inference can handle variable traffic, it suffers from cold-start latency and is not optimized for consistent low-latency real-time inference; more critically, Inference Recommender helps select optimal instance types but does not monitor or alert on model quality deviations.
Option D is wrong because Asynchronous Inference is the source of the delays - it queues requests and is designed for workloads taking seconds to minutes, making it fundamentally unsuitable for real-time fraud detection.
Memory tip: Match the latency requirement to the inference type - "real-time + delays" → Real-Time Inference; "quality deviation + notification" always points to Model Monitor. If the word "batch" or "async" appears in a scenario demanding instant responses, eliminate it immediately.
Topics
Community Discussion
No community discussion yet for this question.