Scenario practice questions

A company uses AWS CodePipeline with a manual approval step before deployment. The developer wants to ensure that if a pipeline execution is waiting for approval and new code is pushed, the awaiting execution is canceled and a new one starts with the latest code. Which pipeline execution mode should be configured?

Trap 1: Queued

In Queued mode, if a new source change is detected while a pipeline execution is already in progress, the new execution will be placed in a queue. It will only begin processing once the currently running execution has successfully completed or failed. This mode ensures sequential processing of changes but does not cancel any existing execution, meaning the manual approval for the initial execution would still be pending and relevant until that execution finishes.

Trap 2: Parallel

In Parallel execution mode, AWS CodePipeline allows multiple pipeline executions to run concurrently, each triggered by a new source change. If a new change arrives while an execution is awaiting manual approval, a new, separate execution will start without canceling the previous one. This could lead to multiple pending approvals for different code versions or potentially deploying an older version if its approval is granted after a newer version has already started processing.

Trap 3: Single

'Single' is not a recognized or configurable execution mode within AWS CodePipeline. Pipeline execution modes are limited to 'Queued', 'Superseded', and 'Parallel', which define how the pipeline handles new source revisions when an execution is already active. Therefore, selecting 'Single' as an execution mode is not a valid option for managing pipeline behavior.

A
Queued
Why it fails: In Queued mode, if a new source change is detected while a pipeline execution is already in progress, the new execution will be placed in a queue. It will only begin processing once the currently running execution has successfully completed or failed. This mode ensures sequential processing of changes but does not cancel any existing execution, meaning the manual approval for the initial execution would still be pending and relevant until that execution finishes.
B
Superseded
The Superseded execution mode is designed to prioritize the latest changes by canceling any currently running pipeline execution when a new source revision is detected. This ensures that the manual approval step, if present, will always apply to the most recent code changes, preventing the deployment of outdated versions. A new pipeline execution is then immediately initiated with the latest code, requiring a fresh approval for the most current state.
C
Parallel
Why it fails: In Parallel execution mode, AWS CodePipeline allows multiple pipeline executions to run concurrently, each triggered by a new source change. If a new change arrives while an execution is awaiting manual approval, a new, separate execution will start without canceling the previous one. This could lead to multiple pending approvals for different code versions or potentially deploying an older version if its approval is granted after a newer version has already started processing.
D
Single
Why it fails: 'Single' is not a recognized or configurable execution mode within AWS CodePipeline. Pipeline execution modes are limited to 'Queued', 'Superseded', and 'Parallel', which define how the pipeline handles new source revisions when an execution is already active. Therefore, selecting 'Single' as an execution mode is not a valid option for managing pipeline behavior.

Question 2mediummulti select

A developer is using AWS Lambda and needs to ensure that the function can access an RDS database securely. Which THREE steps should be taken?

Trap 1: Attach an IAM role to the Lambda function that grants rds:*…

An IAM role defines permissions for AWS API actions, not for database logins. rds:* would let the Lambda call RDS management endpoints like CreateDBInstance or DescribeDBInstances, but RDS still expects a database user name and password in the connection string. Even when using IAM database authentication, the correct permission is rds-db:connect for a specific database resource, not the blanket rds:* policy, so this option cannot authenticate the function.

Trap 2: Configure the RDS instance to require client certificates.

Client certificate verification is a mutual TLS feature that proves the identity of the connecting application, but Lambda functions do not natively present a client certificate for RDS connections. Standard drivers for MySQL, Postgres, or SQL Server do not automatically use the certificate associated with an IAM role or execution environment. Even if enabled, this does not resolve network access or provide the database password, so it is irrelevant to the core requirement and would likely break the connection.

