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

Question 1

A company manages 42 AWS accounts and authenticates employees in an existing corporate identity provider. It wants central assignment of job-scoped access without issuing separate IAM user passwords in each account. Which design best meets the requirement?

Attach a permissive SCP to the organization root and treat it as a workforce login service.
Share each account root user with a central password manager for all employee tasks.
Federate the workforce through AWS IAM Identity Center and assign appropriate permission sets to users or groups for the target accounts.
Create an IAM user with a long-lived access key in every account for each employee.

Explanation

Correct Answer

IAM Identity Center centralizes workforce access, uses federated sign-in and provisions account roles based on the assigned permission sets; it avoids per-account IAM user credentials.

Incorrect Answers

SCPs set permission guardrails but neither authenticate employees nor issue access assignments.

Root identities have excessive account-wide permissions and should not be the normal multi-account workforce sign-in route.

Replicated IAM identities and static keys multiply credential lifecycle and leakage exposure; the company already has an identity provider for federation.

Question 2

An analyst in account A must read one report bucket in account B temporarily without creating a permanent analyst identity in account B. Which architecture is most suitable?

Copy every report into account A and remove the resource-account role requirement.
Create a role in account B that trusts the authorized account A principal, grant that role the required bucket read permissions, and allow the analyst to assume it.
Add a source IP to the bucket DNS record and rely on DNS to authorize the analyst.
Give the analyst account B root access keys and rotate them monthly.

Explanation

Correct Answer

Cross-account IAM role assumption provides temporary credentials under a role owned by the resource account; trust and permissions govern who can assume it and what it can read.

Incorrect Answers

Replication creates redundant data and governance risks; role delegation can grant the required access without moving the source.

DNS does not evaluate AWS principal identity or grant S3 object-read authorization.

Root access keys grant far more permission than one bucket read and create a persistent cross-account secret.

Question 3

A target-account role trusts an IAM role in a source account. The source principal has no identity-based permission to call sts:AssumeRole on the target role, and its AssumeRole request is denied. What must be evaluated first?

Grant the source principal authorized sts:AssumeRole permission for the target role while retaining the target trust and permission checks.
Add s3:ListBucket to the target role and assume it can then be assumed.
Create an EC2 instance profile in the target account for the human analyst.
Attach a permissions boundary that lists sts:AssumeRole on the source role, but leave the source role identity policy without a corresponding Allow.

Explanation

Correct Answer

The caller requires an effective path to AssumeRole; the target role trust and the caller-side IAM authorization must be evaluated together for this delegated flow.

Incorrect Answers

The target role's S3 permissions apply after the role is assumed; they do not fix a caller that cannot invoke sts:AssumeRole.

An instance profile attaches roles to EC2 instances; it does not supply the missing delegated role-assumption permission.

An IAM permissions boundary constrains identity policy permissions rather than granting them. An STS action listed only in the boundary cannot supply the missing source-principal Allow for a cross-account assumption.

Question 4

An IAM role in a member account has AdministratorAccess but cannot create an EC2 instance in a designated prohibited Region. An inherited AWS Organizations SCP explicitly denies ec2:RunInstances in that Region. Which explanation is correct?

AdministratorAccess overrides SCPs after the role is assumed.
The SCP is an organization-level permissions boundary, so its explicit deny prevents the action even though the IAM policy allows it.
Region restrictions apply only to AWS Management Console and not to API calls.
SCPs grant permissions and the role only needs a matching allow inside the SCP.

Explanation

Correct Answer

Effective member-account permissions must satisfy organization guardrails as well as applicable IAM policies; an explicit SCP deny prevails.

Incorrect Answers

An administrator IAM policy cannot bypass an attached organization SCP deny for a member-account principal.

SCP conditions and denies apply to evaluated AWS API requests regardless of whether the request originated in a console or SDK.

SCPs define maximum permitted operations and never independently grant the IAM action; an explicit deny remains prohibitive.

Question 5

An organization uses an SCP allowlist for a regulated OU. An application role has an IAM allow for a newly approved AWS service, but calls are rejected because no applicable SCP allows that service. What is the proper authorization fix?

Attach a new SCP that grants the application role the action by itself.
Supply an STS role session policy permitting the newly approved service while leaving the Organizations SCP allowlist unchanged.
Have an authorized Organizations administrator update the applicable SCP guardrail to permit the reviewed service, while preserving role-level least-privilege grants.
Replace the application role policy with AdministratorAccess to override the OU policy.

Explanation

Correct Answer

With an allowlist strategy, the service must be within the permitted organization maximum and separately granted by IAM; only changing the role policy cannot cross the SCP boundary.

Incorrect Answers

An SCP can increase the maximum allowed set but does not directly grant identity permissions; the underlying IAM grant remains required.

A session policy can narrow effective session permissions but cannot elevate the role beyond the applicable SCP allowlist. The organization-level maximum must be adjusted by authorized administrators.

A broader identity policy does not overcome an SCP permission ceiling.

Question 6

A finance operator only needs monthly billing visibility and a limited set of cost-management tasks. The organization proposes daily use of the AWS account root login. Which design is safer?

Create root access keys for the finance operator so use can be audited.
Give all finance employees the root password but require a shared hardware MFA token.
Create one shared IAM user with PowerUserAccess for the finance department and distribute its console password instead of delegating named billing roles.
Secure root credentials for rare root-only operations and delegate ordinary finance tasks through a scoped IAM Identity Center role or other approved non-root identity.

Explanation

