CCNA Design Secure Questions — Page 1 of 2

MCQmedium

You deploy a Web ACL with an AWS WAF rate-based rule intended to limit abusive traffic to your API. After the deployment, attackers still reach the backend service. ALB access logs show requests arrive at the ALB, but WAF logs indicate the Web ACL is not evaluating those requests. Which change most likely fixes the issue?

A.Associate the Web ACL with the Application Load Balancer resource ARN so WAF evaluates requests sent to that ALB.

B.Add a security group rule that drops inbound traffic from the attacker IP range at the instances' ENIs.

C.Create a target group stickiness policy so WAF can count requests consistently per client IP.

D.Enable AWS Shield Advanced but keep the Web ACL unattached because Shield automatically applies rate limiting.

AnswerA

For an ALB, the Web ACL must be associated with the load balancer resource itself. If it is not attached to the ALB, WAF will not inspect those requests.

Why this answer

A Web ACL must be explicitly associated with a resource (such as an ALB) for AWS WAF to evaluate incoming requests. In this scenario, the Web ACL was deployed but not associated with the ALB resource ARN, so WAF never inspected the traffic. Associating the Web ACL with the ALB ensures that all requests to the ALB are evaluated by the rate-based rule before reaching the backend.

Exam trap

The trap here is that candidates assume deploying a Web ACL automatically applies it to all resources in the account, when in fact it must be explicitly associated with each resource ARN to take effect.

Why the other options are wrong

The issue is that the Web ACL is not evaluating requests at all, which indicates a missing association between the Web ACL and the ALB. Adding a security group rule to drop traffic from attacker IPs does not address the root cause—the Web ACL is not in the evaluation path—and security groups operate at the instance level, not at the ALB level for WAF inspection.

Stickiness (session affinity) ensures requests from the same client are sent to the same target, but it does not cause WAF to evaluate requests. The issue is that the Web ACL is not associated with the ALB, so WAF never inspects traffic regardless of stickiness.

AWS Shield Advanced does not automatically apply rate limiting; it provides DDoS protection but does not replace the need to associate a Web ACL for WAF rate-based rules. The Web ACL must be explicitly associated with a resource like an ALB to evaluate requests.

Practice this question →

MCQmedium

Your company has an internal service hosted behind a Network Load Balancer (NLB) in VPC 10.0.0.0/16. A consumer team in a different VPC (10.1.0.0/16) must call the service without using the public internet. You want private connectivity using AWS PrivateLink. Which configuration best enables least-privilege access while keeping the traffic private?

A.Expose the NLB with an Internet Gateway route and restrict access using a security group attached to the NLB.

B.Create a VPC endpoint (interface endpoint) in the consumer VPC that points to the service name published by the provider account, and limit allowed clients using the endpoint’s security group rules.

C.Create an S3 Gateway endpoint in the consumer VPC and store the service hostname in SSM Parameter Store so clients can resolve privately.

D.Use a bastion host in the provider VPC and allow the consumer VPC to SSH to it; from there, the consumer makes HTTP calls to the NLB.

AnswerB

PrivateLink uses an interface VPC endpoint in the consumer VPC (using the provider’s published service name). Traffic stays on the AWS network, not the public internet. Security groups on the interface endpoint provide least-privilege control over which client resources can reach the endpoint, and the provider side can also restrict who can connect.

Why this answer

AWS PrivateLink uses an interface VPC endpoint in the consumer VPC to connect privately to a Network Load Balancer (NLB) in the provider VPC, keeping traffic within the AWS network. The endpoint’s security group acts as a stateful firewall to restrict which clients in the consumer VPC can access the service, enforcing least-privilege access. This eliminates exposure to the public internet and avoids complex routing or gateway configurations.

Exam trap

The trap here is that candidates often confuse Gateway Endpoints (which only work with S3 and DynamoDB) with Interface Endpoints (which support PrivateLink for services behind an NLB), leading them to incorrectly select Option C.

How to eliminate wrong answers

Option A is wrong because attaching an Internet Gateway route to the NLB would expose the service to the public internet, violating the requirement for private connectivity and least-privilege access; NLB security groups are not supported (NLBs use security groups only for target instances, not the load balancer itself). Option C is wrong because an S3 Gateway endpoint is designed exclusively for Amazon S3 access and cannot be used to connect to an NLB or resolve a service hostname; SSM Parameter Store does not provide private network connectivity. Option D is wrong because using a bastion host introduces a single point of failure, requires SSH key management, and violates least-privilege by granting broad network access; it also adds latency and operational overhead compared to a direct PrivateLink connection.

Practice this question →

Multi-Selecthard

A image sharing application uses CloudFront in front of an S3 origin. Which two settings help keep users from bypassing CloudFront and accessing the bucket directly?

Select 2 answers

A.Enable CloudFront standard logging

B.Enable S3 static website hosting

C.Configure Origin Access Control for the S3 origin

D.Use an S3 bucket policy that allows access only from the CloudFront distribution

AnswersC, D

Origin Access Control allows CloudFront to securely access a private S3 bucket.

Why this answer

Origin Access Control (OAC) is a CloudFront feature that restricts access to an S3 origin by requiring that all requests include a specific signature that only CloudFront can generate. When you configure OAC, CloudFront signs requests to S3 using its own credentials, and the S3 bucket policy is updated to allow access only to the CloudFront distribution's canonical user ID. This ensures that direct requests to the S3 bucket URL are denied, preventing users from bypassing CloudFront.

Exam trap

The trap here is that candidates often confuse enabling S3 static website hosting (which creates a public endpoint) with a security control, when in fact it would undermine the goal of restricting direct access.

Practice this question →

MCQhard

An EC2 instance in a private subnet must access an S3 bucket that contains regulated exports for a customer analytics portal. The security team requires access to be allowed only when traffic comes through a specific VPC endpoint. What should the architect add to the bucket policy? The design must avoid adding custom operational scripts.

A.A security group rule that allows HTTPS to S3

B.A condition that matches aws:RequestedRegion to the bucket Region

C.A deny statement for all IAM users except the EC2 role

D.A condition that matches aws:sourceVpce to the endpoint ID

AnswerD

The aws:sourceVpce condition restricts S3 access to requests that arrive through the specified VPC endpoint.

Why this answer

The bucket policy can use the `aws:sourceVpce` condition key to restrict access exclusively to traffic originating from a specific VPC endpoint ID. This ensures that only requests sent through that VPC endpoint are allowed, meeting the security team's requirement without requiring custom scripts or additional infrastructure.

Exam trap

The trap here is that candidates may confuse security group rules with bucket policies, or assume that restricting by IAM user or region is sufficient to enforce network-level control, when in fact only the `aws:sourceVpce` condition key directly ties access to a specific VPC endpoint.

How to eliminate wrong answers

Option A is wrong because security group rules operate at the network interface level and cannot be attached to an S3 bucket; S3 bucket policies are resource-based policies that do not support security group references. Option B is wrong because `aws:RequestedRegion` restricts the AWS Region in which the request is made, not the network path or VPC endpoint used, so it does not enforce that traffic comes through a specific VPC endpoint. Option C is wrong because denying all IAM users except the EC2 role would not restrict traffic to a specific VPC endpoint; it only controls which IAM identities can access the bucket, not the network path, and could break legitimate access from other services or users.

Practice this question →

MCQmedium

In AWS Organizations, a Service Control Policy (SCP) denies kms:Decrypt on a production CMK for all principals in the Finance OU. A developer in the Finance OU created/updated an IAM policy that allows secrets access, but the application still fails with AccessDenied due to the SCP. You must enable only the Finance OU to decrypt that specific CMK while keeping the SCP restrictions for other OUs. What is the correct remediation?

A.Update the developer’s IAM policy to allow kms:Decrypt on the CMK alias ARN so the request bypasses the SCP.

B.Modify the SCP so it no longer denies kms:Decrypt for that specific CMK when applied to the Finance OU, while preserving the deny behavior for other OUs.

C.Add a KMS key policy statement that allows the developer role to decrypt the CMK.

D.Attach a permissions boundary that grants kms:Decrypt so the SCP becomes irrelevant.

AnswerB

Because the SCP is what creates the Deny, the correct fix is to adjust the SCP scope/conditions so that kms:Decrypt for the specific CMK is not denied for the Finance OU. Other OUs remain under the same restrictive SCP behavior.

Why this answer

SCPs are evaluated before IAM policies and cannot be bypassed by IAM permissions. By modifying the SCP to exclude the specific CMK for the Finance OU (e.g., using a Condition key like `kms:ViaService` or a resource-level exception), you remove the explicit deny for that OU while keeping it in place for all other OUs. This ensures the developer's IAM policy can then allow `kms:Decrypt` without being blocked by the SCP.

Exam trap

The trap here is that candidates mistakenly think IAM policies or KMS key policies can override an SCP, but SCPs are a higher-order policy that always takes precedence over any allow within the account.

How to eliminate wrong answers

Option A is wrong because SCPs take precedence over IAM policies; an IAM policy allowing `kms:Decrypt` cannot bypass an SCP that explicitly denies the same action. Option C is wrong because a KMS key policy statement granting decrypt to the developer role is still subject to the SCP's explicit deny, which overrides any allow from the key policy. Option D is wrong because a permissions boundary limits the maximum permissions an IAM role can have, but it does not override an SCP; the SCP's explicit deny still applies and blocks the action.

Practice this question →

MCQhard

Based on the exhibit, a public API is behind CloudFront. A single client IP is sending bursts of requests that are overwhelming the origin, and the team wants AWS to automatically mitigate the abuse at the edge without changing the application code. What should the team do?

A.Associate an AWS WAF web ACL with CloudFront and add a rate-based rule for the offending IP behavior.

B.Increase the ALB idle timeout to allow the origin to absorb more concurrent requests.

C.Add an Amazon Route 53 health check to fail over traffic to another DNS name.

D.Enable AWS Shield Advanced and rely on automatic DDoS protection for all request bursts.

AnswerA

AWS WAF is the right control at the CloudFront edge because it can inspect requests before they reach the origin and enforce a rate-based rule on abusive traffic patterns. A rate-based rule can automatically count requests by source IP and block or challenge requests that exceed the configured threshold, which directly addresses the burst traffic shown in the logs. This meets the requirement to mitigate at the edge without any application changes.

Why this answer

AWS WAF rate-based rules automatically block or rate-limit requests from a client IP when the request rate exceeds a threshold you define. By associating the web ACL with CloudFront, the rule is enforced at the edge before traffic reaches the origin, mitigating abuse without modifying application code.

Exam trap

The trap here is that candidates confuse AWS Shield Advanced's automatic DDoS mitigation (which handles network/transport layer floods) with the need for a WAF rate-based rule to stop application-layer request bursts from a single IP.

How to eliminate wrong answers

Option B is wrong because increasing the ALB idle timeout does not reduce the volume of requests hitting the origin; it only keeps idle connections open longer, which can actually worsen resource exhaustion. Option C is wrong because Route 53 health checks and failover reroute traffic to another endpoint but do not mitigate bursts from a single IP; the abusive client would simply follow the failover. Option D is wrong because AWS Shield Advanced provides enhanced DDoS protection against volumetric attacks, but it does not automatically apply per-IP rate limiting for application-layer request bursts; a rate-based rule in AWS WAF is required for that granular control.

Practice this question →

MCQmedium

A SOC analyst needs an immutable, centralized audit record of configuration and API changes across multiple AWS accounts. Recently, an operator changed an IAM role trust policy, and investigators must determine exactly which principal made the change and which parameters were used. Your current setup sends application logs to CloudWatch Logs, but there is no organization-level API audit logging. Which approach best satisfies the requirement?

A.Enable an AWS Organizations CloudTrail organization trail that delivers management event logs (including IAM) to a centralized S3 bucket in a dedicated audit account, for all regions.

B.Use CloudWatch Logs metric filters on application logs to infer which principals changed trust policies.

C.Rely on GuardDuty alerts to provide the full request parameters for every IAM policy change.

D.Enable AWS Config only and store periodic snapshots without CloudTrail management events.

AnswerA

CloudTrail management events provide authoritative audit logs for API actions like IAM policy changes and can be centralized via an organization trail.

Why this answer

An AWS Organizations CloudTrail organization trail captures management events (including IAM API calls like 'UpdateAssumeRolePolicy') across all accounts in the organization, delivering immutable logs to a centralized S3 bucket in a dedicated audit account. This provides the exact principal ARN, source IP, user agent, and request parameters for every API call, meeting the requirement for a centralized, immutable audit record of configuration and API changes.

Exam trap

The trap here is that candidates confuse AWS Config's resource tracking with CloudTrail's API-level auditing, failing to realize that only CloudTrail captures the 'who' and 'how' (principal and parameters) of a change, while Config only records the 'what' (state after change).

Why the other options are wrong

CloudWatch Logs metric filters on application logs cannot capture the full API request parameters (e.g., which principal made the change and the exact parameters used) because application logs are not authoritative for IAM changes and lack the detailed API call context required for immutable audit records.

AWS Config stores resource configuration changes but does not capture the full API request parameters (e.g., which principal made the change or the exact parameters used), so it cannot provide the immutable audit record of API calls required for forensic investigation.

Practice this question →

MCQmedium

An application in Account B (IAM role arn:aws:iam::account-b:role/app-read) reads objects from an S3 bucket in Account A. The bucket uses SSE-KMS with a customer-managed KMS key in Account A. Object reads consistently fail with an error that includes "AccessDenied" and "kms:Decrypt". The IAM permissions in Account B for kms:Decrypt are correct, but the requests still fail. Which change will most directly fix the failure?

A.Add kms:Decrypt to the KMS key policy in Account A for the Account B role arn:aws:iam::account-b:role/app-read, and remove kms:Decrypt from the role policy in Account B.

B.Update the IAM role in Account B to use the s3:GetObject permission only, and rely on S3 to authorize KMS decrypt automatically.

C.Modify the KMS key policy in Account A to allow kms:Decrypt for the Account B role arn:aws:iam::account-b:role/app-read, using the appropriate cross-account conditions (for example, allowing the use via S3 and the expected encryption context for the bucket).

D.Switch the S3 bucket encryption from SSE-KMS to SSE-S3, keeping all existing IAM and KMS configuration unchanged.

AnswerC

For SSE-KMS, S3 must call KMS Decrypt when serving objects. KMS authorization is evaluated against the KMS key policy in Account A in addition to the identity policy in Account B. If the error includes kms:Decrypt AccessDenied in a cross-account scenario, the most direct fix is to update the KMS key policy to allow the Account B role to use the key for decrypt (often with conditions tied to S3 usage and the specific bucket/object encryption context).

Why this answer

When using SSE-KMS with a customer-managed KMS key in a cross-account scenario, the KMS key policy must explicitly grant the external IAM role (arn:aws:iam::account-b:role/app-read) permission to perform kms:Decrypt. Even if the IAM role in Account B has the correct kms:Decrypt permission, the KMS key policy in Account A acts as a resource-based policy that must also allow the cross-account principal. Without this, the KMS service denies the decrypt request, resulting in the 'AccessDenied' error.

Exam trap

The trap here is that candidates often assume IAM permissions alone are sufficient for cross-account KMS operations, forgetting that KMS key policies are resource-based and must explicitly allow external principals, even when the IAM role has the correct permissions.

Why the other options are wrong

The error indicates that the KMS key policy in Account A does not grant the Account B role permission to decrypt. Adding kms:Decrypt to the key policy is necessary, but removing it from the role policy in Account B is incorrect because the role still needs the permission for the request to proceed; both the key policy and the role policy must allow the action.

The error includes 'kms:Decrypt', indicating the KMS key policy is missing cross-account decrypt permission. Simply using s3:GetObject does not bypass KMS authorization; S3 cannot automatically authorize KMS decrypt across accounts without proper key policy.

Switching to SSE-S3 removes KMS involvement, but the question states that the bucket uses SSE-KMS with a customer-managed key. Changing encryption type is an indirect workaround that does not address the root cause (missing KMS key policy permissions) and may violate compliance or security requirements.

Practice this question →

MCQmedium

A retail company lets developers deploy ECS services but they must never be able to modify IAM. The team currently uses an IAM user per developer with an admin-like policy, and several access keys have been leaked. You are asked to redesign access so that: (1) developers authenticate with temporary credentials, (2) they can create/update ECS services and related autoscaling resources, and (3) IAM changes are impossible even if a developer tries to attach new policies. Which design best meets all requirements?

A.Create an IAM user for each developer and keep the existing broad permissions, rotating keys every 90 days.

B.Use an IAM role that developers assume for deployments; attach least-privilege policies for ECS and Auto Scaling; and attach a permission boundary that does not allow iam:* actions, so additional inline or managed policies cannot grant IAM permissions.

C.Attach a policy that allows ecs:* and autoscaling:* and rely on developers to self-review that no IAM statements are added to their roles.

D.Create a single shared IAM role with full administrator permissions so developers can troubleshoot faster when deployments fail.

AnswerB

Assuming a role provides temporary credentials and removes long-lived keys. Least-privilege policies limit allowed actions, and a permission boundary caps the role's effective permissions so IAM actions cannot be gained through later policy changes.

Why this answer

It uses an IAM role with temporary credentials (via AWS STS AssumeRole), satisfying the requirement that developers never have long-term access keys. The least-privilege policies restrict actions to ECS and Auto Scaling only, and the permission boundary explicitly denies iam:* actions, preventing developers from escalating privileges by attaching new policies to their role. This combination ensures developers can deploy ECS services but cannot modify IAM in any way.

Exam trap

The trap here is that candidates may think a permission boundary is optional or that denying iam:* actions in a policy is sufficient, but without a boundary, a developer could attach a new policy that grants iam:* actions, bypassing the deny—the boundary is required to cap permissions at the role level.

Why the other options are wrong

Option A uses long-term IAM users with static keys, violating requirement (1) for temporary credentials. Rotating keys every 90 days does not prevent leaks between rotations and still allows permanent access, failing to meet the security goal.

