AWS Bedrock Interview Questions and Answers (2026 Edition)

This handbook contains 130 Amazon Bedrock interview questions with detailed, interview-ready answers, prepared by the training faculty at Cloud Soft Solutions for candidates targeting GenAI Engineer, AWS AI Engineer, Cloud Architect and Agentic AI roles.

The questions follow the sequence real interviews use: Bedrock fundamentals and model selection first, then the inference APIs, then Knowledge Bases and RAG, then Agents and AgentCore, then Guardrails and security, and finally cost, architecture and scenario rounds. Sections 1–4 are what a 0–2 year candidate is expected to own completely; Sections 5–8 separate mid-level candidates from senior ones; Sections 9 and 10 are the system-design and rapid-fire rounds.

Four rules for answering Bedrock questions well

• Name the trade-off. On-demand versus provisioned throughput, managed Knowledge Base versus custom RAG, Bedrock Agents versus AgentCore versus a framework — candidates who state the trade-off outscore candidates who state a fact.
• Answer security questions in controls, not intentions. PrivateLink, KMS customer-managed keys, least-privilege IAM, pinned guardrail versions, CloudTrail.
• Talk about measurement. "I would build an evaluation set from production traffic and measure recall@k" is the most credible sentence you can say in a RAG interview.
• Talk about failure. Every senior question is secretly asking what breaks in production and what you did about it.

Amazon Bedrock ships new capabilities at a high cadence. Learn the shape of each capability — what problem it solves and what it trades away — rather than memorising a feature list, and verify model names, Region availability and pricing against the AWS documentation on the day of your interview.

Pair this with our RAG interview questions, LangChain interview questions, LangGraph interview questions, AI & ML interview questions, and the AWS Cloud Engineer roadmap.

1 · Amazon Bedrock Basics

Foundational AWS Bedrock interview questions asked in the first ten minutes of almost every screening round.

1. What is Amazon Bedrock?

Amazon Bedrock is a fully managed, serverless AWS service that gives you API access to foundation models from Amazon and leading model providers through a single, consistent interface. You do not provision GPUs, manage inference servers or handle model weights — you call an API, and AWS handles capacity, patching and scaling.

Beyond raw inference, Bedrock provides the surrounding production building blocks: Knowledge Bases for managed RAG, Agents and AgentCore for tool-using agents, Guardrails for safety policy, model customization, evaluation, and observability — all integrated with IAM, VPC, KMS, CloudWatch and CloudTrail.

2. Why would an enterprise choose Bedrock over calling a model provider's API directly?

Four reasons come up repeatedly in interviews: data governance — requests stay inside your AWS account boundary, traffic can go over PrivateLink, and your prompts and outputs are not used to train the base models; vendor flexibility — you can switch between Claude, Nova, Llama, Mistral and others without re-plumbing auth, networking or billing; native AWS integration — IAM for authorization, KMS for encryption, CloudTrail for audit, CloudWatch for metrics, VPC endpoints for network isolation, and one consolidated bill; and managed higher-level services — Knowledge Bases, Guardrails and Agents remove months of undifferentiated engineering.

3. Bedrock vs Amazon SageMaker — when do you use which?

Bedrock is a serverless model-consumption platform: you consume hosted foundation models and pay per token, with no infrastructure to manage. SageMaker is a full ML platform: you train, tune, host and manage your own models on instances you choose and pay for.

Use Bedrock when you want to build GenAI applications quickly on top of frontier models. Use SageMaker when you need custom architectures, full control of the serving stack, specialised hardware, classic ML, or a model that Bedrock does not offer. Many production estates use both: Bedrock for reasoning-heavy calls, SageMaker endpoints for specialised or cost-optimised small models.

4. What are the core components of Bedrock you should know?

• Model inference — InvokeModel, InvokeModelWithResponseStream and the unified Converse / ConverseStream APIs.
• Knowledge Bases — managed ingestion, chunking, embedding, vector storage and retrieval for RAG.
• Agents & AgentCore — tool-calling agents, action groups, multi-agent collaboration, and the AgentCore runtime, memory, gateway, identity and observability services.
• Guardrails — configurable content filters, denied topics, PII redaction, contextual grounding and automated reasoning checks.
• Customization — fine-tuning, continued pre-training, model distillation and Custom Model Import.
• Evaluation & observability — automatic, human and LLM-as-judge evaluations, RAG evaluation, model invocation logging.
• Prompt Management and Flows — versioned prompts and low-code orchestration of multi-step GenAI workflows.

5. How do you get access to a model in Bedrock?

