SAA-C03 Design Secure Architectures Practice Test 4 — 15 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Update the trust policy on UploadRole (account B) to allow sts:AssumeRole from the app’s IAM role or principal in account A.. 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.

Answer

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

Answer

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

Answer

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

Question 2

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?

Accepted Answer

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.. 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.

Answer

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

Answer

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

Answer

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

Question 3

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?

Accepted Answer

Create a Gateway VPC endpoint for S3 and associate it with the private subnet route tables that contain the instances.. 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.

Answer

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

Answer

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

Answer

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

Question 4

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?

Accepted Answer

Create an interface VPC endpoint for STS (com.amazonaws..sts) and associate it with the instance subnets and a security group that allows HTTPS.. 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..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.

Answer

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

Answer

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

Answer

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

Question 5

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?

Accepted Answer

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.. Permission boundaries must be explicitly set on a role during its creation (via the `CreateRole` API call or an infrastructure-as-code template). Without specifying the boundary ARN in the role creation request, the role inherits no boundary, allowing the developer to attach broad permissions that exceed the intended restriction. Option B correctly identifies that the developer’s role creation process must include the boundary ARN to enforce the limitation.

Answer

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

Answer

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

Answer

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

Question 6

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?

Accepted Answer

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.. An AWS Organizations CloudTrail organization trail captures management events (including IAM API calls like ChangeTrustPolicy) across all accounts and regions, storing immutable logs in a centralized S3 bucket in a dedicated audit account. This provides the exact principal ARN, source IP, and request parameters needed for forensic investigation, meeting the immutable and centralized audit requirement.

Answer

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

Answer

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

Answer

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

Question 7

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?

Accepted Answer

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.. 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 return 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 response packets to be dropped, resulting in connection timeouts.

Answer

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

Answer

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

Answer

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

Question 8

A SaaS vendor needs temporary access to an S3 bucket in your AWS account to read customer exports. The vendor will assume an IAM role you created. During integration testing, the vendor reports that their AssumeRole requests succeed, but your security team is concerned about the possibility of confused-deputy attacks. Which trust policy approach most directly mitigates this risk?

Accepted Answer

Add an sts:ExternalId condition to the role trust policy that must match the unique external ID you provide to the vendor.. Adding an `sts:ExternalId` condition to the role trust policy forces the vendor to include a unique external ID in their `AssumeRole` API call. This prevents a confused-deputy attack by ensuring that the role can only be assumed when the caller presents the specific external ID you control, even if the vendor's account is compromised or used by a different AWS service.

Answer

Require the vendor to use the same MFA device serial number as your internal administrators in the trust policy.

Answer

Remove the role’s permissions policy and rely only on the S3 bucket policy to validate the caller.

Answer

Allow sts:AssumeRole from the vendor account root principal without restricting to the vendor’s specific IAM role.

Question 9

A security analyst needs to let an external vendor (AWS account 555566667777) read data from a set of internal resources in your AWS account. You created an IAM role called VendorReadRole with a policy that allows the required API calls. However, when the vendor tries to access, CloudTrail shows the call fails at AssumeRole with: "Not authorized to perform: sts:AssumeRole".

What is the most appropriate fix?

Accepted Answer

Add an allow statement for the vendor in the role’s trust policy to permit sts:AssumeRole from the vendor account (and include any required ExternalId condition).. The error 'Not authorized to perform: sts:AssumeRole' indicates that the role's trust policy does not grant the external AWS account (555566667777) permission to assume the role. The trust policy must include an Allow statement with the sts:AssumeRole action, specifying the external account as the principal, and optionally an ExternalId condition to prevent the confused deputy problem. This is the required configuration for cross-account IAM role access.

Answer

Attach the same allow policy to the vendor account’s existing IAM user so the user can call sts:AssumeRole directly into your role.

Answer

Replace the AssumeRole call with GetCallerIdentity so the vendor can infer permissions without assuming the role.

Answer

Enable MFA on the vendor’s IAM user and require MFA for your role using condition keys in the permissions policy.

Question 10

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?

Accepted Answer

Associate the Web ACL with the Application Load Balancer resource ARN so WAF evaluates requests sent to that ALB.. The Web ACL must be explicitly associated with the ALB resource ARN for AWS WAF to evaluate incoming requests. Without this association, WAF does not inspect traffic, allowing attackers to bypass the rate-based rule and reach the backend service. Associating the Web ACL with the ALB ensures that all requests to the ALB are evaluated by the WAF rules before being forwarded to the target group.

Answer

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

Answer

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

Answer

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

Question 11

Your CI system assumes an IAM role RoleForDeploy using STS AssumeRole and includes a session tag called Project=blue. The role’s permissions policy uses an ABAC condition like aws:PrincipalTag/Project to allow access only to resources tagged with the same project.

AssumeRole succeeds, but deployments fail with AccessDenied. CloudTrail shows the role was assumed, yet the effective session does not contain the Project tag.

Which change most directly fixes this issue?

Accepted Answer

Add permissions for sts:TagSession to the IAM role so the CI pipeline is allowed to pass the Project session tag during AssumeRole.. When an IAM role is assumed with STS AssumeRole and session tags are included, the calling principal must have explicit permission to pass those tags via the `sts:TagSession` action. Without this permission, the session tags are silently dropped, even though the AssumeRole call succeeds. Adding `sts:TagSession` to the role's permissions allows the CI pipeline to pass the `Project=blue` tag, making the ABAC condition on `aws:PrincipalTag/Project` evaluate correctly and granting access to tagged resources.

Answer