This option relies on developers self-policing their policies, which does not prevent them from accidentally or intentionally adding IAM permissions, violating the requirement that IAM changes be impossible.

Option D grants full administrator permissions, violating the requirement that developers must never be able to modify IAM. It also uses a single shared role with permanent credentials, contradicting the need for temporary credentials and least privilege.

Practice this question →

MCQeasy

A team stores important documents in Amazon S3. They want to recover earlier versions if someone overwrites or deletes a file by mistake. What should they enable?

A.Amazon S3 Versioning

B.Amazon EBS snapshots

C.Amazon CloudWatch logs

D.VPC flow logs

AnswerA

Amazon S3 Versioning is the correct solution as it automatically retains multiple variants of an object in the same bucket, each with a unique version ID. This crucial feature enables recovery from both accidental overwrites and deletions, ensuring the integrity and availability of important documents. When an object is modified or deleted, S3 does not remove the previous version, but rather stores it as a non-current version, allowing for easy restoration to any prior state.

Why this answer

Amazon S3 Versioning is the correct choice because it allows you to preserve, retrieve, and restore every version of every object stored in an S3 bucket. When enabled, S3 automatically maintains a unique version ID for each object, so if a file is overwritten or deleted, the previous version remains accessible. This directly addresses the requirement to recover earlier versions after accidental modification or deletion.

Exam trap

The trap here is that candidates may confuse S3 Versioning with backup services like EBS snapshots, but versioning is an S3-native feature for object-level recovery, not a volume-level backup mechanism.

Why the other options are wrong

Amazon EBS snapshots are used for backing up Amazon Elastic Block Store volumes attached to EC2 instances, not for S3 object versioning. They do not provide the ability to recover earlier versions of S3 objects.

Amazon CloudWatch logs capture log data from AWS resources, not file versions. They cannot recover overwritten or deleted S3 objects.

VPC flow logs capture IP traffic information for network interfaces in a VPC, not file version history in S3. They cannot recover overwritten or deleted S3 objects.

Practice this question →

MCQhard

Based on the exhibit, a CI pipeline assumes a shared deployment role in Account A. The role can access several artifact prefixes, but this pipeline must only upload to teamA/prod/ and decrypt using a single KMS key for this execution. Changing the shared role would affect other pipelines. Which approach should the pipeline use?

A.Attach a permission boundary to the pipeline's assumed session so the temporary credentials cannot exceed the shared role permissions.

B.Pass an inline session policy in the AssumeRole request that further restricts the temporary credentials to teamA/prod/ and the approved KMS key.

C.Add an SCP to Account A that forces all roles to use the same S3 prefix and key whenever they are assumed.

D.Change the role trust policy to allow only the teamA/prod/ prefix and the key ARN because trust policies can scope S3 object paths directly.

AnswerB

STS session policies are designed to further restrict the permissions of temporary credentials issued by AssumeRole. In this case, the shared role can remain reusable for other pipelines, while this one execution is narrowed to the exact S3 prefix and KMS key required. The effective permissions become the intersection of the role permissions and the session policy, which preserves least privilege without changing the shared role itself.

Why this answer

An inline session policy passed in the AssumeRole request allows you to further restrict the temporary credentials' permissions without modifying the shared role itself. This ensures the pipeline can only upload to teamA/prod/ and decrypt using the specified KMS key, while other pipelines using the same role remain unaffected.

Exam trap

The trap here is that candidates confuse permission boundaries (which set a maximum limit) with session policies (which further restrict a specific session), or mistakenly think trust policies can scope resource-level permissions like S3 prefixes or KMS keys.

How to eliminate wrong answers

Option A is wrong because a permission boundary sets the maximum permissions for the role but does not dynamically restrict the session to specific prefixes or keys; it would still allow access to all prefixes the role can access. Option C is wrong because SCPs apply to all principals in the account and cannot be scoped to a single pipeline's session without affecting other roles and users. Option D is wrong because trust policies control who can assume the role, not what actions the assumed session can perform; S3 object paths cannot be scoped in trust policies.

Practice this question →

MCQeasy

A company runs EC2 instances in private subnets and needs to access Amazon S3 objects without using a NAT gateway. They want the traffic to stay within AWS private networking as much as possible (no internet egress). Which VPC endpoint type should they create for Amazon S3?

A.Create an Interface VPC endpoint for S3 and point the instances to it

B.Create a Gateway VPC endpoint for S3 and update the route tables to use it

C.Create a NAT gateway and allow outbound HTTPS to S3

D.Create a VPC endpoint service and manually register S3 as a provider endpoint

AnswerB

Gateway VPC endpoints for S3 are the supported way to send S3 traffic from private subnets without NAT. They add routes in the relevant route tables (via S3 prefix lists) so requests to S3 go through the AWS network. This avoids internet egress and keeps the path private to the extent intended by VPC endpoint routing.

Why this answer

A Gateway VPC endpoint for S3 is the correct choice because it uses prefix lists and route table entries to send S3 traffic directly through AWS's private network without leaving the AWS backbone or requiring a NAT gateway. This endpoint type supports S3 and DynamoDB only, and it does not incur hourly charges, making it cost-effective for private subnet instances to access S3 objects securely.

Exam trap

The trap here is that candidates often confuse Gateway endpoints (for S3/DynamoDB) with Interface endpoints (for other AWS services), or incorrectly assume that a NAT gateway is required for private subnet egress, missing that Gateway endpoints provide a free, private alternative for S3 access.

How to eliminate wrong answers

Option A is wrong because an Interface VPC endpoint for S3 uses an Elastic Network Interface (ENI) with a private IP, but it still requires a NAT gateway or internet gateway for private subnet instances to reach it unless the endpoint is in the same subnet; more importantly, Gateway endpoints are the recommended and simpler option for S3. Option B is the correct answer. Option C is wrong because a NAT gateway allows outbound internet traffic, which violates the requirement to keep traffic within AWS private networking and avoid internet egress.

Option D is wrong because a VPC endpoint service is used to expose your own services to other VPCs via AWS PrivateLink, not to access AWS services like S3; you cannot manually register S3 as a provider endpoint.

Practice this question →

MCQeasy

A CI/CD pipeline needs to deploy to your production environment. Security requires that the pipeline uses temporary credentials (not long-lived access keys) and only has permissions to read a specific set of parameters from AWS Systems Manager Parameter Store and write application logs to CloudWatch Logs. What is the best AWS approach?

A.Create an IAM user for the pipeline and store access keys in the CI system.

B.Create an IAM role in the production account, grant least-privilege policies, and let the CI assume it using STS AssumeRole.

C.Attach the required permissions to an IAM group and add the pipeline’s principal to that group directly.

D.Use AWS KMS to encrypt the pipeline’s access keys and store the ciphertext in the CI system.

AnswerB

IAM roles with STS provide temporary credentials and allow least-privilege permissions via attached policies.

Why this answer

It uses an IAM role with least-privilege policies that the CI/CD pipeline can assume via AWS STS AssumeRole, generating temporary credentials that automatically expire. This eliminates the need for long-lived access keys and adheres to the security requirement of using temporary credentials. The role's policies can be scoped to exactly read specific parameters from Systems Manager Parameter Store and write logs to CloudWatch Logs.

Exam trap

The trap here is that candidates may choose Option A or D because they focus on credential storage rather than the fundamental requirement for temporary credentials, or they may confuse IAM groups with roles, thinking a group can be used for cross-account access without understanding that groups only apply to IAM users within the same account.

How to eliminate wrong answers

Option A is wrong because creating an IAM user with long-lived access keys violates the security requirement for temporary credentials and introduces a static credential risk if the keys are leaked. Option C is wrong because IAM groups are used to attach policies to IAM users, not to external principals like a CI/CD pipeline; the pipeline's principal cannot be added directly to an IAM group without first being an IAM user. Option D is wrong because encrypting access keys with KMS still results in long-lived credentials that must be decrypted and used, failing the temporary credentials requirement and adding unnecessary complexity without addressing the core security mandate.

Practice this question →

MCQhard

Based on the exhibit, a workload in Account B must assume a role in Account A. Security requires that only the specific role arn:aws:iam::444455556666:role/PipelineExecRole can assume it, and only when the caller supplies the external ID acct-b-prod-7788. Which change best satisfies the requirement with the least privilege?

A.Keep the root principal and add an aws:PrincipalTag condition in the trust policy to require the tag acct-b-prod-7788.

B.Replace the principal with arn:aws:iam::444455556666:role/PipelineExecRole and add a StringEquals condition on sts:ExternalId = acct-b-prod-7788.

C.Attach a permission boundary to the role in Account A so that only PipelineExecRole can use it.

D.Add an SCP in Account B that allows sts:AssumeRole only for PipelineExecRole.

AnswerB

This change directly restricts trust to one named role in Account B and adds a confused-deputy defense with the external ID. The role trust policy is the correct place to control who can assume the role, and the external ID ensures only the expected caller can complete the STS request.

Why this answer

It explicitly restricts the trust policy principal to the specific IAM role ARN `arn:aws:iam::444455556666:role/PipelineExecRole` and adds a `StringEquals` condition on `sts:ExternalId` set to `acct-b-prod-7788`. This satisfies the security requirement by ensuring only that exact role can assume the role in Account A, and only when the correct external ID is provided, following the principle of least privilege.

Exam trap

The trap here is that candidates often confuse the trust policy's `Principal` element with permission boundaries or SCPs, mistakenly thinking those can restrict who can assume a role, when in fact only the trust policy controls the assumption, and the external ID condition is required to prevent confused deputy attacks.

How to eliminate wrong answers

Option A is wrong because using a root principal (which allows any IAM entity in Account B) combined with an `aws:PrincipalTag` condition does not restrict the caller to the specific role `PipelineExecRole`; tags can be modified or absent, and the root principal is overly permissive. Option C is wrong because a permission boundary attached to the role in Account A limits the permissions of that role but does not control which external principal can assume it; the trust policy alone governs who can assume the role. Option D is wrong because an SCP in Account B can deny or allow `sts:AssumeRole` actions for principals in Account B, but it cannot enforce the external ID requirement or restrict which role in Account A is assumed; the trust policy in Account A is the authoritative mechanism.

Practice this question →

MCQmedium

In an AWS Organizations environment, developers create IAM roles using an automation tool. The security team wants to guarantee that even if a developer attaches an overly permissive inline policy, the role cannot exceed a fixed set of allowed actions. The team already uses permission boundaries on each role. The tool’s role-creation API call succeeds, but one developer’s new role can still delete production S3 buckets. What is the most likely reason, and what should be corrected?

A.Permission boundaries do not affect permissions for resources created with role chaining; enable role chaining instead to apply the boundary.

B.The boundary policy was not actually attached during role creation, or the automation tool attached the wrong boundary ARN; correct the role-creation request to set the intended PermissionBoundary.

C.KMS key policies override permission boundaries for S3, so deletion permission comes from the KMS policy; restrict the KMS key policy instead.

D.Permission boundaries apply only to managed policies, not to inline policies; move the overly permissive permissions to a managed policy type to keep it bounded.

AnswerB

Permission boundaries work by intersecting allowed actions from the role’s attached policies with the actions permitted by the boundary policy. If the automation tool fails to set the PermissionBoundary ARN (or sets an incorrect one), then the role can use the developer’s attached policies without the intended restriction. Fixing the PermissionBoundary parameter in the role creation call is the direct remedy.

Why this answer

Permission boundaries must be explicitly attached to an IAM role during creation via the `PermissionBoundary` parameter. If the automation tool fails to attach the intended boundary policy or attaches the wrong ARN, the role will have no effective boundary, allowing any inline policy to grant full access. The developer's role could then delete production S3 buckets because the boundary was not enforced.

Exam trap

The trap here is that candidates may assume permission boundaries are automatically inherited from the AWS Organizations policy or that they only affect managed policies, when in fact they must be explicitly attached and apply to all policy types.

How to eliminate wrong answers

Option A is wrong because permission boundaries do apply to roles used in role chaining; role chaining does not bypass boundaries, and enabling it would not fix the issue. Option C is wrong because KMS key policies control encryption operations, not S3 bucket deletion permissions; S3 delete actions are governed by S3 resource-based policies and IAM policies, not KMS policies. Option D is wrong because permission boundaries apply to both managed and inline policies equally; they limit the maximum permissions a role can have regardless of policy type.

Practice this question →

MCQmedium

An administrator needs the ability to read and update infrastructure for a specific AWS account, but only when using MFA. The security team wants to eliminate long-lived administrator access keys and ensure that even if someone obtains temporary session credentials, actions are only allowed with MFA present. Which IAM design best meets these requirements?

A.Create an IAM user for administrators with AdministratorAccess and require MFA only at the IAM user login.

B.Create an IAM role for administration and use a permissions policy that allows only the required read/write actions. Add a condition to deny all allowed actions unless aws:MultiFactorAuthPresent is true.

C.Attach policies to an IAM user that allow read/write actions and enable MFA in the account, but do not use condition keys in IAM policies.

D.Use a role with the correct actions but enforce MFA only in the application by prompting users for an OTP before every API call.

AnswerB

A role-based approach removes long-lived keys and supports temporary credentials. Using a permissions-policy condition to require MFA presence enforces that the session must have MFA to perform actions, aligning with the “actions only allowed with MFA present” requirement.

Why this answer

It uses an IAM role with a condition key `aws:MultiFactorAuthPresent` set to `true` to enforce MFA for all API calls made with temporary credentials. This eliminates long-lived access keys and ensures that even if temporary session credentials are compromised, actions are denied unless MFA was used during the session. The policy explicitly denies all allowed actions when MFA is not present, meeting the security team's requirement for MFA on every administrative action.

Exam trap

The trap here is that candidates often confuse requiring MFA at login (console) with enforcing MFA for all API calls, failing to realize that without a condition key in the IAM policy, access keys or temporary credentials can be used without MFA after the initial login.

Why the other options are wrong

Option A only requires MFA at login, but does not enforce MFA for API calls made with temporary credentials, allowing actions without MFA if session credentials are obtained.

This option does not use a condition key in IAM policies to require MFA for API calls, so temporary session credentials obtained without MFA could still perform actions. It only enforces MFA at login, not for subsequent API operations.

Enforcing MFA only at the application level (via OTP prompt) does not prevent actions taken through other means like AWS CLI or SDK, and does not use IAM condition keys to enforce MFA for all API calls, leaving a security gap.

Practice this question →

MCQmedium

A CI/CD system creates an IAM role (CICDRole) used for deployments. Your organization uses IAM permission boundaries to prevent developers from granting themselves higher privileges. After an incident, you discover that CICDRole can perform unintended IAM actions because the role’s identity policy includes broad permissions. Which change most directly ensures permission boundaries continue to restrict CICDRole regardless of what is later added to the role’s identity policies?

A.Remove the permission boundary from CICDRole so that only the identity policy controls access.

B.Ensure CICDRole is created with the required permissions boundary ARN, and verify that the boundary policy does not allow the unintended IAM actions.

C.Add an identity-policy deny for iam:CreatePolicy and iam:UpdateRole on all resources.

D.Rely on CloudTrail alerts to stop deployments from performing IAM changes after the fact.

AnswerB

Permission boundaries cap the maximum effective permissions for the role by intersecting the identity policy and the permissions boundary at authorization time. Even if the identity policy later expands, the boundary still prevents actions not allowed by the boundary policy, providing deterministic enforcement against privilege escalation.

Why this answer

IAM permission boundaries define the maximum permissions that an IAM role can have, regardless of what is later added to its identity-based policies. By ensuring CICDRole is created with a permission boundary that explicitly denies the unintended IAM actions, even if broad permissions are added to the role's identity policy, the boundary will override and restrict those actions. This directly addresses the requirement to prevent privilege escalation through policy modifications.

Exam trap

The trap here is that candidates often think adding deny statements to the identity policy is sufficient, but they overlook that permission boundaries are the only mechanism that can restrict permissions added later, and that deny statements in the identity policy can be overridden by a broader allow if not carefully scoped.

How to eliminate wrong answers

Option A is wrong because removing the permission boundary eliminates the only mechanism that caps the role's maximum permissions, allowing any broad identity policy to grant unintended IAM actions without restriction. Option C is wrong because adding a deny for iam:CreatePolicy and iam:UpdateRole does not prevent the role from using other IAM actions like iam:PassRole or iam:AttachRolePolicy that could still lead to privilege escalation; it is an incomplete fix that does not address the root cause of broad permissions. Option D is wrong because relying on CloudTrail alerts is a detective control, not a preventive one; it only notifies after the fact, allowing unauthorized IAM actions to occur before any response can be taken.

Practice this question →

MCQmedium

A company runs an application in private subnets (no inbound internet). The application must access Amazon S3 and AWS Secrets Manager endpoints without routing through the public internet and without exposing the instances to NAT gateways due to cost. Security requirements also state that only the required VPC traffic should be allowed to reach AWS services. Which architecture best satisfies these requirements?

A.Place instances in private subnets but use NAT gateways so traffic to S3 and Secrets Manager goes through the internet; restrict security groups to instance-to-instance only.

B.Add a VPC gateway endpoint for S3 and an interface VPC endpoint for Secrets Manager; keep instances in private subnets and configure security group rules attached to the endpoints to allow inbound traffic only from the application subnets.

C.Use public subnets with instances that have no security group rules; rely on AWS services to reject unauthorized traffic.

D.Create an S3 bucket policy that allows requests from the application instances’ private IP addresses and enable public access to Secrets Manager via the default service endpoint.

AnswerB

Gateway endpoints provide private routing to S3, and interface endpoints provide private access to Secrets Manager without internet traversal. Security group controls on interface endpoints restrict traffic to only the application subnets, meeting segmentation and cost constraints.

Why this answer

It uses a VPC gateway endpoint for S3 and an interface VPC endpoint for Secrets Manager, both of which allow private subnet instances to access these AWS services without traversing the public internet or requiring a NAT gateway. The security group rules attached to the interface endpoint restrict inbound traffic to only the application subnets, satisfying the security requirement of allowing only required VPC traffic. This architecture avoids NAT gateway costs and keeps instances isolated from inbound internet traffic.

