Skill 1.1.1: Extract data from data sources

Question 1 - IAM Credentials for SageMaker Inference

A financial services company has deployed a fraud detection model to a SageMaker real-time endpoint. The model is invoked by a production trading application running on Amazon EC2 instances that needs to call the endpoint 24/7 with zero downtime. The security team mandates that no long-lived credentials should be stored on disk, and the credentials used for model invocation must automatically rotate without any application redeployment.

Which credential approach should the company use to meet these requirements? (Select ONE)

A) Generate a long-term IAM user access key pair and store it in AWS Systems Manager Parameter Store as a SecureString parameter.
B) Attach an IAM role to the EC2 instance with a policy allowing sagemaker:InvokeEndpoint, and let the application use the instance profile's temporary credentials.
C) Create an Amazon Bedrock API key with a 90-day expiry and store it in an encrypted S3 bucket that the EC2 application reads at startup.
D) Generate a short-term IAM access key using aws sts get-session-token and hardcode the output into the application's environment variables.
E) Store a shared IAM user access key in an environment file on each EC2 instance and protect the file with AWS KMS encryption.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: EC2 instance profiles provide automatically rotating, temporary credentials via the EC2 metadata service. This aligns with AWS IAM best practices—no credentials on disk, no manual rotation, and no redeployment needed when credentials expire.

Distractor Analysis

A is Incorrect: Storing a long-term access key in Parameter Store still requires the application to fetch a static secret. While better than hardcoding, this introduces credential management overhead and does not satisfy the "automatically rotate without redeployment" requirement.
C is Incorrect: Amazon Bedrock API keys are not a credential type for invoking SageMaker endpoints, and storing a long-lived key in S3 still leaves a credential that expires and requires operational intervention.
D is Incorrect: Hardcoding credentials into environment variables violates security best practices and does not enable automatic rotation without redeployment.
E is Incorrect: Shared long-lived credentials are hard to audit, cannot rotate automatically without redeployment, and storing them on each host creates a security risk.

Key Takeaway: For production workloads on EC2, always prefer IAM roles attached to the instance over static access keys stored anywhere on the system.

Question 2 - Bedrock Model Access for Multi-Account Setup

A multinational retail company uses AWS Organizations with a dedicated ML account containing Amazon Bedrock foundation models. The data science team works in a separate development account and needs to invoke Amazon Bedrock models (via InvokeModel API) from SageMaker notebooks in that development account. The security team requires role-based access with the ability to audit exactly which principal invoked which model at what time in the development account.

Which configuration should be implemented? (Select ONE)

A) Create an IAM user in the ML account, generate a long-term API key, and share it with the data science team via encrypted email.
B) Create an IAM role in the ML account with bedrock:InvokeModel permission, and create an IAM role in the development account that can assume it via a trust policy. Have the SageMaker notebook execution role assume the ML account role.
C) Grant bedrock:InvokeModel permission directly to the SageMaker notebook execution role in the development account, and configure an SCP to allow cross-account Bedrock access.
D) Use Amazon Cognito with a user pool in the development account and an identity pool in the ML account to federate access to Bedrock.
E) Create a short-term API key in the ML account using bedrock:CreateApiKey and share it with the development account via AWS Secrets Manager cross-account sharing.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: Cross-account access to Bedrock requires a role in the account that owns the model with a trust policy allowing a role from another account to assume it. The development SageMaker execution role assumes the ML account role, providing temporary credentials. This is the standard AWS cross-account pattern—providing auditable, role-based access.

Distractor Analysis

A is Incorrect: Long-term API keys used in a multi-account setup violate least privilege and auditing best practices. Sharing credentials via email is a security anti-pattern.
C is Incorrect: Cross-account access to Bedrock cannot be established solely by granting IAM permissions in the calling account. Bedrock requires using bedrock:RequestModelInvocation in the resource-based policy on the model in addition to identity-based permissions in the caller's account.
D is Incorrect: Amazon Cognito is designed for federating human users to application resources, not for cross-account service-to-service access between SageMaker notebooks and Bedrock.
E is Incorrect: bedrock:CreateApiKey is not an actual API operation. Bedrock uses IAM roles and policies for credential delegation.

Key Takeaway: Cross-account Bedrock access requires both identity-based policies in the caller's account AND permission on the model via bedrock:RequestModelInvocation in the resource-based policy.