Model access is opt-in per account and per Region. An administrator requests access to specific models in the Bedrock console (some third-party models require accepting the provider's EULA), and access is then granted at the account level. On top of that, IAM policies control which principals may call bedrock:InvokeModel on which model ARNs — so "the model is enabled" and "this role may call it" are two separate controls, and interviewers like candidates who distinguish them.

6. What IAM actions matter for Bedrock?

The common ones are bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream for inference, bedrock:Converse and bedrock:ConverseStream for the unified API, bedrock:Retrieve and bedrock:RetrieveAndGenerate for Knowledge Bases, bedrock:InvokeAgent for agents, and bedrock:ApplyGuardrail for standalone guardrail evaluation. Restrict by resource ARN so a role can only call the specific models, knowledge bases and agents it needs, and use condition keys to enforce guardrail usage where required.

7. Is Bedrock regional? Why does that matter?

Yes — Bedrock is a Regional service, and model availability differs by Region. That matters for data residency (a regulated workload may be restricted to a specific Region), for latency (call the Region closest to your users), and for capacity (a model may be quota-constrained in one Region and plentiful in another). This regional variation is exactly why cross-region inference profiles exist.

8. What is a cross-region inference profile?

An inference profile is an abstraction over a model that lets Bedrock route a request to one of several Regions in a geography, improving throughput and resilience during demand spikes. You invoke the profile ID instead of a plain model ID. It reduces throttling and improves availability, at the cost of the request potentially being served from another Region within the same geography — which you must confirm is acceptable under your data-residency policy.

9. What are application inference profiles used for?

Application inference profiles let you attach cost-allocation tags to inference calls, so you can track and attribute Bedrock spend per team, per application or per tenant in Cost Explorer. In multi-tenant SaaS platforms this is the standard answer to "how do we know which customer is generating the token bill?"

10. What is Amazon Bedrock Marketplace?

A catalogue of additional specialised and emerging foundation models — beyond the core serverless line-up — that you can discover, subscribe to and deploy to managed endpoints, then call through Bedrock APIs. It is how AWS extends model choice into long-tail and domain-specific models while keeping one integration surface.

11. How is Bedrock priced at a high level?

Four consumption modes: On-demand — pay per 1,000 input and output tokens (or per image/second for media models) with no commitment. Batch inference — asynchronous bulk processing at a substantial discount (commonly around 50%) for workloads that tolerate delay. Provisioned Throughput — reserved capacity in model units purchased hourly or with a 1- or 6-month commitment, giving guaranteed throughput. Custom / imported model hosting — charged for hosting your customised models. On top of this sit separate charges for Knowledge Base vector stores, Guardrails, and evaluation runs.

12. What is the difference between the Standard, Flex and Priority inference tiers?

They trade latency against price. Priority targets the lowest and most consistent latency for interactive, user-facing workloads at a premium rate. Standard is the default balance. Flex accepts higher and more variable latency in exchange for a lower price, which suits background jobs, evaluations and non-interactive summarisation. Choosing the tier per workload is a straightforward cost lever that many candidates forget to mention.

13. What does Bedrock do with your data?

Your inputs and outputs are not shared with model providers and are not used to train the base foundation models. Data is encrypted in transit and at rest, can be encrypted with a customer-managed KMS key, and stays within the Region you call (unless you deliberately enable cross-region inference). Model invocation logging is off by default — you turn it on to write prompts and completions to S3 or CloudWatch Logs, and that store then becomes your responsibility to secure and retain appropriately.

14. What is Amazon Bedrock Data Automation?

A capability for turning unstructured multimodal content — documents, images, audio and video — into structured output such as extracted fields, summaries and transcripts, using a configurable blueprint rather than hand-built parsing pipelines. It is commonly used as the ingestion front end for document-heavy RAG systems, replacing bespoke OCR and table-extraction code.

15. Name five realistic enterprise use cases for Bedrock.

Internal knowledge assistants over policy and documentation; customer support automation with grounded answers and escalation; document intelligence over contracts, claims and invoices; code and test generation for engineering teams; and content operations such as summarisation, translation and personalised marketing copy. Each one maps to a different mix of Bedrock features, and a good answer names that mapping rather than just listing use cases.

2 · Foundation Models and Model Selection

Model-choice questions test whether you can justify architecture decisions with cost, latency and quality evidence.

16. Which model families are available on Bedrock?

Bedrock hosts models from multiple providers — Anthropic's Claude family, Amazon's own Nova family (text, multimodal, image, video and speech variants), Meta Llama, Mistral, Cohere, AI21, Stability AI, DeepSeek, Qwen, and a growing set of specialised models via Bedrock Marketplace. AWS has also added OpenAI-compatible endpoint support so teams with existing OpenAI-shaped code can call Bedrock with minimal changes.

In an interview, do not recite a model list that will be stale in a month — say that model choice is a per-task, evidence-driven decision and that Bedrock's value is making the swap cheap.

17. How do you choose a model for a given task?

Define the task and the acceptance criteria first, then evaluate candidates against them on your own data. The dimensions: quality on your task (measured, not assumed), latency and time-to-first-token, cost per 1,000 tokens and per successful outcome, context window size, modality support, tool-calling and structured-output reliability, and Region availability. Run a Bedrock model evaluation job with a representative dataset — that answer beats any opinion about which model is "best".

18. What is model routing and why does it save money?

Route each request to the smallest model that can handle it: a micro or lite model for classification, routing, extraction and simple Q&A, and a frontier model only for complex reasoning. Because price differences between tiers are often an order of magnitude, routing typically cuts spend far more than prompt micro-optimisation. Bedrock also offers intelligent prompt routing, which can select between models in a family automatically based on the prompt's predicted difficulty.

19. What are the Amazon Nova models used for?

Nova is Amazon's first-party family, spanning very low-cost text models for high-volume tasks up to premier reasoning models, plus multimodal understanding and generation variants for image, video and speech. Their attraction is price-performance for volume workloads and tight Bedrock integration; the trade-off is that for the hardest reasoning tasks teams often still route to a frontier third-party model. A sensible production pattern is Nova for the 80% of cheap traffic, a frontier model for the 20% that needs it.

20. What embedding models does Bedrock provide, and what do you consider when choosing one?

Amazon Titan Text Embeddings (v2 supports configurable output dimensions such as 256, 512 and 1024), Cohere Embed models including multilingual variants, and multimodal embedding models for image-and-text search. Selection criteria: retrieval quality on your corpus, language coverage, dimension size (which drives storage and query cost), max input length, and price at ingestion scale. Remember that changing the embedding model means re-indexing the entire corpus.

21. How do you compare two models objectively?

Build a golden dataset from real traffic, define metrics that match the business outcome, and run a Bedrock model evaluation job — automatic metrics for well-defined tasks, LLM-as-a-judge for open-ended quality, and human evaluation for high-stakes judgement calls. Report quality alongside p95 latency and cost per request. Never migrate models on vibes; a model that scores two points higher but costs three times more may be the wrong choice.

22. What is the context window and why does it matter operationally?

The context window is the total tokens of input plus output a model can handle in one call. Operationally it caps how much retrieved context, conversation history and instruction you can supply. But bigger is not automatically better: cost scales with input tokens, latency grows, and models degrade on information buried in the middle of very long contexts. Good engineering keeps context tight through retrieval and reranking rather than relying on a huge window.

23. How do you handle multimodal inputs on Bedrock?

Multimodal models accept content blocks containing images or documents alongside text within the same message. In the Converse API you pass an image or document block in the message content and the service formats it for the model. Typical uses are chart and diagram interpretation, screenshot-based support, ID and invoice extraction, and quality inspection. Watch payload size limits and remember that images consume tokens.

24. What is Custom Model Import?

It lets you bring your own weights for supported open architectures — for example a model you fine-tuned in SageMaker — and serve it through Bedrock's API on managed infrastructure. You get one consistent invocation interface and Bedrock's surrounding features while retaining a model you own. The trade-off is hosting cost and the operational responsibility for the model's quality.

25. What is model deprecation and how do you plan for it?

Providers retire model versions. AWS publishes lifecycle notices with legacy and end-of-life dates. Plan for it by pinning explicit model IDs in configuration rather than code, keeping an evaluation suite so you can qualify a successor quickly, abstracting the model behind an internal interface, and subscribing to Bedrock model lifecycle announcements. "How would you handle a model deprecation notice?" is a favourite senior question, and the expected answer is an evaluation-gated migration, not a hot swap.

3 · Inference APIs, Streaming and Tool Use

Hands-on API questions. Expect follow-ups asking you to write the boto3 call on a whiteboard.

26. What is the difference between InvokeModel and the Converse API?

InvokeModel takes a provider-specific JSON body — every model family has its own request and response shape, so switching models means rewriting the payload. The Converse API is a unified, model-agnostic interface built around messages, a system prompt, an inference configuration and a tool specification. The same Converse call works across model families, which is what makes model swapping genuinely cheap.

Use Converse by default. Use InvokeModel when you need a provider-specific parameter that Converse does not surface, which you can still pass via the additionalModelRequestFields escape hatch.

27. Write a basic Converse API call in boto3.

import boto3
brt = boto3.client("bedrock-runtime", region_name="ap-south-1")
resp = brt.converse(
    modelId="MODEL_ID_OR_INFERENCE_PROFILE",
    system=[{"text": "You are a concise support assistant."}],
    messages=[{"role": "user",
               "content": [{"text": "Summarise this ticket: ..."}]}],
    inferenceConfig={"maxTokens": 512, "temperature": 0.2, "topP": 0.9},
)
print(resp["output"]["message"]["content"][0]["text"])
print(resp["usage"])       # inputTokens, outputTokens, totalTokens
print(resp["stopReason"])  # end_turn | max_tokens | tool_use | ...

28. How does streaming work?

Use ConverseStream (or InvokeModelWithResponseStream) and iterate the event stream, handling messageStart, contentBlockDelta, contentBlockStop, messageStop and metadata events. Streaming does not reduce total generation time — it reduces time to first token, which is what users perceive as speed. In a web app, forward the deltas over Server-Sent Events or WebSockets. Remember that guardrail evaluation in streaming mode may buffer and mask content, so test the guardrail behaviour with streaming enabled.

29. How does tool use (function calling) work in Bedrock?

You pass a toolConfig containing tool names, descriptions and JSON input schemas. The model returns a message with stopReason: "tool_use" and a toolUse block naming the tool and its arguments. Your application executes the tool, then sends the result back as a toolResult content block in a new user message. The model then answers or calls another tool. Bedrock never executes your code — that loop lives in your application, or in Bedrock Agents / AgentCore if you want it managed.

30. How do you force structured JSON output?

The most reliable route is tool use: define a single tool whose input schema is your output schema and set toolChoice to require it, so the model must emit a schema-conformant object. Alternatively, use a model's native structured-output or JSON mode where available, set temperature low, and validate with Pydantic. Always validate and have a repair path — schema enforcement reduces failures but does not eliminate them.

31. What is batch inference and when do you use it?

Batch inference processes a JSONL file of records from S3 asynchronously and writes results back to S3, at a significantly lower per-token price than on-demand. Use it for backfills, bulk classification and enrichment, embedding generation at ingestion time, offline evaluation and periodic report generation. Do not use it for anything a user is waiting on — completion time is measured in minutes to hours depending on job size and queue depth.

32. How do you handle throttling and quota errors?

ThrottlingException means you exceeded requests-per-minute or tokens-per-minute quotas. Handle it with exponential backoff and jitter (the AWS SDK retry configuration does much of this), a client-side rate limiter so you stay under quota rather than discovering it at the API, cross-region inference profiles to spread load, a queue for burst absorption, and Provisioned Throughput for workloads that need guaranteed capacity. Request quota increases through Service Quotas with a justification and forecast — and monitor the throttle metric so you see the problem before customers do.

33. What is prompt caching and how much does it help?

Prompt caching lets Bedrock cache a long, static prefix — a system prompt, a large instruction block, a fixed document — so repeat requests that share that prefix skip re-processing it. The result is markedly lower input-token cost and lower time-to-first-token on multi-turn or high-repetition workloads. You mark cache checkpoints in the request; the cache has a short TTL, so it helps most with sustained traffic against a stable prefix. Structure prompts with static content first and variable content last to maximise the hit rate.

34. What are Prompt Management and Prompt Flows?

Prompt Management stores prompts as versioned Bedrock resources with variables, so prompts are governed artefacts rather than strings buried in code — you can promote a version without redeploying the application. Prompt Flows is a visual, low-code way to chain prompts, Knowledge Bases, agents, Lambda functions and conditional logic into a deployable workflow. Flows suit well-defined business processes and cross-functional teams; hand-written orchestration or a framework suits complex, code-heavy applications.

35. How do inference parameters affect output?

temperature controls randomness — near 0 for extraction, classification and SQL generation; higher for creative work. topP is nucleus sampling, an alternative diversity control; tune one, not both. maxTokens caps output length and therefore cost. stopSequences ends generation at a marker, useful for structured formats. The common production default for enterprise tasks is temperature 0–0.2 with an explicit maxTokens ceiling.

4 · Knowledge Bases and RAG on Bedrock

The heaviest-weighted section in most AWS GenAI interviews. Retrieval quality is where real systems succeed or fail.

36. What is a Bedrock Knowledge Base?

A managed RAG service. You point it at a data source — most commonly an S3 bucket, but also SharePoint, Confluence, Salesforce, Web Crawler and others — and Bedrock handles parsing, chunking, embedding, vector storage, index synchronisation and retrieval. You then call Retrieve to get passages or RetrieveAndGenerate to get a grounded, cited answer in one call.

AWS now offers both a customer-managed Knowledge Base, where you choose the vector store, embedding model and chunking strategy and get every tuning knob, and a newer fully managed option where AWS manages the vector store, embeddings and reranker with a smaller configuration surface. Choose customer-managed when retrieval quality must be tuned; choose managed when speed of delivery matters more.

37. Which vector stores can a Bedrock Knowledge Base use?

Amazon OpenSearch Serverless (the common default), Amazon S3 Vectors for low-cost large-scale vector storage, Aurora PostgreSQL with pgvector, Amazon Neptune Analytics for GraphRAG, plus third-party options including Pinecone, Redis Enterprise Cloud and MongoDB Atlas. Selection drivers: cost at your vector count, query latency targets, whether you need relational joins or graph traversal, and whether the team already operates the store.

38. Explain the chunking strategies available.

• Default — a sensible fixed split that works for a quick start.
• Fixed-size — you set max tokens and overlap percentage. Predictable and cheap; can cut mid-idea.
• Hierarchical — parent and child chunks: search matches small children, but the larger parent is returned for context. Usually the strongest production default.
• Semantic — splits where embedding similarity between adjacent sentences drops, producing topically coherent chunks at higher ingestion cost. Best for uniformly dense prose.
• No chunking — treat each file as one chunk, for pre-chunked content.
• Custom (Lambda) — your own chunking code, including logic borrowed from LangChain or LlamaIndex.

39. Retrieve vs RetrieveAndGenerate — when do you use each?

Retrieve returns ranked passages with scores and metadata and leaves generation to you — choose it when you need custom prompting, your own citation format, multi-source fusion, or a different model per user tier. RetrieveAndGenerate performs retrieval, prompting and generation in one managed call with citations returned, and supports session continuity for follow-up questions. Choose it for speed of delivery; move to Retrieve when you need control.

40. How does metadata filtering work and why does it matter?

You attach attributes to each document via a companion .metadata.json file in S3 (or the equivalent at ingestion), then pass a filter in the retrieval configuration using operators such as equals, greaterThan, in, andAll and orAll. This is how you scope retrieval by department, document type, date or tenant.

It is also your access-control mechanism: derive the filter from the caller's verified entitlements server-side so a user can never retrieve a document they are not allowed to see. Never rely on the model to withhold restricted content that you put in its context.

41. What is hybrid search in Bedrock Knowledge Bases?

Hybrid search combines semantic vector similarity with keyword (sparse) matching, so exact terms — product codes, error strings, policy numbers, rare proper nouns — are matched reliably while paraphrased questions still work. It is a search-type setting on the retrieval configuration when the underlying store supports it. For enterprise corpora full of identifiers, hybrid consistently beats pure semantic search.

42. What is the Rerank API and where does it fit?

Reranking is a second-stage relevance model that scores query-document pairs jointly and reorders results. The pattern is retrieve wide, rerank narrow: fetch 25–50 candidates cheaply, rerank, keep the top 3–5 for the prompt. Bedrock exposes reranker models through the Rerank API and as a setting inside Retrieve and RetrieveAndGenerate. It is usually the single highest-return improvement to a mediocre RAG system, and it also cuts token cost because you send fewer, better passages.

43. What is query decomposition?

For a compound question — "compare our 2024 and 2025 refund policies and list what changed" — a single embedding search retrieves poorly. Query decomposition breaks the question into sub-queries, retrieves for each, and combines the evidence before generation. Enable it for analytical and comparative workloads; it costs extra retrievals and latency, so it is not a blanket default.

44. How do you handle complex PDFs, tables and images in a Knowledge Base?

Enable advanced parsing — either a foundation model parser or Bedrock Data Automation — so tables are extracted as structured markup and images are described rather than dropped. Combine with hierarchical chunking so a table is not severed from its caption. For heavily visual corpora, generate descriptions of charts and diagrams at ingestion and index those descriptions. Naive text extraction on a table-heavy PDF is the most common silent cause of bad RAG answers.

45. How do you keep a Knowledge Base in sync with changing documents?

Run ingestion jobs — full or incremental — triggered by an S3 event or on a schedule via EventBridge. Incremental sync processes only added, changed and deleted objects, which keeps cost down and removes stale content. Monitor ingestion job status and failed-document counts, and alert on failures: a silently broken sync means users are being answered from last quarter's policy, and nothing in the response will look wrong.

46. How does GraphRAG on Bedrock work and when is it worth it?

With Neptune Analytics as the store, Bedrock can build a knowledge graph of entities and relationships alongside the vector index and traverse those relationships during retrieval. This handles multi-hop questions ("which suppliers are affected by the policy that changed in the contract Acme signed?") and corpus-wide summarisation that chunk retrieval answers poorly. The cost is a more complex, more expensive pipeline, so justify it with question types your current system demonstrably fails.

47. How do you evaluate RAG quality on Bedrock?

Separate retrieval from generation. For retrieval, build a golden set of question-to-relevant-document pairs and measure recall@k and precision@k, plus how often the correct passage survives reranking. For generation, use Bedrock's RAG evaluation with metrics such as faithfulness/groundedness, relevance, correctness and completeness, judged automatically, by an LLM judge, or by humans for high-stakes content. Run the suite on every configuration change — chunking, embedding model, top-k — so improvements are proven, not assumed.

48. A Knowledge Base returns irrelevant chunks. Walk through your debugging.

(1) Confirm ingestion — is the document actually in the index, and how was it chunked? Inspect the chunks. (2) Run Retrieve alone with the raw query and look at scores; if the right passage is absent, it is a retrieval problem, not a prompt problem. (3) Try hybrid search — the query may hinge on an exact term. (4) Increase the candidate pool and add reranking. (5) Revisit chunking — switch to hierarchical if chunks lack context, semantic if they cut mid-topic. (6) Check metadata filters are not over-restricting. (7) Only then touch the generation prompt. Fixing in this order is what separates experienced candidates.

49. How do you implement multi-tenant isolation in a Bedrock RAG system?

Three levels. Shared knowledge base with mandatory metadata filters — cheapest, but one filter bug is a data breach, so the filter must be constructed server-side from an authenticated identity and covered by tests. Separate data sources or knowledge bases per tenant — clean logical isolation, higher management overhead. Separate accounts or vector stores per tenant — strongest isolation for regulated customers, highest cost. Pair whichever you choose with per-tenant IAM scoping, KMS keys and application inference profiles for cost attribution.

50. When would you build RAG yourself instead of using a Knowledge Base?

When you need retrieval behaviour Bedrock does not expose — a custom fusion of several retrievers, a bespoke reranker, query rewriting driven by your own logic, or an existing vector store and pipeline you already operate. Managed Knowledge Bases trade tuning surface for speed and lower operational burden; a custom pipeline (often with LangChain or LlamaIndex calling Bedrock models) trades engineering effort for control. A strong answer names the specific capability gap driving the decision rather than a general preference.

5 · Bedrock Agents, Multi-Agent Systems and AgentCore

Agentic AI is the fastest-growing area of AWS GenAI hiring. These questions decide the seniority band.

51. What is an Amazon Bedrock Agent?

A managed agent that takes a user request, plans the steps needed, calls the APIs and knowledge bases you have given it, and returns a result — without you writing the orchestration loop. You configure a foundation model, instructions, action groups (the tools), optional knowledge bases, guardrails and memory. Bedrock runs the reasoning loop, manages session state and returns a trace of every step.

52. What is an action group and how do you define one?

An action group is a set of operations the agent may call. You define them either with an OpenAPI schema describing the operations and parameters, or with a simpler function detail definition. Each action group is backed by a Lambda function that executes the call, or by return of control, where Bedrock hands the requested action back to your application to execute instead. The description text is what the model uses to choose — write it as carefully as a prompt.

53. What is return of control and why is it useful?

Instead of Bedrock invoking a Lambda function, the agent returns the intended action and its parameters to your application, which executes it and sends the result back. This matters when the action must run inside your own network, needs credentials Bedrock should never hold, requires human approval first, or is implemented in an existing service you do not want to wrap in Lambda. It is the standard answer to "how do you keep sensitive execution on your side?"

54. How do agent memory and sessions work?

A sessionId maintains conversational context across turns within a session, and sessionAttributes / promptSessionAttributes let you inject application state such as the authenticated user ID or account tier — which is also how you avoid trusting the model with identity. Agent memory extends retention across sessions by summarising past conversations so the agent recalls prior context for the same user. AgentCore Memory generalises this further with short-term, long-term and episodic memory.

55. How do you debug a Bedrock Agent?

Enable trace in the InvokeAgent call and read the trace events: the pre-processing decision, the orchestration rationale, which action group was chosen with what parameters, the observation returned, and the post-processing step. Nine times out of ten a misbehaving agent is caused by ambiguous action-group descriptions, a Lambda returning an unexpected shape, or missing parameters the model then hallucinates. Pair traces with CloudWatch Logs from the Lambda and Bedrock model invocation logging.

56. What is multi-agent collaboration on Bedrock?

A supervisor agent decomposes a request and delegates to specialised collaborator agents — for example a research agent, a pricing agent and a compliance agent — then synthesises their outputs. Supervisor mode can route with or without an intermediate consolidation step. Use it when tool counts grow large enough to hurt selection accuracy, when sub-tasks need different models or permissions, or when different teams own different capabilities. Every hop adds latency and cost, so the burden of proof is on splitting.

57. What is Amazon Bedrock AgentCore?

AgentCore is AWS's production platform for agents, usable with any framework and any model — including agents you wrote in LangGraph, CrewAI or Strands. Its composable services include Runtime (serverless execution with per-session isolation and support for long-running workloads), Memory (short-term, long-term and episodic), Gateway (turns APIs and Lambda functions into agent-ready tools, with MCP support), Identity (secure auth and delegated access to third-party services), Observability (traces and metrics through CloudWatch), and built-in Code Interpreter and Browser tools.

More recent additions include Policy controls that validate tool calls outside the model's reasoning loop, Evaluations with built-in quality evaluators, and optimisation features that turn evaluation findings into recommended prompt and tool-description improvements.

58. Bedrock Agents vs AgentCore vs a framework like LangGraph — how do you choose?

Bedrock Agents: fastest path, fully managed orchestration, least control over the loop. Framework (LangGraph, Strands, CrewAI): maximum control over state, branching, cycles and human-in-the-loop, but you own deployment, memory, identity and observability. AgentCore: keep your framework and your control over the agent logic, but let AWS run the production concerns — isolation, scaling, memory, tool gateway, identity and tracing. Many teams prototype with a framework locally and deploy the same code onto AgentCore Runtime. (See our LangGraph interview questions.)

59. What is AgentCore Gateway and why does MCP matter?

Gateway converts existing APIs, Lambda functions and services into tools an agent can call, handling schema translation, authentication and discovery — so you do not hand-write a tool wrapper for every internal service. Support for the Model Context Protocol matters because it standardises how agents discover and invoke tools across vendors, which means a tool exposed once can be consumed by agents built on different frameworks and models.

60. What guardrails do you place around an agent that takes real actions?

• Least privilege — a scoped IAM role per action group; read-only unless write is essential.
• Policy enforcement outside the model — validate every tool call against explicit rules rather than trusting instructions in a prompt.
• Human approval for irreversible actions, implemented via return of control or an approval step.
• Idempotency keys so a retry cannot double-charge or double-submit.
• Limits — max iterations, session timeout, and a token/cost budget per run.
• Full audit — traces, CloudTrail, and logs of every tool call with its arguments and result.

61. How do you defend a Bedrock agent against prompt injection?

Treat every retrieved document, web page and API response as untrusted. Delimit and label it as data rather than instruction; enforce authorisation inside the tool implementation instead of relying on the model to comply; deny by default and allow-list the tools and destinations the agent may reach; require human confirmation for consequential actions; apply Guardrails to both input and output; and never let model output be executed directly as SQL, shell or HTML. The principle interviewers want to hear: a prompt is not a security control.

62. What are the common failure modes of agents in production?

Looping between tools without progress; picking the wrong tool because two descriptions overlap; inventing parameter values instead of asking; context growth as the trace accumulates; silent breakage when a downstream API changes shape; and cost blowouts on a single pathological request. Mitigate with hard iteration and budget caps, mutually exclusive tool descriptions that state when not to use them, explicit instructions to ask when a required parameter is missing, contract tests on every action group, and alerting on per-session token spend.

6 · Guardrails, Security and Compliance

Security questions are where AWS interviews are won. Answer in terms of controls, not intentions.

63. What are Amazon Bedrock Guardrails?

A configurable safety and policy layer applied to model inputs and outputs, independent of the model you use. Its policy types are: content filters with adjustable strength across categories such as hate, insults, sexual content, violence, misconduct and prompt attacks; denied topics defined in natural language; word filters including a managed profanity list and custom terms; sensitive information filters that block or mask PII entity types and custom regex patterns; contextual grounding checks that score responses for groundedness against source passages and relevance to the query; and automated reasoning checks that validate statements against a formal policy model for domains where correctness must be provable.

64. How do you apply a guardrail?

Attach the guardrail identifier and version to a Converse or InvokeModel call, to a Knowledge Base retrieve-and-generate call, or to an agent. You can also call the standalone ApplyGuardrail API to evaluate arbitrary text without invoking a model — which is how you apply the same policy to content generated by a non-Bedrock model, to user input before it reaches your system, or to text stored elsewhere in your pipeline.

65. What is a contextual grounding check and why is it important?

It scores a generated response on two axes: grounding — is the response supported by the source passages provided? — and relevance — does it actually answer the question? You set thresholds, and responses below them are blocked or replaced with a fallback message. This is the practical anti-hallucination control for RAG systems, because it evaluates the answer against evidence rather than hoping a prompt instruction was obeyed.

66. How do you version and roll out guardrail changes safely?

Guardrails are versioned resources. Develop against the DRAFT version, test against a corpus of adversarial and benign prompts, publish a numbered version, and reference that explicit version in production rather than DRAFT. Roll out behind configuration so you can revert instantly, and measure both block rate and false-positive rate — an over-tight guardrail that blocks legitimate customer questions is also an outage, just a quieter one.

67. How do you keep Bedrock traffic off the public internet?

Use VPC interface endpoints (AWS PrivateLink) for the Bedrock control plane and runtime, so calls from private subnets never traverse the internet. Combine with endpoint policies restricting which models and actions may be called through the endpoint, security groups, and (for Knowledge Bases) private connectivity to the vector store. For agents, ensure the Lambda functions in action groups run in the VPC when they access private resources.

68. How is encryption handled?

Everything is encrypted in transit with TLS and at rest by default. You can supply a customer-managed KMS key for agents, knowledge bases, custom models, model invocation logs and evaluation jobs — which gives you key rotation, an audit trail of key usage, and the ability to revoke access by disabling the key. For regulated workloads, a customer-managed key is usually a hard requirement, so know that it is supported and where you configure it.

69. How do you audit and log Bedrock usage?

CloudTrail records control-plane and data-plane API activity — who called what, when, from where. Model invocation logging, which you enable explicitly, writes prompts, completions and metadata to S3 or CloudWatch Logs. CloudWatch metrics cover invocations, latency, token counts, throttles and errors. Agent traces capture the reasoning and tool-call sequence. Note that invocation logs contain user content, so encrypt them, restrict access, and set a retention policy that satisfies your privacy obligations.

70. How do you prevent PII from leaking into prompts and logs?

Layer the controls: detect and redact PII before the request leaves your service (Amazon Comprehend PII detection, Bedrock Guardrails sensitive-information filters, or your own pipeline), keeping a reversible token map only if you must restore values; mask PII in outputs with guardrails; disable or redact model invocation logging for sensitive workloads; encrypt logs with a customer-managed key and restrict access by role; and set short retention. Also design for deletion requests — you must be able to purge a subject's data from the vector index as well as from your database.

71. Which compliance programs cover Bedrock, and how do you answer a compliance question?

Bedrock is covered by the major AWS assurance programs — SOC, ISO, PCI DSS, HIPAA eligibility under a BAA, FedRAMP in supported Regions and GovCloud availability for AgentCore. The right interview answer, though, is architectural: name the shared responsibility model, state that AWS certifies the service while you are responsible for data classification, access control, retention and the content of prompts, and point to the specific controls you would implement — PrivateLink, CMK, least-privilege IAM, guardrails, logging and retention.

72. How do you enforce that every call goes through a guardrail?

Do not rely on developers remembering. Enforce it at the platform layer: an IAM policy with a condition requiring the guardrail identifier on inference calls, an internal SDK wrapper that is the only sanctioned path to Bedrock, service control policies at the organisation level, and detective controls — a CloudTrail-driven check that alerts on invocations without a guardrail attached. Preventive plus detective is the answer a security-minded interviewer is listening for.

73. What are the top security risks specific to LLM applications on Bedrock?

Prompt injection, both direct and indirect through retrieved content; sensitive-data disclosure via over-broad retrieval or unfiltered logs; insecure output handling, where model text is executed as SQL, shell or rendered HTML; excessive agency, where an agent holds permissions beyond its task; unbounded consumption leading to cost-based denial of service; and supply-chain risk from unvetted tools and integrations. Controls: authorisation in code, output encoding, sandboxed execution, quotas and budgets, allow-lists, and human approval on consequential actions.

74. How do you handle cross-account access to Bedrock?

Use IAM role assumption with an external ID for third parties, or a resource-based policy pattern where a central shared-services account owns the Bedrock configuration, knowledge bases and guardrails, and workload accounts assume a scoped role to invoke them. Combine with application inference profiles so usage is attributable per consuming account, and with SCPs to prevent workload accounts calling models the organisation has not approved.

7 · Model Customization, Distillation and Evaluation

Where candidates prove they know when NOT to fine-tune.

75. What customization options does Bedrock offer?

Fine-tuning — supervised training on labelled prompt/completion pairs to adapt behaviour, tone or task format. Continued pre-training — further training on large volumes of unlabelled domain text to build domain familiarity. Model distillation — use a large teacher model to generate training data that fine-tunes a smaller, cheaper student model that approaches teacher quality on a narrow task. Custom Model Import — bring weights you trained elsewhere. Customised models are served through Bedrock and, depending on the model, may require provisioned capacity for inference.

76. When should you fine-tune versus use RAG?

RAG is for knowledge — facts that change, need citing and need access control. Fine-tuning is for behaviour — a consistent output format, a house tone, a domain-specific task the base model performs poorly, or reducing prompt length by baking instructions into the weights. Fine-tuning does not keep facts current and cannot cite sources.

The order of attempts should be: prompt engineering, then few-shot examples, then RAG, then fine-tuning — because each step up costs more and locks in more. Saying "we would fine-tune" as a first answer to a knowledge problem is a red flag in interviews.

77. What does a fine-tuning job on Bedrock require?

A training dataset in JSONL format in S3 with the schema the target model expects, optionally a validation set, an IAM service role granting Bedrock access to those buckets and any KMS key, hyperparameters such as epochs, batch size and learning-rate multiplier, and an output location for metrics. After training you evaluate the custom model, then purchase Provisioned Throughput or use the supported inference mode to serve it. Data quality matters far more than volume — a few hundred excellent examples beat thousands of noisy ones.

78. Explain model distillation and its business case.

You provide sample prompts; Bedrock uses a large teacher model to generate high-quality responses, then fine-tunes a smaller student model on those pairs. The result is a model that costs a fraction as much per token and responds faster while retaining most of the teacher's quality on that specific task distribution. It is the standard answer to "our frontier-model bill for a high-volume, narrow task is too high". The caveat: the student inherits the teacher's blind spots and generalises poorly outside the distilled task.

79. What is Bedrock model evaluation?

A managed evaluation capability offering automatic evaluation with built-in metrics and datasets or your own, LLM-as-a-judge evaluation for open-ended quality with rubric-based scoring, human evaluation with a managed workflow and your own workforce, and RAG evaluation for retrieval and generation quality. Use it to select models, qualify a customised model against its base, and gate changes to prompts, chunking or retrieval settings.

80. What are the pitfalls of LLM-as-a-judge, and how do you mitigate them?

Position bias toward the first option, verbosity bias toward longer answers, self-preference toward the judge's own model family, and inconsistency on vague rubrics. Mitigate by writing a specific rubric with a discrete scale, requiring a justification before the score, randomising option order, using a different and stronger model as judge, and calibrating the judge against human labels on a sample before trusting it to gate releases.

81. How do you build an evaluation dataset that is actually useful?

Seed it from real production traffic rather than imagination, and deliberately over-sample the failures, edge cases and adversarial prompts. Include the categories your business cares about — refusals that should not have happened, questions with no answer in the corpus, ambiguous phrasings, multilingual inputs. Keep it versioned in S3 alongside the code, and grow it every time production surfaces a new failure. An evaluation set that only contains easy questions will report 95% and teach you nothing.

82. How do you decide a customised model is ready for production?

It must beat the base model plus prompt engineering on the same evaluation set by a margin that justifies its cost and operational burden; it must not regress on safety and refusal behaviour; latency and throughput must meet the SLO under provisioned capacity; and you must have a rollback path to the base model behind configuration. Also confirm the training data was licensed and free of PII, because that question will be asked in a security review even if it is not asked in the interview.

8 · Cost, Performance and Production Architecture

Senior-level questions. These determine the offer band.

83. How do you reduce Bedrock cost without hurting quality?

In rough order of return: route by task difficulty so cheap models handle the bulk of traffic; rerank so you send four excellent passages instead of twenty mediocre ones; enable prompt caching for long static prefixes; use batch inference and the Flex tier for anything not user-facing; cap maxTokens and trim conversation history; distil a small model for the highest-volume narrow task; and use Provisioned Throughput only where sustained utilisation actually justifies it. Validate every change against your evaluation set so "no quality loss" is measured, not claimed.

84. When does Provisioned Throughput make sense?

When you need guaranteed capacity and predictable latency — a customer-facing SLA, a large scheduled batch window, or a customised model that requires it. It is bought in model units with hourly or 1/6-month commitment pricing. The break-even analysis is straightforward: compare committed cost against on-demand cost at your forecast token volume, and remember that unused reserved capacity is pure waste. Bursty, unpredictable traffic is usually better served by on-demand plus cross-region inference profiles.

85. How do you reduce latency in a Bedrock application?

Stream so time-to-first-token, not total time, is what users feel. Use a smaller or faster model for simple intents. Shorten prompts — input length drives latency as well as cost. Enable prompt caching. Parallelise independent calls. Cache complete responses for repeated questions. Call the Region closest to your users. Consider the Priority inference tier for interactive paths. Profile first: in RAG systems the bottleneck is frequently retrieval or reranking, not generation.

86. Design the reference architecture for a production Bedrock chatbot.

Client → CloudFront → API Gateway (WAF, throttling, Cognito or OIDC auth) → Lambda or ECS/Fargate service → Bedrock Converse with a guardrail attached, plus a Knowledge Base for grounding. Conversation state in DynamoDB with a TTL; documents in S3 with an EventBridge-triggered ingestion pipeline; secrets in Secrets Manager; PrivateLink endpoints for Bedrock and the vector store; CloudWatch metrics, alarms and dashboards plus model invocation logging; and X-Ray or AgentCore Observability for tracing. Streaming responses over Server-Sent Events or WebSockets via API Gateway.

Mention the operational extras that separate a real design from a diagram: per-tenant cost attribution with application inference profiles, an evaluation pipeline in CI, a feedback capture path, and a documented rollback for prompt, model and guardrail versions.

87. How do you monitor a Bedrock workload?

Track invocation count, throttles, client and server errors, latency (p50/p95/p99), input and output token counts, and guardrail intervention rate through CloudWatch. Add business metrics — deflection rate, escalation rate, thumbs-up ratio, and "no answer" rate, which spikes when ingestion breaks. Alarm on throttling, error rate, latency SLO breaches and daily spend anomalies via AWS Budgets. Sample production traffic into offline evaluation to catch quality drift that no infrastructure metric will show.

88. How do you handle a Bedrock outage or model unavailability?

Multi-layer fallback: retries with exponential backoff and jitter for transient errors; a secondary model in the same Region and a cross-region inference profile for capacity issues; a circuit breaker so a hard-down dependency does not exhaust your connection pool; graceful degradation to cached answers, keyword search over the knowledge base, or a queued "we will follow up" path; and a clear user-facing message. Test the fallback deliberately with fault injection — an untested fallback is a wish, not a control.

89. How do you version prompts and models safely in production?

Treat prompts as code: store them in version control or Bedrock Prompt Management with explicit versions, reference a pinned model ID or inference profile in configuration rather than code, run the evaluation suite on every candidate change, roll out behind a feature flag with A/B comparison on live traffic, and keep instant rollback. Tag every request with the prompt version, model ID and guardrail version so a quality regression can be attributed to a specific change.

90. How would you migrate an existing OpenAI-based application to Bedrock?

Inventory the calls and the features used — tool calling, structured output, streaming, embeddings, vision. Stand up Bedrock access and model enablement, then map each call to the Converse API (or use the OpenAI-compatible endpoint support to shorten the change). Build an evaluation set from production traffic and compare candidate Bedrock models against the incumbent on quality, latency and cost before migrating. Re-index embeddings with the new embedding model. Migrate behind a flag with dual-running and per-request routing, and keep rollback until the metrics hold for a full traffic cycle.

91. How do you attribute Bedrock cost across teams in a shared platform?

Application inference profiles with cost-allocation tags per team, application or tenant, surfaced in Cost Explorer and AWS Budgets. Complement with your own token accounting from the usage block on every response, written to a metrics store keyed by tenant, so you can compute cost per conversation and cost per resolved ticket. Then enforce budgets — soft alerts, then hard throttles per tenant — because unbounded token consumption is a real denial-of-wallet risk.

92. What does a well-run Bedrock platform team provide to product teams?

A sanctioned SDK wrapper that enforces guardrails, logging, tagging and retries; approved model list and inference profiles; shared knowledge base patterns and ingestion pipelines; a prompt registry with versioning; an evaluation harness wired into CI; dashboards for quality, latency and cost per team; and documented paths for exceptions. This turns GenAI from a collection of experiments into a governed capability — and it is exactly the answer expected when an interviewer asks how you would "scale GenAI across the organisation".

9 · Scenario and Architecture Questions

Open-ended rounds. Structure every answer: requirements, architecture, trade-offs, evaluation, operations.

93. Design an internal HR policy assistant for 20,000 employees with role-based access.

Ingestion: policies in S3 with a metadata JSON per document carrying department, country, effective date and audience; advanced parsing for tables; hierarchical chunking; incremental sync triggered by S3 events.

Retrieval: Knowledge Base with hybrid search, a mandatory metadata filter built server-side from the employee's verified attributes, retrieve wide and rerank to the top four.

Generation: Converse with a grounding prompt, citations returned, a guardrail with contextual grounding thresholds, denied topics for anything requiring HR judgement, and PII masking.

Operations: DynamoDB session store, CloudWatch dashboards, weekly evaluation runs against a golden set, feedback capture, and an escalation path to a human HR partner when grounding scores are low.

94. A user reports the assistant invented a leave policy. What do you do?

Immediate: pull the invocation log and agent trace for that request, confirm what was retrieved and what was in the prompt, and ship a temporary control — raise the grounding threshold or add a denied topic — if the failure is systemic.

Diagnosis: was the correct document ingested, retrieved, ranked and included? Most "hallucinations" are retrieval misses. Prevention: add the case to the evaluation set, enable or tighten contextual grounding checks, require citations and verify them programmatically, and instrument a user feedback button so the next one surfaces in hours rather than months. Close with the process point: one hallucination is a bug; an unmeasured hallucination rate is a management failure.

95. Design a claims-processing agent for an insurer.

Bedrock Data Automation extracts structured fields from the claim documents. An agent validates fields against policy data through an action group backed by an internal API, looping back to request clarification when data is missing. A fraud-scoring service is called as a separate tool. Claims above a value threshold pause for human approval via return of control. Approved claims are submitted and the customer notified.

Controls: least-privilege roles per action group, idempotency keys on submission, policy validation outside the model's reasoning, full audit trail with CloudTrail and agent traces, and KMS-encrypted storage of claim content. Say explicitly what you would not automate — irreversible payouts stay human-initiated.

96. Your Bedrock bill jumped 4x in a month. How do you investigate?

Break spend down by model, Region and application inference profile in Cost Explorer, then by tenant using your own token accounting. Typical causes: a change that lengthened prompts or context, a switch to a more expensive model, retry storms from an error condition, an agent looping, a batch job accidentally running on-demand, a leaked API path being abused, or a new feature with no caching. Fix the specific cause, then add structural controls — budgets with alarms, per-tenant token limits, iteration caps on agents, and cost-per-request tracking in the dashboard so the next spike is visible in hours.

97. Design a multilingual support assistant for Indian and Gulf markets.

Use a model with strong coverage of the target languages and a multilingual embedding model so cross-lingual retrieval works. Decide between translating documents at ingestion (one consistent index, translation cost and drift) or indexing natively with multilingual embeddings. Detect the user's language and instruct the model to answer in it while citing the original source. Configure guardrails and denied topics per language — a policy tested only in English is not tested. Extend the evaluation set with native-language questions, and budget for higher token counts, since non-Latin scripts often tokenise 2–3× more expensively.

98. How would you add GenAI to an existing AWS application with minimum risk?

Pick one narrow, high-value, low-blast-radius use case — internal summarisation or draft generation rather than autonomous customer-facing action. Build it behind a feature flag for an internal cohort. Attach a guardrail from day one. Instrument quality, latency and cost from day one. Define the success metric before launch and the kill criteria alongside it. Expand only after the metrics hold. The interviewer is testing product judgement and risk management as much as architecture.

99. Bedrock vs Azure OpenAI vs Google Vertex AI — how do you frame the comparison?

Frame it on four axes rather than model brand loyalty: model choice (Bedrock's multi-provider catalogue versus a single primary provider), ecosystem fit (which cloud already holds your data, identity, network and compliance posture — this usually dominates), managed higher-level services (Knowledge Bases, Guardrails, Agents and their equivalents), and commercial terms (pricing modes, committed discounts, existing enterprise agreement). Then say that the decision should be validated with a bake-off on your own evaluation set, because published benchmarks rarely predict performance on your data.

100. How would you take a Bedrock proof of concept to production in 90 days?

Weeks 1–3: define acceptance criteria, build the evaluation dataset from real traffic, and select the model with a formal bake-off. Weeks 4–7: harden the architecture — PrivateLink, IAM least privilege, KMS, guardrails, logging, session storage, ingestion pipeline with incremental sync. Weeks 8–10: load and failure testing, quota planning, fallback paths, cost model and budgets, dashboards and alarms. Weeks 11–13: limited rollout behind a flag with feedback capture, evaluation gates in CI, runbooks and on-call handover, then progressive expansion. The message: production readiness is evaluation, security and operations — the model call was the easy part.

10 · Rapid-Fire Round

One-line answers used to test breadth quickly in screening calls.

101. Is Bedrock serverless?

Yes — no infrastructure to provision for standard inference; you pay per token or for reserved throughput.

102. Which API is model-agnostic?

The Converse API, along with ConverseStream for streaming.

103. What does stopReason 'tool_use' mean?

The model is requesting a tool call; your application must execute it and return a toolResult.

104. How do you enable a model?

Request model access per account and Region in the Bedrock console, then grant IAM permission on the model ARN.

105. What is a model unit?

The unit of capacity purchased under Provisioned Throughput, defining guaranteed tokens per minute for a model.

106. Typical batch inference discount?

Around 50% off on-demand pricing for asynchronous bulk jobs.

107. Which service provides managed RAG?

Amazon Bedrock Knowledge Bases.

108. Name three supported vector stores.

OpenSearch Serverless, S3 Vectors and Aurora PostgreSQL with pgvector — plus Pinecone, Redis Enterprise, MongoDB Atlas and Neptune Analytics.

109. Which chunking strategy is the strongest production default?

Hierarchical chunking, paired with hybrid search and reranking.

110. What does the Rerank API do?

Reorders retrieved passages by joint query-document relevance so you send fewer, better chunks to the model.

111. Retrieve or RetrieveAndGenerate for custom prompting?

Retrieve — it returns passages and leaves generation to you.

112. How is metadata attached to Knowledge Base documents?

Via a companion .metadata.json file alongside each object in S3.

113. What blocks ungrounded answers?

The contextual grounding check in Bedrock Guardrails.

114. Which API evaluates text without invoking a model?

ApplyGuardrail.

115. What is return of control?

The agent hands the requested action back to your application to execute instead of invoking a Lambda function.

116. What identifies an agent conversation?

The sessionId, with sessionAttributes carrying application state.

117. Name three AgentCore services.

Runtime, Memory and Gateway — plus Identity, Observability, Code Interpreter and Browser.

118. What does AgentCore Policy do?

Validates tool calls against defined rules outside the model's reasoning loop before they reach tools or data.

119. Which protocol standardises agent tool access?

The Model Context Protocol (MCP), supported through AgentCore Gateway.

120. How do you keep Bedrock traffic private?

VPC interface endpoints via AWS PrivateLink, with endpoint policies restricting actions and models.

121. Is model invocation logging on by default?

No — you enable it explicitly and choose S3 or CloudWatch Logs as the destination.

122. Are your prompts used to train base models?

No.

123. What reduces cost on a long static system prompt?

Prompt caching.

124. Which inference tier is cheapest?

Flex, which trades higher and more variable latency for a lower price.

125. What does a cross-region inference profile solve?

Throttling and capacity limits, by routing requests across Regions in a geography.

126. What enables per-team cost attribution?

Application inference profiles with cost-allocation tags.

127. When do you distil a model?

When a high-volume, narrow task is being served by an expensive frontier model.

128. First thing to try before fine-tuning?

Prompt engineering, then few-shot examples, then RAG.

129. Which evaluation types does Bedrock support?

Automatic, LLM-as-a-judge, human, and RAG evaluation.

130. What does ThrottlingException require?

Exponential backoff with jitter, client-side rate limiting, and a quota or capacity plan.

Keep going — from interview-ready to job-ready

This handbook is part of the AWS GenAI & Agentic AI curriculum at Cloud Soft Solutions, Ameerpet. Our APEX program covers AI / GenAI, Cloud and Cyber Security; NEXUS covers Cloud, DevOps, SRE and AIOps. Both are delivered with live projects, real cloud accounts, mock interviews and placement support — with 5,500+ alumni placed to date.

📞 For course details or a free demo, call or WhatsApp +91 96660 19191 / +91 99496 16388, or email info@cloudsoftsol.com. Cloud Soft Solutions, 513, 5th Floor, Aditya Enclave, Nilagiri Block, beside Ameerpet Metro Station, Ameerpet, Hyderabad – 500016. Browse the 2026 fresher jobs hub.