Exam trap

The trap here is that candidates may assume all AWS service endpoints require a NAT gateway or internet gateway for private subnet access, overlooking the cost-effective and secure alternative of VPC endpoints (gateway and interface) that keep traffic within the AWS network.

Why the other options are wrong

NAT gateways route traffic through the public internet, violating the requirement to avoid public internet and incurring additional cost, which the question explicitly wants to avoid.

Using public subnets without security groups exposes instances to inbound internet traffic, violating the requirement to avoid public internet and the security rule that only required VPC traffic should be allowed to reach AWS services.

Option D is wrong because enabling public access to Secrets Manager via the default service endpoint would expose the service to the internet, violating the requirement to avoid routing through the public internet and the security requirement to allow only required VPC traffic.

Practice this question →

MCQhard

A claims portal uses Amazon RDS for PostgreSQL. Application credentials must not be stored on the EC2 instances, and authentication should use short-lived credentials. What should the architect recommend?

A.Store the database password in user data

B.Embed the database password in the AMI

C.IAM database authentication for RDS with an EC2 instance role

D.Use a security group rule that allows only application instances

AnswerC

IAM database authentication allows the application to use temporary AWS credentials instead of stored database passwords.

Why this answer

IAM database authentication for RDS with an EC2 instance role allows the application to obtain a short-lived authentication token (valid for 15 minutes) using the AWS CLI or SDK, without storing any credentials on the instance. The EC2 instance role provides the necessary permissions to generate the token, which is then used instead of a static password, meeting both security requirements.

Exam trap

The trap here is that candidates often confuse network-level controls (security groups) with authentication mechanisms, or assume that storing credentials in user data or AMIs is acceptable because they are 'hidden' from the application code, but AWS explicitly considers these insecure practices for production workloads.

How to eliminate wrong answers

Option A is wrong because storing the database password in user data persists the credential in plaintext on the instance metadata and can be exposed via the console or API, violating the requirement to not store credentials on EC2. Option B is wrong because embedding the database password in the AMI hard-codes the credential into the image, making it static and long-lived, and any instance launched from that AMI inherits the password, which cannot be rotated without rebuilding the AMI. Option D is wrong because a security group rule controls network access at the transport layer but does not address credential storage or authentication; it only restricts which IPs or instances can connect, not how the application authenticates.

Practice this question →

MCQhard

Based on the exhibit, an automation pipeline in several member accounts creates IAM roles for application deployments. Security says no future role may exceed the approved boundary arn:aws:iam::123456789012:policy/DeployBoundary, even if someone later attaches AdministratorAccess. What should you implement to enforce this across the organization?

A.Attach DeployBoundary to the automation role only, because that automatically forces every created role to inherit the same boundary.

B.Create an SCP that denies iam:CreateRole and iam:PutRolePermissionsBoundary unless aws:RequestTag equals DeployBoundary.

C.Create an SCP that denies iam:CreateRole unless iam:PermissionsBoundary equals arn:aws:iam::123456789012:policy/DeployBoundary, and also deny removing that boundary from created roles.

D.Use AWS Access Analyzer to automatically attach the approved boundary whenever a role is created without one.

AnswerC

This is the strongest organization-wide enforcement. The SCP prevents role creation unless the approved permissions boundary is attached, and it can also prevent boundary removal later. That ensures the maximum effective permissions for all created roles remain capped, even if someone attaches a broader identity policy afterward.

Why this answer

It uses an SCP to enforce that any IAM role creation must include the specific permissions boundary `arn:aws:iam::123456789012:policy/DeployBoundary`, and also prevents removal or modification of that boundary from existing roles. This ensures that even if an attacker or administrator later attaches a policy like AdministratorAccess, the effective permissions are still limited by the boundary, meeting the security requirement across all member accounts in the organization.

Exam trap

The trap here is confusing the condition key `aws:RequestTag` (used for tagging) with `iam:PermissionsBoundary` (the actual boundary ARN), leading candidates to pick Option B, which would not enforce the boundary requirement.

How to eliminate wrong answers

Option A is wrong because attaching a permissions boundary to the automation role does not automatically propagate that boundary to roles created by that role; each role must have its own boundary explicitly set. Option B is wrong because it uses `aws:RequestTag` to match the boundary, but permissions boundaries are not tags; the correct condition key is `iam:PermissionsBoundary`, not a request tag. Option D is wrong because AWS Access Analyzer is a tool for analyzing resource policies and identifying unintended access, not for automatically attaching permissions boundaries to roles.

Practice this question →

MCQmedium

A company hosts an internal HTTP API on an internal Network Load Balancer (NLB) in VPC A. A partner team in a separate AWS account needs access, but their VPC CIDR overlaps with VPC A, so VPC peering is not feasible. Security requirements state the API must remain non-public (no internet-facing ALB/NLB) and access must use AWS private networking. Which architecture best meets these requirements?

A.Use AWS PrivateLink by creating a VPC endpoint service backed by the NLB in VPC A, then create an interface VPC endpoint in the partner VPC with appropriate endpoint access controls.

B.Expose the NLB to the internet with an Elastic IP and restrict access using the NLB’s security group only.

C.Use VPC peering between VPC A and the partner VPC and update route tables to resolve the overlap.

D.Deploy a NAT gateway in VPC A and route the partner’s traffic to the NLB through the NAT gateway.

AnswerA

AWS PrivateLink establishes private, secure connectivity between VPCs without requiring VPC peering, VPN connections, or exposing services to the public internet. By creating a VPC endpoint service backed by the internal Network Load Balancer in VPC A, the internal HTTP API becomes available to the partner VPC via an interface VPC endpoint. This solution inherently avoids CIDR overlap issues and provides granular access control through endpoint policies and service permissions, ensuring the NLB remains non-public.

Why this answer

AWS PrivateLink allows you to expose an internal NLB as a VPC endpoint service in VPC A, and the partner team can create an interface VPC endpoint in their own VPC to connect privately. This works even with overlapping CIDR blocks because PrivateLink uses ENIs with private IPs from the endpoint subnet, not routing based on CIDR. The traffic stays within the AWS network and never traverses the internet, meeting the non-public requirement.

Exam trap

The trap here is that candidates may think VPC peering is always the simplest solution, but they overlook the CIDR overlap restriction, or they assume a NAT gateway can provide inbound private connectivity, which it cannot.

How to eliminate wrong answers

Option B is wrong because attaching an Elastic IP to the NLB makes it internet-facing, violating the requirement that the API must remain non-public; additionally, NLBs do not support security groups, so access control via security groups is not possible. Option C is wrong because VPC peering requires non-overlapping CIDR blocks; overlapping CIDRs cause routing conflicts and are explicitly not supported by AWS VPC peering. Option D is wrong because a NAT gateway is used for outbound internet traffic from a private subnet, not for inbound private connectivity between VPCs; routing partner traffic through a NAT gateway would not establish a private, direct connection and would still require internet routing.

Practice this question →

MCQhard

A platform team lets application teams create IAM roles in member accounts through Infrastructure as Code. Security says every new role must stay within a centrally approved permission ceiling, even if someone later attaches broader managed policies or inline policies. Which control should be used to enforce that maximum permission set?

A.Use an AWS Organizations service control policy to grant the role all needed permissions directly.

B.Attach a permissions boundary to each role so the role can never exceed the approved ceiling.

C.Use a resource-based policy on Amazon S3 to restrict the permissions that IAM roles can receive.

D.Require temporary STS session policies whenever the role is assumed.

AnswerB

A permissions boundary is specifically designed to cap the maximum permissions a role can ever receive, regardless of what identity-based policies are attached later. If a developer adds a broader managed policy or inline policy, the effective permissions still cannot exceed the boundary. This makes it the best fit for delegated role creation with a centrally approved ceiling.

Why this answer

A permissions boundary is an AWS IAM feature that sets the maximum permissions an IAM role can have. When attached to a role, any policy that grants permissions beyond the boundary is effectively ignored, ensuring the role cannot exceed the approved permission ceiling even if broader managed or inline policies are later attached. This directly enforces the security requirement without restricting the application teams' ability to create roles via Infrastructure as Code.

Exam trap

The trap here is confusing service control policies (SCPs) with permissions boundaries: SCPs apply to all principals in an account and cannot be used to set a per-role permission ceiling, while permissions boundaries are specifically designed for that granular control.

How to eliminate wrong answers

Option A is wrong because an AWS Organizations service control policy (SCP) applies to all principals in an account or OU, not to a specific role, and granting permissions directly via SCP would not prevent the role from exceeding the ceiling—it would actually add permissions, not restrict them. Option C is wrong because a resource-based policy on Amazon S3 can only control access to that S3 resource, not restrict the permissions that IAM roles can receive across all services. Option D is wrong because requiring temporary STS session policies only limits permissions during a specific session, but the role itself could still have broader permissions attached, violating the permanent permission ceiling requirement.

Practice this question →

MCQhard

Based on the exhibit, users must access private PDF reports only through CloudFront. Direct requests to the S3 object URL must fail, and the bucket should not be publicly readable. Which solution is the best fit?

A.Enable CloudFront Origin Access Control for the distribution and update the bucket policy to allow only the CloudFront distribution principal with its SourceArn.

B.Keep the bucket public and require signed URLs at CloudFront, because signed URLs automatically block all direct S3 requests.

C.Add an S3 access point and allow the CloudFront distribution to use it without changing the bucket policy.

D.Attach AWS WAF to the distribution and block requests that do not include a signed cookie.

AnswerA

Origin Access Control is the modern pattern for restricting S3 origins to CloudFront. The bucket policy can then permit only the specific distribution, preventing direct S3 access while keeping the content private. Signed URLs or cookies can still be used at the viewer layer for authorization.

Why this answer

CloudFront Origin Access Control (OAC) allows you to restrict access to an S3 bucket so that only the specific CloudFront distribution can retrieve objects. By updating the bucket policy to allow the CloudFront distribution principal with its SourceArn, you ensure that direct requests to the S3 object URL are denied, while CloudFront-signed URLs or cookies can still control user access. This meets the requirement of blocking direct S3 access while keeping the bucket private.

Exam trap

The trap here is that candidates often assume signed URLs or cookies alone can block direct S3 access, but they only control access at the CloudFront level, not at the S3 bucket level, so the bucket must still be private and explicitly restricted to CloudFront.

How to eliminate wrong answers

Option B is wrong because making the bucket public violates the requirement that the bucket should not be publicly readable; signed URLs at CloudFront do not block direct S3 requests if the bucket itself is public. Option C is wrong because an S3 access point alone does not restrict access to only CloudFront; you would still need a bucket policy or OAC to prevent direct S3 access, and the access point does not inherently block requests that bypass CloudFront. Option D is wrong because AWS WAF attached to CloudFront can block requests based on signed cookies, but it does not prevent direct requests to the S3 object URL, which bypass CloudFront entirely.

Practice this question →

MCQmedium

Your EC2 instances run in private subnets with no NAT gateway. The instances use the AWS SDK to call STS AssumeRole to obtain temporary credentials for other services. Application logs show errors like: "EndpointConnectionError: Could not connect to https://sts.<region>.amazonaws.com". Which change most directly resolves this while keeping instances private?

A.Create an interface VPC endpoint for STS (com.amazonaws.<region>.sts) and associate it with the instance subnets and a security group that allows HTTPS.

B.Create a gateway VPC endpoint for S3 and route the STS traffic through the S3 endpoint gateway.

C.Open an inbound rule in the instances’ security group to allow outbound HTTPS to the internet CIDR block directly.

D.Attach an Internet Gateway to the private subnet route table so the STS API can be reached over public internet.

AnswerA

Interface endpoints provide private, in-VPC connectivity to AWS APIs like STS without requiring internet access or NAT.

Why this answer

The error indicates that the EC2 instances in private subnets cannot reach the STS public endpoint over the internet because there is no NAT gateway or internet gateway attached to the private subnets. Creating an interface VPC endpoint for STS (com.amazonaws.<region>.sts) allows the instances to communicate with the STS API privately using AWS PrivateLink, without requiring internet access. Associating the endpoint with the instance subnets and a security group that allows HTTPS (port 443) ensures that traffic stays within the AWS network, resolving the connectivity error while keeping the instances private.

Exam trap

The trap here is that candidates often confuse gateway endpoints (for S3/DynamoDB) with interface endpoints (for most other AWS services like STS), or they mistakenly think security group rules alone can enable internet access without a proper routing path.

Why the other options are wrong

A gateway VPC endpoint only supports S3 and DynamoDB; it cannot route STS traffic, which requires an interface endpoint. STS uses HTTPS traffic that must be directed through an interface endpoint, not a gateway endpoint.

Opening an inbound rule for outbound HTTPS to the internet CIDR does not provide a route to the internet; the instances are in a private subnet with no NAT gateway, so outbound traffic cannot reach the internet.

Attaching an Internet Gateway to the private subnet route table would make the subnet public, violating the requirement to keep instances private. The instances would have direct internet access, which is not allowed.

Practice this question →

MCQhard

Based on the exhibit, an application role in Account B can reach an S3 bucket in Account A, but reads fail with AccessDenied on KMS. The bucket objects use SSE-KMS with a customer managed key in Account A. What change is required so the application can decrypt the objects while keeping the access restricted?

A.Add the Account B role ARN to the KMS key policy with kms:Decrypt and kms:DescribeKey permissions, scoped to S3 usage in us-east-1.

B.Add s3:GetEncryptionConfiguration to the Account B IAM policy so S3 can use the customer managed key on reads.

C.Change the bucket to SSE-S3 because SSE-S3 always allows cross-account reads without any KMS policy changes.

D.Add the Account B role to the bucket ACL with FULL_CONTROL so S3 can bypass KMS on behalf of the reader.

AnswerA

S3 object retrieval with SSE-KMS requires that KMS authorize decryption, and that authorization must exist in the key policy for a CMK in another account. Scoping the statement to the specific role and S3 usage keeps the access narrow while allowing the object read to succeed.

Why this answer

When using SSE-KMS with a customer managed key, cross-account access requires the KMS key policy to explicitly grant the external IAM role (from Account B) the kms:Decrypt and kms:DescribeKey permissions. Without these, S3 can retrieve the encrypted object, but KMS will deny the decryption request, resulting in an AccessDenied error. Scoping the policy to S3 usage in us-east-1 follows the principle of least privilege while enabling the necessary decryption.

Exam trap

The trap here is that candidates often focus only on the S3 bucket policy or IAM permissions, forgetting that SSE-KMS with a customer managed key requires explicit cross-account grants in the KMS key policy, not just in S3 or IAM policies.

How to eliminate wrong answers

Option B is wrong because s3:GetEncryptionConfiguration is a read-only permission that retrieves the bucket's encryption configuration, not a permission that allows S3 to use the KMS key for decryption; it does not grant any KMS decrypt rights. Option C is wrong because changing the bucket to SSE-S3 would remove the KMS requirement, but it violates the requirement to keep access restricted and does not address the existing SSE-KMS setup; moreover, SSE-S3 does not inherently allow cross-account reads without proper bucket policies. Option D is wrong because bucket ACLs do not interact with KMS; granting FULL_CONTROL via ACL cannot bypass KMS decryption permissions, as S3 still needs to call KMS on behalf of the reader, which requires explicit KMS key policy grants.

Practice this question →

MCQmedium

Company A runs an internal app in account A. The app needs to upload objects to an S3 bucket in account B. When the app calls S3, it receives AccessDenied for s3:PutObject. The team already created an IAM role in account B named UploadRole with a policy allowing s3:PutObject. They did not yet set up any trust relationship. Which change most directly fixes the access problem with least privilege?

A.Create IAM user access keys in account A and attach the UploadRole policy directly to those keys.

B.Update the trust policy on UploadRole (account B) to allow sts:AssumeRole from the app’s IAM role or principal in account A.

C.Add s3:PutObject permissions to the bucket policy in account B for all principals in account A.

D.Attach an SCP (service control policy) in AWS Organizations to deny sts:AssumeRole unless the caller uses an MFA device.

AnswerB

A cross-account role requires both an IAM permissions policy and a trust policy. The trust policy must allow the specific principal in account A to call sts:AssumeRole into account B’s role. With that trust in place, the app can obtain temporary credentials and then use the UploadRole permissions for s3:PutObject.

Why this answer

The app in account A needs to assume the UploadRole in account B to gain s3:PutObject permissions. Without a trust policy on UploadRole that allows sts:AssumeRole from the app's IAM principal in account A, the role cannot be assumed, and the S3 PutObject call fails with AccessDenied. Updating the trust policy is the most direct fix and follows least privilege by granting only the necessary cross-account role assumption.

Exam trap

The trap here is that candidates often think bucket policies alone can grant cross-account access without considering the need for role assumption and trust policies, leading them to choose Option C as a simpler but overly permissive solution.

How to eliminate wrong answers

Option A is wrong because attaching the UploadRole policy directly to IAM user access keys in account A would create long-term credentials and violate least privilege, and the policy is defined in account B and cannot be attached to account A users; cross-account access requires role assumption, not direct policy attachment. Option C is wrong because adding s3:PutObject to the bucket policy for all principals in account A is overly permissive and does not leverage the existing UploadRole, violating least privilege by granting blanket access to the entire account A. Option D is wrong because an SCP denying sts:AssumeRole unless MFA is used would block the legitimate cross-account role assumption needed to fix the access problem, making the issue worse.

Practice this question →

MCQmedium

Developers for a e-learning platform need temporary elevated access to production resources for troubleshooting. The security team wants approvals, expiry, and audit logging. Which approach is best?

A.Disable CloudTrail during troubleshooting

B.Use IAM Identity Center permission sets with time-bound access processes and CloudTrail auditing

C.Attach AdministratorAccess permanently to every developer role

D.Create shared administrator access keys for the team

AnswerB

Federated access with permission sets and audited temporary assignments reduces standing privilege.

Why this answer