A
Place the Lambda function inside a VPC.
By default, Lambda functions run in an AWS-owned VPC and cannot connect to resources in your private subnets. Attaching the function to the same VPC provisions elastic network interfaces in your subnets, giving it private IP connectivity to the RDS instance. This is the foundational step required before any TCP connection to RDS can be established.
B
Store the database credentials in AWS Secrets Manager and retrieve them in the Lambda code.
Hardcoding database passwords in Lambda environment variables or code creates a security risk and makes rotation difficult. Secrets Manager lets the function call GetSecretValue at runtime to retrieve the current credentials, with IAM permissions controlling which functions may access the secret. This addresses authentication, not networking, so it complements the VPC setup but does not replace it.
C
Attach an IAM role to the Lambda function that grants rds:* permissions.
Why it fails: An IAM role defines permissions for AWS API actions, not for database logins. rds:* would let the Lambda call RDS management endpoints like CreateDBInstance or DescribeDBInstances, but RDS still expects a database user name and password in the connection string. Even when using IAM database authentication, the correct permission is rds-db:connect for a specific database resource, not the blanket rds:* policy, so this option cannot authenticate the function.
D
Configure the RDS instance to require client certificates.
Why it fails: Client certificate verification is a mutual TLS feature that proves the identity of the connecting application, but Lambda functions do not natively present a client certificate for RDS connections. Standard drivers for MySQL, Postgres, or SQL Server do not automatically use the certificate associated with an IAM role or execution environment. Even if enabled, this does not resolve network access or provide the database password, so it is irrelevant to the core requirement and would likely break the connection.
E
Configure the security group of the RDS instance to allow inbound traffic from the Lambda function's security group.
After the Lambda is placed in the VPC, its associated security group becomes the source for outbound connections, so the RDS instance's security group must permit inbound traffic on the database port from that security group. This stateful rule limits the database to only accept traffic from the Lambda's network interface, providing a precise control plane. It is necessary to actually open the path, but it only works if the Lambda has already been attached to the VPC.

Question 3hardmultiple choice

A developer is troubleshooting an IAM policy that is not working as expected. The policy has an Allow effect for s3:PutObject but the user gets AccessDenied. The user also has a Deny policy attached. What is the most likely reason?

Trap 1: The resource-based policy on S3 denies access

A resource-based policy on S3 could indeed deny access, but the fundamental IAM evaluation logic dictates that an explicit Deny statement in *any* applicable policy, including an identity-based policy attached to the user, will always take precedence over any Allow statement. Therefore, even if the S3 bucket policy explicitly allowed the action, an explicit Deny in the user's IAM policy would still prevent access, making the user's identity policy the primary point of failure in this scenario related to an IAM policy not working as expected.

Trap 2: The Allow policy is evaluated before the Deny policy

The order in which Allow and Deny policies are conceptually 'evaluated' is irrelevant to the final access decision in AWS IAM. The system's logic is designed such that an explicit Deny statement, if present in any applicable policy, immediately overrides any Allow statements, regardless of their position or the sequence in which they might appear to be processed. This ensures that a clear prohibition always takes precedence, making the evaluation order a non-factor in the outcome.

Trap 3: An SCP denies the action

While Service Control Policies (SCPs) can indeed deny actions at the AWS Organizations account level, they operate as guardrails that set maximum permissions for an entire account, not directly for individual IAM principals within an account. The question specifically refers to troubleshooting an 'IAM policy' which implies an identity-based policy attached to a user or role within the account. An explicit Deny within such an IAM policy would be the more direct and specific cause of the issue described, rather than an SCP.

A
The resource-based policy on S3 denies access
Why it fails: A resource-based policy on S3 could indeed deny access, but the fundamental IAM evaluation logic dictates that an explicit Deny statement in *any* applicable policy, including an identity-based policy attached to the user, will always take precedence over any Allow statement. Therefore, even if the S3 bucket policy explicitly allowed the action, an explicit Deny in the user's IAM policy would still prevent access, making the user's identity policy the primary point of failure in this scenario related to an IAM policy not working as expected.
B
The Allow policy is evaluated before the Deny policy
Why it fails: The order in which Allow and Deny policies are conceptually 'evaluated' is irrelevant to the final access decision in AWS IAM. The system's logic is designed such that an explicit Deny statement, if present in any applicable policy, immediately overrides any Allow statements, regardless of their position or the sequence in which they might appear to be processed. This ensures that a clear prohibition always takes precedence, making the evaluation order a non-factor in the outcome.
C
An explicit Deny in an IAM policy overrides the Allow
This statement accurately reflects a core principle of AWS IAM policy evaluation. If an IAM policy contains an explicit Deny statement for a specific action on a resource, that Deny will always override any Allow statements that might exist in the same policy, other identity-based policies, or even resource-based policies. An explicit Deny acts as an absolute prohibition, ensuring that access is blocked even if multiple Allow statements are present.
D
An SCP denies the action
Why it fails: While Service Control Policies (SCPs) can indeed deny actions at the AWS Organizations account level, they operate as guardrails that set maximum permissions for an entire account, not directly for individual IAM principals within an account. The question specifically refers to troubleshooting an 'IAM policy' which implies an identity-based policy attached to a user or role within the account. An explicit Deny within such an IAM policy would be the more direct and specific cause of the issue described, rather than an SCP.