Correct Answer

Root has unrestricted account authority and should be reserved for actions that require it; delegated workforce access can meet regular billing needs without exposing root.

Incorrect Answers

Root access keys are exceptionally privileged long-lived credentials, not a least-privilege billing solution.

Sharing root eliminates individual accountability and retains needless privilege even if MFA is present.

A broadly privileged shared user can expose unrelated resources and obscures which finance operator performed an action. Individual scoped workforce roles provide attribution and least privilege.

Question 7

A Python service on Amazon EC2 needs GetObject access to one S3 bucket. The deployment policy forbids storing an IAM user access key in instance configuration. How should it authenticate?

Store IAM user keys in an environment file baked into the AMI.
Attach a least-privilege IAM role through the EC2 instance profile and use the AWS SDK credential provider for temporary credentials.
Allow the instance security group to access TCP/443 and assume S3 authorizes object reads.
Embed root access keys in the EC2 user data and hide the script after boot.

Explanation

Correct Answer

EC2 roles deliver renewable temporary credentials to workloads without packaging long-lived keys in the application or image.

Incorrect Answers

An AMI carries reusable static secrets into every derived instance, unlike role-delivered temporary credentials.

Network egress permission does not establish the IAM identity permission required by the S3 API.

User data can expose privileged credentials and root keys violate the long-lived-secret prohibition.

Question 8

Employees can now authenticate successfully through a corporate SAML identity provider connected to AWS IAM Identity Center. They still see no assigned AWS account in the access portal, though the target account is part of the organization. Which next authorization configuration is missing?

Change the corporate IdP SAML assertion claims but leave IAM Identity Center account assignments empty.
Update the IAM Identity Center permission set description and policy only, without assigning it to this user or group in the target account.
Assign the right user/group to the target AWS account and permission set in IAM Identity Center, then verify the account assignment is provisioned.
Configure a standalone SAML-trusted IAM role outside Identity Center and assume it must appear automatically as an Identity Center portal tile.

Explanation

Correct Answer

SAML establishes authentication; IAM Identity Center account assignments bind a user or group to a permission set and the relevant member account. Successful sign-in alone grants no account role.

Incorrect Answers

Valid SAML assertions prove authentication and convey identity attributes, but they do not create an Identity Center user/group-to-account assignment that the portal can display.

A permission set defines an access package, but editing it does not give a specific employee access to a specific member account until the correct account assignment is made.

Direct federation to a separate IAM role can be useful in another design; it does not automatically provision an AWS account assignment within the IAM Identity Center portal.

Question 9

A GitHub Actions workflow deploys infrastructure to AWS. The security team prohibits long-lived AWS access keys in repository secrets and wants role assumption restricted to one repository and branch. What should be used?

Trust all GitHub-issued OIDC identities with an unrestricted subject condition, assuming that a valid GitHub token necessarily came from the approved repository and branch.
Create an IAM OIDC identity provider and role trust conditions for the intended GitHub repository and branch, then assume the role with a web-identity token.
Give the workflow account root access keys encrypted as GitHub repository secrets.
Rely on repository name in the IAM role description without trust-policy conditions.

Explanation

Correct Answer

OIDC federation lets the workflow exchange a scoped identity assertion for temporary STS credentials without storing IAM user keys in the repository.

Incorrect Answers

A valid GitHub OIDC token does not alone prove the specific repository or branch. Without an exact subject/audience trust restriction, workflows outside the intended branch could attempt to obtain AWS credentials.

Encryption of a repository secret does not eliminate persistent root credentials or restrict branch-based role assumption.

A description does not enforce issuer/audience/subject constraints on token-based role assumption.

Question 10

A multi-tenant monitoring vendor assumes customer-owned roles to audit usage. The customer needs to prevent the vendor from using another tenant's known role ARN under the wrong customer context. Select TWO controls that establish this third-party role-assumption boundary.

Create static IAM access keys for the customer root account and share them with the vendor.
Limit the customer role trust policy to the vendor's designated AWS principal.
Make the customer role assumable by all AWS principals and rely on a hard-to-guess role name.
Require a customer-specific ExternalId condition in the trust policy and have the vendor present it on AssumeRole.
Use the vendor's CloudWatch alarm name as the sole authorization check.

Explanation

Correct Answer

The trusted principal restricts which AWS identity can request the role; role names alone are not sufficient caller authentication.

The ExternalId binds a third-party AssumeRole operation to the intended customer context and mitigates the confused-deputy problem.

Incorrect Answers

Root static keys introduce excessive persistent authority and bypass the intended customer-scoped delegated role.

An ARN is not an authorization secret; open trust would allow unintended principals to try role assumption.

A monitoring alarm is not an STS trust condition and cannot distinguish customer context for role assumption.

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

Question 1

Explanation

Correct Answer

Incorrect Answers

Question 2

Explanation

Correct Answer

Incorrect Answers

Question 3

Explanation

Correct Answer

Incorrect Answers

Question 4

Explanation

Correct Answer

Incorrect Answers

Question 5

Explanation

Correct Answer

Incorrect Answers

Question 6

Explanation

Correct Answer

Incorrect Answers

Question 7

Explanation

Correct Answer

Incorrect Answers

Question 8

Explanation

Correct Answer

Incorrect Answers

Question 9

Explanation

Correct Answer

Incorrect Answers

Question 10

Explanation

Correct Answer

Incorrect Answers

AWS Certified Solutions Architect - Associate SAA-C03 Practice Tests