Course menuDVA-C03

Exams / DVA-C03 / Study guide / AI service access and data privacy

AI service access and data privacy: DVA-C03 study notes and practice questions

What to know about AI service access and data privacy for the DVA-C03 exam, from the Security domain (26% of the exam guide), then 3 free questions to test it. Part of the DVA-C03 study guide.

Last verified against current AWS documentation ·How we write our questions

What to know for the exam

These questions describe a team that calls Amazon Bedrock from an application and must keep traffic private, control who can invoke models, and keep sensitive prompts out of logs. Work out which control sits at the access, network, region or logging layer.

Who can call a model

Access to models is granted with IAM policies that allow bedrock:InvokeModel (and InvokeModelWithResponseStream, or the Converse actions) on the model or inference profile. Use an IAM role for application code, so it gets temporary credentials. An SCP can block model invocation across an account even when the account’s own policies allow it, and a deny on aws:RequestedRegion keeps calls in approved Regions.

In commercial Regions most serverless models need no access request: the first invocation subscribes the account, using the caller’s AWS Marketplace permissions, and accepts the model’s license. Anthropic models also need a one-time use case form per account or organization. A team that must review a license first blocks the model with an IAM or SCP deny on the invoke actions until it is approved. When traffic will exceed a Bedrock quota, such as tokens per minute, request an increase in Service Quotas before launch.

A cross-Region inference profile is invoked by its own ARN, but the role must also be allowed the foundation model in each Region the profile can route to.

Private connectivity with VPC endpoints

Create interface VPC endpoints (AWS PrivateLink) for bedrock-runtime to send inference calls, and bedrock for control plane calls. Agent calls use bedrock-agent-runtime. With private DNS enabled on the endpoint, applications keep the normal Regional endpoint names and no code changes are needed. Without private DNS, the client must set the endpoint URL to the VPC endpoint DNS name. An endpoint policy limits what passes through the endpoint, but only a deny on aws:SourceVpce in the role’s policy stops the role from calling Bedrock some other way.

Training and data use

Amazon Bedrock does not use your prompts or model outputs to train foundation models, and it does not share them with model providers. Models run in deployment accounts operated by the Bedrock service team, and providers have no access to those accounts or to customer prompts and completions. Use VPC endpoints when the wording is about keeping traffic off the public internet.

Data residency with inference profiles

A geographic cross-Region inference profile (prefixes such as us., eu. or apac.) routes requests only within that geography, which suits data residency rules. A global profile can route to any supported commercial Region, which adds capacity but gives no residency guarantee. An SCP that blocks regions must allow every Region in the profile, or calls fail.

Model invocation logging

Model invocation logging is disabled by default. When you enable it, Bedrock writes the full request and response, including prompts, to Amazon S3, CloudWatch Logs, or both. Limit read access to the destination, encrypt it and set retention. For SSE-KMS on the S3 bucket, the key policy must let bedrock.amazonaws.com call kms:GenerateDataKey. Prompts that your own code writes to CloudWatch Logs can be masked with a CloudWatch Logs data protection policy, which masks events ingested after it is set; only principals with logs:Unmask see the original values. Logging covers the bedrock-runtime calls; calls through the separate bedrock-mantle endpoint are not captured.

Bedrock API keys

A short-term API key lasts up to 12 hours, or the length of the session that created it, and inherits the permissions of the IAM principal that made it. AWS recommends short-term keys for production. A long-term key creates an IAM user with attached policies, lasts until a set expiry, and AWS says is for exploration only. For production code, prefer an IAM role; if a key is needed, prefer a short-term key over a long-term one. Denying bedrock:CallWithBearerToken stops an identity from using API keys at all.

How to choose

Scenario wording Answer
Only the app role may invoke models IAM policy on the role, scoped to the model or profile
Block model calls across all accounts SCP
Model calls must not cross the internet Interface VPC endpoint with private DNS
Data must stay in the EU Geographic eu. profile
Keep prompts out of logs Turn off invocation logging, or protect the log destination and mask PII
Client must send a bearer key, in production Short-term Bedrock API key
Role may call Bedrock only through the VPC endpoint IAM deny with aws:SourceVpce condition
Block a new model until legal approves its license IAM or SCP deny on invoking that model
Launch traffic will exceed tokens per minute Quota increase in Service Quotas, before launch

Common traps

  • Assuming invocation logging is on. It is off until enabled.
  • Choosing a global profile to meet a residency rule.
  • Using a long-term API key in production.
  • Thinking a VPC endpoint hides prompts from logs. It only changes the network path.
  • Forgetting the endpoint for the control plane when a client needs both kinds of call.

Try the 3 practice questions

A health insurer is building a claims-summary assistant on Amazon Bedrock. Claim notes contain medical details, so the compliance team must confirm before launch that a model provider cannot read the company's prompts or the model's replies.

The team does not want to build its own pipeline to prove this, and the design must use managed AWS services only.

Which approach meets these requirements?

Choose one answer.

  1. A. Turn on model invocation logging to an S3 bucket, and give each model provider read access to the bucket so it can review how its model is used.
  2. B. Ask each model provider to sign a data processing agreement, then send the claim notes to that provider's own API endpoint instead of Amazon Bedrock.
  3. C. Run an open-source model on Amazon EC2 in the company's own account, and patch and operate the model server in a private subnet with its own logging and access controls.
  4. D. Call the models through Amazon Bedrock, which runs them in Bedrock-owned deployment accounts. Providers have no access to Bedrock logs or to customer prompts.
Show the answer and explanation

