Skill 4.3.8: Select the appropriate credential type to access FMs
| Question | Answer & Explanation |
|---|---|
| ### Question 1 - Production EC2 Access to Amazon Bedrock A production enterprise AI application running on Amazon EC2 instances needs to invoke an Amazon Bedrock foundation model. The security team mandates that no long-term credentials be stored on the instances or passed via environment variables, and the solution must require the least operational overhead. Which credential approach satisfies these requirements? Select ONE that applies. - A) Generate a long-term Amazon Bedrock API key and store it in an encrypted Amazon S3 bucket, retrieving it at startup. - B) Create an IAM role with a trust policy for Amazon EC2 and attach an inline policy granting bedrock:InvokeModel permissions. Attach this role to the EC2 instances.- C) Create an IAM user with an access key, store the access key in AWS Secrets Manager, and configure the application to retrieve it. - D) Generate a short-term Bedrock API key from the AWS console and manually update the EC2 environment variables before the session expires. |
Correct Answer: B Correct Answer Analysis: - B is Correct: Using an IAM role attached to the EC2 instance profile provides temporary, automatically rotated security credentials via AWS Security Token Service (STS). This approach requires no operational overhead for credential management and adheres strictly to the principle of least privilege without storing static secrets. Distractor Analysis: - A is Incorrect: Storing a long-term API key in S3, even encrypted, introduces unnecessary operational overhead and security risks compared to using an IAM role. - C is Incorrect: Storing IAM user access keys in Secrets Manager is an anti-pattern for compute workloads on AWS. It introduces unnecessary complexity when IAM roles natively handle temporary credentials. - D is Incorrect: Manually updating environment variables with short-term keys is highly prone to human error, causes application downtime when keys expire, and fails the least operational overhead constraint. > Key Takeaway: For production workloads running on AWS compute services (EC2, Lambda, ECS, EKS), always use IAM roles to automatically provision temporary credentials. |
| ### Question 2 - Local Laptop Prototyping with Bedrock A machine learning engineer is building a quick prototype on their local laptop to test a new foundation model in Amazon Bedrock. They need temporary access to the model without creating long-term static credentials that could be compromised if the laptop is lost. Which approach is most appropriate for this exploration phase? Select ONE that applies. - A) Generate a long-term API key backed by its own identity and hardcode it into the local Python script. - B) Create an IAM user with programmatic access and save the access key ID and secret access key in a .env file.- C) Generate a short-term API key that inherits the permissions of the engineer's identity and expires with the current session. - D) Create an IAM role and use aws sts assume-role in the terminal to generate temporary credentials for the local script. |
Correct Answer: C Correct Answer Analysis: - C is Correct: A short-term API key for a foundation model inherits the permissions of the identity that generated it and expires with that session. This makes it highly convenient and secure for short-term exploration without leaving lingering static credentials. Distractor Analysis: - A is Incorrect: Long-term API keys are documented for exploration and development, but hardcoding them into scripts is a security risk, especially on local machines. - B is Incorrect: Creating IAM users with static access keys for development is an outdated practice and poses a significant risk if the local environment is compromised. - D is Incorrect: While assuming a role via STS is a valid pattern for local development, it requires more setup (defining trust policies, configuring profiles) than generating a short-term API key directly for quick exploration. > Key Takeaway: Short-term API keys are ideal for exploration because they expire automatically with the generating session, reducing risk without added operational friction. |
| ### Question 3 - Lambda Function Invocation An event-driven AI workload uses an AWS Lambda function to process user inputs and invoke an Amazon Bedrock model. The security policy requires the workload to use temporary credentials, maintain least privilege, and ensure a workload identity is completely separate from any human user identity. Which configuration meets these requirements? Select ONE that applies. - A) Configure the Lambda function's execution role with a managed policy granting AmazonBedrockFullAccess.- B) Pass a long-term Bedrock API key via the Lambda environment variables encrypted using AWS KMS. - C) Configure the Lambda function's execution role with a custom IAM policy granting only bedrock:InvokeModel on the specific foundation model ARN.- D) Store an IAM user's access key in Secrets Manager and retrieve it inside the Lambda function code at runtime. |
Correct Answer: C Correct Answer Analysis: - C is Correct: The Lambda execution role automatically provides temporary credentials via STS. By scoping the policy to only bedrock:InvokeModel on a specific model ARN, the configuration adheres to the principle of least privilege and keeps the workload identity distinct from human identities.Distractor Analysis: - A is Incorrect: AmazonBedrockFullAccess violates the principle of least privilege by granting unnecessary administrative and invocation permissions across all models.- B is Incorrect: Passing any API key via environment variables for a Lambda function is unnecessary and introduces security risks, as Lambda natively handles temporary credentials through its execution role. - D is Incorrect: Retrieving static IAM user credentials from Secrets Manager at runtime adds unnecessary latency and operational overhead compared to using the Lambda execution role. > Key Takeaway: Lambda execution roles automatically provide temporary credentials; always scope the role's policy to the specific model ARN using bedrock:InvokeModel. |
| ### Question 4 - ECS Fargate Workload Access An enterprise is deploying a containerized microservice on Amazon ECS using AWS Fargate that requires access to Amazon Bedrock. The compliance team strictly prohibits baking secrets into the container image or passing them via environment variables. Which credentialing approach satisfies this requirement with the least operational overhead? Select ONE that applies. - A) Use an Amazon ECR interface endpoint to securely pull the image, which automatically grants Bedrock access. - B) Attach an IAM execution role to the ECS task definition that grants permissions to invoke the Bedrock model. - C) Mount an Amazon EFS volume containing a long-term API key to the Fargate task at runtime. - D) Use AWS Secrets Manager to store a short-term API key and retrieve it when the Fargate task boots. |
Correct Answer: B Correct Answer Analysis: - B is Correct: ECS Task Roles provide temporary, automatically rotated credentials to containers running on AWS Fargate. This approach requires no secret management operational overhead and securely decouples the credentials from the container image and environment variables. Distractor Analysis: - A is Incorrect: An ECR interface endpoint is used for private network access to pull container images; it does not provide IAM credentials or authorization for Amazon Bedrock. - C is Incorrect: Mounting an EFS volume with a long-term API key introduces unnecessary complexity and violates security best practices by persisting long-term credentials in a file system. - D is Incorrect: Retrieving a short-term API key from Secrets Manager at runtime adds unnecessary latency and cost. Short-term API keys expire and would require continuous manual rotation in Secrets Manager. > Key Takeaway: For ECS workloads, use the ECS Task Role to securely grant temporary AWS credentials to your containers without embedding secrets. |
| ### Question 5 - On-Premises Server Access A legacy application running on an on-premises server needs to make periodic calls to an Amazon Bedrock foundation model. The server does not have direct internet access but connects to AWS via a Site-to-Site VPN. The security team requires that no static IAM access keys be stored locally on the on-premises server. Which approach provides the most secure access? Select ONE that applies. - A) Generate a long-term Amazon Bedrock API key and store it in a HashiCorp Vault instance on the on-premises server. - B) Configure an IAM role in a AWS account, and have the on-premises server use IAM STS AssumeRole to exchange on-prem identity credentials for temporary AWS credentials.- C) Create an IAM user with an access key, store it in AWS Secrets Manager, and pull it via the VPN using an interface endpoint. - D) Generate a short-term API key from the AWS console and hardcode it into the on-premises application configuration. |
Correct Answer: B Correct Answer Analysis: - B is Correct: Using IAM STS AssumeRole (potentially via IAM Roles Anywhere or a custom OIDC/SAML identity broker) allows the on-premises server to exchange its local identity for temporary AWS credentials. This completely removes the need to store long-term AWS credentials on-premises.Distractor Analysis: - A is Incorrect: While storing the key in a vault is better than plaintext, a long-term API key is still being used. AWS explicitly recommends temporary credentials over long-term keys for accessing FMs, even in hybrid scenarios. - C is Incorrect: Creating an IAM user with an access key for an on-premises server violates the requirement of not storing static IAM access keys. Furthermore, retrieving the key still means it lives on the server temporarily in memory or disk. - D is Incorrect: Hardcoding any API key into an on-premises application is a critical security risk. Short-term keys will also expire, breaking the application. > Key Takeaway: For on-premises workloads, use IAM Roles Anywhere or STS AssumeRole to obtain temporary AWS credentials dynamically, avoiding static IAM users entirely. |
| ### Question 6 - Understanding Bedrock API Key Types An organization is evaluating the use of Amazon Bedrock API keys versus standard IAM credentials for accessing foundation models. The lead architect needs to understand the exact differences between short-term and long-term Bedrock API keys to design the company's security policy. Which TWO statements correctly describe these API key types? Select TWO that apply. - A) A short-term API key inherits the permissions of the identity that generated it and expires with that session. - B) A long-term API key is backed by its own identity with an expiry set for it, and is recommended for production workloads. - C) A long-term API key is documented for exploration and development rather than for production. - D) A short-term API key is recommended for long-running production batch inference jobs. - E) A long-term API key inherits the permissions of the identity that generated it and expires when that identity is deleted. |
Correct Answers: A and C Correct Answer Analysis: - A is Correct: A short-term API key for a foundation model inherits the permissions of the identity that generated it and expires with that session, making it convenient for exploration. - C is Correct: A long-term API key is backed by its own identity with an expiry that is set for it, and AWS explicitly documents it for exploration and development rather than for production. Distractor Analysis: - B is Incorrect: Long-term API keys are explicitly documented for exploration and development, NOT for production workloads. Production access should use IAM roles with temporary credentials. - D is Incorrect: Short-term API keys expire with the session that generated them. Using them for long-running production batch jobs would result in authentication failures when the session expires. - E is Incorrect: Long-term API keys are backed by their own identity (not inheriting permissions from the generating identity), and their expiry is explicitly set during creation, not tied to the deletion of the generating user. > Key Takeaway: Short-term API keys expire with the session; long-term API keys are for development. Neither should be used for production workloads. |
| ### Question 7 - Migrating from Hardcoded Keys A legacy AI application currently uses a hardcoded long-term Bedrock API key stored in an environment variable on a fleet of Amazon EC2 instances. The engineering team has been tasked with removing this static secret to improve security and auditability with the least operational overhead. Which solution removes the need for static credentials while maintaining access to Bedrock? Select ONE that applies. - A) Move the long-term API key into AWS Secrets Manager and configure the application to retrieve it at startup. - B) Revoke the API key, create an IAM role with bedrock:InvokeModel permissions, and attach it to the EC2 instances as an instance profile.- C) Replace the long-term API key with a short-term API key and update the EC2 user data script to fetch a new one daily. - D) Create an AWS Lambda function that rotates the long-term API key in the environment variables every 30 days. |
Correct Answer: B Correct Answer Analysis: - B is Correct: Attaching an IAM role as an instance profile to EC2 instances provides temporary, automatically rotated credentials. This completely removes the need for static API keys, minimizing operational overhead and maximizing auditability through CloudTrail. Distractor Analysis: - A is Incorrect: While storing the key in Secrets Manager is more secure than hardcoding it, it still relies on a long-term API key for production, which is an anti-pattern. It also adds operational overhead to manage the secret retrieval logic. - C is Incorrect: Updating EC2 user data to fetch short-term API keys daily is highly complex, operationally heavy, and prone to failure if the session expires sooner. - D is Incorrect: Rotating a long-term API key in environment variables still leaves static secrets in the environment, failing the security objective and adding unnecessary Lambda operational overhead. > Key Takeaway: When migrating away from hardcoded secrets on EC2, always transition to IAM instance profiles for temporary, rotation-free credentials. |
| ### Question 8 - CI/CD Pipeline Testing An automated CI/CD pipeline running on AWS CodePipeline needs to execute a test script that invokes an Amazon Bedrock model to verify inference responses. The pipeline must use temporary, automatically rotated credentials and operate without storing any static API keys in the source repository. How should the pipeline be configured to securely access Bedrock? Select ONE that applies. - A) Configure the CodeBuild project service role with an IAM policy granting bedrock:InvokeModel permissions.- B) Store a Bedrock API key in AWS Systems Manager Parameter Store and reference it as an environment variable in the buildspec file. - C) Attach an IAM user access key directly to the CodeBuild environment variables via the AWS Management Console. - D) Use a long-term API key for the CI/CD pipeline, as pipelines are inherently non-production environments. |
Correct Answer: A Correct Answer Analysis: - A is Correct: The AWS CodeBuild service role automatically provides temporary credentials to the build environment. By attaching an IAM policy granting bedrock:InvokeModel to this role, the test script can securely invoke the model without any static secrets.Distractor Analysis: - B is Incorrect: Storing an API key in Parameter Store and passing it as an environment variable still requires managing a static secret, violating the requirement to operate without static API keys. - C is Incorrect: Hardcoding IAM user access keys in the AWS Management Console environment variables is a significant security risk and violates the principle of using temporary credentials. - D is Incorrect: Even if pipelines are non-production, testing production-like behavior should use secure methods. AWS explicitly documents long-term API keys for exploration/development, not automated pipeline execution. > Key Takeaway: AWS CodePipeline and CodeBuild service roles natively provide temporary credentials to securely access AWS services like Bedrock during CI/CD runs. |
| ### Question 9 - Multi-Tenant SaaS Access A company is building a secure, multi-tenant SaaS application on AWS that uses Amazon Bedrock to generate responses for its customers. The security team wants to ensure that the application uses a single workload identity with temporary credentials to invoke the model, rather than passing individual user credentials downstream. Which approach aligns with AWS best practices for this architecture? Select ONE that applies. - A) Generate a short-term API key for each customer upon login and pass it directly to the Bedrock API endpoint. - B) Configure an application-level IAM role with permissions to invoke Bedrock, and control tenant access within the application logic before invoking the model. - C) Create an IAM user for each tenant and use their credentials to authenticate the Bedrock API calls. - D) Use Amazon Cognito to map tenant identities directly to Bedrock Foundation Models using long-term API keys. |
Correct Answer: B Correct Answer Analysis: - B is Correct: In a multi-tenant SaaS architecture, the application should use a single IAM role (workload identity) with temporary credentials to invoke Bedrock. The application layer enforces tenant authorization and controls prompts/inputs before invoking the model. Distractor Analysis: - A is Incorrect: Generating and managing API keys for each customer is operationally complex, insecure, and not supported as a scalable pattern for Bedrock access. - C is Incorrect: Creating IAM users for tenants in a SaaS environment violates AWS multi-tenant best practices, as IAM is not designed for end-user identity management at scale. - D is Incorrect: While Amazon Cognito is the right service for user authentication, mapping Cognito identities directly to Bedrock via API keys is incorrect. The application backend should broker the request using its own IAM role. > Key Takeaway: In multi-tenant SaaS applications on AWS, use a backend IAM role to invoke models and handle tenant authorization within the application logic. |
| ### Question 10 - SageMaker Studio Exploration A data scientist is setting up a development environment in Amazon SageMaker Studio to experiment with Amazon Bedrock. They want to use a credential type that is convenient for exploration but will automatically expire without requiring manual rotation or cleanup. Which credential type is explicitly documented by AWS for this exploration phase? Select ONE that applies. - A) A long-term API key backed by its own identity. - B) An IAM user access key stored in the SageMaker execution role. - C) A short-term API key generated from the user's identity session. - D) An IAM role configured with a trust policy for sagemaker.amazonaws.com using AssumeRole. |
Correct Answer: C Correct Answer Analysis: - C is Correct: A short-term API key for a foundation model inherits the permissions of the identity that generated it and expires with that session. This makes it highly convenient for exploration in SageMaker Studio without leaving lingering static credentials. Distractor Analysis: - A is Incorrect: Long-term API keys do not automatically expire with the session and require manual rotation and cleanup, making them less ideal for short-term exploration compared to short-term keys. - B is Incorrect: Storing IAM user access keys in a SageMaker execution role is an anti-pattern. The execution role already provides temporary credentials via STS; adding a static user key is redundant and insecure. - D is Incorrect: While SageMaker execution roles use AssumeRole to provide temporary credentials for AWS services, the question specifically asks for the documented API key type for FM exploration, which is the short-term API key.> Key Takeaway: When exploring FMs in environments like SageMaker Studio, short-term API keys provide automatic expiration tied to your session, simplifying credential management. |