Refer to the Exhibit Practice Questions

Increase the on-demand table limits so DynamoDB can automatically absorb more traffic.

Why wrong: On-demand already scales capacity automatically, and the problem here is hot, repeated reads with cacheable data rather than missing capacity.

Create a global secondary index on tenantId to distribute the load across more partitions.

Why wrong: A GSI changes access paths, but it does not cache repeated reads and may add write overhead without solving the hot-read pattern.

Move the dashboard data into S3 and use Lambda functions to read it on demand.

Why wrong: That would replace a low-latency database with an object-storage workflow and would worsen the user-facing read path.

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

Why wrong: A boundary on the creator role does not automatically propagate to newly created roles. The new role must either be created with the boundary or be blocked unless it includes the approved boundary. Creator boundaries and target-role boundaries are separate controls.

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

Why wrong: Request tags are useful for tagging governance, but they do not validate which permissions boundary is attached to the new role. The enforcement must check the permissions boundary parameter or the boundary ARN condition, not a general request tag.

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

Why wrong: Access Analyzer is a detection and analysis service, not an enforcement mechanism that modifies IAM resources. It can help identify overly broad access, but it cannot automatically attach permissions boundaries to IAM roles during creation.

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

Why wrong: Spread placement groups are designed to reduce correlated failure risk, not to minimize latency between tightly coupled nodes. Spreading instances across Availability Zones also adds network distance and does not improve east-west communication. This would make the cluster more resilient in some cases, but it works against the stated performance goal.

Add an Application Load Balancer in front of the workers to reduce inter-node latency.

Why wrong: An Application Load Balancer helps distribute client traffic to application targets, but it does not reduce latency between worker nodes that are already talking to each other directly. It would introduce another hop for incoming traffic and does nothing to change physical placement of the instances.

Increase the EC2 instance size while keeping the current multi-AZ layout.

Why wrong: Larger instances may improve CPU or memory headroom, but they do not solve the core issue shown in the exhibit: network latency between workers. The RTT problem is caused by placement and topology, not lack of compute capacity. Keeping the current AZ spread preserves the latency penalty.

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

Why wrong: ALB idle timeout affects how long an existing connection can remain open, not how many requests a hostile client can generate. Increasing it may actually increase resource consumption at the origin instead of stopping the abuse.

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

Why wrong: Route 53 health checks and failover are used for endpoint availability and regional failover, not for filtering or rate-limiting abusive requests from a single client IP. This would not stop the malicious traffic from reaching the origin.

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

Why wrong: AWS Shield Advanced is useful for broader DDoS resiliency, especially for large-scale network and transport layer attacks, but the precise control for this HTTP request pattern is AWS WAF with a rate-based rule. The scenario calls for request-level edge filtering, not only infrastructure-level DDoS protection.

Use latency-based routing with both ALB records enabled.

Why wrong: Latency-based routing chooses the Region with the lowest latency, not a designated primary/secondary pair. It does not provide the explicit health-based failover behavior required here.

Use geolocation routing so users are always sent to the closest Region.

Why wrong: Geolocation routing is based on client location, not the health of the primary Region. It can still direct users to an unhealthy endpoint if that Region matches the location rule.

Use a CNAME record that points to both ALBs so DNS can round-robin between Regions.

Why wrong: A single DNS record cannot provide health-aware active failover to two targets in that manner. Round-robin behavior also does not guarantee that traffic will move away from a failed primary only when the primary becomes unhealthy.

Use io2 EBS volumes because they provide the highest durable block storage performance.

Why wrong: io2 can be very fast, but the workload does not require durable local scratch data, so paying for persistence adds unnecessary cost and complexity.

Use Amazon EFS for the workspace so the temporary files survive instance replacement.

Why wrong: EFS is shared and persistent, but a network file system adds latency and is unnecessary when the workspace is disposable.

Use S3 as the working directory and read and write the intermediate files directly there.

Why wrong: S3 is object storage, not a low-latency filesystem for frequent read-modify-write scratch operations and temporary intermediates.

Convert the DB instance to Multi-AZ so the primary can serve more reads.

Why wrong: Multi-AZ improves availability and failover behavior, but it does not add read scaling capacity for reporting traffic.

Increase the primary instance class to a larger size and keep all traffic on one writer.

Why wrong: A larger instance might help temporarily, but it keeps read and write workloads competing on the same primary database.

Migrate the reporting workload to DynamoDB to gain faster reads.

Why wrong: That would require a data model redesign and service migration, which is unnecessary for the stated problem and not the simplest performance fix.

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

Why wrong: ACLs control S3 object access, not KMS cryptographic authorization. The error is coming from KMS decrypt operations, so ACL changes would not solve it.

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