IAM Identity Center permission sets allow you to define fine-grained permissions and assign them to users or groups with time-bound access (e.g., using a session duration or approval workflow). Combined with CloudTrail, every API call made during the elevated session is logged for audit, meeting the security team's requirements for approvals, expiry, and audit logging.

Exam trap

The trap here is that candidates may think IAM roles with a trust policy and temporary credentials are sufficient, but they overlook that IAM Identity Center provides centralized, time-bound permission sets with built-in approval workflows and audit integration, which is the best fit for the given requirements.

How to eliminate wrong answers

Option A is wrong because disabling CloudTrail during troubleshooting would eliminate audit logging, directly violating the security team's requirement for audit logging. Option C is wrong because permanently attaching AdministratorAccess to every developer role grants unrestricted, persistent elevated access with no expiry or approval process, violating the principle of least privilege and the need for time-bound access. Option D is wrong because creating shared administrator access keys for the team removes individual accountability, prevents proper audit trails (as actions cannot be attributed to a specific user), and provides no expiry or approval mechanism.

Practice this question →

Multi-Selecthard

A third-party payroll vendor in another AWS account must assume a role in your account to write a daily settlement file to Amazon S3. You want to prevent confused-deputy attacks and make every assumed session traceable in CloudTrail back to an individual vendor user. Which three trust-policy or session controls should be used? Select three.

Select 3 answers

A.Specify the exact vendor role ARN as the trusted principal in the role trust policy.

B.Require an external ID in the trust policy conditions.

C.Require sts:SourceIdentity when the vendor assumes the role.

D.Use a wildcard principal and rely on the S3 bucket policy to narrow access later.

E.Give the vendor long-term IAM user credentials in your account for easier auditing.

AnswersA, B, C

The trust policy should name only the specific vendor role that is allowed to assume the role in your account. Restricting the principal minimizes the trust boundary and prevents unrelated identities from attempting the assumption path.

Why this answer

Specifying the exact vendor role ARN as the trusted principal in the trust policy ensures that only that specific role in the vendor's account can assume the role, preventing any other entity from impersonating the vendor. This is a key control to limit the trust boundary and avoid confused-deputy attacks.

Exam trap

The trap here is that candidates often think a bucket policy alone can control role assumption, but it cannot—the trust policy is the only mechanism to restrict which external principals can assume a role, and confused-deputy protections require explicit conditions like external ID and source identity.

Why the other options are wrong

Using a wildcard principal in the trust policy would allow any AWS principal to assume the role, violating the principle of least privilege and failing to prevent confused-deputy attacks. The S3 bucket policy cannot restrict who assumes the role, only what the assumed role can access.

Option E suggests giving the vendor long-term IAM user credentials in your account, which violates the principle of least privilege and makes auditing harder because actions are tied to a shared credential rather than individual vendor users. It also does not prevent confused-deputy attacks or ensure traceability to individual vendor users.

Practice this question →

MCQmedium

A SaaS vendor will access your AWS resources by assuming an IAM role in your account. You want to prevent confused-deputy attacks and ensure the vendor can only assume the role using an agreed external identifier. Your role trust policy currently allows sts:AssumeRole from the vendor’s principal, but it does not include any external ID protection. Which change is the best next step?

A.Add a condition to the trust policy: Condition = {"StringEquals": {"sts:ExternalId": "vendor-agreed-id"}}.

B.Add a condition to the trust policy: Condition = {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}.

C.Remove sts:AssumeRole and replace it with sts:AssumeRoleWithWebIdentity to use the vendor’s browser-based tokens.

D.Add a condition to the role permissions policy (not the trust policy) requiring aws:PrincipalTag/ExternalId to equal the external identifier.

AnswerA

Using sts:ExternalId in the trust policy ensures only assume-role requests presenting the correct external identifier are allowed. This directly mitigates confused-deputy attacks by binding authorization to a value the vendor must know. It also keeps the permissions model clean, because the check is enforced during the STS AssumeRole request.

Why this answer

The `sts:ExternalId` condition key is specifically designed to prevent confused-deputy problems. By adding `{"StringEquals": {"sts:ExternalId": "vendor-agreed-id"}}` to the trust policy, you ensure that the vendor must provide the agreed external ID in the `AssumeRole` API call, which only the legitimate vendor knows. This prevents a malicious third party from tricking the vendor into assuming a role in your account on their behalf.

Exam trap

The trap here is that candidates often confuse where to place the condition (trust policy vs. permissions policy) or mistakenly think IP-based restrictions or changing the API action are appropriate solutions for confused-deputy prevention.

Why the other options are wrong

The question requires protection against confused-deputy attacks using an external ID, not IP-based restrictions. The vendor's IP addresses may change or be shared, and IP conditions do not prevent a different vendor from using the same role.

This option is wrong because the question is about preventing confused-deputy attacks when a vendor assumes an IAM role, which requires sts:AssumeRole with an external ID condition, not sts:AssumeRoleWithWebIdentity, which is used for federated users with web identity tokens (e.g., from Amazon Cognito, Google, or Facebook).

The permissions policy controls what actions the role can perform, not who can assume it. The external ID check must be in the trust policy to prevent confused-deputy attacks during role assumption.

Practice this question →

MCQhard

A order processing API must ensure that only encrypted EBS volumes can be created in the account. What is the strongest preventive control?

A.Run a daily Lambda function to encrypt unencrypted volumes

B.Enable VPC Flow Logs

C.Use an SCP that denies ec2:CreateVolume when the encrypted condition is false

D.Tag encrypted volumes after creation

AnswerC

An SCP can prevent noncompliant volume creation across accounts in an organization.

Why this answer

Service Control Policies (SCPs) are a preventive control that can deny the ec2:CreateVolume API call when the encryption condition (ec2:Encrypted) is false. This ensures that no unencrypted EBS volumes can be created at the account level, regardless of IAM permissions. SCPs operate at the AWS Organizations root, OU, or account level and are evaluated before any IAM policies, making them the strongest preventive mechanism.

Exam trap

The trap here is confusing detective/reactive controls (like Lambda remediation) with preventive controls (like SCPs), leading candidates to choose a solution that fixes the problem after it occurs rather than blocking it entirely.

How to eliminate wrong answers

Option A is wrong because running a daily Lambda function to encrypt unencrypted volumes is a detective/reactive control, not a preventive one; it does not block the creation of unencrypted volumes and leaves a window of exposure. Option B is wrong because VPC Flow Logs capture network traffic metadata (IP addresses, ports, protocols) and have no ability to enforce encryption policies on EBS volumes; they are a monitoring tool, not a preventive control. Option D is wrong because tagging encrypted volumes after creation is a labeling action that does not prevent unencrypted volumes from being created; it is a detective or organizational control, not a preventive one.

Practice this question →

Multi-Selectmedium

A data lake stores raw files in a single Amazon S3 bucket that is shared by three internal analytics teams. Each team should access only its own prefix, and the company wants to eliminate ACL management because objects come from multiple producers. Which three changes should the architect make? Select three.

Select 3 answers

A.Create a separate S3 access point for each team and scope it to that team’s prefix.

B.Leave ACLs enabled so each producer can grant permissions directly on uploaded objects.

C.Set Object Ownership to Bucket owner enforced so ACLs are disabled.

D.Use bucket or access point policies to restrict access to the allowed principals and prefixes.

E.Make the bucket public and rely on application-layer authorization for data protection.

AnswersA, C, D

Access points let you expose different policy boundaries on the same bucket. They are a good fit when multiple teams need controlled access to different prefixes without creating separate buckets.

Why this answer

S3 Access Points allow you to create separate access points scoped to specific prefixes within a shared bucket, enabling each analytics team to access only its own prefix without managing ACLs. This simplifies access control by using access point policies that restrict access to the allowed principals and prefixes, aligning with the requirement to eliminate ACL management.

Exam trap

The trap here is that candidates may think ACLs are necessary for multi-producer environments, but AWS recommends disabling ACLs and using bucket policies or access point policies with Object Ownership set to 'Bucket owner enforced' to simplify access control.

Why the other options are wrong

Leaving ACLs enabled contradicts the requirement to eliminate ACL management, and ACLs do not restrict access by prefix—they grant permissions on individual objects, which is not scalable for multiple producers and teams.

Practice this question →

MCQmedium

An application in account A needs to use an encrypted EBS volume whose snapshots were copied from account B. The EBS volume is encrypted with a customer-managed KMS key in account B. After attaching the volume, the instance fails to mount it and logs show KMS access errors (kms:Decrypt) for the instance role. The instance role in account A already has an IAM policy allowing kms:Decrypt on that key ARN, but the mount still fails. What must be updated in account B to allow the mount to succeed?

A.Enable KMS automatic key rotation for the customer-managed key in account B.

B.Update the KMS key policy in account B to allow the instance role’s principal from account A to call kms:Decrypt and kms:CreateGrant.

C.Attach the key policy as an IAM permissions policy to the instance role in account A only; key policies are not evaluated cross-account.

D.Disable encryption on the EBS volume until authorization is fixed, then re-enable encryption after mount.

AnswerB

Customer-managed KMS keys use resource-based key policies to control cross-account usage. Even if the IAM role in account A has kms:Decrypt permissions, the account B key policy must also allow that principal to use the key. Including kms:Decrypt (and often kms:CreateGrant) resolves cross-account mount authorization.

Why this answer

The instance role in account A has an IAM policy allowing kms:Decrypt on the key ARN, but cross-account KMS access requires the key policy in account B to explicitly grant the external principal (the instance role's ARN) the necessary permissions. Without a key policy statement allowing kms:Decrypt and kms:CreateGrant for the account A role, KMS will deny the decryption request, causing the mount to fail. Option B correctly identifies that the key policy in account B must be updated to authorize the cross-account principal.

Exam trap

The trap here is that candidates assume an IAM policy on the instance role is sufficient for cross-account KMS access, but KMS requires the key policy in the owning account to explicitly authorize the external principal, as IAM policies alone cannot grant cross-account permissions.

How to eliminate wrong answers

Option A is wrong because enabling automatic key rotation does not grant cross-account permissions; it only rotates the key material periodically. Option C is wrong because IAM policies alone cannot authorize cross-account access to a KMS key; the key policy in the owning account must explicitly allow the external principal. Option D is wrong because disabling encryption on an encrypted EBS volume is not supported; you cannot toggle encryption on an existing volume, and the underlying authorization issue must be resolved via key policy updates.

Practice this question →

MCQmedium

A mobile app reads the same product catalog items repeatedly throughout the day. The DynamoDB table is already properly keyed, but read latency is still a problem during sales events. The team can tolerate eventually consistent reads and wants the least disruptive change. What should they add?

A.Add a global secondary index for every frequently viewed product attribute.

B.Enable DynamoDB Accelerator to cache frequently accessed items in memory.

C.Switch the table to on-demand capacity mode to reduce latency.

D.Move the catalog to Aurora and use a read replica for every region.

AnswerB

DynamoDB Accelerator, or DAX, is the best fit for repeated reads of the same items when eventual consistency is acceptable. It provides an in-memory cache in front of DynamoDB and can dramatically reduce read latency for hot catalog items during traffic spikes. Because the table schema is already sound, DAX adds performance without forcing a redesign of keys or access patterns.

Why this answer

DynamoDB Accelerator (DAX) is a fully managed, in-memory cache that reduces read latency for frequently accessed items by orders of magnitude, from single-digit milliseconds to microseconds. Since the team can tolerate eventually consistent reads, DAX is ideal because it caches read results and serves them without additional DynamoDB read capacity consumption, making it the least disruptive change — no schema changes or application rewrites are required.

Exam trap

The trap here is that candidates often confuse throughput scaling (on-demand capacity) with latency reduction, or they over-engineer the solution by migrating to a different database when a simple caching layer (DAX) is the least disruptive and most cost-effective fix.

Why the other options are wrong

Adding a GSI for every frequently viewed attribute does not reduce read latency for repeated reads of the same items; it adds storage and write costs without addressing the latency caused by repeated reads from disk.

Switching to on-demand capacity mode addresses throughput provisioning, not read latency. Latency issues from repeated reads are better solved by caching, not capacity mode changes.

Moving to Aurora and using read replicas is a much more disruptive change than enabling DAX, and it does not address the core issue of caching frequently accessed items in memory for low-latency reads. Aurora is a relational database, not a key-value store like DynamoDB, and the question specifies the team wants the least disruptive change.

Practice this question →

Matchinghard

Match each database availability event to the AWS failover behavior that best describes it.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

The standby in another Availability Zone is promoted, and the same database endpoint remains in use after a brief reconnect.

Aurora promotes another healthy instance to writer while the shared storage layer stays intact across Availability Zones.

A manual failover can be triggered so the standby becomes primary before the reboot finishes.

Only that reader is removed from the reader set; the cluster can still serve read traffic through the remaining healthy readers.

Why these pairings

Multi-AZ RDS automatically fails over to standby; read replicas require manual redirect; Aurora uses replicas for failover; without replicas, Aurora recovers in-place.

Practice this question →

MCQmedium

An application runs on EC2 instances in private subnets in a VPC. There is no NAT gateway. The instances need to download objects from S3 over HTTPS and also call DynamoDB. The security group outbound rules allow TCP 443 to the VPC endpoint addresses. After deployment, the app times out when connecting to S3, but it can reach DynamoDB. Which single change is most likely to restore S3 connectivity?

A.Create a Gateway VPC endpoint for S3 and associate it with the private subnet route tables that contain the instances.

B.Replace the security group egress rule to allow all outbound traffic to 0.0.0.0/0 on TCP 443.

C.Add an Internet Gateway to the VPC and route the private subnet’s 0.0.0.0/0 to the IGW.

D.Switch from network ACLs to security groups by removing the existing NACL allow rules for ephemeral ports.

AnswerA

S3 connectivity without NAT typically requires a Gateway VPC endpoint. For a gateway endpoint, you must update the route tables to direct S3 traffic to the endpoint. If DynamoDB works but S3 times out, it often means DynamoDB has the required endpoint while S3 is missing or not routed via the correct route tables.

Why this answer

The application runs in private subnets without a NAT Gateway, so it cannot reach the internet. A Gateway VPC Endpoint for S3 allows private subnet instances to access S3 over the AWS network without internet connectivity. The security group already permits outbound TCP 443 to the endpoint addresses, so the missing piece is the route table association that directs S3 traffic to the endpoint.

Exam trap

The trap here is that candidates often assume a security group egress rule to 0.0.0.0/0 is sufficient, forgetting that private subnets without a NAT Gateway have no internet path, so the traffic is silently dropped.

How to eliminate wrong answers

Option B is wrong because allowing all outbound traffic to 0.0.0.0/0 on TCP 443 does not help; the instances are in private subnets with no internet path, so traffic to the internet will still be dropped. Option C is wrong because adding an Internet Gateway and routing 0.0.0.0/0 to it would require a NAT Gateway or assigning public IPs to the instances, which is not mentioned and would break the private subnet design. Option D is wrong because network ACLs are stateless and must allow ephemeral ports for return traffic, but the issue is about outbound connectivity to S3, not NACL misconfiguration; security groups already handle stateful filtering.

Practice this question →

MCQmedium

A partner company needs read-only access to reports in an S3 bucket for a customer analytics portal. The partner has its own AWS account. What is the most secure scalable access pattern?

A.Make the objects public and rely on difficult-to-guess object names

B.Create a bucket policy that grants the partner role least-privilege access to the required prefix

C.Copy the objects to a public website bucket

D.Create an IAM user in the company account and share the access keys

AnswerB

A resource policy can grant cross-account access to a specific external role and prefix.

Why this answer

A bucket policy that grants the partner's IAM role (from the partner's AWS account) least-privilege access to a specific prefix is the most secure and scalable pattern. This uses cross-account IAM roles, avoiding long-term credentials and allowing the partner to manage their own users and permissions. The bucket policy explicitly trusts the partner's AWS account, and the partner assumes the role to access only the required objects, following the principle of least privilege.

Exam trap

The trap here is that candidates often choose Option D (sharing IAM user access keys) because it seems straightforward, but the exam tests the understanding that cross-account IAM roles are more secure and scalable than sharing static credentials.

How to eliminate wrong answers

Option A is wrong because making objects public with difficult-to-guess names relies on security through obscurity, which is not a secure pattern; objects can be discovered via enumeration or accidental exposure, and it violates AWS's shared responsibility model. Option C is wrong because copying objects to a public website bucket exposes the data to the internet without any access control, which is insecure and does not scale for read-only access by a specific partner. Option D is wrong because creating an IAM user in the company account and sharing access keys introduces long-term static credentials that must be rotated and managed, increasing the risk of leakage; it also does not scale across multiple partners and violates the principle of using IAM roles for cross-account access.

Practice this question →

MCQmedium

A.Create IAM user access keys in account A and attach the UploadRole policy directly to those keys.

B.Update the trust policy on UploadRole (account B) to allow sts:AssumeRole from the app’s IAM role or principal in account A.

C.Add s3:PutObject permissions to the bucket policy in account B for all principals in account A.

D.Attach an SCP (service control policy) in AWS Organizations to deny sts:AssumeRole unless the caller uses an MFA device.

AnswerB

Why this answer

The app in account A needs to assume the UploadRole in account B to gain s3:PutObject permissions. Without a trust policy on UploadRole that allows sts:AssumeRole from the app's IAM principal in account A, the role cannot be assumed, resulting in AccessDenied. Updating the trust policy directly establishes the cross-account trust relationship with least privilege, as it grants only the necessary assume-role capability.

Exam trap

The trap here is that candidates often think bucket policies alone can solve cross-account access, but without a trust policy on the IAM role, the app cannot assume the role to obtain the required permissions.

Why the other options are wrong

IAM user access keys are long-term credentials and do not solve cross-account access; the app in account A needs to assume a role in account B, not use a user with a policy attached directly.

Option C grants s3:PutObject to all principals in account A, which violates least privilege by not restricting to the specific app role, and it does not address the missing trust relationship needed for cross-account access via role assumption.

The problem is lack of cross-account trust, not an SCP. SCPs deny actions at the OU/account level but don't grant permissions; they would only block access if already allowed, and here no trust exists.

