Amazon AWS AIF-C01: AI and ML Fundamentals

AI and machine-learning fundamentals make up the foundation of AWS Certified AI Practitioner because every later topic—generative AI, foundation models, responsible AI, and security/governance—depends on understanding what kind of AI problem is being solved and what evidence makes a solution useful.

The current AIF-C01 guide, version 1.1 published April 30, 2026, explicitly includes agentic AI in the fundamentals vocabulary. That update does not turn the exam into an engineering certification; it expands what a modern AI practitioner should recognize and reason about.

Start by separating AI, machine learning, deep learning, and generative AI

Artificial intelligence is the broad category. Machine learning refers to systems that learn patterns from data. Deep learning uses multilayer neural networks for more complex representation learning. Generative AI produces new content such as text, images, code, or audio.

These categories overlap. A generative-AI application may use a large deep-learning foundation model, while a traditional forecasting system may use supervised machine learning without generative AI at all.

Use examples to test the distinction. Spam filtering can be supervised ML; customer segmentation can be clustering; image recognition can use deep learning; text generation can use a foundation model. The categories become easier when tied to actual tasks.

Do not assume every AI problem needs the newest technique. A simpler statistical or rules-based solution may be cheaper, easier to explain, and more reliable for a narrow problem.

Include traditional rules and analytics in the comparison. Not every intelligent-looking workflow needs ML, and not every ML problem benefits from a foundation model.

Choosing a simpler method can improve cost, explainability, latency, and governance while still meeting the business requirement.

Foundation models add another layer: they are large pretrained models that can support many downstream tasks. Generative AI applications often use them through prompting, retrieval, adaptation, or fine-tuning rather than training from scratch.

That distinction helps explain why modern AI practitioners need both conceptual ML knowledge and awareness of managed foundation-model services.

Understand supervised, unsupervised, and reinforcement learning

Supervised learning uses labeled examples to learn a relationship between inputs and expected outputs. Unsupervised learning looks for structure without labeled target outcomes. Reinforcement learning learns behavior through interaction and reward signals.

The exam is more interested in choosing an appropriate approach than deriving algorithms. Given a business problem, ask what data exists, whether labels exist, what output is required, and how success will be measured.

Supervised learning quality depends on labels that are accurate and representative. Unsupervised learning requires interpretation because discovered groups may not correspond to useful business categories. Reinforcement learning needs carefully designed rewards because the system optimizes what is measured.

These limitations matter more than memorizing textbook definitions. The practitioner should recognize which assumptions can cause the approach to fail.

Classification, regression, clustering, and forecasting solve different problems

Classification predicts categories, regression predicts numeric values, clustering groups similar observations, and forecasting estimates future values over time. Recommendation systems, anomaly detection, and other AI applications may combine several techniques.

Practice translating business language into AI task language. “Will this customer churn?” suggests classification; “what will demand be next month?” suggests forecasting; “which users behave similarly?” suggests clustering.

Also separate prediction from explanation. A model can predict churn accurately without proving why a customer will leave. Business decisions should not confuse model correlation with causal understanding.

Consider baseline methods. If a simple rule or historical average performs nearly as well as a complex model, the extra complexity may not be justified.

Training and inference are different phases

Training is the process of fitting or adapting a model using data. Inference is using the trained model to produce predictions or outputs. The infrastructure, latency, cost, and data requirements can differ significantly between the two.

AIF-C01 version 1.1 also expects awareness of different inference modes such as batch, real-time, asynchronous, and serverless. The right mode depends on workload latency, volume, cost, and interaction pattern.

Training may require large datasets and significant compute, while inference may need low latency or high throughput. Those different requirements influence service choice and cost.

Foundation models shift some training responsibility to the provider, but applications still make choices about prompting, retrieval, adaptation, fine-tuning, and inference configuration.

Cost behaves differently across the phases too. Training or adaptation may be infrequent but expensive; inference cost grows with usage, model choice, token volume, latency requirements, and deployment pattern.

Practitioners should ask which part of the lifecycle dominates cost before recommending an optimization.

Model evaluation must match the business objective

Accuracy alone can be misleading. Classification may require precision, recall, F1, or other measures depending on the cost of false positives and false negatives. Regression and forecasting use different metrics. Generative-AI applications require evaluation of relevance, quality, groundedness, safety, and task success.

Evaluation should be defined before deployment. A system cannot be improved reliably if the organization has no agreed definition of useful output.

A fraud model may value recall because missed fraud is costly, while a manual-review process may care about precision because false alerts consume analysts. The metric should reflect the consequence of error.

For generative AI, evaluation often combines automated measures with human judgment. Define test cases and expected behavior before changing prompts or models so improvements can be compared.

