AWSAWS Certified Generative AI Developer - Professional2026-101.1 Analyze requirements and design GenAI solutions
Package approved architectures for repeatable deployment
Completed by the knowledge check
Learning objective
Standardize approved GenAI architectures with AWS CDK, CloudFormation, and AWS Service Catalog. Preserve reviewed controls while allowing application teams to provision an appropriate configuration.
Core idea
Standardization turns an approved design into a maintained deployment product. It is more than sharing a sample repository. Teams need a repeatable definition, a bounded configuration surface, a controlled provisioning path, version ownership, and evidence that updates preserve the controls.
AWS Cloud Development Kit (AWS CDK) defines infrastructure in programming languages and provisions it through AWS CloudFormation. CloudFormation defines resources in templates and manages them as stacks. AWS Service Catalog provides catalogs of approved products, with portfolios and provisioning constraints. These mechanisms have different jobs and can form one delivery path.
An infrastructure product does not certify every generated answer. Standardize deployable controls and configuration boundaries, then require application-specific evaluation and authorization. An approved scaffold can still host a prompt, corpus, or tool integration that fails the task’s acceptance contract.
How it works
Define the product’s contract
Start with the reviewed architecture from 1.1.5. Identify what remains invariant across deployments and what varies legitimately. For a read-only assistant, the invariant might include a restricted execution role, approved inference routing, protected evidence access, required monitoring, and a documented retention policy.
Expose parameters only when a caller can make a valid decision about them. Project ownership tags and an approved environment choice are useful inputs. Unrestricted policy documents, arbitrary data sources, or arbitrary model-routing destinations can let callers remove the very controls that made the architecture approved.
State prerequisites and responsibilities. An application team might own source approval, prompt evaluation, and escalation behavior. A platform team might own the infrastructure definition, deployment permissions, and supported upgrade path. The contract should make those responsibilities visible before provisioning.
Treat the product’s operating envelope as part of the contract. Describe the intended workload, allowed data classification, delivery mode, and excluded capabilities. A read-only evidence assistant and a tool-executing agent need different authority boundaries even when they share some infrastructure.
Encode reusable infrastructure with CDK
AWS CDK constructs are reusable building blocks that compose into stacks and applications. Use a construct to package a coherent responsibility rather than merely to shorten repeated syntax. For example, a construct can keep an evidence-access boundary and the monitoring needed to verify it together.
Review the resulting resource definitions as well as the source abstraction. A helper with a reassuring name does not establish restrictive permissions. The approved version must produce the intended roles, data paths, and configuration for every supported parameter combination.
Keep defaults conservative and make exceptions explicit. Avoid inferring production-sensitive settings from a developer’s local environment. Record model choices and inference routing separately from generic resource names, so an update cannot quietly change the processing boundary.
Test configuration boundaries rather than reproducing every line of generated output. Useful checks establish that permitted options preserve required controls and that unsupported combinations fail before deployment. Application quality tests remain separate because infrastructure assertions cannot determine whether an answer is supported by evidence.
Review deployment changes through CloudFormation
A CloudFormation stack groups resources described by its template. Changes to the architecture therefore need review of the proposed resource effects, not only the source-code diff. A small source edit can produce a substantial deployment change.
CloudFormation change sets preview how proposed changes affect running resources, including potential deletion or replacement. CloudFormation applies those changes when the change set is executed. A change set does not guarantee successful execution; runtime or service-specific conditions can still cause failures.
Use that preview to inspect changes to stateful resources, permissions, processing locations, and recovery dependencies. Decide how to migrate or preserve evidence stores before executing a replacement. A deployment operation and a data migration are related responsibilities, but they are not interchangeable.
Pin the infrastructure version used for a release and retain its deployment evidence. If a change fails, operators need to know what configuration was attempted and how to return to a supported state. Do not assume that repeating the same deployment safely repairs every partially completed operation.
Distribute through a governed catalog
Service Catalog lets administrators assemble products into portfolios and grant access to the approved offerings. Consumers discover products available to them and launch provisioned products. This creates a controlled distribution surface rather than requiring every team to copy and modify the platform definition.
A Service Catalog launch constraint specifies the IAM role the service assumes when a consumer launches, updates, or terminates a product. It applies to the product-portfolio association, not automatically to every product in a portfolio. Review each association so a new product does not inherit permissions merely by being nearby.
Service Catalog template constraints narrow allowed values of parameters in a product’s underlying CloudFormation template. They are bound within a portfolio, so a constraint on the same product in another portfolio does not apply automatically. Terraform Open Source and Terraform Cloud products do not support template constraints; distinguish these parameter restrictions from the launch constraint’s provisioning role.
Keep the provisioning role separate from the application’s runtime roles. The role that creates infrastructure might need permissions that an answering assistant must never receive. A successful launch proves that provisioning completed; it does not prove that runtime authorization is appropriate.
Publish supported product versions with a clear upgrade policy. Separate availability of a new version from migration of existing deployments. Require application owners to re-evaluate relevant behavior when an upgrade changes model selection, source processing, tool authority, or runtime validation.
Key distinctions and trade-offs
The following table separates the mechanisms by responsibility:
| Mechanism | Primary responsibility | What still needs another control |
|---|---|---|
| AWS CDK | Express and compose reusable infrastructure definitions | Deployment-effect review and application evaluation |
| CloudFormation | Provision and update template-defined stacks | Approval policy and workload-specific acceptance |
| Service Catalog | Distribute approved products with governed provisioning | Runtime authorization and ongoing product maintenance |
Reusable component versus approved product: A construct packages a definition. An approved product adds reviewed configuration limits, ownership, distribution, and lifecycle policy.
Provisioning authority versus runtime authority: Permission to create a resource does not imply that the deployed application should receive the same permission. Evaluate those roles independently.
Standardization versus uniformity: Different workload classes can need different approved products. Forcing every task into one unrestricted template shifts complexity to consumers and weakens reviewability.
A narrow product is easier to govern but can exclude valid uses. A broad product supports more teams but requires more configuration testing and clearer boundaries. Prefer a small set of explicit architecture variants over a large collection of interacting switches that no reviewer can assess together.
Architecture / decision scenario
A platform team wants business units to deploy document assistants. It publishes a read-only product with an approved inference boundary, restricted source access, required monitoring, and ownership metadata. Teams choose a supported environment and identify an approved source; they cannot grant arbitrary write tools through a free-form parameter.
The platform uses CDK to maintain the infrastructure definition, reviews CloudFormation change sets for releases, and distributes the approved offering through Service Catalog. Template constraints limit the supported environment parameter in each portfolio, while each product-portfolio association receives its reviewed launch constraint. Deployed runtime permissions remain narrower than provisioning permissions.
A business unit later requests automated record updates. The team treats that as a new authority requirement and reviews a separate product variant instead of relaxing the read-only product. Existing consumers retain a clear, supported contract, while the new variant receives its own controls and evaluation gate.
Common exam traps
- Treating CDK as a replacement for CloudFormation’s deployment role.
- Assuming a reusable construct is automatically an approved architecture.
- Giving runtime code the provisioning role’s permissions.
- Confusing template constraints on parameter values with launch constraints on provisioning authority.
- Treating a change set as a guarantee of successful deployment.
- Assuming standardized infrastructure guarantees factual model outputs.
What to remember
- Standardize controls, configuration boundaries, and ownership together.
- Use CDK for reusable definitions and CloudFormation for stack deployment.
- Inspect resource effects before executing infrastructure changes.
- Use Service Catalog to distribute governed offerings.
- Maintain runtime and evaluation gates beyond successful provisioning.
Knowledge check
A platform team wants reusable infrastructure definitions written in a programming language and deployed as stacks. Which division of responsibilities fits?
A small edit to a CDK construct might cause a stateful evidence store to be replaced. What should reviewers inspect before the update runs?
Service Catalog consumers must choose from a restricted set of environment values, and launches must run under a reviewed role. Which controls address these two requirements?
A product with a reviewed launch constraint in one portfolio is added to a second portfolio for another business unit. What must the administrator do?
A governed read-only assistant product is deployed successfully. A team now asks to add tools that change records. How should the product contract evolve?