Why wrong: Moving the data would avoid the immediate trust problem, but it is an architectural workaround, not the required fix. It adds duplication, cost, and operational complexity without addressing the KMS sharing requirement.

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

Why wrong: SSE-S3 removes customer-managed key control, which may violate security or compliance requirements. The scenario requires safe use of the customer-managed KMS key, not eliminating it.

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

Why wrong: Principal tags can help with authorization, but they do not ensure that only one exact role in Account B can call STS. Any principal that can supply the tag might still satisfy the condition. This does not provide the required caller-specific trust boundary.

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

Why wrong: Permission boundaries limit the maximum permissions a role can have after it is assumed, but they do not control who is trusted to assume the role. The trust policy, not the permission boundary, determines which external principal can call sts:AssumeRole.

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

Why wrong: An SCP can constrain identities in Account B, but it cannot by itself grant trust on the role in Account A. The trust policy in Account A must still explicitly allow the correct principal and should include the external ID condition for secure cross-account access.

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

Why wrong: Permission boundaries are attached to IAM users or roles, not to an STS session after the role has already been assumed. They set the maximum permissions for that principal, but they do not provide a per-execution narrowing mechanism for one AssumeRole call while leaving the shared role unchanged for other pipelines.

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

Why wrong: Service control policies act as account-level guardrails, not per-session controls. They cannot tailor permissions for one pipeline execution and would be too broad for a shared-role scenario where different pipelines need different prefixes and keys. SCPs also do not replace identity or session policies for fine-grained runtime restriction.

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.

Why wrong: Trust policies control which principals are allowed to assume the role; they do not scope the S3 object paths or KMS key resources that the resulting temporary credentials may access. Resource-level restrictions belong in identity policies, resource policies, or session policies. The scenario specifically asks for a per-execution restriction without modifying the shared role, which makes a session policy the correct control.

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

Why wrong: Signed URLs protect access through CloudFront, but they do not make the S3 bucket private. If the bucket policy is public, anyone who knows the S3 URL can still bypass CloudFront. The origin itself must be locked down.

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

Why wrong: An access point does not automatically solve the direct-public-access problem. The origin still needs a resource policy that restricts who can read the objects, and the CloudFront distribution must be explicitly authorized to use that origin path.

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

Why wrong: WAF can help with edge filtering, but it does not prevent direct S3 object URL access. The origin must be private through CloudFront authorization, otherwise the bucket remains reachable outside CloudFront regardless of WAF rules.

Create a read replica in the same Availability Zone as the primary database.

Why wrong: A read replica helps with read scaling and some recovery scenarios, but it does not provide automatic failover like a Multi-AZ deployment.

Increase the backup retention period to 35 days.

Why wrong: Longer backups improve recovery options, but they do not provide automatic failover during an outage. Backups are still a restore-based process.

Move the database to an EC2 instance with an attached EBS volume.

Why wrong: Running the database on EC2 adds operational burden and usually reduces managed failover capability compared with RDS Multi-AZ.

Use a spread placement group to maximize instance separation across hardware.

Why wrong: Spread placement groups increase isolation, but they do not optimize for the lowest possible latency between instances.

Use a partition placement group to distribute instances across many partitions.

Why wrong: Partition placement groups are better for reducing correlated hardware failures in large distributed systems, not for minimizing latency between tightly coupled nodes.

Use multiple Auto Scaling groups to spread traffic across more subnets.

Why wrong: More Auto Scaling groups do not reduce latency between the existing instances. This is a placement problem, not a scaling problem.

Keep the current cache key and increase the S3 bucket's storage class.

Why wrong: Changing S3 storage class does not improve CloudFront cache reuse. The problem is that the cache key is too granular and prevents reuse across requests.

Disable the CloudFront cache so every request is served directly from S3.

Why wrong: Disabling caching guarantees more origin traffic and worse performance. It would make the origin fetch problem much worse instead of improving cache reuse.

Switch the origin from Amazon S3 to an Application Load Balancer.

Why wrong: An ALB origin is not appropriate for static versioned asset delivery. It adds cost and complexity without addressing the cache-key design issue that is hurting hit ratio.

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

Why wrong: This would certainly reduce risk, but it removes the delegated administration model the team explicitly needs. It is operationally expensive and slows delivery unnecessarily.

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

Why wrong: Alerting after the fact detects bad changes, but it does not prevent a powerful role from being created or used. The requirement is preventive least privilege, not detective monitoring alone.

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

Why wrong: IAM authorization is not controlled by VPC networking constructs. Security groups and network ACLs do not restrict IAM actions such as role creation or policy attachment.