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

Question 1

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.. Option A is correct because 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 2

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 3

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.. Option A is correct because 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 4

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 5

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 6

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.. Option A is correct because 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 7

A team wants to remove a bastion host used for administrative access to EC2 instances in private subnets. The instances should be reachable only for occasional troubleshooting by engineers who authenticate with AWS SSO. What is the best secure alternative within AWS, assuming the instances already have an instance profile attached?

Accepted Answer

Use AWS Systems Manager Session Manager, enabling the required SSM permissions in the instance profile and restricting access to engineers via IAM.. AWS Systems Manager Session Manager provides secure, auditable, agent-based access to EC2 instances without requiring a bastion host, public IPs, or open inbound ports. Since the instances already have an instance profile, you only need to add the required SSM permissions (e.g., AmazonSSMManagedInstanceCore) to that profile and use IAM policies to restrict Session Manager access to engineers authenticated via AWS SSO. This eliminates the bastion host while maintaining secure, on-demand troubleshooting access.

Answer

Keep the bastion host but move it into a private subnet; engineers can connect by using a corporate VPN into the VPC.

Answer

Attach a public IP to each private instance so engineers can SSH directly and use security groups to restrict access.

Answer

Create a security group rule that allows engineers’ source IP addresses to reach instances over RDP on port 3389.

Question 8

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?

Accepted Answer

Update the CMK key policy in account A to allow the account B role principal to call kms:Decrypt (and kms:DescribeKey if needed).. 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.

Answer

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

Answer

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

Answer

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

Question 9

Your security team needs to detect and alert on any attempt to change sensitive policies, specifically S3 bucket policy changes and KMS key policy changes. The team wants alerts within minutes, and logs must be centrally retained for forensics. Which design best meets these detective control requirements using AWS-native services?

Accepted Answer

Enable CloudTrail management events and configure an EventBridge rule to send notifications for PutBucketPolicy and PutKeyPolicy API calls, while also delivering CloudTrail logs to a dedicated S3 bucket for retention.. Option A is correct because CloudTrail management events capture all API calls for S3 bucket policies (PutBucketPolicy) and KMS key policies (PutKeyPolicy) by default, and EventBridge rules can trigger near-real-time alerts (within minutes) for these specific API calls. Additionally, delivering CloudTrail logs to a dedicated S3 bucket provides centralized, immutable retention for forensic analysis, meeting both the alerting and retention requirements.

Answer

Rely on AWS Config resource snapshots only; use the snapshots to infer policy changes and generate alerts from the daily compliance summary reports.

Answer

Enable S3 access logging on the affected buckets only; treat these logs as sufficient evidence for KMS key policy modifications.

Answer

Turn on CloudWatch Logs for the S3 bucket and KMS key; alert on any log line containing the word 'policy' to detect changes.

Question 10

A CI pipeline in account A uploads build artifacts to an S3 bucket (arn:aws:s3:::build-artifacts-prod) under the prefix teamA/. The pipeline must not be able to list other prefixes, and it must only upload objects under teamA/. Which IAM policy design best enforces least privilege for this requirement?

Accepted Answer

Allow s3:PutObject on arn:aws:s3:::build-artifacts-prod/teamA/* and allow s3:ListBucket on arn:aws:s3:::build-artifacts-prod with a condition that requires s3:prefix equals 'teamA/'.. Option B is correct because it grants the minimal permissions required: s3:PutObject is scoped to the specific prefix teamA/*, preventing uploads to other prefixes, and s3:ListBucket is allowed only with a condition that restricts the s3:prefix to 'teamA/', ensuring the pipeline cannot list objects under other prefixes. This enforces least privilege by combining resource-level and condition-based access control.

Answer

Allow s3:PutObject on arn:aws:s3:::build-artifacts-prod/* and allow s3:ListBucket on arn:aws:s3:::build-artifacts-prod with no condition.

Answer

Allow s3:PutObject on arn:aws:s3:::build-artifacts-prod/teamA/* and allow s3:GetBucketLocation on arn:aws:s3:::build-artifacts-prod/teamA/.

Answer

Allow s3:* on arn:aws:s3:::build-artifacts-prod/teamA/* and allow s3:ListAllMyBuckets for easier auditing.

Question 11

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.. Option B is correct because 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 12

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?

Accepted Answer

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.. Option B is correct because 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.

Answer

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

Answer

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

Answer

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.

Question 13

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?

Accepted Answer

Update the KMS key policy in account A to allow the account B role principal to use kms:Decrypt on the key.. Option B is correct because 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.

Answer

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

Answer

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

Answer

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

Question 14

A security requirement states: all uploads to an S3 bucket must (1) use TLS in transit and (2) use server-side encryption with AWS KMS (SSE-KMS) using the CMK key id 'abcd-1234'; otherwise the upload should be rejected. A developer reports that uploads are succeeding even though clients are sometimes using non-encrypted requests. Which bucket policy approach most directly enforces both controls?

Accepted Answer

Use Deny statements that reject PutObject when aws:SecureTransport is false and reject PutObject when s3:x-amz-server-side-encryption is not 'aws:kms' or when s3:x-amz-server-side-encryption-aws-kms-key-id does not equal 'abcd-1234'.. Option B is correct because bucket policies can use the `aws:SecureTransport` condition key to enforce TLS and the `s3:x-amz-server-side-encryption` and `s3:x-amz-server-side-encryption-aws-kms-key-id` condition keys to enforce SSE-KMS with the specific CMK key ID. By using Deny statements, any request that does not meet both conditions is explicitly rejected, regardless of any Allow statements that might otherwise grant access. This directly enforces the security requirement at the bucket level.

Answer

Add an Allow statement granting s3:PutObject to the developer role; rely on IAM conditions in the developer role to enforce TLS and SSE-KMS.

Answer

Enable S3 default encryption to SSE-KMS and remove any bucket policy enforcement, since default encryption automatically rejects all noncompliant uploads.

Answer

Attach a WAF rule to the S3 website endpoint to block non-TLS requests, because bucket policies cannot evaluate aws:SecureTransport.

Question 15

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?

Accepted Answer

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.. Option A is correct because 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.

Answer

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

Answer

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.

Answer

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