Question 3 - Temporary Credentials for SageMaker Pipeline

A machine learning engineering team uses Amazon SageMaker Pipelines to automate a model training workflow. A step in the pipeline needs to call an external SaaS API that generates feature embeddings. The SaaS vendor uses AWS IAM with a custom credential broker that issues credentials valid for 12 hours. The pipeline runs daily and cannot have human intervention for credential refresh.

Which credential mechanism should the engineer implement for the pipeline step? (Select ONE)

A) Store the SaaS API key as a SageMaker Pipeline parameter and pass it directly to the step's script.
B) Use AWS Secrets Manager to store the SaaS credential, and have the step's script retrieve the secret using the pipeline execution role's temporary credentials.
C) Generate a long-term access key for a pipeline IAM user and store it in an S3 bucket with SSE-KMS enabled.
D) Hardcode an API token in the pipeline definition YAML file and protect the file by storing it in a private GitHub repository.
E) Create a Lambda function that rotates the access key daily and sends the new credential to an SNS topic the pipeline subscribes to.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: Using Secrets Manager to store external credentials and retrieving them at runtime with the pipeline execution role's temporary credentials is the proper secure pattern. Secrets Manager integrates with automatic rotation and KMS encryption, and the pipeline role provides short-lived temporary credentials without the need for manual intervention.

Distractor Analysis

A is Incorrect: Passing secrets as pipeline parameters exposes them in SageMaker Pipeline metadata, logs, and the pipeline definition itself. This is an anti-pattern for handling sensitive credentials.
C is Incorrect: Long-term access keys stored in S3 are static credentials that don't automatically rotate and are likely to be misconfigured with overly broad permissions. AWS recommends using IAM Roles with temporary credentials rather than long-term access keys.
D is Incorrect: Hardcoding credentials in code is a security anti-pattern. Storing them in a private repository never guarantees that the secret is not accidentally leaked or exposed.
E is Incorrect: Building a custom rotation mechanism with SNS adds unnecessary operational overhead and can introduce failure points. AWS Secrets Manager exists specifically to handle credential rotation and secure retrieval.

Key Takeaway: Secrets Manager is the right place for external static secrets; the service that retrieves them should use its own IAM role's temporary credentials.

Question 4 - Bedrock Access via API Key for Prototyping

A startup's data scientist needs to experiment with Amazon Bedrock foundation models quickly for a proof of concept. The company has an AWS account with all Bedrock model access enabled. The data scientist uses a SageMaker notebook instance that has an execution role with broad access to Bedrock APIs. The scientist wants to quickly test a few foundation models without changing the notebook's role permissions or writing any extra code to refresh credentials.

Which approach best supports this exploratory workflow? (Select ONE)

A) Generate a short-term Bedrock API key using the IAM role's credentials and use that key for testing in the notebook.
B) Create an IAM user access key, hardcode it into the notebook, and use it to call Bedrock.
C) Use the notebook's execution role temporary credentials directly to call Bedrock APIs with boto3 in the notebook.
D) Create a Bedrock API key using bedrock:CreateApiKey, which returns a token valid for 12 hours.
E) Generate a presigned URL for Bedrock models using the notebook role, then call the URL from the notebook.

Click to reveal Answer & Explanation

Correct Answer: C

Correct Options Analysis

C is Correct: When running on a SageMaker notebook instance, boto3 automatically retrieves temporary credentials from the instance metadata service. No API keys or manual credential handling are needed—simply call bedrock:InvokeModel or bedrock:Converse directly with the execution role.

Distractor Analysis

A is Incorrect: Amazon Bedrock does not have a native short-term API key mechanism. Even if it did, using a manually generated key when the instance already has temporary credentials defeats the purpose of IAM roles.
B is Incorrect: Hardcoding an IAM user access key into a notebook is a security risk, even for prototyping. Notebooks are often shared or exported, and credentials might leak.
D is Incorrect: bedrock:CreateApiKey is not a valid Bedrock API operation. Bedrock relies on IAM identity-based credential delegation.
E is Incorrect: Bedrock models are not addressable via presigned URLs. Presigned URLs are an S3 concept for granting temporary access to objects.

Key Takeaway: On SageMaker notebooks or any AWS compute, the execution role's temporary credentials are automatically available via the metadata service; use them instead of creating separate credentials.

