Amazon AWS Certified Solutions Architect - Associate SAA-C03 Practice Test 5

Question 40

A software vendor supports two customers with the same assume-role principal. A configuration bug sends the customer A role ARN while processing customer B. The third-party access succeeds because the trust has no customer-specific context. What protection is missing?

A distinct expected ExternalId condition in the customer-owned role trust, verified in the vendor’s AssumeRole request.
Use a single ExternalId value shared across all of the vendor's customers so customer-role calls can be distinguished by that one global ID.
Check only that the vendor principal ARN is trusted, without verifying any customer-specific ExternalId in the request.
A role name with at least 128 random characters as the only access protection.

Explanation

Correct Answer

ExternalId helps the vendor demonstrate which customer relationship an assume-role operation represents, mitigating confused-deputy cross-customer mistakes.

Incorrect Answers

A shared vendor-wide ExternalId does not bind the AssumeRole request to an individual customer relationship and therefore fails the intended cross-customer confused-deputy protection.

A valid trusted vendor principal establishes who can ask to assume the role, but not which customer relationship the request belongs to. The distinct ExternalId is the missing context boundary.

Role names are not secret authorization credentials and do not bind the intended customer context.

Question 41

A company places production and sandbox accounts in the same OU and attaches a strict production SCP. Sandbox deployment testing now fails on actions that should be allowed only for development. What is the structural mistake?

Both environments inherited the same OU-level guardrail instead of having separate OU branches with the intended policies.
Attach an additional permissive SCP to the sandbox account while leaving the inherited production explicit Deny on its parent OU.
Keep the restrictive SCP on the shared OU but add AdministratorAccess to sandbox IAM roles and assume that the new identity policy bypasses the SCP.
CloudFormation templates always ignore SCPs in sandbox accounts.

Explanation

Correct Answer

SCPs apply to affected accounts in the ancestor OU structure; a shared restrictive parent denies sandbox actions as well as production actions.

Incorrect Answers

An Allow attached to a child account cannot override an explicit Deny inherited from an ancestor SCP. The inappropriate Deny must be removed or moved to the intended production branch.

The effective permissions of a member-account role remain subject to ancestor SCP guardrails, even when its identity policy is AdministratorAccess.

Organization policies still apply to covered principals in sandbox member accounts.

Question 42

A developer uses a valid temporary role session but sts:AssumeRole is denied for a sensitive second role because the role trust requires an MFA-related condition. Which cause fits the policy failure?

Assume the role's trust MFA condition automatically evaluates true because the current session still has unexpired STS credentials.
An IAM role always uses password authentication even when using STS temporary credentials.
The actual STS request context did not satisfy the required MFA condition supported by that authentication path.
The condition was automatically satisfied because the IAM policy has AdministratorAccess.

Explanation

Correct Answer

An AWS role trust or identity policy can require MFA context for supported AssumeRole flows; valid credentials alone are not evidence of MFA satisfaction.

Incorrect Answers

Temporary credentials prove that a session was issued, but do not guarantee that its request context contains the MFA attribute required by a separate trust condition.

Temporary role sessions are not human password logins; MFA context depends on the federation and STS path.

High IAM privilege does not override an unmet condition in a role trust policy.

Question 43

An IAM role lists only arn:aws:s3:::reports as the Resource for s3:GetObject. The role can list the bucket but fails when downloading reports/2026.csv. What is the resource-scoping error?