Answer: D

  • A. Wrong: This gives the providers direct access to customer prompts and completions, which is the exposure the compliance team must rule out. It also adds a custom review path.
  • B. Wrong: Sending claim notes to a provider's own endpoint takes them out of Amazon Bedrock, which breaks the managed-service requirement. A contract does not replace the technical control the team needs.
  • C. Wrong: Self-hosting avoids model providers, but the team would have to run and patch the model itself. That conflicts with the requirement to use managed AWS services only.
  • D. Right: Correct. Bedrock runs the models in deployment accounts that the Bedrock service team owns and operates, and the model providers have no access to those accounts, to Bedrock logs or to customer prompts and completions. The team needs no extra pipeline for this control. Learn more: Data protection in Amazon Bedrock (opens in a new tab)

Explanation

Amazon Bedrock runs each provider's models in deployment accounts owned and operated by the Bedrock service team. Model providers have no access to those accounts, to Bedrock logs or to customer prompts and completions. The other options either send the data to a provider or add infrastructure the team would have to build and run.

Study

A logistics company runs a Lambda function in private subnets of its VPC. The function calls a model on Amazon Bedrock and also reads an Amazon RDS database in the same VPC.

Security policy forbids any route from these subnets to the internet, so the function must reach Bedrock privately. The SDK code should not need a different endpoint URL, and the security team wants the Bedrock access limited to the model-invocation actions the function needs.

Which solution meets these requirements?

Choose one answer.

  1. A. Create an interface VPC endpoint for bedrock-runtime, turn on private DNS, and attach an endpoint policy that allows only the model-invocation actions the function needs.
  2. B. Attach a NAT gateway in a public subnet, and route the private subnets' default traffic through it so the function can reach the public Bedrock endpoint for model calls.
  3. C. Create an interface endpoint for the bedrock service name, and point the function's model calls at that endpoint.
  4. D. Move the function outside the VPC so it can reach the public Bedrock endpoint, and connect to the database through its public address.
Show the answer and explanation

Answer: A

  • A. Right: Correct. An interface endpoint for bedrock-runtime gives the function a private path to the runtime API with no internet route. Private DNS keeps the standard service name in the SDK, and an endpoint policy narrows the Bedrock actions allowed through it. Learn more: Use interface VPC endpoints (AWS PrivateLink) with Amazon Bedrock (opens in a new tab)
  • B. Wrong: A NAT gateway gives the subnets a route to the internet, which the security policy forbids. It would work for reachability, but it breaks the stated constraint.
  • C. Wrong: The bedrock service name is a separate endpoint from bedrock-runtime. Model calls are served by the bedrock-runtime endpoint, so this route would not carry them.
  • D. Wrong: Running outside the VPC means the database must have a public route, which the security policy also rules out. The option fails the no-internet rule and the private database access.

Explanation

An interface VPC endpoint for bedrock-runtime lets the function reach model calls over private connectivity, with no internet route. Private DNS lets the SDK keep the standard service name, so the code does not change. An endpoint policy can restrict which Bedrock actions pass through the endpoint.

An interface VPC endpoint giving private subnets a path to an AWS service In private subnets with no NAT gateway, an application calls an AWS service by its normal name. Private DNS resolves the name to an interface endpoint in the subnets, which has an endpoint policy, and the traffic reaches the AWS service over the AWS network through PrivateLink. Private subnets, no NAT Application calls the normal service name Interface endpoint private DNS, endpoint policy AWS service PrivateLink
Private DNS keeps the SDK's normal Bedrock name, and the endpoint policy limits calls to model invocation.

Study

A telecom company builds a customer-support agent with Amazon Bedrock Agents. An action group uses an AWS Lambda function to look up a customer's plan, and the developer created the function and the action group with the AWS CLI.

When the agent tries to use the action group, the call to the function is denied. The function must be callable only by this agent, not by other agents or accounts.

Which change meets these requirements?

Choose one answer.

  1. A. Add lambda:InvokeFunction on the function's ARN to the agent's service role, and leave the function's resource-based policy without any statements.
  2. B. Add a resource-based policy statement that allows the bedrock.amazonaws.com service principal to invoke the function, with no conditions on the request.
  3. C. Add a resource-based policy that lets bedrock.amazonaws.com invoke the function, conditioned on aws:SourceAccount and on aws:SourceArn matching this agent's ARN.
  4. D. Give the Lambda function's execution role permission to call bedrock:InvokeAgent, so that the function and the agent trust each other.
Show the answer and explanation

Answer: C

  • A. Wrong: Bedrock calls an action group function as the bedrock.amazonaws.com service, so the function's resource-based policy must allow it. An identity policy on the service role does not grant that.
  • B. Wrong: This clears the error, but any Bedrock agent in any account could then invoke the function. That breaks the requirement that only this agent may call it.
  • C. Right: Correct. Action group functions need a resource-based policy that allows Bedrock to invoke them. The source account and source ARN conditions limit that permission to this one agent, which also prevents the confused deputy problem. Learn more: Create a service role for Amazon Bedrock Agents (opens in a new tab)
  • D. Wrong: The execution role controls what the function's code can call. It does not decide who may invoke the function, so the agent is still denied.

Explanation

Amazon Bedrock Agents invokes an action group's Lambda function as the bedrock.amazonaws.com service principal, so the function needs a resource-based policy that allows it. Adding aws:SourceAccount and aws:SourceArn conditions for the agent's ARN limits the permission to that one agent. Identity policies on the agent's role or the function's role do not grant permission to invoke the function.

Study

Want more on AI service access and data privacy? The 5 full-length practice sets have 11 more AI service access and data privacy questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets

Study AI service access and data privacy

More Security topics