Question 5 - Credential for Serverless Inference

A serverless application running on AWS Lambda invokes a deployed model on Amazon SageMaker for real-time inference. The Lambda function currently has a timeout of 15 seconds and is throttled by the number of concurrent invocations. The model endpoint has autoscaling configured. The security team requires that the Lambda function uses temporary, automatically rotating credentials with least-privilege scope.

Which credential/lifecycle configuration should the engineer implement? (Select ONE)

A) Create an IAM user with sagemaker:InvokeEndpoint permission and store its access key in Lambda environment variables. Use a KMS key to encrypt the environment variables.
B) Create an IAM role for the Lambda function with sagemaker:InvokeEndpoint permission on the target endpoint resource, and attach the role to the Lambda function.
C) Configure Lambda with a custom VPC endpoint that automatically injects temporary credentials into the function's environment at runtime.
D) Use Lambda Layers to store a pre-shared API token that the function sends to sagemaker:InvokeEndpoint.
E) Generate a short-lived access key using STS and include it in the Lambda deployment package so the function can refresh it when called.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: Lambda execution roles provide temporary credentials that AWS STS automatically rotates without any user action. The role's policy can be scoped to specific actions and resources (e.g., sagemaker:InvokeEndpoint on a particular endpoint ARN), providing true least-privilege access.

Distractor Analysis

A is Incorrect: Storing static access keys in environment variables—even encrypted with KMS—is an anti-pattern for serverless applications. The key remains a static credential and must be manually rotated, violating the requirement for automatic rotation.
C is Incorrect: VPC endpoints provide private connectivity to services, not the credential injection mechanism. Credentials come from IAM roles, regardless of the network path taken.
D is Incorrect: Lambda Layers contain code and libraries, not a credential management mechanism. Sending a pre-shared token to SageMaker InvokeEndpoint via a custom header is not a supported authentication method.
E is Incorrect: Including access keys in the deployment package and writing custom refresh logic is unnecessary complexity and a security risk. IAM roles handle rotation natively.

Key Takeaway: For serverless compute, always use the Lambda execution role with least-privilege IAM policies. Never embed static credentials in code or packaging.

Question 6 - Model Access via Bedrock vs SageMaker Endpoint

A healthcare analytics company uses two different model hosting options:

A SageMaker endpoint hosting a proprietary medical code classification model.
Amazon Bedrock foundation model access for document summarization.

The security architect wants to understand which credential types are used for each. The current setup uses IAM roles. Which statement about the credential mechanisms for these two options is correct? (Select ONE)

A) Both SageMaker endpoints and Bedrock foundation models use IAM-based authentication with the same API operation: InvokeModel.
B) SageMaker endpoints are invoked via sagemaker:InvokeEndpoint with IAM credentials, while Bedrock foundation models are accessed via bedrock:InvokeModel with IAM credentials.
C) SageMaker endpoints require a unique API key in the Authorization header, while Bedrock only accepts IAM roles.
D) Both services require API keys that must be renewed every 90 days.
E) SageMaker endpoints require IAM credentials, while Bedrock uses either IAM or a standalone API token that can be created in the Bedrock console.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: In SageMaker, the API operation to get inference from a hosted endpoint is sagemaker:InvokeEndpoint, while in Bedrock, foundation model inference is done via bedrock:InvokeModel or bedrock:Converse. Both use IAM (signature V4) authentication.

Distractor Analysis

A is Incorrect: While both services use IAM, the API operations are different. InvokeModel is a Bedrock API operation, not a SageMaker operation.
C is Incorrect: SageMaker does not require a unique API key in the Authorization header. Its authentication uses SigV4 signature-based authentication with temporary IAM credentials.
D is Incorrect: Neither service requires long-lived API keys or 90-day renewal cycles. IAM temporary credentials are automatically rotated.
E is Incorrect: Bedrock does not have a standalone API token mechanism. All Bedrock access goes through IAM authentication.

Key Takeaway: SageMaker uses sagemaker:InvokeEndpoint while Bedrock uses bedrock:InvokeModel or bedrock:Converse; both authenticate exclusively via IAM SigV4.

Question 7 - Credential for Batch Transform

A logistics company runs a weekly batch inference job using SageMaker Batch Transform to process millions of shipment records. The batch job is triggered by a Step Functions workflow running in the same AWS account. The company's security team requires that no long-lived credentials are used anywhere in the pipeline, and that all service-to-service calls use temporary IAM credentials.