Question 4easymultiple choice

A developer wants to deploy a containerized application to Amazon ECS using Fargate. The application requires persistent storage that can be shared across multiple containers in the same task. Which storage option should the developer use?

Trap 1: Amazon EC2 instance store

Amazon EC2 instance stores provide temporary block-level storage directly attached to an EC2 instance. This storage is ephemeral, meaning all data is lost when the instance stops or terminates, making it unsuitable for persistent application data. Crucially, AWS Fargate, which abstracts the underlying EC2 infrastructure, does not expose or support the use of EC2 instance stores for container volumes.

Trap 2: Amazon S3 bucket

Amazon S3 (Simple Storage Service) is an object storage service, designed for storing and retrieving large amounts of unstructured data via an API. While highly durable and scalable, S3 does not function as a traditional POSIX-compliant file system that can be directly mounted as a volume within an AWS Fargate container. Containerized applications typically require a file system interface for their persistent storage needs, which S3 does not natively provide for direct volume mounting.

Trap 3: Amazon EBS volume

Amazon EBS (Elastic Block Store) provides persistent block storage volumes that can be attached to a single Amazon EC2 instance. While highly performant and durable, EBS volumes are fundamentally designed for single-instance attachment and are not directly supported as a volume type for AWS Fargate tasks. Fargate's serverless operational model abstracts the underlying infrastructure, preventing direct attachment or management of EBS volumes for container storage.

A
Amazon EC2 instance store
Why it fails: Amazon EC2 instance stores provide temporary block-level storage directly attached to an EC2 instance. This storage is ephemeral, meaning all data is lost when the instance stops or terminates, making it unsuitable for persistent application data. Crucially, AWS Fargate, which abstracts the underlying EC2 infrastructure, does not expose or support the use of EC2 instance stores for container volumes.
B
Amazon EFS file system
Amazon EFS (Elastic File System) provides scalable, elastic, shared file storage that can be accessed concurrently by multiple AWS Fargate tasks. It offers persistent storage, ensuring data remains available even if containers are stopped, replaced, or scaled. This makes EFS an excellent choice for containerized applications requiring shared state, persistent data, or a common file system across different application instances running on Fargate.
C
Amazon S3 bucket
Why it fails: Amazon S3 (Simple Storage Service) is an object storage service, designed for storing and retrieving large amounts of unstructured data via an API. While highly durable and scalable, S3 does not function as a traditional POSIX-compliant file system that can be directly mounted as a volume within an AWS Fargate container. Containerized applications typically require a file system interface for their persistent storage needs, which S3 does not natively provide for direct volume mounting.
D
Amazon EBS volume
Why it fails: Amazon EBS (Elastic Block Store) provides persistent block storage volumes that can be attached to a single Amazon EC2 instance. While highly performant and durable, EBS volumes are fundamentally designed for single-instance attachment and are not directly supported as a volume type for AWS Fargate tasks. Fargate's serverless operational model abstracts the underlying infrastructure, preventing direct attachment or management of EBS volumes for container storage.

Question 5easymultiple choice

Refer to the exhibit. An IAM policy is attached to an IAM user. The user tries to upload a file to s3://my-bucket/confidential/report.pdf. What will happen?

Exhibit