Remove the ABAC condition using aws:PrincipalTag/Project so the policy ignores session tags.

Answer

Move the aws:PrincipalTag/Project condition into the trust policy so it applies during the AssumeRole call.

Answer

Add kms:Decrypt permission to the CI role because missing tags are typically caused by KMS authorization failures.

Question 12

Account C wants engineers to access a role (RoleInAccountA) in account A using STS AssumeRole. Security policy requires that (1) only engineers from account C can assume the role, (2) they must provide an external ID value, and (3) the session must be MFA-authenticated. Which change is most appropriate in the RoleInAccountA trust policy to meet all three requirements?

Accepted Answer

Add conditions that (a) restrict the caller principals to account C engineers (for example, aws:PrincipalArn matches a specific engineer role/user pattern from account C), (b) require sts:ExternalId = <value>, and (c) require aws:MultiFactorAuthPresent = true.. It satisfies all three security requirements: it restricts the caller principals to engineers from account C using the `aws:PrincipalArn` condition, enforces the external ID with `sts:ExternalId`, and mandates MFA authentication via `aws:MultiFactorAuthPresent = true`. The trust policy on RoleInAccountA must explicitly include the MFA condition because MFA enforcement cannot be delegated to the session policy or to the calling account's IAM permissions when the role is in a different account.

Answer

Add conditions sts:ExternalId = <value> only; do not include any MFA requirement because MFA can be enforced by the IAM role session policy.

Answer

Add conditions for aws:PrincipalTag:Department = Engineering and sts:ExternalId = <value>; omit MFA because MFA is optional for AssumeRole.

Answer

Add conditions aws:SecureTransport = true and sts:ExternalId = <value>; rely on IAM permissions in account C to require MFA.

Question 13

Your organization uses IAM permission boundaries to prevent engineers from escalating privileges. An automated pipeline creates an IAM role for an application deployment and attaches a permission boundary. After deployment, the pipeline reports that the role could create a new KMS key. The permission boundary policy attached to the role allows only (for a specific KMS key ARN, prod-key): - kms:Decrypt - kms:DescribeKey There is no Allow statement for: - iam:CreateKey - kms:CreateKey What is the most likely reason the role was still able to create a KMS key?

Accepted Answer

The permission boundary was not actually attached to the role at creation time (for example, the pipeline bug attached a different boundary ARN or the attachment step failed).. The most likely reason is that the permission boundary was not actually attached to the role at creation time. Permission boundaries define the maximum permissions a role can have; if the boundary is missing or not attached, the role inherits the full permissions of its attached IAM policies. Since the boundary explicitly denies kms:CreateKey, the only way the role could create a KMS key is if the boundary was not enforced, pointing to a pipeline bug or attachment failure.

Answer

Permission boundaries automatically grant all KMS permissions needed by applications, even when they are not listed in the boundary.

Answer

Because the boundary allows kms:DescribeKey for prod-key, kms:CreateKey must also be implicitly allowed.

Answer

SCPs always override permission boundaries, so the boundary is ignored in Organizations.

Question 14

An AWS Organizations setup uses an SCP to enforce that developers can read only non-production secrets. A developer role in a member account is correctly configured with an identity policy that allows: - secretsmanager:GetSecretValue on arn:aws:secretsmanager:us-east-1:222222222222:secret:app/* However, the developer gets AccessDenied with an error message mentioning an organization policy (SCP). The SCP includes this Deny statement: "Deny secretsmanager:GetSecretValue on * unless secretsmanager:ResourceTag/environment equals 'dev'". Which change best restores access for secrets tagged environment=dev while still blocking prod secrets?

Accepted Answer

Update the SCP to match the correct tag key/format actually used on your Secrets Manager secret resources so the condition evaluates to true for environment=dev.. The SCP Deny statement uses a condition key `secretsmanager:ResourceTag/environment` that must evaluate to true for the tag value 'dev' to allow access. If the actual Secrets Manager secrets are tagged with a different key format (e.g., `environment` vs. `Environment`) or the tag is missing, the condition fails and the Deny applies. Updating the SCP to match the exact tag key and value used on the secrets ensures the condition evaluates to true, allowing GetSecretValue for dev-tagged secrets while still blocking prod secrets.

Answer

Remove the Deny statement from the SCP and rely only on the member account identity policy.

Answer

Add an IAM policy statement with Effect=Allow and "Condition: aws:PrincipalOrgID" in the member account to override the SCP.

Answer

Use a longer STS session duration so the SCP is evaluated less frequently.

Question 15

Your organization uses IAM permission boundaries to prevent privilege escalation. A deployment role was created with a permission boundary. After an incident, you discover that an operator was later able to remove or change the permission boundary (the operator has iam:PutRolePermissionsBoundary permissions). You need to ensure operators cannot remove or change the permission boundary after it is set. What is the best security control to add?

Accepted Answer

Add an explicit IAM Deny for operators on both iam:PutRolePermissionsBoundary and iam:DeleteRolePermissionsBoundary for all affected roles.. Adding an explicit IAM Deny for both `iam:PutRolePermissionsBoundary` and `iam:DeleteRolePermissionsBoundary` on the affected roles prevents operators from removing or changing the permission boundary, even if they have the corresponding Allow permissions. This is a classic use of an explicit Deny, which overrides any Allow in AWS IAM policy evaluation logic, ensuring the boundary remains immutable after deployment.

Answer

Grant operators iam:PutRolePermissionsBoundary so they can reapply the boundary if needed.

Answer

Rely only on the role’s trust policy so operators cannot assume the role.

Answer

Attach a more permissive permission boundary so the roles remain functional after changes.