Which credential architecture should the engineer use? (Select ONE)

A) Create a dedicated IAM user for the Step Functions workflow, store its credentials in Systems Manager Parameter Store as SecureString, and have the workflow retrieve them at runtime.
B) Create separate IAM roles for Step Functions, SageMaker, and S3. Configure trust relationships so that Step Functions assumes the SageMaker role to start the batch transform job, and SageMaker assumes the S3 role to read input data.
C) Use a single IAM role with broad permissions (sagemaker:* and s3:*) and assign it to both Step Functions and SageMaker.
D) Generate a set of short-term access keys using STS and store them in an encrypted S3 bucket that the Step Functions workflow reads at the start of each run.
E) Configure a custom Lambda authorizer that exchanges an external API key for temporary credentials, and invoke that Lambda at the start of the Step Functions workflow.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: The proper pattern for service-to-service credential management is to use service-specific IAM roles with tightly scoped trust policies. Step Functions has an execution role that grants permission to start SageMaker batch transform jobs. SageMaker's batch transform job uses a role that grants access to the input S3 bucket. Each service assumes its role and receives temporary credentials.

Distractor Analysis

A is Incorrect: Creating an IAM user and storing credentials in Parameter Store is a long-term static credential approach, even if the parameter is encrypted. This violates the "no long-lived credentials" requirement.
C is Incorrect: A single broad role violates least privilege by granting sagemaker:* and s3:* to both services. This creates an unnecessarily large blast radius if either service is compromised.
D is Incorrect: Generating short-term keys and storing them in S3 is redundant and unnecessary—IAM roles natively provide temporary credentials without custom mechanisms.
E is Incorrect: A custom Lambda authorizer adds unnecessary operational complexity when native IAM role chaining already provides the right solution.

Key Takeaway: For service-to-service workflows in AWS, use a separate IAM role for each service with least-privilege policies and trust relationships that allow the caller to assume the callee's role.

Question 8 - Bedrock API Keys for Third-Party Model Providers

A security analyst at an e-commerce company is investigating credential types for accessing third-party foundation models through Amazon Bedrock. The company regularly invokes models from Anthropic, Cohere, and AI21 Labs through Bedrock. The analyst wants to understand how they authenticate calls to these third-party models.

Which statement is correct about authenticating against third-party foundation models accessed via Amazon Bedrock? (Select ONE)

A) Each third-party model provider issues its own API key that must be stored in Secrets Manager and passed to Bedrock in the request header.
B) Bedrock uses a unified IAM-based authentication model—you authenticate with IAM credentials to Bedrock, and Bedrock handles the provider-specific authentication for you.
C) Bedrock requires a special bedrock:ApiKey parameter that must be included in the request body, and this key is obtainable from the AWS Management Console.
D) Third-party models in Bedrock do not require any authentication when called from an AWS Lambda function.
E) You must create separate IAM users for each model provider and assign each user's credentials to the provider's console for authentication.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: Amazon Bedrock provides a fully managed authentication layer. You authenticate to Bedrock using your IAM identity (IAM role, user, or temporary credentials), and Bedrock internally handles the provider-specific authentication to Anthropic, Cohere, AI21, etc. You never need to manage provider-specific API keys.

Distractor Analysis

A is Incorrect: When accessing third-party models through Bedrock, you never interact directly with the model provider for authentication. Bedrock abstracts away the provider's authentication entirely.
C is Incorrect: There is no bedrock:ApiKey parameter or special console-generated key for Bedrock. All authentication is via IAM SigV4.
D is Incorrect: All Bedrock API calls, including those from Lambda, require IAM authentication. There are no unauthenticated calls.
E is Incorrect: You do not register IAM users with the third-party model providers. Bedrock manages the integration.

Key Takeaway: Amazon Bedrock provides a unified IAM-based authentication model—you do not need to manage provider-specific credentials at all.

Question 9 - Temporary Credentials vs Long-Term Credentials for Edge Deployment

An IoT company deploys ML models to edge devices using AWS IoT Greengrass. The devices require access to Amazon Bedrock for on-demand inference (called via the AWS SDK). The devices are sometimes offline for extended periods, and the security team wants to minimize the risk of credential theft from compromised devices. The devices cannot store long-term credentials.