Refer to the exhibit.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    },
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::my-bucket/confidential/*"
    }
  ]
}

Trap 1: The upload succeeds because the Deny statement applies only to the…

The Deny statement in an IAM identity-based policy directly restricts the user to whom the policy is attached. It does not solely apply to the resource in isolation; rather, it defines what actions the user is prohibited from performing on specified resources. Therefore, the Deny statement effectively prevents the user from uploading objects to the bucket, making the upload fail, not succeed.

Trap 2: The upload fails because the policy does not allow PutObject on…

The policy's Allow statement actually grants s3:PutObject on `arn:aws:s3:::my-example-bucket/*`, which covers any path within the bucket. The upload failure is not due to a lack of an initial permission grant for the specific path. Instead, the explicit Deny statement for s3:PutObject on the entire bucket overrides this general Allow, causing the operation to be rejected.

Trap 3: The upload succeeds because the Allow statement grants PutObject.

While the policy does contain an Allow statement for s3:PutObject on the bucket, the presence of an explicit Deny statement for the same action and resource fundamentally alters the outcome. According to AWS IAM policy evaluation, an explicit Deny always overrides any existing Allow. Consequently, the Allow statement's grant is nullified by the Deny, preventing the upload from succeeding.

A
The upload fails because the Deny statement overrides the Allow.
AWS IAM policy evaluation logic dictates that an explicit Deny statement always takes precedence over any Allow statement, even if the Allow statement would otherwise grant the requested permission. In this scenario, despite an Allow for s3:PutObject, the presence of a Deny for the same action on the bucket ensures the upload operation is blocked. This fundamental rule prioritizes security by preventing unintended access, making the upload fail.
B
The upload succeeds because the Deny statement applies only to the bucket, not the user.
Why it fails: The Deny statement in an IAM identity-based policy directly restricts the user to whom the policy is attached. It does not solely apply to the resource in isolation; rather, it defines what actions the user is prohibited from performing on specified resources. Therefore, the Deny statement effectively prevents the user from uploading objects to the bucket, making the upload fail, not succeed.
C
The upload fails because the policy does not allow PutObject on that path.
Why it fails: The policy's Allow statement actually grants s3:PutObject on `arn:aws:s3:::my-example-bucket/*`, which covers any path within the bucket. The upload failure is not due to a lack of an initial permission grant for the specific path. Instead, the explicit Deny statement for s3:PutObject on the entire bucket overrides this general Allow, causing the operation to be rejected.
D
The upload succeeds because the Allow statement grants PutObject.
Why it fails: While the policy does contain an Allow statement for s3:PutObject on the bucket, the presence of an explicit Deny statement for the same action and resource fundamentally alters the outcome. According to AWS IAM policy evaluation, an explicit Deny always overrides any existing Allow. Consequently, the Allow statement's grant is nullified by the Deny, preventing the upload from succeeding.

Question 6hardmulti select

A developer is building an API using Amazon API Gateway and AWS Lambda. The API must authenticate users using a third-party OAuth 2.0 provider. Which TWO components are required to implement this authentication?

Trap 1: Amazon CloudFront distribution for API caching

CloudFront caches responses at edge locations; it neither validates OAuth 2.0 tokens nor invokes authorizers. The scenario needs a Lambda authorizer to validate the third-party token and an API Gateway authorizer configuration that attaches it to the API methods.

Trap 2: An API Gateway resource policy that invokes the Lambda authorizer

A resource policy controls which principals may invoke the API; it performs no token validation and cannot call a Lambda authorizer. The required components are a Lambda authorizer that validates the third-party OAuth 2.0 token and an API Gateway authorizer configuration referencing it.

Trap 3: An Amazon Cognito user pool as the OAuth provider

The stem specifies a third-party OAuth 2.0 provider, so a Cognito user pool would itself be the identity provider, not the external one. Cognito user pools suit scenarios where you control the user directory; here a Lambda authorizer validating the third-party token is required.

A
The OAuth 2.0 access token in the Authorization header
Passing the third-party OAuth 2.0 access token in the Authorization header lets API Gateway validate it against the provider's JWKS endpoint via a Lambda authoriser or JWT authoriser, satisfying the requirement to authenticate users through an external OAuth 2.0 provider rather than native AWS credentials.
B
Amazon CloudFront distribution for API caching
Why it fails: CloudFront caches responses at edge locations; it neither validates OAuth 2.0 tokens nor invokes authorizers. The scenario needs a Lambda authorizer to validate the third-party token and an API Gateway authorizer configuration that attaches it to the API methods.
C
An API Gateway resource policy that invokes the Lambda authorizer
Why it fails: A resource policy controls which principals may invoke the API; it performs no token validation and cannot call a Lambda authorizer. The required components are a Lambda authorizer that validates the third-party OAuth 2.0 token and an API Gateway authorizer configuration referencing it.
D
An AWS Lambda authorizer function
A Lambda authorizer validates the third-party OAuth 2.0 token and returns an IAM policy, letting API Gateway enforce authorisation. It is required because API Gateway cannot natively validate arbitrary third-party OAuth tokens without custom logic.
E
An Amazon Cognito user pool as the OAuth provider
Why it fails: The stem specifies a third-party OAuth 2.0 provider, so a Cognito user pool would itself be the identity provider, not the external one. Cognito user pools suit scenarios where you control the user directory; here a Lambda authorizer validating the third-party token is required.