AIP-C01 sample questions — 25 answered and explained

Decoupling long-running FM calls from the client with a queue and a status store.

Two separate failures need one design. Long processing means the client must not wait on the model call, and throttling means requests need a durable buffer with retries. Putting an SQS queue behind API Gateway solves both: the API returns immediately with an ID, the consumer retries throttled calls from the queue, and the client polls a status record (or is notified). Longer timeouts and a synchronous Express workflow keep the client blocked and lose throttled work; provisioned throughput addresses throttling only and at a fixed cost.

1. Separate the symptoms: client timeouts and lost requests under throttling.
2. A queue gives durability and retries; an asynchronous response frees the client.
3. Reject options that keep the request synchronous.
4. Prefer managed services over standing capacity for the least overhead.

Exam tip: Long or throttle-prone FM calls belong behind a queue; return a job ID, not the answer.

Bedrock service tiers (Reserved, Priority, Standard, Flex) versus batch inference.

The workload tolerates minutes of delay but must stay request-by-request. Bedrock's Flex tier is designed for exactly that: set service_tier to flex on the runtime call and accept longer processing in return for a discount. Batch inference is also cheap but works on files in S3, which the stem rules out. Priority pays more for speed, and provisioned throughput is a fixed commitment.

1. Note the latency tolerance: minutes are acceptable.
2. Note the interaction model: one API call per request, no files.
3. Choose the per-request option priced for latency-tolerant work.

Exam tip: Latency-tolerant but per-request: Flex tier; latency-tolerant and file-based: batch inference.

Choosing a Bedrock service tier by latency need and commitment tolerance.

The requirements are fastest responses, a willingness to pay a premium, and no reservation or term. The Priority tier matches all three: it is selected per request through the service_tier parameter, its requests are served ahead of Standard and Flex, and it needs no prior reservation. The Reserved tier also gives priority capacity but requires a monthly or quarterly reservation. Flex is the slow, discounted tier, and retries only lengthen waits.

1. Rank the needs: speed first, cost second, no commitment.
2. Map 'pay more, no reservation' to a per-request tier.
3. Eliminate tiers that need a term reservation or are designed to be slower.

Exam tip: Fastest responses without a reservation: Priority tier; guaranteed reserved capacity: Reserved tier.

Deterministic orchestrated workflows versus autonomous agents for regulated processes.

When the sequence is fixed and must be provable, the model should do the language work while a workflow controls the order. Step Functions Standard runs states in a defined order, keeps a full execution history, integrates directly with Bedrock InvokeModel and supports the wait-for-callback pattern for human approval. An agent chooses its own plan, which breaks the same-order guarantee. Express workflows cannot hold a long human wait, and a hand-built Lambda chain recreates what Step Functions already provides.

1. Decide who controls the sequence: the business (workflow) or the model (agent).
2. Fixed regulated steps with an audit trail point to an orchestrated workflow.
3. Long human waits need Standard workflows and a callback pattern.
4. Prefer managed orchestration to custom glue code.

Exam tip: Fixed, auditable steps: orchestrate with Step Functions and call the model inside; use agents only when the path must be decided at run time.

When an agent fits: run-time choice of tools across multiple turns.

The assistant's path is not known in advance: the needed APIs and their order depend on the conversation. That is what an agent provides, with the model planning tool calls from the API descriptions in its action groups while Lambda functions execute them. A Step Functions design would have to enumerate every path, a knowledge base cannot act, and a Bedrock flow follows a fixed sequence.

1. Ask whether the sequence of actions is known before the request arrives.
2. Unknown, conversation-dependent tool use points to an agent.
3. Check each option can actually invoke APIs, not just retrieve text.

Exam tip: Agents for paths decided at run time; workflows for paths you can draw in advance.

Managed RAG with Amazon Bedrock Knowledge Bases versus a custom-built pipeline.

The constraints are least overhead, no vector-database skills, and citations. Bedrock Knowledge Bases covers the whole RAG pipeline as a managed feature: it syncs from S3, chunks and embeds documents, stores vectors (it can create the vector store for you), and RetrieveAndGenerate returns answers with citations. Custom pipelines on Lambda or ECS meet the functional goal but add components to run, and fine-tuning cannot cite.

1. Identify the pattern: RAG with citations.
2. Weigh build-it-yourself against the managed feature for the stated skills and overhead.
3. Eliminate approaches that cannot cite sources.

Exam tip: Least-overhead RAG on AWS: start with a Bedrock knowledge base before building your own pipeline.

Using Amazon Bedrock to validate feasibility quickly in a proof of concept.

A proof of concept should answer the business question with the least investment. For one document, Bedrock lets you run retrieve-and-generate against an external source, either an S3 object or base64 bytes up to 10 MB, with no knowledge base or vector store, and the response includes citations. Creating a knowledge base, fine-tuning, or deploying an endpoint all produce resources and cost that a one-day feasibility check does not need.

