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

Question 1

An application encrypts data directly with AWS KMS using an encryption context. Your KMS key policy includes a condition that allows kms:Decrypt only when the encryption context contains: "purpose" = "myapp-secrets" After a deployment, decryption fails. CloudTrail shows kms:Decrypt was called, but it was denied by the key policy due to the encryption context condition. What is the best fix?

Accepted Answer

Update the application code to supply the correct encryption context "purpose" = "myapp-secrets" when calling decrypt (and encrypt if rotating).. Option A is correct because the decryption failure is directly caused by the application not supplying the required encryption context in the decrypt call. The KMS key policy condition explicitly requires the encryption context to include 'purpose'='myapp-secrets' for kms:Decrypt. Without this context, the request is denied regardless of IAM permissions. Updating the application code to pass the correct encryption context during both encrypt and decrypt operations resolves the issue.

Answer

Add kms:Decrypt to the IAM role attached to the application without changing the key policy.

Answer

Disable the encryption context condition in the KMS key policy to avoid future failures.

Answer

Rotate the KMS key immediately and re-encrypt all secrets with a different key ID.

Question 2

You serve private reports stored in an S3 bucket through CloudFront. After a recent change, users report that they can access the S3 object URLs directly (bypassing CloudFront), which violates your design. You want to ensure S3 objects are readable only through CloudFront using Origin Access Control (OAC), even if someone guesses the S3 URL. Which update best enforces this at the S3 bucket level?

Accepted Answer

Add a bucket policy Allow for s3:GetObject only when the principal is cloudfront.amazonaws.com and aws:SourceArn matches your CloudFront distribution ARN, while blocking public access.. Option A is correct because it uses an S3 bucket policy that grants s3:GetObject access only when the principal is cloudfront.amazonaws.com and the aws:SourceArn matches the CloudFront distribution ARN. This ensures that only CloudFront, using Origin Access Control (OAC), can retrieve objects, blocking direct S3 URL access even if the URL is guessed. Blocking public access at the bucket level further prevents any anonymous or public reads.

Answer

Enable an S3 bucket lifecycle policy to transition objects to Glacier, so public S3 URLs become inaccessible.

Answer

Rely only on CloudFront signed URLs validation; do not change the S3 bucket policy.

Answer

Add a WAF rule on CloudFront to block requests that contain "amazonaws.com" in the URL path.

Question 3