Evaluation sets should represent the population and conditions where the model will actually operate. A benchmark built from easy or repetitive examples can create false confidence.

Track both technical metrics and business metrics where appropriate. A model can improve accuracy without improving customer, fraud, revenue, or operational outcomes.

Create a baseline before celebrating model performance. A sophisticated model that barely outperforms a simple rule may not justify its complexity, operational burden, or governance cost.

Evaluation should also be repeated after major data, model, or prompt changes so the team knows whether improvement is real.

Overfitting and underfitting are practical quality problems

An overfit model performs well on training data but generalizes poorly. An underfit model is too simple or poorly trained to capture the useful pattern. Both can create impressive-looking development results that fail in real use.

Practitioners should understand why validation data, testing, representative datasets, and ongoing monitoring matter even if they are not expected to tune every model themselves.

Distribution shift creates another risk: even a well-fit model can degrade when real-world data changes. Monitoring should therefore compare current input and output behavior with the conditions under which the model was evaluated.

Practitioners should recognize that retraining or model replacement is part of the lifecycle, not evidence that the original model was necessarily poor.

Data quality and bias shape AI behavior

Models learn from the data and objectives provided to them. Missing coverage, mislabeled data, historical bias, leakage, poor sampling, or changing real-world behavior can all produce unreliable output.

Responsible-AI reasoning should therefore begin before model selection. Ask who is represented in the data, which outcomes matter, what errors are harmful, and what human review is needed.

Data leakage can make evaluation look artificially strong when information from the future or target outcome slips into training features. This is a classic example of why process discipline matters more than a high score.

Representativeness also matters. A model trained on one region, language, customer segment, or device population may fail when deployed more broadly.

Data governance includes ownership, access, lineage, retention, and change management. AI teams need to know not only where the data came from but who can change it and how those changes affect model behavior.

Privacy-preserving approaches or data minimization may be necessary when the task can be solved without exposing the full sensitive dataset.

Agentic AI adds actions and tool use to the fundamentals

AIF-C01 now includes agentic AI terminology because modern AI systems may do more than return a prediction or response. Agents can plan steps, use tools, retrieve data, preserve context, and take actions.

That creates new security and governance questions. The security of agentic systems depends on limiting data access, tool permissions, unsafe actions, and excessive agency.

Agents also introduce state and orchestration. They may need memory, handoffs, retries, tool selection, and recovery from partial failure. Even at practitioner level, knowing that these elements exist helps explain why agentic systems are more complex than chat interfaces.

The system should limit what the agent is allowed to do. Permission boundaries, approval, and logging are engineering controls around model behavior.

Agentic AI also introduces planning and state. A workflow may need to remember prior steps, decide which tool to call, handle failed calls, and know when to stop or ask a human for help.

These features increase capability and failure modes at the same time, which is why agentic AI now belongs in foundational AI literacy.

Fundamentals should help you choose the right AI approach

The value of this domain is decision quality. A practitioner should be able to recognize when a problem needs conventional analytics, supervised ML, generative AI, an agent, or no AI at all.

AWS Certified AI Practitioner is foundational because it builds that shared language before deeper architecture, data, ML engineering, or generative-AI development. The exam should leave you better at framing AI problems, not simply better at recalling terminology.

Practice with short business cases and explain why you would or would not use AI. Include expected value, data availability, evaluation, risk, and operating cost in the answer.

This is the durable outcome of the AIF-C01 fundamentals domain: better problem framing before a model or AWS service is selected.

Create one-page decision records for practice scenarios: problem, available data, candidate AI approach, expected metric, major risk, and reason to reject alternatives.

This trains the exact habit a practitioner needs before selecting a managed AWS AI service.

Use the AWS service only after the problem type is understood. A managed service can accelerate implementation, but it does not determine whether the business problem is classification, forecasting, retrieval, generative AI, or something simpler.

The strongest practitioner answer begins with the problem and success criteria, then selects the technique and service.

Keep service names secondary during first-pass reasoning. Identify the problem, data, technique, evaluation, and risk first; only then map that decision to Bedrock, SageMaker, or another AWS capability.

That order makes the knowledge portable even as AWS services and exam references evolve.

That problem-first habit also makes later AWS specialization easier because architecture, data engineering, ML engineering, and GenAI development all start from a clearer statement of what the system must accomplish.

Practice explaining the choice in plain business language; if the value proposition cannot be stated clearly, the technical solution may be premature.

Keep one notebook of recurring decision patterns—data available, labels available, latency need, explainability need, acceptable error, and cost. These patterns make new AI scenarios easier to classify without relying on memorized examples.

That discipline matters more than recognizing the newest service name.

Problem framing comes first.

That priority keeps AI decisions grounded.