Practice this question →

MCQmedium

A team wants detective controls to investigate suspected exfiltration from an S3 bucket. They need to know when objects are accessed (GetObject) and also when new encrypted objects are written. They already enabled AWS CloudTrail for management events, but their investigation shows no visibility into object-level reads/writes in the logs they review. Which CloudTrail configuration change most directly provides the missing object-level visibility?

A.Enable CloudTrail data events for the specific S3 bucket so that GetObject and PutObject operations are logged at the object level.

B.Enable AWS Config delivery to a separate bucket and create a rule to detect noncompliant S3 policies; this will automatically generate GetObject logs.

C.Turn on VPC Flow Logs for the VPC hosting the S3 gateway endpoint, because network logs show S3 object read and write details.

D.Add an S3 bucket policy that denies all GetObject requests unless the caller uses TLS; the denial events will create investigation logs automatically.

AnswerA

CloudTrail management events cover control-plane activity, not per-object access details in S3. Enabling S3 data events (object-level logging) causes CloudTrail to record events like GetObject and PutObject for the targeted bucket and prefixes. This directly addresses the missing visibility symptom described. It also limits logging scope when you specify the bucket/prefix.

Why this answer

CloudTrail management events do not include object-level operations like GetObject or PutObject. By enabling CloudTrail data events for the specific S3 bucket, you capture object-level read (GetObject) and write (PutObject) API calls, including those for encrypted objects, providing the missing visibility for detective controls.

Exam trap

The trap here is that candidates confuse management events (which log bucket-level operations like CreateBucket) with data events (which log object-level operations like GetObject), assuming management events cover all S3 activity.

Why the other options are wrong

AWS Config does not generate GetObject logs; it tracks resource configuration changes and compliance, not data plane operations like S3 object access.

VPC Flow Logs capture IP traffic metadata (source/destination IP, ports, protocol) but do not log S3 API operations like GetObject or PutObject; they lack object-level details.

Denial events from a bucket policy that denies GetObject requests do not provide visibility into successful object access or writes; they only log denied attempts, not the actual GetObject or PutObject operations needed for detective controls.

Practice this question →

MCQmedium

A high-frequency trading analytics service runs on several EC2 instances in the same Availability Zone. The application exchanges small messages between nodes and is sensitive to microsecond-level network latency. Which design best meets the requirement?

A.Place the instances in a cluster placement group in one Availability Zone.

B.Place the instances in a spread placement group across multiple Availability Zones.

C.Place the instances in a partition placement group within one Availability Zone.

D.Deploy the instances behind an Application Load Balancer in multiple Availability Zones.

AnswerA

A cluster placement group places instances physically close together within one Availability Zone, which improves network throughput and reduces latency between nodes. That is the right fit for tightly coupled workloads that exchange frequent small messages and need the lowest possible east-west latency. It also keeps the design simple because the application already runs in a single AZ.

Why this answer

A cluster placement group is designed for low-latency, high-throughput scenarios by placing instances in a single Availability Zone with non-blocking, fully bisectioned bandwidth and microsecond-level latency. This meets the requirement for microsecond-sensitive inter-node communication in high-frequency trading.

Exam trap

The trap here is that candidates confuse 'fault isolation' (spread/partition groups) with 'performance optimization' (cluster groups), or assume a load balancer can reduce latency when it actually adds overhead.

Why the other options are wrong

Spread placement groups are designed to reduce correlated failures by placing instances across distinct hardware, but they do not provide the low-latency, high-bandwidth network performance required for microsecond-level latency. Additionally, placing instances across multiple Availability Zones increases network distance and latency.

Partition placement groups are designed to reduce correlated hardware failures for large distributed workloads like HDFS or Cassandra, not to minimize network latency. They do not provide the low-latency, high-bandwidth network performance required for microsecond-level inter-node communication.

An Application Load Balancer (ALB) operates at Layer 7 and introduces significant latency (milliseconds), which is unacceptable for microsecond-sensitive trading. It also distributes traffic across AZs, increasing latency further.

Practice this question →

MCQmedium

Company A stores encrypted log files in its S3 bucket using SSE-KMS with a customer-managed KMS key. A partner application in Company B uploads objects into Company A's bucket using an IAM role in Company B. Uploads fail with an error indicating KMS access is denied (kms:Encrypt not authorized). Neither the partner IAM policy nor the S3 bucket policy currently mentions KMS. What is the most secure and correct change to allow cross-account uploads to succeed?

A.In Company A's KMS key policy, allow Company B's partner role principal to use the key for kms:Encrypt, kms:GenerateDataKey, and kms:DescribeKey, and also add a matching IAM policy in Company B that grants the partner role those same KMS actions on Company A's key ARN, constrained to the target S3 bucket context when possible.

B.In Company B's IAM policy, allow kms:Encrypt on Company A's KMS key ARN, without changing Company A's key policy.

C.Create a new KMS key in Company B and configure Company A's S3 bucket to use that key for SSE-KMS.

D.Disable key policy restrictions by setting the KMS key to enabled and removing all policy statements so that encryption automatically works for any principal.

AnswerA

Cross-account SSE-KMS requires both the KMS key policy in the key owner account and an IAM policy in the caller account to allow the required KMS actions. Scoping the permissions to the specific bucket or encryption context reduces blast radius.

Why this answer

Cross-account SSE-KMS uploads require both the KMS key policy in Company A to explicitly grant the partner role principal the necessary KMS actions (kms:Encrypt, kms:GenerateDataKey, kms:DescribeKey) and an IAM policy in Company B that allows the partner role to call those actions on Company A's key ARN. The bucket policy alone cannot authorize KMS operations; KMS key policies act as the primary access control for customer-managed keys, and without the key policy grant, the partner role's IAM permissions are insufficient. Constraining the IAM policy to the target S3 bucket context (using kms:ViaService or kms:EncryptionContext conditions) adds a security best practice by limiting the key's use to only that specific S3 bucket.

Exam trap

The trap here is that candidates assume an IAM policy in the partner account is sufficient for cross-account KMS access, overlooking that KMS key policies are the mandatory gatekeeper for external principals, and that the key policy must explicitly grant the external role.

Why the other options are wrong