Which credential strategy should the engineer implement for the edge devices? (Select ONE)

A) Create an IAM user for each device with long-term access keys, store the keys in the device's TPM (Trusted Platform Module), and use them to call Bedrock.
B) Use AWS IoT Core's X.509 certificate-based authentication with a custom authorizer that exchanges the certificate for temporary IAM credentials using an IoT Core credential provider.
C) Generate a Bedrock API key for each device and store it in the device's local keystore for up to one year.
D) Use AWS STS to generate a one-year access key that never expires, then burn it into the device's firmware during provisioning.
E) Create an IAM role for the devices and hardcode its ARN into the device; at runtime, the device calls an unauthenticated Lambda function that injects credentials.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

B is Correct: AWS IoT Core supports X.509 client certificates as the primary authentication mechanism for devices. The IoT Core credential provider allows a device to exchange its valid IoT certificate for short-lived AWS IAM credentials using TLS authtication. This avoids storing long-term access keys on the device while still providing credentials to call AWS services like Bedrock.

Distractor Analysis

A is Incorrect: Storing long-term IAM user access keys on edge devices is a security risk. Even in a TPM, the keys remain static and do not rotate automatically. A compromised device could leak credentials.
C is Incorrect: Bedrock API keys do not exist. Even if they did, a one-year validity period on a device credential is extremely long and violates the credential hygiene requirement.
D is Incorrect: AWS STS does not issue access keys with a one-year expiration period. STS credentials have a maximum duration of 12 hours (or 36 hours with role chaining). Burning credentials into firmware is an anti-pattern.
E is Incorrect: An unauthenticated Lambda function that injects credentials is a security vulnerability. It would allow anyone to access the function and obtain credentials.

Key Takeaway: For edge/IoT deployments, prefer certificate-based authentication with credential exchange (e.g., AWS IoT Core credential provider) rather than long-term access keys burned into devices.

Question 10 - IAM Policy Scoping for Bedrock Invocation

A media streaming company uses Amazon Bedrock to generate personalized content recommendations. The team has multiple applications:

A production web application running on ECS Fargate
A development notebook in SageMaker
A CI/CD pipeline in CodePipeline

The security team wants to enforce least privilege for Bedrock access. Each application needs bedrock:InvokeModel and bedrock:Converse for only specific foundation models. The security team also wants logging of all model invocations for auditability.

Which configuration meets these requirements? (Select ONE)

A) Create three separate IAM roles (one per application) with policies that allow bedrock:InvokeModel and bedrock:Converse on specific model ARNs, and configure CloudTrail data events for Bedrock.
B) Create one shared IAM role with bedrock:* permission, assign it to all three applications, and rely on Bedrock Guardrails to filter access.
C) Create three IAM users with access keys, embed the keys into each application's configuration, and scope the IAM policies to model ARNs.
D) Create three separate IAM roles, each with bedrock:* permission, and configure CloudTrail to log management events only.
E) Create one IAM role with bedrock:InvokeModel and bedrock:Converse scoped to all models, assign it to all three applications, and configure AWS Config to track Bedrock resource changes.

Click to reveal Answer & Explanation

Correct Answer: A

Correct Options Analysis

A is Correct: The proper approach is to create separate roles for each application with least-privilege policies scoped to the specific model ARNs (arn:aws:bedrock:region::foundation-model/model-id). CloudTrail data events need to be configured manually to capture Bedrock model invocation calls for auditing.

Distractor Analysis

B is Incorrect: One shared role with bedrock:* grants excessive permissions to all applications. Bedrock Guardrails filter content, not IAM access. They are not a substitute for identity-based access controls.
C is Incorrect: Creating IAM users and embedding keys in application configuration is a long-term credential anti-pattern. IAM roles with temporary credentials are preferred.
D is Incorrect: Granting bedrock:* to all roles is not least privilege. Additionally, CloudTrail management events do not capture model invocation data-plane events—data events must be configured explicitly.
E is Incorrect: While one role with scoped permissions could be acceptable if all applications had identical needs, the security team wants separation. Additionally, AWS Config tracks configuration changes, not model invocation audit logs.

Key Takeaway: For least-privilege Bedrock access, scope IAM policies to specific model ARNs and configure CloudTrail data events separately and explicitly for audit logging.