s3:GetObject must authorize object ARNs such as arn:aws:s3:::reports/reports/*; the bucket ARN alone is not an object resource.
Add s3:ListBucket to arn:aws:s3:::reports and assume successful listing implicitly authorizes GetObject with the same bucket ARN.
Add the reports/* prefix to an S3 bucket policy but keep the role identity policy's GetObject resource limited to the bucket ARN alone.
The correct fix is s3:ListAllMyBuckets on * because it covers object content.

Explanation

Correct Answer

S3 ListBucket and GetObject apply to different ARN resource types. A policy that names only the bucket cannot authorize retrieval of objects.

Incorrect Answers

ListBucket uses the bucket ARN and permits listing keys; the object read requires s3:GetObject on object ARNs. The resource-type distinction remains unaddressed.

A bucket policy cannot guarantee this IAM role's effective GetObject access when its identity-based grant names the wrong S3 resource type; object-level ARNs must be considered.

Account bucket enumeration is not the same permission as reading an object.

Question 44

A delegated project administrator can create IAM roles with a required permissions boundary, but can then call DeleteRolePermissionsBoundary and attach AdministratorAccess. Why is the guardrail bypassed?

The delegation allowed removal of the mandatory boundary, so the administrator could create a role whose identity policy no longer intersects the intended maximum.
Permission boundaries automatically block every resource-based policy grant without exceptions.
Require the permissions boundary during CreateRole but continue allowing DeleteRolePermissionsBoundary without a corresponding deny.
Use a role-name condition to require a restricted role prefix while allowing permission-boundary deletion and identity policy expansion.

Explanation

Correct Answer

Enforcement requires restricting which boundary may be attached and denying edits or removals that would remove it; merely asking for a boundary at creation is incomplete.

Incorrect Answers

Some direct resource-based grants have nuanced implicit-deny behavior; this incident is specifically boundary removal.

A creation-time boundary constraint does not maintain a lasting permissions ceiling when an administrator can subsequently remove it and broaden role permissions.

A name convention is useful for administration, but no name prefix enforces maximum IAM permissions after a delegated administrator removes the boundary.

Question 45

An analyst role in a different AWS account has s3:GetObject permission in its IAM policy, yet an owned report bucket does not permit any external principals. Why is the cross-account request denied?

Add the external role ARN to the role's own identity policy Resource field and expect it to create a grant in the bucket owner's separate account.
Enable S3 Block Public Access and assume it independently grants a private external-account role GetObject without a scoped bucket policy.
The resource-owning bucket needs a scoped cross-account resource-policy authorization in addition to the external caller’s effective IAM permission.
Any identity-policy GetObject allow from any AWS account necessarily overrides the target bucket policy.

Explanation

Correct Answer

Cross-account S3 access is evaluated against the bucket-owning side’s resource permissions and the external caller’s identity permissions.

Incorrect Answers

An identity policy in the requester account cannot modify the bucket owner's resource-side authorization. Cross-account S3 access requires compatible effective permissions on both sides.

Blocking anonymous/public access does not issue an affirmative cross-account resource grant for a specific role. The owner must authorize the eligible external principal.

A caller outside the resource account cannot unilaterally grant itself access to another owner’s S3 bucket.

Question 46

A partner AWS account uploads an object to a bucket configured with S3 Object Ownership = Bucket owner enforced. Its old client sends an object ACL other than bucket-owner-full-control and the upload fails. Why?

Switch the bucket to Object writer ownership, while assuming that grants of s3:PutObject automatically cause the destination bucket account to own partner objects.
S3 replication has to be disabled because Object Ownership disallows every cross-account PUT.
Bucket owner enforced disables ACL-based object access and rejects PUT requests that attempt unsupported ACL grants.
Require the partner to send a bucket-owner-full-control canned ACL but leave its client sending a different legacy ACL value without changing the request.

Explanation

Correct Answer

The bucket-owning account manages access through policies under this setting; arbitrary uploader ACLs are not accepted, while uploads without ACLs or allowed owner-full-control may succeed.

Incorrect Answers

Under Object writer mode, uploaded objects generally remain owned by the writer account. This does not match the bucket owner enforced ACL-disabled configuration in the scenario.

Cross-account uploads are supported with appropriate policies; the incompatible ACL header is the issue.

When ACLs are disabled the bucket only accepts uploads with no ACL or the supported bucket-owner-full-control canned ACL. An unchanged incompatible ACL header continues to be rejected.

Question 47

IAM Access Analyzer reports no external S3 access, yet an engineer suspects a new bucket policy changed since the last check. The analyzer is scoped to the wrong zone of trust. What explains the misleading finding set?

An external-access analyzer evaluates policy exposure relative to its configured zone of trust; using the wrong account or organization scope can misclassify what counts as external.
Access Analyzer only inventories EC2 instance types and ignores all S3 policies.
Inspect only the bucket's public-access-block flags and treat an enabled block as proof that no external AWS account has any resource-policy access.
A bucket must be public before any external account authorization can generate findings.

Explanation

Correct Answer

Analyzer findings depend on the selected trust boundary and supported resource-policy reasoning; investigate that scope as well as recent resource changes.

Incorrect Answers

External-access analyzers support S3 resource-policy analysis.

Block Public Access is not a complete zone-of-trust analysis. Specific nonpublic external principals can still be exposed through supported resource policies that an analyzer evaluates.

External access includes selected other AWS accounts even without anonymous public access.

Question 48

A team generates an IAM least-privilege policy from a short CloudTrail review window. The resulting policy breaks a rarely used quarterly operation. What limitation explains the failure?

Policy generation automatically blocks IAM condition keys on every role.
Observed CloudTrail activity did not include the infrequent API action; generated policies must be reviewed against all required workload operations and tested.
Increase CloudTrail retention going forward, but treat the same short historical review period as proof of quarterly permissions not observed in that period.
Least-privilege analysis always captures future service actions even without evidence.

Explanation

Correct Answer

Access Analyzer policy generation is evidence-based and cannot infer business-required operations never recorded in the chosen observation period.

Incorrect Answers

The root issue is absent historical action evidence, not a universal ban on IAM conditions.

Longer future retention cannot retroactively add unlogged past usage to a completed policy-generation window. Rare business operations must be identified and tested separately.

An activity-derived policy is a starting point, not proof of future coverage.

Question 49

An IAM role has no identity-based s3:GetObject Allow, and its permissions boundary does not allow s3:GetObject. The S3 bucket policy grants GetObject directly to the IAM ROLE ARN (not the assumed-role session ARN), with no explicit Deny. Why is the role unable to use that resource-policy grant?

S3 evaluates only the last saved policy, so the bucket Allow is ignored until the role policy is edited more recently.
All S3 bucket policy Allows automatically override permissions boundaries for role ARNs, so this is a DNS problem.
A resource-based grant to a role ARN remains constrained by the role's permissions boundary; the relevant action is not allowed within that maximum.
The role must be replaced with a shared account-root access key because roles can never receive cross-account S3 bucket policy permissions.

Explanation

Correct Answer

A role permissions boundary limits the role-ARN principal's effective permissions when a resource policy grants to that role ARN. Because s3:GetObject is absent from the boundary, the resource-policy grant cannot be used despite no explicit Deny.

Incorrect Answers

IAM evaluation does not use timestamps as policy precedence. The problem arises from the permissions-boundary ceiling on the role-ARN recipient, not from update ordering.

The grant is to the IAM role principal ARN. IAM explicitly distinguishes this from directly granting to an assumed-role session principal; the role-ARN grant still intersects the role permissions boundary.

IAM roles can receive scoped resource-policy permissions. Root access keys are unnecessary and would be an insecure workaround for a permissions-boundary configuration issue.

Question 50

A developer configured an AWS CLI profile that automatically assumes a role and refreshes credentials. The next day, commands still fail with ExpiredToken because old AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN environment variables remain set in the shell. Which change fixes the precedence mistake?

Increase the role MaxSessionDuration while retaining the same expired environment variables, expecting the CLI to reinterpret their existing token expiry.
Clear the stale explicit AWS credential environment variables and invoke the intended refreshing CLI role profile so the configured provider can obtain fresh credentials.
Add s3:* to the expired STS token and assume a broader policy extends the validity of previously issued credentials.
Create another S3 bucket named after the role so the CLI automatically ignores expired environment credentials when accessing that name.

Explanation

Correct Answer

The AWS CLI credential resolution order gives explicit environment variables precedence over many profile credentials. Removing the stale variables lets the intended role profile obtain and refresh temporary STS sessions as configured.

Incorrect Answers

Role MaxSessionDuration governs newly issued role sessions, not already expired environment credentials. The CLI can still select the stale higher-precedence variables instead of its configured refreshing provider.

The access policy and an STS session expiration are separate concerns. Broadening access does not renew a session token that the CLI continues to read from its environment.

A bucket name has no effect on the credential provider chain. The shell environment credentials must be cleared or replaced so the intended profile takes precedence.

Pass Your Amazon AWS Certified Solutions Architect - Associate SAA-C03 Exam Easy!

Question 40

Explanation

Correct Answer

Incorrect Answers

Question 41

Explanation

Correct Answer

Incorrect Answers

Question 42

Explanation

Correct Answer

Incorrect Answers

Question 43

Explanation

Correct Answer

Incorrect Answers

Question 44

Explanation

Correct Answer

Incorrect Answers

Question 45

Explanation

Correct Answer

Incorrect Answers

Question 46

Explanation

Correct Answer

Incorrect Answers

Question 47

Explanation

Correct Answer

Incorrect Answers

Question 48

Explanation

Correct Answer

Incorrect Answers

Question 49

Explanation

Correct Answer

Incorrect Answers

Question 50

Explanation

Correct Answer

Incorrect Answers

AWS Certified Solutions Architect - Associate SAA-C03 Practice Tests