A backend service in AWS uses an IAM role to upload large files to an S3 bucket using multipart upload. The upload typically succeeds, but it intermittently fails during cleanup with this error: "AccessDenied: User is not authorized to perform: s3:AbortMultipartUpload" The role identity policy currently allows only: - s3:PutObject on arn:aws:s3:::my-bucket/uploads/* - s3:ListBucket on arn:aws:s3:::my-bucket with a prefix condition What is the best least-privilege change to fix the cleanup failure?

Accepted Answer

Add s3:AbortMultipartUpload for arn:aws:s3:::my-bucket/uploads/*.. The error occurs because the IAM role lacks permission to abort multipart uploads. Multipart uploads in S3 require s3:AbortMultipartUpload to clean up incomplete upload parts after a failure or interruption. Option A grants this permission on the specific uploads/* prefix, which is the least-privilege fix because it scopes the action to the exact path where the service uploads files.

Answer

Add s3:AbortMultipartUpload for arn:aws:s3:::my-bucket/*.

Answer

Add s3:ListBucket for arn:aws:s3:::my-bucket/uploads/* so the service can find parts to abort.

Answer

Add kms:Decrypt permissions for the KMS key used to encrypt objects in the bucket.

Question 4

Account A hosts a role named AppReadRole. Account B needs to access it using STS AssumeRole. Account A’s role trust policy includes this condition: - StringEquals: { "sts:ExternalId": "b-7f9a" } When Account B runs: aws sts assume-role --role-arn arn:aws:iam::111111111111:role/AppReadRole --role-session-name test the call fails with: "AccessDenied: ExternalId mismatch". What should Account B change?

Accepted Answer

Provide the correct --external-id value (b-7f9a) in the AssumeRole call.. The error 'AccessDenied: ExternalId mismatch' occurs because the trust policy on Account A's role requires an `sts:ExternalId` condition with the value `b-7f9a`, but Account B's `aws sts assume-role` command did not include the `--external-id` parameter. By providing the correct `--external-id b-7f9a` in the call, Account B satisfies the condition, allowing the role assumption to succeed. This is a standard security mechanism to prevent the confused deputy problem.

Answer

Add kms:Decrypt permissions to Account B’s IAM user because trust policy failures are KMS related.

Answer

Remove the ExternalId condition from the trust policy so any caller can assume the role.

Answer

Use AssumeRoleWithSAML instead of AssumeRole so ExternalId is not required.

Question 5

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 6

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 7

A company wants S3 access to be available only from private connectivity. They created an Interface VPC Endpoint for S3 (that provides private connectivity from their VPC to S3) and configured the application to use it from private subnets. The IAM role allows: - s3:GetObject on arn:aws:s3:::confidential-bucket/reports/* However, requests fail with AccessDenied. The S3 bucket policy includes an allow statement that permits GetObject only if: - aws:SourceVpce equals "vpce-0abc12345def6789" After redeploying the VPC endpoint, the application still uses the same IAM permissions but gets AccessDenied. What change is most likely to fix the issue?

Accepted Answer

Update the bucket policy to allow the new VPC endpoint ID (the vpce-* value) created by the redeployment.. Option A is correct because redeploying a VPC Endpoint creates a new endpoint ID (vpce-*). The bucket policy explicitly allows access only if aws:SourceVpce matches the original endpoint ID. Since the new endpoint has a different ID, the condition fails, causing AccessDenied. Updating the bucket policy to reference the new vpce ID restores access.

Answer

Add internet egress via a NAT Gateway so the requests can reach S3 over the public endpoint.

Answer

Remove the aws:SourceVpce condition from the bucket policy to ensure the IAM permissions are sufficient.

Answer

Update the IAM role to add s3:PutObject permissions so the requests can be authorized.

Question 8

A microservice reads a secret from AWS Secrets Manager using its task role (ServiceRole). The secret is configured to use a customer-managed CMK. In production, the service fails with AccessDeniedException on GetSecretValue. CloudTrail shows that Secrets Manager attempted kms:Decrypt but was denied. Which IAM policy change is most appropriate to fix the failure while keeping least privilege?

Accepted Answer

Add kms:Decrypt permission for the specific CMK ARN to ServiceRole, and also keep secretsmanager:GetSecretValue for the specific secret ARN.. The AccessDeniedException occurs because the task role (ServiceRole) lacks the kms:Decrypt permission for the customer-managed CMK used to encrypt the secret. Secrets Manager calls kms:Decrypt on your behalf when retrieving the secret value. Adding kms:Decrypt for the specific CMK ARN to ServiceRole, while retaining secretsmanager:GetSecretValue for the specific secret ARN, grants the minimum required permissions to decrypt and read the secret.

Answer

Add secretsmanager:ListSecrets permission on "*" so the service can discover the secret and retry the read.

Answer

Add s3:GetObject permission to ServiceRole for the KMS key alias stored in an S3 bucket.

Answer

Add kms:Encrypt permission instead of kms:Decrypt, because the service only needs to read the secret.

Question 9

A batch process uploads artifacts to an Amazon S3 bucket using multipart uploads. The bucket policy contains a statement that explicitly denies PutObject and CreateMultipartUpload unless the request uses server-side encryption with AWS KMS (SSE-KMS) and includes these request headers/parameters: x-amz-server-side-encryption=aws:kms and x-amz-server-side-encryption-aws-kms-key-id set to a specific CMK. After the process was updated, uploads intermittently fail with AccessDenied errors. Which change is the best way to make uploads succeed while still meeting the bucket policy's encryption requirement?

Accepted Answer

Update the uploader so the CreateMultipartUpload request includes SSE-KMS with the required CMK key ID; any separate PutObject uploads should include the same headers.. Option B is correct because the bucket policy explicitly denies `PutObject` and `CreateMultipartUpload` unless the request includes both `x-amz-server-side-encryption=aws:kms` and the specific `x-amz-server-side-encryption-aws-kms-key-id` header. The intermittent failures occur because the batch process's `CreateMultipartUpload` request (which initiates the multipart upload) is missing these required headers, causing the explicit Deny to trigger. By ensuring that the `CreateMultipartUpload` request includes SSE-KMS with the correct CMK key ID, and that any subsequent `PutObject` parts also include the same headers, the uploads will satisfy the bucket policy and succeed.

Answer

Update the IAM role policy to add s3:PutObject permissions for the bucket prefix.

Answer

Remove the bucket policy's explicit Deny statement so the IAM permissions control access.

Answer

Switch to client-side encryption (SSE-C) because it also encrypts data at rest in S3.

Question 10

Account A has an IAM role named FinanceDataRole that is assumed by a principal in Account B. The role’s trust policy includes a condition requiring sts:ExternalId to equal "Fin-2026-Q2". A developer in Account B calls AssumeRole but receives an error: AccessDenied: ExternalId mismatch. The security team requires that you do not remove the ExternalId condition. What is the correct remediation?

Accepted Answer

Update the AssumeRole call in Account B to include sts:ExternalId="Fin-2026-Q2" exactly as required.. The error 'AccessDenied: ExternalId mismatch' occurs because the AssumeRole API call from Account B does not include the required sts:ExternalId parameter. The trust policy on the FinanceDataRole explicitly requires this parameter to match 'Fin-2026-Q2' as a security measure to prevent the confused deputy problem. Option B is correct because the developer must pass the exact ExternalId value in the AssumeRole request to satisfy the condition and successfully assume the role.

Answer

Add kms:Decrypt to the developer’s IAM policy so KMS can validate the ExternalId during AssumeRole.

Answer

Increase the role’s MaxSessionDuration to reduce authentication failures.

Answer

Remove the ExternalId condition from the trust policy to allow all AssumeRole requests.

Question 11

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

Question 12

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?

Accepted Answer

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

Answer

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

Answer

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

Answer

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

Question 13

A service reads encrypted data from Amazon S3. The S3 objects use a customer-managed CMK. The IAM role used by the service has kms:Decrypt in its identity policy, but decryption fails with a KMS error stating the role is not authorized to perform kms:CreateGrant. The CMK’s key policy allows kms:Decrypt for the role but does not include kms:CreateGrant. What is the most appropriate change to resolve the failure while preserving least privilege?

Accepted Answer

Add kms:CreateGrant permission to the CMK key policy for the role (scoped to the necessary CMK), keeping other KMS permissions minimal.. The error indicates that the service requires a grant to allow the KMS key to be used in a cryptographic operation that involves a grant-based workflow (e.g., using the S3 bucket key or cross-account access). The IAM role has kms:Decrypt, but the key policy does not grant kms:CreateGrant, which is necessary for the service to create a grant on the CMK. Adding kms:CreateGrant to the key policy scoped to the role resolves the failure while adhering to least privilege by only granting the minimum additional permission needed.

Answer

Enable key rotation because it makes grant creation unnecessary.

Answer

Add kms:DescribeKey to the key policy and remove kms:Decrypt to reduce permissions.

Answer

Update the IAM role to use kms:ScheduleKeyDeletion so future decrypt attempts succeed.

Question 14

A microservice running in ECS retrieves a secret from AWS Secrets Manager. The secret is encrypted with a customer-managed CMK. An administrator re-keyed the secret to a new CMK (the key ARN changed), but kept the same KMS alias name. After re-keying, the service fails with an error from KMS: AccessDenied for kms:Decrypt. The ECS task role’s IAM policy still grants kms:Decrypt but only for the old CMK ARN. What is the best remediation to restore access while maintaining least privilege?

Accepted Answer

Update the ECS task role IAM policy to grant kms:Decrypt on the CMK alias ARN (arn:aws:kms:region:account-id:alias/<alias-name>) or to include the new CMK ARN, so decrypt authorization matches the re-keyed CMK.. Option B is correct because the ECS task role's IAM policy still references the old CMK ARN, but the secret is now encrypted with a new CMK. Since KMS authorization is based on the key ARN (not the alias), the policy must be updated to grant kms:Decrypt on the new CMK ARN or on the alias ARN (which resolves to the current underlying key). This restores access while maintaining least privilege by scoping permissions to the specific key used for decryption.

Answer

Update the IAM policy to allow kms:Decrypt for all CMKs in the account using a wildcard resource (for example, arn:aws:kms:region:account-id:key/*).

Answer

Change the application to decrypt the secret itself using SSE-C keys so Secrets Manager no longer needs KMS.

Answer

Enable KMS key rotation for the old CMK so the CMK ARN resolves to the new key.

Question 15

A static website uses an Amazon S3 bucket as the origin for an Amazon CloudFront distribution. The team accidentally configured the S3 bucket policy to allow s3:GetObject to Principal "*", so objects are accessible via direct S3 URLs. They want to ensure objects are retrievable only through CloudFront. What is the best corrective action?

Accepted Answer

Remove public access from the bucket and update the bucket policy to allow GetObject only from CloudFront using the distribution’s SourceArn (and use CloudFront origin access control or origin access identity).. Option A is correct because the S3 bucket policy currently allows s3:GetObject from any principal, making objects publicly accessible via direct S3 URLs. By removing public access and updating the policy to restrict GetObject to only requests that originate from the CloudFront distribution (using either Origin Access Control or Origin Access Identity), objects become retrievable exclusively through CloudFront, preventing direct S3 access.

Answer

Enable S3 static website hosting and disable CloudFront, because website hosting blocks direct object URL access.

Answer

Add a WAF rule that rate-limits requests to the S3 bucket domain to make direct access impractical.

Answer

Turn on S3 object versioning so that attackers cannot read previous objects.