1. Define the PoC question: can a model answer from this document with citations?
2. Choose the smallest mechanism that answers it.
3. Check size and scope limits: one document per request, 10 MB as bytes.
4. Avoid anything that leaves billable resources behind.

Exam tip: A PoC answers one feasibility question cheaply; one document needs no knowledge base.

Validating model fit during a PoC with evaluations on representative data.

A PoC decision needs evidence from the organisation's own data at a scale that means something. A Bedrock LLM-as-a-judge evaluation job takes a custom prompt dataset with reference responses, generates outputs from one model and has a judge model score correctness, helpfulness and similar metrics. Running one job per candidate on the same 300 tickets gives directly comparable scores without manual grading. Public leaderboards measure different tasks, a five-prompt playground session is too small, and a live A/B test needs a production system the team has not built yet.

1. Use the company's own representative examples, not general benchmarks.
2. Use enough examples to separate the models.
3. Automate scoring where manual grading does not scale.
4. Keep the comparison before production.

Exam tip: Choose PoC models on your own data at scale; public leaderboards are a shortlist, not evidence.

Agent loops need explicit stopping conditions; Step Functions Standard executions also have a hard execution history quota (25,000 events).

Two facts combine here. A ReAct loop has no built-in end other than the model choosing to answer, and a Standard workflow fails once its history reaches the 25,000-event quota. A counter checked by a Choice state is a deliberate stopping condition, and routing to a final call without tools turns the cap into a graceful best-effort answer. Express and execution-level timeouts fail the run (a state's Catch cannot catch an execution timeout), and a timeout on the search state never fires because each call is short.

1. Identify the missing stopping condition in the loop.
2. Note that execution-level limits fail the run, and per-state timeouts do not count iterations.
3. Add a counter plus a Choice state to cap iterations deliberately.
4. Finish with a model call that has no tools so it must answer.

Exam tip: Cap agent loops with your own counter and end with a forced answer; timeouts fail runs, they do not finish them.

Timeout mechanisms for agent tools belong inside the tool so it can return a structured result instead of being killed.

The requirement is a meaningful result within 8 seconds. A timeout on the outbound HTTP call (shorter than the function timeout) lets the function catch the timeout and return a normal action group response saying the data is unavailable, which the agent can turn into a helpful reply. Cutting the function timeout only produces the same generic error faster, and memory or concurrency settings do not bound a hung remote call.

1. Separate the function's own timeout from the timeout on the remote call.
2. Note that a killed function cannot return a result.
3. Bound the remote call and return a structured unavailable result.
4. Reject settings that do not limit waiting on the partner.

Exam tip: Time out the dependency inside the tool, not the tool itself, so the agent still gets an answer it can use.

IAM resource boundaries enforce what an agent's tools can touch regardless of model output; prompts and filters cannot.

Isolation must not depend on the model. The tool should obtain credentials scoped to the tenant of the authenticated caller, for example by assuming a role with a tenant session tag set from the verified identity. A dynamodb:LeadingKeys condition comparing the partition key to that principal tag then makes IAM deny reads of any other tenant's items. Prompt instructions, guardrails and format validation all leave the decision with model-supplied data.

1. Treat every model-generated parameter as untrusted.
2. Derive the tenant from the authenticated caller, not the prompt.
3. Let IAM enforce the partition key match with dynamodb:LeadingKeys.
4. Reject controls that rely on the model or on content filtering.

Exam tip: Agent tools get least-privilege credentials from the caller's identity; IAM, not the prompt, enforces the boundary.

Permissions boundaries cap the maximum permissions of roles, and a condition on role creation makes them mandatory for delegated administrators.

The goal is delegated role creation with a hard ceiling that only affects these roles. A managed policy used as a permissions boundary defines that ceiling, and requiring iam:PermissionsBoundary on CreateRole (and on the policy-attachment actions) ensures developers cannot create roles without it. An SCP caps the whole account, managed-policy-only rules do not cap actions, and session policies are opt-in for the code that assumes the role.

1. Recognise delegated role creation as the permissions boundary use case.
2. Define the ceiling as a managed policy.
3. Make the ceiling mandatory with an iam:PermissionsBoundary condition.
4. Reject account-wide or opt-in controls.

Exam tip: Delegate role creation safely with a required permissions boundary; it caps the role whatever policies get attached.

A circuit breaker stops calls to a failing dependency for a cool-down (open), allows a trial call (half-open) and resumes on success (closed); its state must be shared.

The breaker must be visible to every concurrent execution, so its state has to live in a shared store such as DynamoDB. Before calling, the tool checks the state; while open it returns a clear unavailable result immediately, after the cool-down it allows a trial call, and success closes the circuit. Module-level variables are per execution environment, backoff only spaces retries within one run, and a concurrency of one throttles healthy traffic as well.

1. Identify the pattern: stop calling a failing dependency, then probe.
2. Note that many executions run concurrently in separate environments.
3. Put the breaker state in a shared store and check it before calling.
4. Reject per-environment state and per-request retries.

Exam tip: Circuit breaker state must be shared across all callers; retries with backoff are not a circuit breaker.

A model ensemble combines several models' outputs with custom aggregation logic, such as majority voting with escalation on disagreement.

Three independent classifications are needed for a vote, and they must run concurrently to keep latency near one call. A Step Functions Parallel state runs the three invocations at once, and a Lambda function aggregates them: two or more matching labels win, otherwise the claim goes to a human. Sequential calls add latency, intelligent prompt routing picks a single model, and a primary-with-fallback design is not an ensemble.

1. Recognise the ensemble requirement: several models vote on each item.
2. Run the calls concurrently to protect latency.
3. Aggregate with custom logic: majority label or escalation.
4. Reject routing or fallback designs that use one model's answer.

Exam tip: Ensembles need parallel calls plus your own aggregation rule, including what to do when models disagree.

Retrieval-augmented generation with a managed knowledge base grounds answers in your documents and returns citations.

Amazon Bedrock Knowledge Bases ingests data from S3, creates embeddings and stores them in a vector store, and RetrieveAndGenerate retrieves relevant chunks, generates an answer from them and returns citations that point to the source. The custom OpenSearch pipeline also grounds answers but violates the effort constraint; fine-tuning and stuffing the prompt do not ground answers reliably.

1. Identify the needs: grounded answers plus source attribution.
2. Note the constraint: no self-managed embedding pipeline.
3. Pick the managed RAG service with built-in citations.
4. Reject training-based or prompt-stuffing approaches that cannot cite reliably.

Exam tip: Grounded answers with citations and minimal build = Bedrock Knowledge Bases + RetrieveAndGenerate.

Automated Reasoning checks in Amazon Bedrock Guardrails validate natural-language content against formal rules extracted from your policy documents.

Automated Reasoning checks detect statements that contradict the policy, highlight unstated assumptions, and give mathematically verifiable explanations citing the specific rules and variable assignments. That rule-level, per-answer evidence is what the regulator asks for. Contextual grounding gives a similarity-style score, evaluation jobs are offline, and denied topics only block subjects.

1. Note the requirement: per-answer evidence tied to specific rules.
2. Recall which guardrail policy reasons over extracted rules.
3. Choose Automated Reasoning checks.
4. Reject score-only, offline or topic-blocking options.

Exam tip: Need provable, rule-cited validation of answers against a policy document = Automated Reasoning checks.

Automated Reasoning checks return findings (they do not block) and validate complete responses (no streaming).

AWS documents two limits that explain both symptoms: Automated Reasoning checks operate in detect mode only, returning findings such as VALID or INVALID rather than blocking, and they do not support streaming APIs, so complete responses must be validated. The fix is to generate the full answer, validate it, and act on the findings in code. Synchronous streaming mode, grounding qualifiers and cross-Region settings belong to other features.

1. Separate the two symptoms: INVALID answers shown, and no findings on streamed answers.
2. Recall that Automated Reasoning is detect-only, so the app must act on findings.
3. Recall that it does not support streaming, so validate complete answers.
4. Reject settings that belong to other guardrail policies.

Exam tip: Automated Reasoning: detect-only and no streaming - validate the full answer, then act on the findings yourself.

Structured outputs on Amazon Bedrock constrain a model's response to a JSON schema you supply.

With Converse you set outputConfig.textFormat to a json_schema (InvokeModel uses output_config.format for Claude or response_format for open-weight models); strict tool use enforces tool input schemas. Bedrock compiles the schema into a grammar so responses comply, which AWS positions as eliminating retry loops from prompt-based approaches. Prompting, temperature and post-validation reduce or detect errors but do not prevent them.

1. Name the failure: malformed or incomplete JSON.
2. Look for a mechanism that guarantees schema compliance at generation time.
3. Use structured outputs with the schema in outputConfig.textFormat.
4. Reject approaches that only lower the error rate or detect it afterwards.

Exam tip: Need guaranteed JSON shape from Bedrock = structured outputs (json_schema), not prompt examples or retries.

Structured outputs support a subset of JSON Schema Draft 2020-12 and validate the schema before inference.

Bedrock validates the schema first and returns 400 for unsupported features. Two rules apply here: every object must explicitly set additionalProperties to false, and numerical constraints (minimum, maximum, multipleOf) are not supported. enum of strings and arrays of strings are fine. maxTokens and timeouts affect truncation and the up-to-90-second first compilation, not schema validation.

1. Note that the error is immediate and a 400, so it is schema validation.
2. Check the object for additionalProperties: false.
3. Check for unsupported keywords such as minimum and maximum.
4. Reject fixes aimed at truncation or compilation time.

Exam tip: Structured outputs schema: additionalProperties false on every object, and no numeric/length constraints.

Context pruning in RAG: the number of retrieved chunks multiplied by chunk size sets most of the input tokens; pass only as many as answer quality needs.

Twenty-five 1,000-token chunks is about 25,000 input tokens per question, while the evaluation shows five are enough. Lowering numberOfResults is a one-value change that removes most of that input. Bigger parent chunks add tokens, embedding dimensions don't affect generation input, and a reranker that still passes 25 results does not prune anything.

1. Estimate the input from retrieved chunks: count x size.
2. Use the evaluation to set how many chunks are needed.
3. Prefer the single configuration change.
4. Reject changes that don't reduce generation input.

Exam tip: Retrieve what answers need: numberOfResults x chunk size is your RAG input bill.

Price-to-performance measurement: compare models on cost per successfully completed task, including the downstream cost of errors, not on price per call alone.

Model Y is cheaper per call, but each of its errors triggers a $0.05 review. Per invoice: X = 0.004 + 0.04 x 0.05 = $0.006; Y = 0.0015 + 0.20 x 0.05 = $0.0115. The tempting answers either leave review cost out of a total or compare the wrong totals. The cheaper model per token is the more expensive system.

1. Write total cost per invoice = model cost + error rate x error-handling cost.
2. Compute it for each model with its own error rate.
3. Compare totals, not list prices.
4. Check each distractor for an omitted term or a wrong comparison.

Exam tip: Rank models by cost per correct outcome: a cheaper model that fails more often can cost more overall.

Efficient inference by distillation: Amazon Bedrock Model Distillation generates or reuses teacher responses and fine-tunes a smaller student model for a specific use case.

The company has good teacher responses already logged and tagged by use case. A distillation job can take prompt-response pairs from invocation logs, filtered on requestMetadata, and fine-tune a cheaper student model, with no manual labeling. Labeled fine-tuning needs new data, routing alone doesn't improve the small model, and continued pre-training teaches domain text rather than the teacher's answers. Distillation supports specific teacher and student model pairs within a family, so check that the chosen models are supported.

1. Note the assets: logged teacher responses tagged by use case.
2. Note the goal: a cheaper model with the large model's quality on one task.
3. Match to distillation from invocation logs with a metadata filter.
4. Reject options that need new labels or don't transfer quality.

Exam tip: Large model quality on a narrow task at small model cost: distill it, using filtered invocation logs as training data.

SageMaker production variants split traffic by weight per request. For a user-level A/B test, the caller assigns users deterministically and targets a variant with the TargetVariant parameter of InvokeEndpoint.

Variant weights randomise each request, so a multi-turn conversation lands on both models. Hashing the user ID to a bucket and sending TargetVariant pins each user to one variant and controls the share of users in each arm. Sticky session routing pins a session to an instance, not a user to a variant for the whole test; shadow variants never answer users, and smaller weights do not fix per-request assignment.

1. Find the cause: weighted routing decides per request.
2. Move assignment to a stable key, the user ID.
3. Use TargetVariant to direct each request.
4. Keep the bucket split at 10% of users.

Exam tip: User-sticky A/B on SageMaker = hash the user ID and invoke with TargetVariant.

An A/B test of Bedrock models lives in the application: Bedrock is serverless, so traffic splitting, user assignment and runtime switches are the caller's job.

Two things are needed: runtime-changeable configuration and sticky user assignment. AppConfig provides the first (feature flags fetched by the function, changed in minutes, no deploy). Hashing the user ID provides the second. Lambda alias weights and API Gateway canaries both split per request and need deployments; intelligent prompt routing is a cost-quality router that works within one provider's model family and is not an experiment mechanism.

1. List the needs: 20% of users, user stickiness, runtime change.
2. Note that per-request splitters break stickiness.
3. Put the split and model IDs in runtime configuration.
4. Assign arms by a stable hash of the user ID.

Exam tip: Bedrock A/B tests: config-driven split (AppConfig) + hashed user assignment in the app.

A/B tests of FMs should be decided by the business outcome they were designed to move, measured per arm over a planned sample. Quality scores and ratings are supporting evidence.

The insurer wants fewer transfers to agents. The transfer-free conversation rate per arm measures that directly and covers every user in the test, unlike ratings from 3% of answers. Higher judged correctness can coexist with worse outcomes (for example longer or less actionable answers), which is exactly why the outcome metric decides.

1. Restate the test's goal: fewer transfers.
2. Pick the metric that measures that goal per arm.
3. Treat quality scores and ratings as diagnostics.
4. Wait for the planned sample before deciding.

Exam tip: Decide an FM A/B test on the business outcome it targets, not on proxy quality scores.