AWSAWS Certified Generative AI Developer - Professional2026-102.3 Design and implement enterprise integration architectures

Release GenAI artifacts with tested rollback

Completed by the knowledge check

Learning objective

Implement CI/CD for code, prompts, IaC, and deployment artifacts with scans, rollout gates, and rollback.

Core idea

A GenAI release changes more than executable code. A prompt version can alter tool selection; an infrastructure policy can widen data access; a container revision can change serialization. You need continuous integration and continuous delivery (CI/CD) to promote a compatible release package with explicit evidence and a return path.

For an engineer designing that pipeline, the key decision is the release unit. Record the code revision, prompt version, infrastructure-as-code (IaC) revision, and deployment artifact identity together. Test and approve those exact inputs rather than approving a branch name whose contents can change before deployment.

AWS supplies different mechanisms for different gates: Inspector scan actions for vulnerabilities, CloudFormation change sets for infrastructure impact, CodePipeline approvals for a human decision, and CodeDeploy configurations and rollback for supported application deployments. No single passing gate establishes complete GenAI quality.

How it works

Define a reproducible release package

Maintain a release record that names every behavior-affecting artifact and its compatibility requirements. Include the prompt’s selected model configuration, tool contract revision, and routing configuration when they change the application. The record is an application-owned contract; it is not an automatically generated AWS object covering all these resources.

For Bedrock Prompt management, a saved draft remains the working copy. Create a prompt version for deployment: AWS describes the version as a snapshot of the prompt and its configuration at a point in time. Select that version as part of the release instead of relying on a mutable draft.

Keep prompt evaluation attached to the same candidate that production receives. A version snapshot establishes which prompt you tested; it does not establish quality, safety, or compatibility by itself. Compare representative answers, tool proposals, denied requests, and unsupported questions against the acceptance criteria. See 1.2.8 for model promotion and rollback; this lesson covers the broader application package.

Make the recovery package equally explicit. Preserve the prior compatible code, prompt, and artifact identities. A rollback instruction that says “use the previous prompt” is ambiguous when several branches or environments have different versions.

Scan the candidate that will be deployed

CodePipeline’s Amazon Inspector action uses provider InspectorScan. Its InspectorRunMode selects SourceCodeScan or ECRImageScan. For an image scan, configure ECRRepositoryName and ImageTag. The action supports CriticalThreshold, HighThreshold, MediumThreshold, and LowThreshold to fail the action when vulnerability counts exceed the configured thresholds.

Choose threshold values from the release policy. For example, a threshold of zero for critical findings means any critical finding exceeds it. Record approved exceptions separately rather than raising the threshold until a candidate passes without a reviewed reason.

Bind the scan result to the deployment artifact. Enable Amazon ECR tag immutability with IMMUTABLE for release tags: pushing an image under an existing tag returns ImageTagAlreadyExistsException. Keep release tags outside any mutable-tag exclusions so the scanned tag cannot be repointed before deployment. Record its content identity and promote the same bytes. Rebuilding from the same source revision is not equivalent evidence if dependencies or build inputs can differ.

A dependency or image vulnerability scan does not assess prompt behavior. Add application-owned checks for prompt regressions, secret exposure in release inputs, and policy configuration. Give each failed check a blocking outcome. The choice of a scanner does not make an untested property part of its coverage.

Review infrastructure and approval evidence

CloudFormation change sets preview additions, modifications, deletions, and potential resource replacement before you execute an update. Review changes that affect service roles, network routes, source stores, or logging destinations alongside ordinary resource changes.

A change set is not a guarantee of successful execution. AWS documents pre-deployment validation for common failures, but runtime conditions can still fail during execution. It also does not prove the application’s end-user authorization or model-output quality. Pair infrastructure review with behavior tests rather than treating a syntactically valid template as the release decision.

A CodePipeline manual approval action stops execution until an authorized reviewer approves or rejects it. If nobody approves or rejects it within seven days, the action fails and the pipeline does not continue. Put this gate after the evidence needed for review exists, and before the production action it authorizes.

The reviewer should receive the exact release record, scan outcomes, prompt evaluation, infrastructure change set, and rollback plan. An approval of one candidate should not be reused after its artifacts change. Approval is an authorization event in the pipeline, not a substitute for evidence the reviewer never saw.

Roll out and recover by resource type

For the Lambda compute platform, CodeDeploy supports canary, linear, and all-at-once traffic shifting to function versions. CodeDeployDefault.LambdaCanary10Percent5Minutes shifts 10 percent first and the remaining 90 percent five minutes later. A linear configuration shifts increments over time. Choose the deployment configuration that provides enough observation for the workload’s traffic and failure signal.

A short canary does not guarantee useful evidence for a low-volume application. Define the required observations and acceptance threshold before release. Inspect technical failures and GenAI-specific outcomes, such as invalid tool proposals or unauthorized evidence. If the sample is insufficient, a quiet interval is not proof that the candidate is safe.

CodeDeploy can automatically roll back when deployment fails or a configured monitoring threshold is met. It redeploys a previously deployed revision as a new deployment with a new deployment ID. Configure the failure signal and rollback behavior before rollout; do not assume traffic shifting alone enables automatic recovery.

Keep resource boundaries explicit. A CodeDeploy application rollback does not automatically restore every independently selected prompt version or reverse a CloudFormation resource change. Coordinate those actions through the release record. Test whether the recovered code can still operate with the infrastructure and data state left after the failed candidate.

Where a change cannot be safely reversed, provide a forward recovery path and block promotion until it is reviewed. Restoring executable bytes cannot undo an already completed external business action. Recovery must distinguish deployment state from business effects.

Key distinctions and trade-offs

Immutable candidate versus mutable selector: A release identifier must bind to tested content. A branch name, prompt draft, or replaceable image tag can point to different content later. ECR tag immutability prevents overwriting the release tag; it does not version prompts or code branches.

Scan versus evaluation: Inspector thresholds gate documented vulnerability findings. Prompt and tool-behavior evaluations answer different questions and need their own acceptance criteria.

Change-set review versus deployment success: Previewing infrastructure impact improves the decision before execution. Runtime failures remain possible.

Canary versus rollback: Traffic shifting limits initial exposure. Rollback requires configured triggers and a compatible recovery package. One does not imply the other.

Architecture / decision scenario

A proposal assistant release changes a Lambda tool adapter, a Bedrock prompt, its containerized preprocessing artifact, and a CloudFormation role policy. You create a release record binding all four revisions.

Inspector scans the candidate image with ECRImageScan and the chosen severity thresholds. Prompt tests reject a candidate that proposes writes without the required approval. The reviewer inspects the CloudFormation change set and the passing replacement candidate before approving CodePipeline’s production gate.

CodeDeploy starts the Lambda canary. A configured monitoring threshold detects adapter failures and triggers rollback. The release controller also restores the prior prompt selection, while the team separately checks infrastructure compatibility. The exercise passes only when the restored application serves requests with the expected permissions and the deployment record identifies the recovered package.

Common exam traps

Versioning code while deploying a mutable prompt draft.
Assuming vulnerability scans evaluate generated answers or tool safety.
Scanning one image and deploying rebuilt or replaced content.
Treating a CloudFormation change set as guaranteed success.
Assuming canary deployment implies configured automatic rollback.
Expecting application rollback to reverse every prompt, infrastructure, or business change.

What to remember

Promote the exact compatible artifacts that passed evaluation.
Gate vulnerabilities with explicit Inspector modes and severity thresholds.
Review infrastructure impact before executing a change set.
Put human approval after evidence generation and before production promotion.
Test recovery across code, prompts, infrastructure, and external effects.