Fundamentals of AI and ML

Arriving with only everyday familiarity with "AI," you will leave Domain 1 able to read any stem's vocabulary precisely, judge whether ML even fits, and name the lifecycle stage in play. Domain 1 is the foundation the other four domains assume, and its three subtopics form a pipeline you walk in order. AI & ML Concepts gives you the vocabulary (AI ⊃ ML ⊃ deep learning ⊃ generative AI, model vs algorithm, supervised/unsupervised/reinforcement, batch vs real-time, overfitting/underfitting, bias/fairness) so a question stem is unambiguous. AI Use Cases then decides whether ML is even the right tool and, if so, which AWS service tier to reach for. ML Development Lifecycle only matters once you have committed to building or fine-tuning your own model. Reach for the concepts subtopic for definition questions, the use-cases subtopic for 'which service / should we use ML' questions, and the lifecycle subtopic for 'which stage / which SageMaker capability' questions.

Across all three subtopics the same ladder appears: do not build what you can buy. Before the custom-build lifecycle even starts, ask whether a deterministic rule beats ML at all (ai-use-cases), then whether a pre-trained AI service (Amazon Comprehend, Rekognition, Transcribe, Translate, Polly, Textract, Lex, Personalize, Kendra, Fraud Detector) already exposes the capability through an API, then whether Amazon Bedrock covers a generative task, and only then drop to Amazon SageMaker AI for a fully custom model. The lifecycle subtopic reinforces this: SageMaker JumpStart lets you start from a pre-trained model rather than training from scratch. Picking SageMaker AI when a managed API would do is the classic over-engineering distractor: it adds cost, data work, and operational burden the question is testing you to avoid.

Every subtopic pivots on data. ai-ml-concepts ties the learning paradigm to what the data tells the model (labels → supervised, raw structure → unsupervised, rewards → reinforcement) and ties the modeling approach to data shape (tabular/structured vs text/image/audio unstructured that needs deep learning). ai-use-cases makes data the hard prerequisite: no representative, sufficiently large dataset disqualifies ML no matter how good the algorithm. ml-lifecycle front-loads data collection, exploratory data analysis (EDA), pre-processing, and feature engineering, and insists the test set be held out from training so evaluation is honest. If a question asks why an ML approach is inappropriate, 'no relevant data' and 'a guaranteed single outcome is required' are the two highest-value answers, both rooted here.

The domain consistently treats deployment as a midpoint, not a finish line. ai-ml-concepts establishes that generalization is measured on held-out data because a model that overfits memorizes noise. ml-lifecycle makes the loop explicit: a deployed model drifts as real-world data shifts, so Amazon SageMaker Model Monitor watches endpoints and sends you back to data collection or feature engineering. Never treat hand-off as the end, the single most-tested lifecycle trap on AIF-C01. Metric choice must match the business cost of being wrong: accuracy is misleading on imbalanced data (a fraud model can be 99% accurate while catching zero fraud), so precision, recall, F1, and AUC are chosen by which error is costlier, then tied to business metrics like ROI and cost per user. Responsible-AI controls in Domain 4 exist precisely because an accurate-on-average model can still be biased and unfair to a subgroup.