Option B is wrong because cross-account KMS access requires the key policy in the key-owning account (Company A) to explicitly grant permissions to the external principal (Company B's role). Without that, Company B's IAM policy alone cannot authorize KMS actions on Company A's key.

Using a KMS key from Company B would not allow Company A to decrypt the objects, as Company A's S3 bucket is configured with its own key for SSE-KMS. The partner application must use Company A's key to encrypt objects so that Company A can decrypt them.

Removing all policy statements from the KMS key disables all access control, making the key effectively public and insecure. This violates the principle of least privilege and is not a secure solution.

Practice this question →

MCQmedium

A legacy market-data service runs on EC2 and exposes a custom TCP protocol. Clients must connect over TCP with very low latency, and the team wants static IP addresses at the load-balancing layer. Which AWS service is the best fit?

A.Application Load Balancer, because it provides advanced routing for all protocols.

B.Network Load Balancer, because it supports TCP, static IPs, and very low latency.

C.Amazon API Gateway, because it can front any network protocol with throttling.

D.Amazon CloudFront, because it can route traffic to EC2 instances at the edge.

AnswerB

A Network Load Balancer is the best fit for a custom TCP service that needs extremely low latency and static IP addresses. NLB operates at Layer 4, preserves high throughput, and is commonly used when protocol simplicity and performance matter more than application-layer routing features. It matches the workload's network requirements without adding unnecessary HTTP-specific behavior.

Why this answer

The Network Load Balancer (NLB) operates at Layer 4, supports TCP traffic natively, provides static IP addresses per Availability Zone, and delivers very low latency by processing packets without inspecting application-layer headers. This makes it the ideal choice for a legacy market-data service that requires a custom TCP protocol and fixed IPs at the load-balancing layer.

Exam trap

The trap here is that candidates often confuse the ALB's 'advanced routing' capabilities with support for all protocols, but ALB is strictly Layer 7 and cannot handle raw TCP or custom protocols, making NLB the only correct choice for TCP with static IPs and low latency.

Why the other options are wrong

Application Load Balancer does not support TCP at the transport layer; it operates at Layer 7 (HTTP/HTTPS) and cannot handle custom TCP protocols. It also does not provide static IP addresses.

Amazon API Gateway does not support custom TCP protocols; it only handles HTTP/HTTPS and WebSocket traffic, and it does not provide static IP addresses at the load-balancing layer.

Practice this question →

MCQmedium

An application runs on EC2 instances in private subnets behind an Application Load Balancer (ALB). Security groups allow inbound HTTPS (443) from the ALB’s security group to the instance security group, and outbound from instances is set to allow ephemeral ports. Despite this, clients see connection timeouts. After reviewing network ACLs, you find the NACL associated with the instance subnet has an inbound allow for destination port 443, but it does not have a corresponding outbound allow for ephemeral ports. What is the most likely reason the traffic fails, and what should be updated?

A.NACLs are stateless, so you must update the NACL to allow the return (outbound) ephemeral port range; security groups alone cannot override a blocked NACL.

B.NACLs are stateful and automatically track connections; the fix is to add a new inbound rule to the security group for client source ports.

C.The issue is caused by ALB health checks; configure a new target group health check on port 80 so traffic can be routed.

D.Because instances are in private subnets, add a NAT gateway so return traffic can reach the internet over dynamic routing.

AnswerA

Stateless NACLs require both inbound and outbound rules. Missing outbound for ephemeral ports will block return traffic even if SG rules are correct.

Why this answer

Network ACLs are stateless, meaning they do not automatically allow return traffic. Even though the security group allows inbound HTTPS from the ALB, the NACL blocks the response traffic because it lacks an outbound rule for ephemeral ports (typically 1024-65535). Since NACLs are evaluated before security groups, a missing outbound allow rule causes the connection to time out.

Exam trap

The trap here is that candidates assume security groups alone handle all traffic filtering, forgetting that NACLs are stateless and require explicit outbound rules for return traffic, especially for ephemeral ports.

Why the other options are wrong

NACLs are stateless, not stateful; they do not automatically track connections. The issue is missing outbound ephemeral port rules in the NACL, not security group inbound rules for client source ports.

The question describes connection timeouts due to missing outbound NACL rules for ephemeral ports, not health check failures. ALB health checks are not mentioned as failing, and changing the health check port does not address the stateless NACL issue.

The issue is not about internet connectivity; instances are in private subnets but the ALB is in a public subnet and handles internet-facing traffic. A NAT gateway is for outbound internet access from private instances, not for fixing return traffic blocked by a stateless NACL.

Practice this question →

MCQhard

Based on the exhibit, a company wants EC2 instances in private subnets to access Amazon S3 without using a NAT gateway, and bucket access must be allowed only when requests come through the approved VPC endpoint. Which design is the most appropriate?

A.Use the S3 gateway VPC endpoint and keep the bucket policy that denies requests unless aws:SourceVpce matches the approved endpoint.

B.Use an interface VPC endpoint for S3 only, because gateway endpoints cannot be used with bucket policies.

C.Add a NAT gateway and remove the bucket policy condition because the NAT route will automatically secure the S3 traffic.

D.Move the bucket policy restriction to a security group attached to the S3 bucket so only the VPC endpoint can reach it.

AnswerA

For S3, a gateway VPC endpoint is the correct private-connectivity option for EC2 instances in private subnets. The route table sends S3 prefix-list traffic to the gateway endpoint, so requests stay on the AWS network instead of traversing a NAT gateway or the public internet. The bucket policy condition on aws:SourceVpce then ensures that even valid AWS-authenticated requests are accepted only when they arrive through the approved endpoint ID.

Why this answer

An S3 gateway VPC endpoint allows EC2 instances in private subnets to access S3 without traversing the internet or requiring a NAT gateway. By adding a bucket policy condition that denies access unless `aws:SourceVpce` matches the approved VPC endpoint ID, you ensure that only requests originating from that specific endpoint are allowed, meeting the security requirement.

Exam trap

The trap here is that candidates often confuse gateway endpoints with interface endpoints, assuming gateway endpoints cannot enforce bucket policies, or they mistakenly think security groups can be applied to S3 buckets, leading them to choose option D.

How to eliminate wrong answers

Option B is wrong because gateway endpoints for S3 can absolutely be used with bucket policies; in fact, the `aws:SourceVpce` condition is specifically designed for gateway endpoints. Option C is wrong because adding a NAT gateway would route traffic through the internet, which is unnecessary and violates the requirement to avoid using a NAT gateway; also, removing the bucket policy condition would leave the bucket open to any request, not just those through the VPC endpoint. Option D is wrong because S3 buckets do not support security groups; security groups are network-level constructs for EC2 instances and cannot be attached to S3 buckets.

Practice this question →

MCQmedium

Account B has an IAM role that includes kms:Decrypt for a specific KMS key ARN in account A. However, when the role tries to read an S3 object encrypted with that CMK, the application fails with AccessDenied: not authorized to perform kms:Decrypt. CloudTrail shows the KMS API call is denied by key policy. What is the most secure and correct fix?

A.Update the IAM role in account B to include kms:Encrypt and kms:GenerateDataKey; then kms:Decrypt will start working automatically.

B.Update the KMS key policy in account A to allow the account B role principal to use kms:Decrypt on the key.

C.Disable key policy for the CMK by switching to S3-managed encryption, because KMS key policies are always enforced regardless of grants.

D.Create an SCP in account A that allows kms:Decrypt for all accounts, avoiding changes to the key policy.

AnswerB

Cross-account use of a CMK requires the KMS key policy (in the CMK’s account) to allow the external principal to perform kms:Decrypt. Since CloudTrail shows the denial is by key policy, updating the key policy to grant the account B role kms:Decrypt on the specific key is the correct and least-privilege solution.

Why this answer

Cross-account access to a customer managed KMS key (CMK) requires the key policy to explicitly grant the external IAM role principal the necessary permissions (e.g., kms:Decrypt). Even if the IAM role in Account B has an IAM policy allowing kms:Decrypt, the KMS key policy in Account A acts as a resource-based policy that must also allow the action; without this, the request is denied by the key policy, as shown in CloudTrail.

Exam trap

How to eliminate wrong answers

Option A is wrong because adding kms:Encrypt and kms:GenerateDataKey to the IAM role does not resolve the key policy denial; the issue is the key policy in Account A, not the IAM permissions in Account B, and kms:Decrypt does not automatically work from other actions. Option C is wrong because disabling the CMK and switching to S3-managed encryption (SSE-S3) is not a secure fix for cross-account access; it removes customer control over encryption keys and does not address the need for cross-account KMS decryption. Option D is wrong because SCPs (Service Control Policies) are used to restrict permissions within an AWS organization, not to grant cross-account access; they cannot override a key policy denial, and creating an SCP that allows kms:Decrypt for all accounts would be insecure and ineffective.

Practice this question →

MCQmedium

A media company has users around the world uploading 1 to 5 GB files directly to a single Amazon S3 bucket. Upload times are slow from distant regions, but the app must keep using S3 as the destination. What should the architects enable to improve upload performance?

A.Amazon CloudFront for origin caching of uploaded files.

B.Amazon S3 Transfer Acceleration on the bucket.

C.Provisioned IOPS EBS volumes attached to a transfer server.

D.Amazon EFS with a mount target in each Region.

AnswerB

S3 Transfer Acceleration improves upload performance over long distances by routing traffic through AWS edge locations and optimized network paths to the target bucket. This is a strong fit for globally distributed users uploading large files directly to S3. It preserves the same storage destination while making the transfer path faster and more consistent for remote clients.

Why this answer

Amazon S3 Transfer Acceleration (B) uses AWS edge locations to accelerate uploads over the public internet. When a user uploads a file, the data is sent to the nearest edge location via optimized network paths, then forwarded over AWS's private backbone to the S3 bucket. This reduces latency and improves throughput for large files (1–5 GB) from distant regions, directly addressing the slow upload times while keeping S3 as the destination.

Exam trap

The trap here is confusing CloudFront's edge caching for downloads with S3 Transfer Acceleration's edge-based upload optimization, leading candidates to select CloudFront (A) even though it does not improve upload performance to S3.

Why the other options are wrong

CloudFront is a content delivery network for caching and accelerating downloads, not uploads. It does not improve upload performance to an S3 bucket because uploads go directly to the origin, not through CloudFront.

Provisioned IOPS EBS volumes attached to a transfer server do not improve upload speeds to S3; they improve disk I/O for an intermediate server, but the bottleneck is network latency to S3, not local disk performance.

Amazon EFS is a shared file system for EC2 instances, not a direct upload destination for users. The question requires users to upload directly to S3, and EFS cannot replace S3 as the upload target.

Practice this question →

MCQmedium

Developers for a B2B file exchange site need temporary elevated access to production resources for troubleshooting. The security team wants approvals, expiry, and audit logging. Which approach is best?

A.Attach AdministratorAccess permanently to every developer role

B.Create shared administrator access keys for the team

C.Disable CloudTrail during troubleshooting

D.Use IAM Identity Center permission sets with time-bound access processes and CloudTrail auditing

AnswerD

Federated access with permission sets and audited temporary assignments reduces standing privilege.

Why this answer

IAM Identity Center (formerly AWS SSO) enables time-bound permission sets that grant temporary elevated access with automatic expiry, satisfying the security team's requirements for approvals and audit logging via AWS CloudTrail. This approach follows the principle of least privilege by providing just-in-time access rather than permanent permissions, and all actions are recorded in CloudTrail for compliance.

Exam trap

The trap here is that candidates may think permanent AdministratorAccess (Option A) is acceptable for developers, failing to recognize that AWS explicitly requires temporary credentials with approval workflows for elevated access in secure architectures.

How to eliminate wrong answers

Option A is wrong because permanently attaching AdministratorAccess to every developer role violates the principle of least privilege, creates a standing privilege that cannot enforce expiry or approvals, and increases the attack surface. Option B is wrong because shared administrator access keys lack individual accountability, cannot enforce time-bound access or approvals, and bypass CloudTrail's ability to attribute actions to specific users. Option C is wrong because disabling CloudTrail during troubleshooting removes audit logging entirely, which directly contradicts the security team's requirement for audit logging and violates AWS security best practices.

Practice this question →

MCQmedium

A public API for a customer analytics portal is deployed on API Gateway. Clients must authenticate with standards-based tokens issued by an external OpenID Connect provider. Which authorization mechanism should be used?

A.API keys only

B.JWT authorizer configured for the OpenID Connect issuer

C.IAM authorization for all internet users

D.A VPC endpoint policy

AnswerB

A JWT authorizer validates tokens from a trusted OIDC issuer with low operational overhead.

Why this answer

The scenario requires standards-based token authentication from an external OpenID Connect (OIDC) provider. API Gateway's JWT authorizer natively validates JSON Web Tokens (JWTs) issued by OIDC providers by verifying the token's signature against the provider's JWKS endpoint, checking the `iss` and `aud` claims, and enforcing token expiration. This directly meets the requirement without needing custom Lambda authorizers or additional infrastructure.

Exam trap

The trap here is that candidates confuse API keys (which are static and not standards-based) with JWT tokens (which are cryptographically signed and verifiable), or assume IAM authorization can be used for external identities without understanding that IAM requires AWS credentials, not OIDC tokens.

How to eliminate wrong answers

Option A is wrong because API keys only provide simple identification and rate limiting, not authentication or authorization; they do not validate token signatures, claims, or issuer trust. Option C is wrong because IAM authorization is designed for AWS internal identities (IAM users/roles) and requires AWS Signature V4 signing, which is not compatible with external OIDC tokens or internet-based clients without custom signing logic. Option D is wrong because a VPC endpoint policy controls access to API Gateway via VPC endpoints, not authentication; it cannot validate OIDC tokens or handle client identity from the public internet.

Practice this question →

MCQeasy

A company’s private workload in a VPC uploads objects to an S3 bucket. Security requires that S3 requests are allowed only when they traverse a specific S3 Gateway VPC Endpoint (vpce-0abc123example). Which change best enforces this restriction at the S3 bucket level?

A.Add an S3 bucket policy Deny statement for s3:PutObject when aws:sourceVpce is not equal to vpce-0abc123example.

B.Add an S3 bucket policy Deny statement that blocks requests unless the principal uses MFA.

C.Enable Block Public Access and remove the public bucket policy statement.

D.Attach an IAM policy to the workload role that allows s3:PutObject only to the bucket ARN.

AnswerA

A bucket policy can use the request context key aws:sourceVpce to distinguish requests that came through a particular VPC endpoint. Using a Deny with a condition such as StringNotEquals on aws:sourceVpce blocks PutObject unless the request reached S3 via that specific Gateway Endpoint. Requests that arrive by other network paths will not match the required endpoint ID and will be denied.

Why this answer

It uses an S3 bucket policy with a Deny statement that explicitly denies any s3:PutObject request unless the request originates from the specified VPC Endpoint (vpce-0abc123example). The aws:sourceVpce condition key evaluates the VPC endpoint ID from which the request is made, ensuring that only traffic through that specific Gateway VPC Endpoint is allowed. This enforces the security requirement at the bucket level, overriding any other policies that might allow access from other sources.

Exam trap

The trap here is that candidates often confuse IAM policies (which control who can act) with bucket policies (which control how and from where access is allowed), leading them to choose an IAM-based solution (Option D) that does not enforce the network-level restriction required by the scenario.

How to eliminate wrong answers

Option B is wrong because requiring MFA does not restrict requests to a specific VPC Endpoint; it only adds an authentication factor, which does not enforce the network-level restriction. Option C is wrong because Block Public Access and removing public policies prevent public access but do not restrict requests to a specific VPC Endpoint; private traffic from other sources (e.g., the internet via a NAT gateway) would still be allowed. Option D is wrong because an IAM policy attached to the workload role controls what the role can do but does not restrict the network path; the workload could still send requests from any network interface, not just the specified VPC Endpoint.

Practice this question →

MCQmedium

A backup process restores a 2 TB production database from an EBS snapshot onto a new volume. During the first hours after restore, the application sees slow reads whenever previously unused blocks are accessed. What is the best way to avoid this performance issue in future restores?

A.Increase the volume size to give the database more free space.

B.Enable Fast Snapshot Restore on the snapshots used for recovery.

C.Move the database files to Amazon EFS after the restore completes.

D.Use magnetic standard volumes because they avoid snapshot hydration delays.

AnswerB

Fast Snapshot Restore removes the initial performance penalty that occurs when a restored EBS volume reads blocks that have not yet been hydrated. By pre-warming the snapshot data in the target AZ, it helps ensure consistent read performance immediately after restore. This is especially valuable for databases and other workloads that must recover quickly without waiting for the background hydration process.

Why this answer

When an EBS volume is restored from a snapshot, it is lazily loaded from Amazon S3 in the background. Accessing data blocks that have not yet been loaded triggers a read penalty because the volume must fetch them from S3 before serving the I/O. Enabling Fast Snapshot Restore (FSR) pre-warms the snapshot data so that restored volumes have full performance immediately, eliminating the slow reads on first access.

Exam trap

The trap here is that candidates may think increasing volume size or switching to a different storage class will fix the lazy hydration delay, but only Fast Snapshot Restore directly addresses the root cause by pre-initializing the data blocks.

Why the other options are wrong

Increasing volume size does not address the 'first touch' latency caused by lazy loading of data from snapshot to S3; it only provides more storage capacity.

Moving database files to Amazon EFS after restore does not address the slow reads caused by lazy loading of data from EBS snapshots (snapshot hydration). EFS is a network file system with its own performance characteristics and does not eliminate the need to initialize EBS blocks.

Magnetic standard volumes (st1/sc1) also suffer from snapshot hydration delays and have lower baseline performance than gp2/gp3, making them unsuitable for avoiding slow reads on previously unused blocks.

Practice this question →

MCQmedium

A.Place instances in private subnets but use NAT gateways so traffic to S3 and Secrets Manager goes through the internet; restrict security groups to instance-to-instance only.

C.Use public subnets with instances that have no security group rules; rely on AWS services to reject unauthorized traffic.

D.Create an S3 bucket policy that allows requests from the application instances’ private IP addresses and enable public access to Secrets Manager via the default service endpoint.

AnswerB

Why this answer

It uses a VPC gateway endpoint for Amazon S3 and an interface VPC endpoint for AWS Secrets Manager, both of which allow private subnet instances to access these services without traversing the public internet or requiring a NAT gateway. The security group rules attached to the interface endpoint restrict inbound traffic to only the application subnets, satisfying the security requirement of allowing only required VPC traffic. This architecture meets all constraints: no public internet, no NAT gateway cost, and least-privilege access.

Exam trap

The trap here is that candidates often assume all AWS services require NAT gateways or internet gateways for private subnet access, overlooking the distinction between gateway endpoints (for S3 and DynamoDB) and interface endpoints (for most other services like Secrets Manager) that provide private connectivity without internet exposure.

How to eliminate wrong answers

Option A is wrong because NAT gateways incur cost and route traffic through the internet, violating the 'without exposing the instances to NAT gateways due to cost' requirement; additionally, security groups on instances alone do not restrict traffic to AWS service endpoints. Option C is wrong because public subnets expose instances to inbound internet traffic, contradicting the 'no inbound internet' requirement, and having no security group rules is a severe security violation. Option D is wrong because enabling public access to Secrets Manager via the default service endpoint exposes it to the internet, and S3 bucket policies based on private IP addresses are unreliable since private IPs can change and do not authenticate the requester; Secrets Manager requires interface endpoints or private connectivity, not public endpoints.

Practice this question →

MCQeasy

A.Create an IAM user for the pipeline and store access keys in the CI system.

B.Create an IAM role in the production account, grant least-privilege policies, and let the CI assume it using STS AssumeRole.

C.Attach the required permissions to an IAM group and add the pipeline’s principal to that group directly.

D.Use AWS KMS to encrypt the pipeline’s access keys and store the ciphertext in the CI system.

AnswerB

IAM roles with STS provide temporary credentials and allow least-privilege permissions via attached policies.

Why this answer

It uses an IAM role with least-privilege policies that the CI/CD pipeline can assume via AWS STS AssumeRole, providing temporary credentials that automatically expire. This avoids long-lived access keys and meets the security requirement of using temporary credentials. The role can be scoped to allow only reading specific parameters from Systems Manager Parameter Store and writing logs to CloudWatch Logs, adhering to the principle of least privilege.

Exam trap

The trap here is that candidates may think IAM users with access keys are acceptable for automation, but the question explicitly requires temporary credentials, making the IAM role with STS AssumeRole the only correct approach.

Why the other options are wrong

Option A uses long-lived access keys, violating the requirement for temporary credentials. IAM users with access keys are not temporary and increase security risk.

Using KMS to encrypt long-lived access keys does not eliminate the security risk of having permanent credentials; the pipeline still uses static keys, violating the requirement for temporary credentials.

Practice this question →

MCQmedium

A media platform stores originals in an S3 bucket. The application must: (1) prevent any public access to the bucket, (2) allow authenticated users to upload and download objects using presigned URLs, and (3) enforce that all requests use HTTPS and only touch objects under the user-specific prefix (for example, s3://media-originals/user-123/*). The bucket currently allows uploads but sometimes returns 403 AccessDenied for presigned URLs. Which change is the best fix while meeting the security requirements?

A.Disable S3 Block Public Access and add an ACL that grants READ and WRITE to the bucket owner only.

B.Keep Block Public Access enabled, remove any Allow statement to Principal="*", and use a bucket policy or access point policy that denies non-HTTPS requests and allows PutObject/GetObject only when the object key matches the authenticated user's session tag, such as arn:aws:s3:::media-originals/${aws:PrincipalTag/userId}/*.

C.Use bucket website hosting and allow public GET requests so presigned URLs are not needed for downloads.

D.Use ACLs to grant ObjectOwner full control and rely on the application to generate presigned URLs with longer expirations to avoid 403 errors.

AnswerB

Block Public Access ensures the bucket cannot become public. A policy that denies non-HTTPS traffic and scopes object ARNs to a session tag or equivalent identity attribute enforces user-specific access without relying on public principals.

Why this answer

It keeps S3 Block Public Access enabled (preventing any public access), uses a bucket policy or access point policy with a condition key like `aws:PrincipalTag` to restrict `PutObject`/`GetObject` to the user-specific prefix (e.g., `arn:aws:s3:::media-originals/${aws:PrincipalTag/userId}/*`), and denies non-HTTPS requests via a `aws:SecureTransport` condition. This ensures presigned URLs work only for authenticated users with the correct session tag, while eliminating the 403 errors caused by overly restrictive policies or missing principal restrictions.

Exam trap

The trap here is that candidates assume presigned URLs bypass all bucket policies, but in reality, presigned URLs are subject to the same bucket policies and IAM permissions as the signing principal, so a missing or overly restrictive policy condition (like not scoping to the user-specific prefix) causes 403 errors.

How to eliminate wrong answers

Option A is wrong because disabling S3 Block Public Access and using an ACL that grants READ and WRITE to the bucket owner only does not prevent public access — Block Public Access is the primary safeguard, and ACLs are legacy and do not enforce user-specific prefix restrictions or HTTPS. Option C is wrong because using bucket website hosting with public GET requests violates the requirement to prevent any public access and makes presigned URLs unnecessary, but it exposes objects to the internet. Option D is wrong because ACLs granting ObjectOwner full control do not enforce user-specific prefix restrictions or HTTPS, and relying on longer presigned URL expirations does not fix the 403 error caused by missing policy conditions or incorrect principal restrictions.

Practice this question →

MCQmedium

A microservice runs in private subnets and must read exactly one AWS Secrets Manager secret using its IAM task role: arn:aws:secretsmanager:us-east-1:111122223333:secret:prod/db-pass-AbCdEf Security requires that every Secrets Manager API call comes only through a specific Interface VPC Endpoint (vpce-0a1b2c3d4e5f6g7h), and must not be reachable over any other network path. Which IAM policy change best enforces this requirement?

A.In the task role policy statement for secretsmanager:GetSecretValue on the secret ARN, add a condition that allows the action only when aws:SourceVpce equals vpce-0a1b2c3d4e5f6g7h.

B.Add a condition that allows secretsmanager:GetSecretValue only when aws:SourceIp is within 10.0.0.0/8.

C.Require TLS by adding a condition on aws:SecureTransport for the Secrets Manager permission.

D.Add a KMS condition using kms:ViaService=secretsmanager.us-east-1.amazonaws.com instead of restricting Secrets Manager directly.

AnswerA

For Interface VPC endpoints, aws:SourceVpce can be used as a condition key so KMS/Secrets Manager API authorization succeeds only when the request originates from the specified endpoint. Restricting the IAM permission to aws:SourceVpce=vpce-... directly matches the requirement that calls must not traverse other network paths (e.g., via NAT/egress).

Why this answer

The condition `aws:SourceVpce` in the IAM policy restricts the `secretsmanager:GetSecretValue` API call to originate only from the specified VPC Endpoint (vpce-0a1b2c3d4e5f6g7h). This ensures that the secret can only be accessed via that specific Interface Endpoint, blocking any other network path (e.g., internet, NAT gateway, or other VPC endpoints). The task role is attached to the microservice, so the policy directly enforces the security requirement at the API level.

Exam trap

The trap here is that candidates often confuse `aws:SourceVpce` with `aws:SourceIp` or `aws:SourceVpc`, thinking any network-level condition will work, but only `aws:SourceVpce` uniquely identifies the specific Interface VPC Endpoint required for this strict enforcement.

How to eliminate wrong answers

Option B is wrong because `aws:SourceIp` condition key is not effective for requests made through a VPC Endpoint; the source IP is replaced by the endpoint's private IP, making the condition unreliable for restricting traffic to a specific endpoint. Option C is wrong because requiring TLS (`aws:SecureTransport`) only ensures encryption in transit, not that the API call comes through a specific VPC Endpoint; it does not restrict the network path. Option D is wrong because `kms:ViaService` restricts KMS key usage to a specific AWS service (Secrets Manager), but it does not control which network path (e.g., VPC Endpoint) the Secrets Manager API call uses; it addresses KMS authorization, not network-level restriction.

Practice this question →

MCQmedium

A solutions architect is designing an S3 bucket for a claims portal. The objects must never be publicly accessible, even if a developer later adds an overly broad bucket policy. What should the architect configure? The design must avoid adding custom operational scripts.

A.Enable S3 Block Public Access at the account or bucket level

B.Create an IAM policy that denies s3:GetObject to anonymous users

C.Enable server access logging on the bucket

D.Enable S3 Transfer Acceleration

AnswerA

S3 Block Public Access prevents public ACLs and public bucket policies from exposing the bucket.

Why this answer

S3 Block Public Access provides a definitive override that prevents any public access to S3 objects, even if a bucket policy or ACL later grants public access. This setting can be applied at the account or bucket level and ensures that all access is denied to anonymous users, meeting the requirement without custom scripts.

Exam trap

The trap here is that candidates may think an IAM policy can block anonymous users, but IAM policies only apply to authenticated IAM principals, not to anonymous (unauthenticated) requests, making S3 Block Public Access the only effective solution.

How to eliminate wrong answers

Option B is wrong because an IAM policy that denies s3:GetObject to anonymous users is not effective; anonymous users are not IAM principals, so IAM policies do not apply to them. Option C is wrong because server access logging records requests but does not enforce access controls or prevent public access. Option D is wrong because S3 Transfer Acceleration speeds up uploads over long distances but has no effect on access permissions or public accessibility.

Practice this question →

MCQhard

Based on the exhibit, a partner account uploads encrypted objects to a central S3 bucket and later reads them back. The S3 permissions are correct, but the requests still fail. What change is required so the partner workload can use the customer-managed KMS key safely?

A.Replace SSE-KMS with S3 object ACLs so the partner account can bypass KMS authorization.

B.Create a new bucket in the partner account and copy the objects there to avoid cross-account encryption.

C.Switch the bucket to SSE-S3 so the partner role no longer needs KMS permissions.

D.Update the CMK key policy, or add a tightly scoped grant, to allow the partner role the required KMS actions through S3.

AnswerD

Cross-account access to SSE-KMS encrypted objects requires KMS authorization in addition to S3 authorization. The key policy must trust the partner role, and the permissions should be limited to the needed KMS actions such as Decrypt, Encrypt, and GenerateDataKey with a service condition for S3. That is why the partner can have valid S3 permissions and still fail until the KMS policy is fixed.

Why this answer

When using a customer-managed KMS key (CMK) for SSE-KMS in a cross-account scenario, the key policy must explicitly grant the partner account's IAM role the necessary KMS actions (kms:Decrypt, kms:GenerateDataKey) to allow S3 to perform the encryption/decryption on behalf of the partner. Without this policy update or a tightly scoped grant, the KMS service will deny the request even if S3 bucket policies are correctly configured.

Exam trap

The trap here is that candidates assume S3 bucket policies alone control all access, forgetting that SSE-KMS introduces a separate authorization layer at KMS that requires explicit cross-account permissions in the key policy.

How to eliminate wrong answers

Option A is wrong because S3 object ACLs cannot bypass KMS authorization; ACLs control access to the object itself, not the encryption key, and removing SSE-KMS would violate security requirements. Option B is wrong because copying objects to a new bucket in the partner account does not resolve the underlying KMS authorization issue; the partner still needs access to the CMK to decrypt the objects. Option C is wrong because switching to SSE-S3 would remove the use of the customer-managed key, which may be a compliance or security requirement, and does not address the need for cross-account access with a CMK.

Practice this question →

MCQmedium

A web application for a healthcare document service is behind an Application Load Balancer. The application must be protected from common SQL injection and cross-site scripting attacks with minimum operational overhead. What should the architect deploy? The design must avoid adding custom operational scripts.

A.Security groups on the application instances

B.AWS WAF associated with the Application Load Balancer

C.Network ACLs on the public subnets

D.AWS Shield Advanced only

AnswerB

AWS WAF can inspect HTTP requests and block common web exploits when associated with an ALB.

Why this answer

AWS WAF is a web application firewall that integrates directly with an Application Load Balancer to filter and monitor HTTP/HTTPS requests. It provides managed rules specifically designed to block common attack patterns like SQL injection and cross-site scripting (XSS) without requiring custom scripts or manual rule maintenance, thus meeting the requirement for minimum operational overhead.

Exam trap

The trap here is that candidates often confuse network-layer security controls (security groups, network ACLs, or Shield) with application-layer protection, assuming they can block SQL injection or XSS, when in fact only a web application firewall like AWS WAF can inspect and filter HTTP payloads for such attacks.

How to eliminate wrong answers

Option A is wrong because security groups act as a stateful virtual firewall at the instance level, filtering traffic based on IP addresses, ports, and protocols; they cannot inspect application-layer payloads to detect SQL injection or XSS patterns. Option C is wrong because network ACLs are stateless and operate at the subnet level, only filtering traffic based on IP, port, and protocol rules, with no capability to parse HTTP request bodies or headers for malicious content. Option D is wrong because AWS Shield Advanced provides DDoS protection at the network and transport layers, not application-layer attack mitigation for SQL injection or XSS; it does not include a web application firewall.

Practice this question →

Multi-Selectmedium

A central security account stores encrypted log files in S3 using a customer managed AWS KMS key. A partner account already has S3 bucket access through an assumed role and now must also be able to encrypt and decrypt objects that use the same KMS key. Which two actions are required? Select two.

Select 2 answers

A.Update the KMS key policy to allow the partner role or account to use the key.

B.Enable automatic key rotation to solve the cross-account access requirement.

C.Attach IAM permissions in the partner account for kms:Encrypt, kms:Decrypt, and kms:GenerateDataKey on the CMK.

D.Replace the CMK with the AWS managed key alias/aws/s3.

E.Export the KMS key material and share it with the partner account.

AnswersA, C

KMS evaluates the key policy before permitting use of a customer managed key. Cross-account use requires the key policy to trust the external principal or a grant to that principal.

Why this answer

The KMS key policy must explicitly grant the partner account or role permission to use the key for cryptographic operations. Without this cross-account policy statement, the key remains inaccessible to the partner account, even if the partner has S3 bucket access. This is a fundamental requirement for cross-account KMS key usage.

Exam trap

The trap here is that candidates often forget that cross-account KMS access requires both a key policy update in the central account AND IAM permissions in the partner account, not just one of them.

Practice this question →

MCQmedium

An S3 bucket in account A uses default server-side encryption with an AWS KMS customer-managed key (CMK) in account A. A team created an IAM role in account B that is allowed by IAM policy to perform s3:GetObject on the bucket. When the account B role tries to read objects, it fails with: AccessDeniedException: 'User is not authorized to perform kms:Decrypt'. Which change is most likely to fix the issue?

A.Add kms:Decrypt permissions to the identity policy in account B only, without modifying the CMK key policy in account A.

B.Update the CMK key policy in account A to allow the account B role principal to call kms:Decrypt (and kms:DescribeKey if needed).

C.Disable SSE-KMS on the S3 bucket so objects use SSE-S3 instead, eliminating the need for KMS permissions.

D.Attach a broad permissions boundary to the account B role allowing all kms:* actions to override the key policy.

AnswerB

Updating the CMK key policy in Account A is the correct approach because KMS key policies are the authoritative resource-based policies that govern access to the key, especially for cross-account scenarios. By explicitly adding the Account B role's ARN as a `Principal` and granting `kms:Decrypt` (and `kms:DescribeKey` for context) within the key policy, Account A explicitly authorizes the external principal to use its CMK, satisfying the two-layer authorization model.

Why this answer

When an S3 bucket uses SSE-KMS with a customer-managed key (CMK) in account A, the account B role must have explicit kms:Decrypt permission on that CMK. The key policy in account A controls access to the CMK, so adding the account B role principal to the key policy with kms:Decrypt (and kms:DescribeKey if needed) is required. Without this, even if the S3 bucket policy and IAM role allow s3:GetObject, the KMS decrypt call will fail.

Exam trap

The trap here is that candidates assume IAM permissions in account B are sufficient for cross-account KMS operations, forgetting that the KMS key policy in the owning account must explicitly grant access to the external principal.

How to eliminate wrong answers

Option A is wrong because adding kms:Decrypt to the identity policy in account B alone is insufficient; the CMK key policy in account A must also grant access to the account B role, as KMS key policies act as a separate authorization layer. Option C is wrong because disabling SSE-KMS and switching to SSE-S3 would change the encryption method and potentially violate security requirements, but it would technically fix the KMS permission issue; however, it is not the most likely fix as it alters the encryption configuration rather than addressing the permission gap. Option D is wrong because a permissions boundary on the account B role cannot override the CMK key policy in account A; the key policy is the ultimate authority for KMS key access, and a boundary only limits the role's maximum permissions within its own account.

Practice this question →

Multi-Selecthard

A company is encrypting sensitive S3 data for a claims portal with AWS KMS. Which two controls help prevent accidental use of the KMS key by unauthorized principals?

Select 2 answers

A.A larger KMS key rotation period

B.IAM policies that grant kms:Decrypt only to required application roles

C.A key policy that limits key administrators and key users

D.S3 Transfer Acceleration

AnswersB, C

IAM permissions should grant least-privilege use of the KMS key to specific roles.

Why this answer

IAM policies can be used to restrict the `kms:Decrypt` action to only the specific IAM roles that require it for the claims portal. This ensures that even if an unauthorized principal has access to the encrypted S3 object, they cannot decrypt it without the explicit IAM permission to use the KMS key. Option C is correct because a key policy that explicitly defines key administrators and key users limits who can manage or use the KMS key, preventing accidental use by unauthorized principals.

Exam trap

The trap here is that candidates often assume that IAM policies alone are sufficient to control KMS key access, but they forget that the key policy must also explicitly allow the IAM principal to use the key, as KMS requires both the key policy and IAM policy to grant access.

Practice this question →

MCQmedium

A solutions architect is designing an S3 bucket for a order processing API. The objects must never be publicly accessible, even if a developer later adds an overly broad bucket policy. What should the architect configure?

A.Enable S3 Block Public Access at the account or bucket level

B.Enable server access logging on the bucket

C.Create an IAM policy that denies s3:GetObject to anonymous users

D.Enable S3 Transfer Acceleration

AnswerA

Enabling S3 Block Public Access at either the account or bucket level is the most robust and recommended control for preventing unintended public exposure of S3 buckets. This feature provides four distinct settings that can be applied to block public access granted through new or existing bucket policies, access control lists (ACLs), or any combination thereof. By enforcing these settings, S3 Block Public Access acts as a comprehensive safeguard, overriding any conflicting permissions that might otherwise inadvertently grant public read or write access to objects.

Why this answer

S3 Block Public Access provides a definitive override that prevents any public access to objects, regardless of bucket policies or ACLs. By enabling this setting at the account or bucket level, the architect ensures that even if a developer later adds an overly broad bucket policy, the objects remain inaccessible to anonymous users. This is the only option that guarantees no public access can be inadvertently granted.

Exam trap

The trap here is that candidates may think an IAM policy denying anonymous access is sufficient, but they miss that bucket policies can override IAM policies when both are evaluated, making S3 Block Public Access the only foolproof solution.

How to eliminate wrong answers

Option B is wrong because server access logging only records requests made to the bucket; it does not enforce any access restrictions. Option C is wrong because an IAM policy that denies s3:GetObject to anonymous users can be overridden by a later bucket policy that grants public access, as IAM and bucket policies are evaluated together and a bucket policy can explicitly allow what an IAM policy denies. Option D is wrong because S3 Transfer Acceleration is a performance feature that speeds up uploads over long distances; it has no effect on access control or public accessibility.

Practice this question →

MCQhard

A financial services company must store audit logs in S3 for 7 years and ensure that no one — including the AWS account root user — can delete or overwrite the logs during the retention period. Which S3 Object Lock configuration should a solutions architect use?

A.Object Lock in Compliance mode with a 7-year retention period

B.Object Lock in Governance mode with a 7-year retention period

C.S3 Versioning with a lifecycle rule to transition objects to Glacier after 7 years

D.A bucket policy with Deny for s3:DeleteObject applied to all principals including root

AnswerA

S3 Object Lock in Compliance mode establishes an unalterable Write Once, Read Many (WORM) state for objects. This mode prevents any user, including the AWS account root user, from deleting or overwriting objects until the specified retention period, in this case, 7 years, has expired. The retention period cannot be shortened or removed by anyone, ensuring the highest level of data immutability required for strict financial regulatory compliance.

Why this answer

S3 Object Lock in Compliance mode prevents ALL users — including the root account — from deleting or overwriting objects before the retention period expires. The retention period itself cannot be shortened once set in Compliance mode.

Governance mode also prevents most deletions, but users with s3:BypassGovernanceRetention permission (and the root account) can delete objects or shorten the retention period. For regulatory requirements where not even root can override, Compliance mode is mandatory.

Exam trap

Candidates choose Governance mode because 'governance' sounds strict. In AWS terminology, Governance is the LESS strict option — it can be bypassed by privileged users. Compliance mode is immutable: no one can remove the retention until the period expires.

This distinction is critical for financial regulations like SEC Rule 17a-4 and FINRA requirements.

Why the other options are wrong

Governance mode can be bypassed by the root account and users with s3:BypassGovernanceRetention permission. This does NOT meet the requirement that no one including root can delete the logs.

S3 Versioning prevents accidental deletion by keeping previous versions, but a privileged user can permanently delete all versions. Lifecycle rules manage storage class transitions — they do not prevent deletion. Compliance mode is required.

Bucket policies cannot restrict the root account. IAM policies (including resource-based policies) cannot override root user permissions. Only AWS Organizations SCPs and S3 Object Lock Compliance mode can restrict root's ability to delete S3 objects.

Practice this question →

MCQmedium

A.Create an interface VPC endpoint for STS (com.amazonaws.<region>.sts) and associate it with the instance subnets and a security group that allows HTTPS.

B.Create a gateway VPC endpoint for S3 and route the STS traffic through the S3 endpoint gateway.

C.Open an inbound rule in the instances’ security group to allow outbound HTTPS to the internet CIDR block directly.

D.Attach an Internet Gateway to the private subnet route table so the STS API can be reached over public internet.

AnswerA

Interface endpoints provide private, in-VPC connectivity to AWS APIs like STS without requiring internet access or NAT.

Why this answer

The error indicates the EC2 instances cannot reach the STS public endpoint over the internet because they are in private subnets without a NAT gateway. An interface VPC endpoint for STS (com.amazonaws.<region>.sts) allows private, direct connectivity to the STS API using AWS PrivateLink, without requiring internet access. Associating the endpoint with the instance subnets and a security group that allows HTTPS (port 443) resolves the connectivity issue while keeping the instances private.

Exam trap

The trap here is that candidates often confuse gateway endpoints (which only work for S3 and DynamoDB) with interface endpoints (which work for many services like STS), or they mistakenly think security group rules alone can enable outbound internet access without a route.

How to eliminate wrong answers

Option B is wrong because a gateway VPC endpoint for S3 only provides private connectivity to S3, not to STS; STS is a different service and cannot be reached through an S3 endpoint. Option C is wrong because opening an inbound rule in the instances’ security group for outbound HTTPS to the internet CIDR block does not provide a route to the internet; the instances are in private subnets with no NAT gateway or internet gateway, so outbound traffic to the internet is blocked regardless of security group rules. Option D is wrong because attaching an Internet Gateway to the private subnet route table would make the subnet public, violating the requirement to keep instances private; it would also expose the instances to inbound internet traffic.

Practice this question →

MCQmedium

A.Use AWS PrivateLink by creating a VPC endpoint service backed by the NLB in VPC A, then create an interface VPC endpoint in the partner VPC with appropriate endpoint access controls.

B.Expose the NLB to the internet with an Elastic IP and restrict access using the NLB’s security group only.

C.Use VPC peering between VPC A and the partner VPC and update route tables to resolve the overlap.

D.Deploy a NAT gateway in VPC A and route the partner’s traffic to the NLB through the NAT gateway.

AnswerA

PrivateLink exposes the service privately via interface endpoints, avoiding peering and keeping the NLB non-public for secure partner access.

Why this answer

AWS PrivateLink allows you to expose an internal NLB in VPC A as a VPC endpoint service, and the partner team can create an interface VPC endpoint in their own VPC to connect privately. This solution avoids overlapping CIDR issues because traffic flows through PrivateLink’s network interfaces using private IPs, not through VPC peering or internet routing. It also satisfies the non-public requirement since the API remains accessible only via private networking within AWS.

Exam trap

The trap here is that candidates may assume VPC peering can handle overlapping CIDRs with route table adjustments, but AWS explicitly prohibits overlapping CIDRs in VPC peering connections, making PrivateLink the only viable private networking option.

Why the other options are wrong

The NLB cannot be made internet-facing with an Elastic IP because the requirement explicitly states the API must remain non-public and use AWS private networking. Additionally, NLB security groups are not supported; security is managed via subnet ACLs and target group health checks.

VPC peering cannot resolve overlapping CIDR blocks; overlapping IP ranges make routing impossible, and the requirement for non-public access is already met by peering, but the overlap is the blocker.

A NAT gateway is used for outbound internet access from private subnets, not for inbound traffic from another VPC. It cannot route traffic from a partner VPC to an internal NLB, and it does not resolve VPC CIDR overlap issues.

Practice this question →

MCQhard

Based on the exhibit, the platform team wants developers to create application roles for Lambda and ECS, but no developer-created role may ever exceed the approved permission set. Which change best meets this requirement?

A.Remove all IAM permissions from AppProvisioner and require a central security team to create every role manually.

B.Attach a permissions boundary strategy to the delegated workflow and require every created role to include that boundary using the iam:PermissionsBoundary condition.

C.Allow developers to keep creating roles, but add a CloudTrail rule that alerts security after a privileged policy is attached.

D.Move the delegated IAM workflow into a separate VPC and restrict it with security groups and network ACLs.

AnswerB

A permissions boundary creates an upper limit on what any developer-created role can ever do, even if someone later attaches broader policies. Requiring the boundary during role creation prevents privilege escalation while still allowing delegated self-service for approved application roles. This is the standard AWS pattern when teams need to create roles but must remain inside a strict security envelope.

Why this answer

It uses an IAM permissions boundary attached to the delegated role creation workflow, combined with the `iam:PermissionsBoundary` condition key to enforce that every developer-created role must include that boundary. This ensures no role can exceed the approved permission set, as the boundary acts as a maximum limit on permissions, even if the role's policy grants more. The delegated workflow (e.g., AWS Service Catalog or IAM Role creation via Lambda) can create roles, but the boundary prevents any escalation beyond the predefined scope.

Exam trap

The trap here is that candidates confuse reactive monitoring (like CloudTrail alerts) with preventive controls, or mistakenly think network isolation (VPC/security groups) can restrict IAM permissions, when only IAM boundaries or service control policies (SCPs) can cap permissions at the identity level.

How to eliminate wrong answers

Option A is wrong because removing all IAM permissions from AppProvisioner and requiring manual role creation by a central security team eliminates the delegation entirely, which contradicts the requirement that developers create application roles for Lambda and ECS; it also introduces operational bottlenecks and does not leverage IAM boundaries. Option C is wrong because adding a CloudTrail rule to alert after a privileged policy is attached is reactive, not preventive; it does not stop a developer-created role from exceeding the approved permission set at creation time, violating the 'may never exceed' requirement. Option D is wrong because moving the delegated IAM workflow into a separate VPC with security groups and network ACLs addresses network-level access control, not IAM permission boundaries; it cannot restrict the permissions of IAM roles created by developers, as IAM policies are not governed by network constructs.

Practice this question →

MCQmedium

An order-quote Lambda function is invoked directly by API Gateway. Traffic is predictable during the business day, and the first request after scaling from zero causes unacceptable latency. The team wants to keep the current architecture and reduce cold-start impact. Which configuration should they use?

A.Increase the function timeout so the first invocation has more time to finish.

B.Enable provisioned concurrency for the Lambda function.

C.Set reserved concurrency to a fixed number and leave the rest unchanged.

D.Increase the memory size only to eliminate cold starts.

AnswerB

Provisioned concurrency keeps a set number of Lambda execution environments initialized and ready to serve traffic. That directly reduces or removes cold starts for predictable workloads such as business-hours APIs. It is the most appropriate choice when the team wants to preserve serverless architecture while delivering consistent response times for the first request and subsequent requests.

Why this answer

Provisioned concurrency initializes a specified number of execution environments in advance, so when the first request arrives after scaling from zero, it is served by a pre-warmed instance instead of incurring a cold start. This directly addresses the unacceptable latency without changing the architecture or requiring code modifications.

Exam trap

The trap here is that candidates confuse reserved concurrency (which caps concurrent executions) with provisioned concurrency (which pre-warms instances), or mistakenly believe that increasing memory or timeout can eliminate the cold-start initialization delay.

Why the other options are wrong

Increasing the function timeout does not reduce cold-start latency; it only allows the function to run longer, but the initial cold-start delay remains.

Reserved concurrency limits the maximum concurrent executions for a function but does not pre-warm instances, so it does not reduce cold-start latency for the first request after scaling from zero.

Increasing memory size can reduce cold start duration but does not eliminate cold starts; the first request after scaling from zero still incurs cold start latency.

Practice this question →

MCQmedium

A website serves mostly cacheable images, CSS, and JavaScript from an ALB. Users in Europe and Asia report slower page loads, and the ALB receives far more requests than expected. The team also wants text assets compressed automatically. Which change is the best first step?

A.Increase the ALB size and add more target instances behind it.

B.Use Route 53 latency-based routing to send users to the nearest ALB.

C.Place Amazon CloudFront in front of the ALB and enable compression and caching.

D.Replace the ALB with an NLB to reduce latency for web requests.

AnswerC

CloudFront is the right choice because it caches static content at edge locations close to users, reducing latency and lowering the number of requests that reach the ALB. It also supports compression for text-based assets such as CSS, JavaScript, and HTML. This improves both performance and origin offload without changing the application logic.

Why this answer

CloudFront is the correct first step because it acts as a CDN that caches cacheable content (images, CSS, JS) at edge locations close to users in Europe and Asia, reducing load on the ALB and improving page load times. It also supports automatic compression of text assets (e.g., via gzip or Brotli) without requiring backend changes, directly addressing the team's requirement for compressed text assets. By offloading requests from the ALB, CloudFront reduces the number of requests hitting the origin, solving the 'far more requests than expected' issue.

Exam trap

The trap here is that candidates often think scaling the ALB (Option A) or using latency-based routing (Option B) will solve performance issues, but they overlook that caching and compression at the edge (CloudFront) directly address both latency and request volume without requiring backend changes.

Why the other options are wrong

The issue is not ALB capacity or backend scaling; it's about excessive requests and latency due to lack of caching and compression. Increasing ALB size and instances doesn't reduce request volume or compress assets.

Route 53 latency-based routing directs users to the nearest ALB, but the problem is that the ALB receives far more requests than expected due to cacheable content not being cached. Latency routing alone does not reduce ALB load or compress text assets automatically.

An NLB does not support caching, compression, or HTTP-level features like image/CSS/JS optimization; it operates at Layer 4 and cannot reduce request volume or compress text assets.

Practice this question →

Multi-Selectmedium

A containerized service on Amazon ECS connects to a database with a password that must never be stored in plaintext or hardcoded in the image. The application reads the password at startup and occasionally reconnects later, so it needs to retrieve the current secret when needed. Which three actions should the architect take? Select three.

Select 3 answers

A.Store the database password in AWS Secrets Manager.

B.Have the application retrieve the secret from Secrets Manager at runtime when it needs the password.

C.Grant the ECS task role least-privilege permission to read only that secret.

D.Store the password in a plain environment variable and update it manually during maintenance windows.

E.Use an IAM user access key inside the container so the database password can be embedded in code.

AnswersA, B, C

Secrets Manager is designed for sensitive credentials and integrates with IAM and rotation features. It is a better fit than putting passwords in code, images, or plain variables.

Why this answer

AWS Secrets Manager is the correct service for storing sensitive data like database passwords because it provides encryption at rest (using AWS KMS) and automatic rotation capabilities. By storing the password in Secrets Manager, the architect ensures it is never exposed in plaintext or hardcoded in the container image, meeting the security requirement.

Exam trap

The trap here is that candidates might think environment variables or IAM access keys are acceptable for secrets, but the exam requires using a dedicated secrets management service like Secrets Manager to avoid plaintext exposure and enable rotation.

Why the other options are wrong

Storing the password in a plain environment variable violates the requirement that the password must never be stored in plaintext. Manual updates during maintenance windows are not secure and do not provide automated rotation or retrieval at runtime.

Using an IAM user access key inside the container violates the principle of not storing secrets in the image or code, and access keys are long-lived credentials that increase security risk. The correct approach is to use IAM roles for tasks to obtain temporary credentials.

Practice this question →

Multi-Selecthard

A private application in two private subnets must download objects from S3 and read parameters from Systems Manager Parameter Store without routing traffic through the public internet. Which two components should the architect use? The design must avoid adding custom operational scripts.

Select 2 answers

A.Interface VPC endpoint for Systems Manager

B.Internet gateway attached to the VPC

C.NAT gateway in each Availability Zone

D.Gateway VPC endpoint for Amazon S3

AnswersA, D

Systems Manager/Parameter Store access uses interface endpoints powered by AWS PrivateLink.

Why this answer

An Interface VPC endpoint for Systems Manager (SSM) allows private subnets to communicate with AWS Systems Manager Parameter Store over the AWS network using private IP addresses, without traversing the internet. This endpoint uses AWS PrivateLink, enabling secure and private access to SSM APIs, which is required for reading parameters from Parameter Store.

Exam trap

The trap here is that candidates often confuse Gateway VPC endpoints (used for S3 and DynamoDB) with Interface VPC endpoints (used for most other AWS services like Systems Manager), and may incorrectly assume a NAT gateway or internet gateway is needed for private subnet access to AWS services.

Practice this question →

Multi-Selectmedium

A company stores customer invoices in an Amazon S3 bucket. The application must keep the bucket private, ACLs should not be used, and customers should receive temporary download links for individual invoices. Which three changes should the architect make? Select three.

Select 3 answers

A.Enable S3 Block Public Access on both the bucket and the AWS account.

B.Continue using object ACLs so each customer invoice can be made public briefly.

C.Configure Bucket owner enforced object ownership to disable ACLs.

D.Generate presigned URLs for customers to download specific invoices for a limited time.

E.Move the bucket to another AWS Region to isolate it from the internet.

AnswersA, C, D

Block Public Access prevents accidental public exposure through bucket policies, ACLs, and other public settings. It is a strong baseline control when the data must remain private.

Why this answer

Enabling S3 Block Public Access at both the bucket and account level ensures that no public access can be granted to the bucket or its objects, which aligns with the requirement to keep the bucket private. This setting overrides any other permissions that might inadvertently allow public access, providing a strong security baseline.

Exam trap

The trap here is that candidates might think moving the bucket to a different region or using ACLs can solve the temporary access requirement, but they overlook that S3 Block Public Access and presigned URLs are the correct mechanisms for private, time-limited access without ACLs.

Why the other options are wrong

The requirement explicitly states 'ACLs should not be used,' so continuing to use object ACLs violates that constraint. Additionally, making objects public briefly is insecure and does not provide temporary download links.

Moving the bucket to another AWS Region does not isolate it from the internet; S3 buckets are accessible over the internet regardless of region. The requirement is to keep the bucket private and provide temporary download links, which is unrelated to region placement.

Practice this question →

MCQmedium

A mobile banking backend stores audit logs in S3. The compliance team requires that logs cannot be overwritten or deleted for seven years. What should be configured? The design must avoid adding custom operational scripts.

A.S3 server access logging

B.S3 lifecycle expiration after seven years

C.S3 versioning only

D.S3 Object Lock in compliance mode with an appropriate retention period

AnswerD

Object Lock compliance mode enforces write-once-read-many retention that even privileged users cannot bypass during the retention period.

Why this answer

S3 Object Lock in compliance mode prevents any user, including the root user, from overwriting or deleting objects for the specified retention period. This meets the compliance requirement of immutable audit logs for seven years without custom scripts. Compliance mode enforces a legal hold that cannot be removed by any user, ensuring logs are write-once-read-many (WORM) protected.

Exam trap

The trap here is that candidates often choose versioning (option C) thinking it prevents deletion, but versioning alone does not block overwrites or permanent deletion of the current version without additional safeguards like MFA delete or Object Lock.

How to eliminate wrong answers

Option A is wrong because S3 server access logging only records requests made to the bucket; it does not prevent deletion or overwriting of existing logs. Option B is wrong because S3 lifecycle expiration deletes objects after a set period, which would violate the requirement to prevent deletion for seven years. Option C is wrong because S3 versioning alone preserves previous versions but does not prevent deletion of the current version or overwrites; it requires additional controls like MFA delete or Object Lock to enforce immutability.

Practice this question →

MCQmedium

A company uses IAM permission boundaries to prevent developers from escalating privileges. The security team created a permission boundary that allows only read-only actions on most AWS services, but teams can still manage their own resources. A developer can create an IAM role with broad permissions, and the boundary does not appear to be restricting it. Which corrective action best aligns with how permission boundaries work?

A.Rely on an AWS-managed policy attached to the developer’s IAM user; permission boundaries only apply to users.

B.Ensure the role creation process sets the permission boundary on the new role, using the boundary’s ARN in the CreateRole call or role template.

C.Attach the permission boundary policy as an SCP in AWS Organizations so it automatically applies to all roles.

D.Grant the developer IAM permissions to add a “deny” statement to the boundary policy so the boundary blocks escalation.

AnswerB

Permission boundaries are evaluated based on the boundary attached to the principal/role being created or used. If a developer creates roles without specifying the boundary, the boundary won’t restrict the resulting permissions. Enforcing boundary attachment via role templates or required parameters ensures every created role is constrained.

Why this answer

Permission boundaries must be explicitly applied to a role during its creation (via the `CreateRole` API call or an infrastructure-as-code template). Without setting the boundary ARN, the role inherits no restriction, allowing the developer to create a role with broad permissions that bypasses the intended boundary. Option B correctly identifies that the role creation process must include the boundary ARN to enforce the limitation.

Exam trap

The trap here is that candidates assume permission boundaries are automatically inherited or enforced by default, when in fact they must be explicitly applied to each role during creation, and SCPs are often confused as a substitute for permission boundaries.

Why the other options are wrong

Permission boundaries apply to IAM roles and users, not just users. The developer can create a role without a boundary, so attaching a policy to the user does not restrict the role's permissions.

SCPs apply to all accounts in an AWS Organization but do not replace or enforce IAM permission boundaries on individual roles; permission boundaries must be explicitly set on each role during creation.

Permission boundaries cannot be modified by the user they restrict; only the boundary's creator (e.g., security team) can update it. Granting the developer permission to add a deny statement would violate the boundary's purpose and is not a valid corrective action.

Practice this question →

MCQhard

Based on the exhibit, the security team needs to detect and alert on both successful and failed attempts to change S3 bucket policies and KMS key policies across the organization. Which solution best meets that requirement?

A.Enable an organization trail for management events in all regions and create an EventBridge rule that matches PutBucketPolicy and PutKeyPolicy, then send alerts to SNS.

B.Enable AWS Config in all accounts and use only a periodic compliance evaluation to alert when bucket or key policies drift.

C.Use IAM Access Analyzer because it continuously blocks policy changes that would expose the resources publicly.

D.Turn on S3 server access logging and KMS key rotation, because both services will capture policy modifications automatically.

AnswerA

CloudTrail management events record API activity, including failed attempts, and an organization trail provides coverage across accounts and Regions. EventBridge can react to those API calls in near real time and route notifications to SNS. This is the clean detective-control pattern for policy-change auditing.

Why this answer

AWS CloudTrail management events capture all API calls that modify S3 bucket policies (PutBucketPolicy) and KMS key policies (PutKeyPolicy). By enabling an organization trail for all regions, you centralize these events across the entire AWS Organization. An Amazon EventBridge rule can then filter for these specific API calls and send alerts via Amazon SNS, meeting the requirement to detect both successful and failed attempts.

Exam trap

The trap here is that candidates often confuse AWS Config's compliance checks or IAM Access Analyzer's policy analysis with real-time API call monitoring, failing to realize that only CloudTrail management events capture every attempt (including failures) to change policies.

How to eliminate wrong answers

Option B is wrong because AWS Config periodic compliance evaluations only check resource compliance at scheduled intervals, not in real-time, and they do not directly capture or alert on every API call attempt (including failed ones) to change policies. Option C is wrong because IAM Access Analyzer is designed to analyze resource-based policies for unintended public or cross-account access, not to block or alert on all policy change attempts; it does not continuously block changes or capture failed attempts. Option D is wrong because S3 server access logging logs object-level access requests, not management API calls like PutBucketPolicy, and KMS key rotation does not capture policy modifications; neither service logs policy change attempts.

Practice this question →

MCQmedium

You have an S3 bucket that stores customer-specific private files. You want to serve these files through CloudFront, where clients must use signed cookies (or signed URLs) to access the content. In addition, you need to block common web exploits and rate-limit suspicious traffic at the edge. Which design best meets these requirements?

A.Keep the S3 bucket private, configure CloudFront with Origin Access Control so only CloudFront can access the origin, require signed cookies/URLs for viewers, and associate an AWS WAF web ACL with CloudFront for blocking and rate limiting.

B.Enable public read access on the S3 bucket and rely on WAF alone for authorization because WAF can validate signatures.

C.Configure CloudFront with signed URLs but do not change the S3 bucket access settings; leaving public access enabled is acceptable since CloudFront can filter traffic.

D.Use WAF at CloudFront but omit signed cookies/URLs because rate limiting and exploit blocking already provide access control for private files.

AnswerA

This ensures S3 remains non-public while CloudFront becomes the only origin access path using Origin Access Control. Signed cookies/URLs enforce authenticated authorization at the edge for each request. Attaching AWS WAF adds request inspection and protections like rate limiting and exploit blocking.

Why this answer

It combines a private S3 bucket with Origin Access Control (OAC) to ensure only CloudFront can access the origin, enforces signed cookies/URLs for viewer authentication, and uses AWS WAF at the edge to block common web exploits and rate-limit suspicious traffic. This layered approach provides both authorization (via signed requests) and security filtering (via WAF) at the CloudFront edge, meeting all requirements.

Exam trap

The trap here is that candidates often think WAF can handle authorization (like validating signed URLs) or that leaving the S3 bucket public is acceptable if CloudFront is used, but WAF cannot verify cryptographic signatures and a public bucket allows direct access bypassing CloudFront's authentication.

How to eliminate wrong answers

Option B is wrong because enabling public read access on the S3 bucket bypasses the need for signed cookies/URLs, and WAF cannot validate signatures—WAF inspects HTTP headers, URI paths, and IP addresses, but does not have the capability to verify CloudFront signed URL or signed cookie cryptographic signatures. Option C is wrong because leaving the S3 bucket publicly accessible defeats the purpose of using signed URLs; CloudFront does not filter traffic based on signed URLs at the origin level, so a public bucket would allow direct access to objects without authentication. Option D is wrong because omitting signed cookies/URLs means there is no mechanism to restrict access to authorized viewers only; WAF rate limiting and exploit blocking do not provide authentication or authorization for private content.

Practice this question →

MCQhard

Based on the exhibit, a public API is behind CloudFront and is experiencing bursts of requests from the same client IP, causing upstream saturation. The team wants AWS to automatically block that IP when the request rate becomes excessive while keeping enforcement as close to the client as possible. Which control should they add?

A.Add an AWS WAF rate-based rule to the CloudFront distribution and configure it to block the source IP after the threshold is exceeded.

B.Add a network ACL rule that denies the source IP after five requests are observed.

C.Enable AWS Shield Advanced and create a custom protection group for the single IP address.

D.Place the API behind a security group rule that allows only the current client IP range.

AnswerA

AWS WAF rate-based rules are purpose-built for this use case. They evaluate the HTTP request rate from a source IP over a sliding window and can automatically block, CAPTCHA, or count when the threshold is exceeded. Attaching the Web ACL to CloudFront enforces the control at the edge, so abusive requests are stopped before they reach the origin and consume upstream capacity.

Why this answer

AWS WAF rate-based rules are designed to automatically block IP addresses that exceed a specified request rate within a 5-minute evaluation window. By attaching this rule to a CloudFront distribution, enforcement occurs at the edge location closest to the client, preventing excessive requests from reaching the upstream API and mitigating saturation.

Exam trap

The trap here is confusing stateless network ACLs or static security groups with the automatic, rate-aware blocking capability of AWS WAF, leading candidates to choose a manual or non-scalable solution.

How to eliminate wrong answers

Option B is wrong because network ACLs are stateless and require manual intervention to add or remove rules; they cannot automatically block an IP after a threshold of requests is observed. Option C is wrong because AWS Shield Advanced provides DDoS protection and custom protection groups for resource-level mitigation, not automatic per-IP rate limiting based on request count. Option D is wrong because security group rules are stateful and cannot dynamically update to block a specific client IP based on request rate; they only allow or deny traffic based on static rules.

Practice this question →

MCQmedium

A company stores private customer documents in an S3 bucket. They want only CloudFront to be able to read objects from the bucket (no direct S3 URL access), even if the bucket name and object key are known. Which configuration best meets this requirement?

A.Attach an AWS WAF Web ACL to CloudFront and allow public reads on the S3 bucket so WAF can block direct object access.

B.Use CloudFront Origin Access Control (OAC) and update the bucket policy to allow s3:GetObject only when the principal is cloudfront.amazonaws.com and aws:SourceArn equals the CloudFront distribution ARN.

C.Create IAM users with s3:GetObject permissions and share the IAM credentials with customers so they can fetch objects directly from S3.

D.Enable S3 static website hosting on the bucket and use the S3 website endpoint as the CloudFront origin so access controls can be enforced at CloudFront.

AnswerB

With OAC, CloudFront signs requests to S3 using an AWS-managed identity (the cloudfront.amazonaws.com service principal). A bucket policy that allows s3:GetObject only when AWS:SourceArn matches your specific CloudFront distribution ARN ensures the bucket is not readable from S3 by other principals. Direct S3 requests from users do not present the required CloudFront context, so they are denied at S3 authorization time.

Why this answer

CloudFront Origin Access Control (OAC) allows you to restrict S3 bucket access exclusively to CloudFront. By configuring the bucket policy to allow s3:GetObject only when the principal is cloudfront.amazonaws.com and the aws:SourceArn matches the CloudFront distribution ARN, you ensure that direct S3 URL requests are denied, even if the bucket name and object key are known. This prevents any unauthorized direct access to the S3 bucket.

Exam trap

The trap here is that candidates often confuse CloudFront's ability to cache content with its ability to enforce access control, mistakenly thinking that enabling static website hosting or using WAF alone can prevent direct S3 access, when in fact only Origin Access Control (or OAI) with a properly scoped bucket policy can achieve this.

How to eliminate wrong answers

Option A is wrong because AWS WAF operates at the application layer (Layer 7) and cannot block direct S3 URL access; it only filters HTTP/HTTPS requests to CloudFront, and allowing public reads on the S3 bucket would still permit direct S3 access. Option C is wrong because sharing IAM credentials with customers violates security best practices, and it does not prevent direct S3 URL access if the credentials are used outside CloudFront. Option D is wrong because enabling S3 static website hosting does not restrict access to CloudFront; the S3 website endpoint is publicly accessible and does not enforce CloudFront-only access controls.

Practice this question →