AWSAWS Certified Generative AI Developer - Professional2026-101.1 Analyze requirements and design GenAI solutions

Review GenAI designs with verifiable evidence

Completed by the knowledge check

Learning objective

Review production GenAI designs with the AWS Well-Architected Framework Generative AI Lens and AWS Well-Architected Tool. Turn the review into an evidence-backed improvement process for the complete workload.

Core idea

A Well-Architected review examines how a workload behaves under its intended conditions and failure modes. It is broader than a model benchmark, a security scan, or a list of deployed AWS services. A strong model can sit inside a design with unsafe authorization, missing recovery, or uncontrolled costs.

The AWS Well-Architected Framework has six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. The Generative AI Lens extends this assessment to generative workloads, including evidence quality, model behavior, tool use, and responsible AI considerations. Apply both the general architecture questions and the GenAI-specific guidance.

AWS Well-Architected Tool supports documenting decisions and tracking architectural improvements. Treat the tool as the record of an informed review, not an automatic certificate that a deployment is safe. Answers need evidence, reviewers need context, and accepted risks need owners.

How it works

Define the workload and review boundary

State the business purpose, supported tasks, users, data classifications, and critical dependencies. Include the application, ingestion and retrieval paths, model invocation, safety controls, tool execution, external systems, and operational processes. A boundary containing only the model API excludes many of the failures that affect customers.

Bring the acceptance contract from 1.1.1 and the experimental evidence from 1.1.4. Also bring data-flow diagrams, deployment descriptions, authorization decisions, evaluation results, runbooks, and change history. Review the implementation that exists rather than the architecture that the team intends to build later.

Identify who can answer each class of question. Operations understands failure handling; data owners understand freshness and entitlements; security understands authority; domain specialists understand harmful or unsupported outputs. An architect can coordinate these views, but cannot establish every property from a diagram alone.

Apply the correct lens

The Generative AI Lens is an AWS official lens in the AWS Well-Architected Tool Lens Catalog. Apply it to the workload like other catalog lenses; no additional installation is required. The lens document also describes downloading a JSON definition from the public AWS Well-Architected custom lens repository and importing it. Treat that as an alternative documented path, not a prerequisite for using the official lens. Record the lens version used so later comparisons have a clear basis.

Milestones, reports, and improvement plans are workload-review features of AWS Well-Architected Tool, rather than features unique to custom lenses. Custom lenses add organization-specific pillars, questions, and best practices; an internal GenAI governance lens can supplement the official one. Do not confuse a saved milestone with a deployment gate; your delivery process determines what evidence and approvals a release requires.

Read the lens guidance before answering its questions. A selected answer is a claim about the workload, so attach or reference supporting evidence in the review record. If a practice is not applicable, document the workload condition that makes it irrelevant. “Not implemented” and “not applicable” are different conclusions.

Review each pillar through the GenAI request path

For operational excellence, inspect artifact ownership and change control. Can the team identify the model, prompt, corpus, and application versions involved in a reported defect? Can it repeat the relevant evaluation and roll back an unsuitable change? Distinguish collected telemetry from a process that acts on it.

For security, examine what evidence and actions each identity can access. Ask whether untrusted retrieved content can influence tool execution, whether sensitive data enters inappropriate logs, and whether runtime enforcement survives model deviation. A prohibition written in a prompt is weaker evidence than a test showing that a prohibited action cannot execute.

For reliability, inspect degraded behavior and dependency failures. What happens when retrieval returns nothing, a tool times out, or inference is unavailable? Check that retries cannot duplicate consequential actions and that partial completion produces a recoverable state. A fluent final response should not conceal a failed external operation.

For performance efficiency, use measurements for the actual workload. Review retrieval, queueing, generation, validation, and delivery together. Check long inputs, long outputs, peak concurrency, and the distinction between first output and complete usable output. A service-level metric covers only its own part of the path.

For cost optimization, connect resource use to accepted task outcomes. Inspect whether larger contexts, repeated calls, agent loops, and unnecessary retrieval add cost without improving quality. A lower-cost model is useful only when it still meets the applicable acceptance gates.

For sustainability, examine avoidable computation and storage. Consider whether every request needs the same processing depth, whether redundant work can be removed, and whether retained artifacts have a defined purpose. Evaluate efficiency changes against quality and safety so resource savings do not create unacceptable results.

These are review prompts for applying the pillars, not replacements for the lens’s published questions. The Generative AI Lens covers the lifecycle from scoping through continuous improvement and emphasizes shared responsibility among model producers, providers, and consumers. Keep that broader context when assigning control ownership.

Convert findings into accountable work

For each gap, record the observed condition, its consequence, supporting evidence, proposed improvement, owner, and target review date. Prioritize by customer impact and likelihood under the intended workload. Avoid ranking findings solely by how easy they are to fix.

Link each proposed improvement to verification. If the issue is unauthorized retrieval, closure needs an entitlement test, not a statement that permissions were reviewed. If the issue is unknown task completion, closure needs a demonstrated recovery path and observable final state.

Capture a milestone before remediation and another after validating the improvements. Revisit the review after meaningful changes to models, tools, sources, data classes, or operating scale. A design that was suitable for read-only drafting can require a different risk assessment after adding write capabilities.

Key distinctions and trade-offs

Framework versus lens: The framework provides the general pillars. The lens supplies domain-specific considerations for applying them to GenAI. Neither removes the need for workload-specific evidence.

Tool record versus compliance determination: A review record helps governance, but it does not independently establish legal compliance or authorize a release. Those decisions need the appropriate owners and evidence.

Model quality versus architecture quality: Evaluation establishes behavior on tested tasks. Architecture review also examines authorization, failures, capacity, and lifecycle management.

Accepted risk versus resolved risk: An owner can accept a documented risk within a defined scope. That does not mean the failing control has been implemented or verified.

Architecture / decision scenario

An internal policy assistant passes answer-quality tests. A production review follows the complete path and discovers that its evidence refresh process has no owner, support logs expose restricted passages, and the unavailable-retrieval path generates an uncited answer.

The team records these as separate findings rather than marking the workload acceptable because it uses Bedrock. Data operations owns refresh verification, security owns log minimization, and application engineering owns a tested abstention path. The review milestone captures the initial state.

After remediation, reviewers repeat the relevant tests and capture a new milestone. Approval stays bounded to the read-only policy task. Adding tools that change employee records triggers another review because the authority boundary has changed.

Common exam traps

Reviewing only the model and ignoring the surrounding workload.
Assuming that applying a lens verifies implementation and closes its identified risks.
Treating selected answers as evidence of implemented controls.
Marking an unimplemented practice as not applicable.
Equating a review report with compliance certification.
Closing a finding without testing the intended improvement.

What to remember

Review the complete workload across all six pillars.
Apply the official Generative AI Lens from the Lens Catalog.
Support review answers with implementation and test evidence.
Assign owners and verification criteria to improvements.
Use milestones and renewed reviews to track meaningful changes.