2.7 AI/ML Foundations Case Lab
Key Takeaways
- Case analysis should identify the business decision, data type, learning pattern, inference pattern, AWS service fit, and no-AI fallback.
- A strong practitioner recommendation includes governance, human review, monitoring, and cost implications, not only a service name.
- Different parts of one workflow may use different approaches, such as rules for policy enforcement and AI for ambiguous triage.
- Official study practice should use AWS Skill Builder, official practice resources, and hands-on console review rather than unauthorized memorization sources.
Case Method for Practitioner Decisions
A case question rarely rewards naming the most advanced service. It rewards matching the business problem to the simplest controlled approach. Start by writing the decision the business wants to improve. Then identify the input data, desired output, timing, risk, and user. Finally compare AWS service paths with a no-AI option. This habit prevents overbuilding and keeps governance visible.
Use the same case worksheet each time. What is the business action? What data type is involved? Is there a label, no label, or reward signal? Is the output a category, number, group, forecast, ranked list, extraction, or generated response? Does the decision need batch, real-time, or embedded inference? What happens when the model is wrong? Which AWS service is the smallest fit?
| Case dimension | What to capture | Why it matters |
|---|---|---|
| Decision | The action changed by the output | Proves the use case is not vague |
| Data | Type, source, quality, permissions | Drives service choice and governance |
| Learning pattern | Supervised, unsupervised, reinforcement, or not ML | Clarifies labels and validation |
| Inference pattern | Batch, real-time, asynchronous, or embedded | Drives cost, latency, and fallback design |
| AWS path | Managed AI, Bedrock, Amazon Q, SageMaker, analytics, rules | Prevents tool-first reasoning |
| Control | Human review, IAM, logging, monitoring, retention | Makes approval defensible |
Case 1: a regional insurer receives thousands of emailed claim documents each week. Staff manually read forms, extract claim numbers and dates, and route incomplete packets for follow-up. The data is document and text. The output is extracted fields plus a completeness decision. Amazon Textract is a strong first service for extraction, with human review for low-confidence or high-value cases. A deterministic checklist can enforce required fields.
The same insurer asks whether a model should approve claims automatically. That is a different and higher-risk decision. The team would need labels, policy clarity, fairness review, auditability, and a human escalation path. The correct recommendation may split the workflow: use AI to extract and prioritize information, but keep claim approval under deterministic policy and trained human review until evidence supports further automation.
Case 2: a retail site wants to improve product discovery. Search logs, purchases, views, carts, and product metadata are available. A recommendation pattern may fit, and Amazon Personalize is relevant if interaction data is sufficient and permitted. For new users or sparse data, popular products, merchandising rules, and search tuning may be needed. The service decision should include privacy, cold start behavior, and business metrics such as conversion and returns.
Case 3: an internal IT team wants a helper for employees who ask cloud support questions. The input is internal documentation and user questions. The output is generated guidance with links or citations. Amazon Q or an Amazon Bedrock retrieval workflow may fit, but only if the knowledge source is curated, current, and access-controlled. If the question requires an exact account-specific fact, the assistant should retrieve from an authorized system rather than invent an answer.
Case 4: a warehouse manager wants to know how many workers are needed next Friday. Historical volume, staffing, promotions, holidays, and seasonality may support forecasting or regression. If the location has only a few weeks of data, a spreadsheet baseline may beat a model. If many locations have years of history, SageMaker Canvas or a governed SageMaker AI approach may help. The metric should be scheduling accuracy and overtime reduction, not model novelty.
Case 5: a finance leader wants every report to include a written summary. If the report is a stable QuickSight dashboard with a few metrics, a templated narrative may be more reliable than free-form generation. If analysts need natural language drafts across many changing datasets, a generative workflow may help. The team should define source data, review responsibility, allowed tone, and how to prevent unsupported conclusions.
Case 6: a security team wants to detect abnormal sign-in behavior. This may involve anomaly detection, supervised classification if labels exist, or rules for known high-risk conditions. It also involves security services and governance beyond ML. A practitioner should ask whether the output informs analysts, blocks access, or starts an incident workflow. The more direct the action, the stronger the need for explainability, logging, and human override.
Practice drill:
- Pick one case above and write the business decision in one sentence.
- List the data type and whether labels exist.
- Choose the task pattern and inference pattern.
- Pick the first AWS service or non-AI path to evaluate.
- Name one governance risk and one human review point.
- Define one business metric and one model or output quality metric.
- Compare your answer with AWS Skill Builder lessons and official practice resources, not unauthorized memorization sources.
When using AWS Skill Builder or the AWS console for reinforcement, focus on recognition and judgment. Open service pages for Amazon Bedrock, Amazon Q, SageMaker AI, SageMaker Canvas, Textract, Comprehend, Rekognition, Transcribe, Translate, Polly, Lex, Personalize, and Fraud Detector. For each service, write one use case it fits, one use case it does not fit, one data requirement, and one governance question.
A good final case answer has a clear shape: recommend a path, explain why it fits the data and decision, name the risk, and state the fallback. For example, use Textract to extract invoice fields, route uncertain fields to human review, apply deterministic approval thresholds, and monitor error rates. That answer is stronger than simply saying use AI because it separates extraction, policy, review, and monitoring.
An insurer wants to extract claim numbers and dates from uploaded forms, then send uncertain values to staff. Which recommendation is strongest?
A retail site has user-item interaction history and wants to rank products for shoppers. What should the practitioner evaluate first?
Which case-lab answer best reflects practitioner judgment?