Amazon AWS SAA-C03 IAM, Federation, Identity Center, and Least-Privilege Access Practice Test 2

 

Topic 01 Practice Test 2 covers IAM, Federation, Identity Center, and Least-Privilege Access for AWS SAA-C03. For broader exam preparation, review the AWS SAA-C03 Exam Dumps. Every option includes focused technical reasoning explaining both the AWS architecture concept and its fit to the scenario.

Question 1

A company manages IAM Identity Center from the AWS Organizations management account. The cloud-security team should administer workforce access for member accounts without routinely signing in to the management account. Which design best reduces management-account use?

1. Register a member account as the delegated administrator for IAM Identity Center
2. Create IAM users for the security team in every member account
3. Move IAM Identity Center into a standalone AWS account outside the organization
4. Grant the security team the root credentials of the management account

Correct Answer(s)

 

A

Rationale

1. IAM Identity Center supports delegated administration to a registered member account. That lets the security team perform most Identity Center administrative work from the delegated account, reducing day-to-day use of the Organizations management account while keeping centralized workforce access.
2. Creating IAM users in every member account multiplies long-lived identities and undermines centralized workforce administration. It also increases credential lifecycle work rather than delegating the existing IAM Identity Center administrative plane to a controlled member account.
3. IAM Identity Center remains integrated with the AWS organization for multi-account access. Moving it outside the organization would not provide the desired centralized account assignments and does not solve the requirement to reduce routine management-account administration.
4. Sharing or granting root credentials violates least-privilege and root-user protection guidance. The security team needs delegated administrative capability, not unrestricted management-account ownership or credentials that bypass normal workforce identity controls. entirely.

 

Question 2

An organization uses an external identity provider with IAM Identity Center. Security requires MFA for workforce sign-in. Where should MFA be enforced for these externally federated users?

1. By enabling MFA on the AWS Organizations management account root user only
2. By adding an MFA requirement to an S3 bucket policy
3. At the external identity provider
4. By creating an IAM virtual MFA device for each permission set

Correct Answer(s)

 

C

Rationale

1. This alternative leaves the principal or session handling unchanged because Protecting root is necessary, but it does not impose MFA on federated workforce sign-ins through an external identity provider. That leaves external IdP unresolved. The required AWS identity semantics are not created by this mechanism.
2. The option cannot express the required authorization relationship because A bucket policy affects access to that S3 resource and is not the authentication control for workforce sign-in to IAM Identity Center. That leaves external IdP unresolved. This cannot substitute for the trust, permission, or federation control the scenario calls for.
3. The control is suitable for this exact context because For an external IdP identity source, authentication and MFA are handled by that IdP; IAM Identity Center relies on the external provider’s authentication result. That directly addresses external IdP. The design remains compatible with centralized federation and role-based access.
4. The result would not be least-privileged because Permission sets define AWS account permissions and session settings; they are not IAM users and cannot own IAM MFA devices. That leaves external IdP unresolved. The design would continue carrying unnecessary risk or administration overhead.

 

Question 3

An enterprise wants its existing AWS Managed Microsoft AD directory to be the workforce identity source for IAM Identity Center so employees can use corporate directory credentials. Which identity-source choice is appropriate?

1. Use AWS KMS aliases to map Active Directory groups
2. Use the AWS Managed Microsoft AD directory as the IAM Identity Center identity source
3. Create one IAM user for each Active Directory user
4. Use an S3 bucket as the identity store

Correct Answer(s)

 

B

Rationale

1. Although plausible, this does not solve the stated identity problem because KMS aliases identify keys; they do not synchronize or authenticate directory users and groups. That leaves AWS Managed Microsoft AD unresolved. A different AWS identity control is needed to govern the principal and the requested action.
2. The intended credential lifecycle is supported because IAM Identity Center can use supported Active Directory through AWS Directory Service, allowing workforce authentication to rely on the existing directory identities. That directly addresses AWS Managed Microsoft AD. The resulting access can be limited, audited, and changed from the intended control plane.
3. The central security requirement remains unsatisfied because IAM users would duplicate corporate identities and create separate AWS credential lifecycle management instead of using the existing directory. That leaves AWS Managed Microsoft AD unresolved. The scenario needs a narrower, identity-aware control to meet the stated objective.
4. This option addresses a different control plane: S3 stores objects and cannot act as the workforce identity source for IAM Identity Center. That leaves AWS Managed Microsoft AD unresolved. The correct design must enforce the requirement through the appropriate IAM identity, policy, or session mechanism.

 

Question 4

An IAM Identity Center group is assigned a permission set to a member account. What does IAM Identity Center create in that account to provide the assigned AWS permissions?

1. A permanent access key for each group member
2. An AWS Organizations service control policy
3. A resource-based policy on every service used by the group
4. An IAM role controlled by IAM Identity Center with the permission-set policies attached

Correct Answer(s)

 

D

Rationale

1. The scenario would remain exposed with this choice because IAM Identity Center provides federated role sessions rather than generating permanent IAM-user access keys for workforce users. That leaves Identity Center group assignment unresolved. Using this would leave either credentials, trust, or effective permissions broader than intended.
2. This is insufficient for the requested access model because SCPs set organization permission guardrails and are not created per Identity Center group assignment to implement a user’s account role. That leaves Identity Center group assignment unresolved. The required least-privilege decision must be made in IAM or the federation path instead.
3. The main limitation is that Identity Center does not rewrite every target resource policy; account access is primarily delivered through the provisioned IAM role. That leaves Identity Center group assignment unresolved. This does not remove the standing risk or provide the requested temporary authorization behavior.
4. The requested least-privilege outcome is met because For AWS account assignments, IAM Identity Center provisions a corresponding IAM role in the target account and manages the policies needed for the permission set. That directly addresses Identity Center group assignment. That gives the requested control while preserving the existing identity model.

 

Question 5

A permission set references a customer managed IAM policy named AppSupport in path /workforce/. Assigning the permission set to a newly created member account fails. The same named policy exists only in the management account. What should be done?

1. Convert the member account into the Organizations management account
2. Create a matching AppSupport customer managed policy with the same name and path in the target member account
3. Add the member account to an S3 bucket ACL
4. Copy the management account root access keys into the member account

Correct Answer(s)

 

B

Rationale

1. The option fails the stated least-privilege constraint because Changing account roles is unrelated to the missing target-account customer managed policy and is neither required nor appropriate. That leaves customer managed policy reference unresolved. This would not reliably prevent the unwanted access pattern described in the prompt.
2. The scenario’s identity model is satisfied because IAM Identity Center references customer managed policies by name and path; the target account must already contain a matching policy for provisioning to succeed. That directly addresses customer managed policy reference. This preserves the least-privilege intent while meeting the operational need.
3. This control cannot satisfy the scenario on its own because S3 ACLs affect object access and cannot satisfy IAM Identity Center’s requirement to find the referenced customer managed policy. That leaves customer managed policy reference unresolved. The design therefore needs the IAM feature that directly controls role, session, or policy evaluation.
4. This does not produce the required IAM behavior because Root credentials do not solve permission-set policy resolution and would introduce a severe credential-security problem. That leaves customer managed policy reference unresolved. The solution needs to narrow the actual AWS authorization path rather than change unrelated infrastructure.

 

Question 6

Human administrators use the AWS CLI from laptops. The company wants them to authenticate through IAM Identity Center and receive automatically refreshed short-term AWS credentials instead of storing access keys in local credential files. Which approach is best?

1. Configure AWS CLI IAM Identity Center authentication and use the resulting SSO sessions
2. Use a VPC endpoint for STS without any identity federation
3. Issue each administrator two IAM-user access keys and rotate them monthly
4. Store a root access key in the shared AWS CLI configuration

Correct Answer(s)

 

A

Rationale

1. For the described workforce or workload path, AWS CLI integration with IAM Identity Center lets users authenticate through the workforce access path and obtain short-term credentials for their assigned account roles. That directly addresses human administrators. This is the supported AWS identity pattern for the described constraint.
2. This alternative is too broad or unrelated because A VPC endpoint changes network reachability to STS but does not authenticate workforce users or replace local long-lived credentials. That leaves human administrators unresolved. The security team would still lack a durable control over the relevant AWS API authorization.
3. This choice would leave the key requirement unresolved because Regular rotation reduces age but still relies on long-lived secrets stored on laptops, which the requested Identity Center design is intended to avoid. That leaves human administrators unresolved. The requested outcome depends on identity context that this option does not supply or evaluate.
4. The access model would still be incorrect because Root access keys are highly privileged long-lived credentials and are inappropriate for routine workforce CLI access. That leaves human administrators unresolved. This would not create the necessary temporary credentials or least-privilege enforcement point.

 

Question 7

A GitHub Actions workflow needs to deploy to one AWS account. The security team refuses to store AWS access keys in repository secrets. GitHub can issue OIDC tokens containing repository and branch claims. Which design is most appropriate?

1. Create an IAM user and encrypt its access key with the repository’s secret store
2. Allow unauthenticated sts:AssumeRole from the internet
3. Attach the deployment policy to the GitHub repository as JSON metadata
4. Configure an IAM OIDC provider and a role whose trust policy restricts the token audience and subject claims

Correct Answer(s)

 

D

Rationale

1. The authorization requirement is not met because Secret storage protects disclosure but the credential remains long-lived and must be rotated; it does not use the available OIDC workload identity. That leaves GitHub Actions unresolved. The correct approach must act on the target identity relationship rather than on a separate service.
2. This would not establish the requested trust or permission boundary because STS still requires an authenticated and authorized principal or supported federation flow; public network reachability is not authorization. That leaves GitHub Actions unresolved. This does not provide the workforce or workload identity behavior the scenario explicitly requires.
3. The operational goal remains unmet because A repository file does not create AWS credentials or an IAM trust relationship, even if the policy document itself is syntactically valid. That leaves GitHub Actions unresolved. The access path would still require a more specific IAM control to become secure and maintainable.
4. The design remains least-privileged because OIDC federation lets the workflow exchange its signed web identity for temporary AWS role credentials, while trust conditions can limit which repository and branch may assume the role. That directly addresses GitHub Actions. This preserves centralized governance while still allowing the required task.

 

Question 8

An EKS cluster uses IAM roles for service accounts. Security wants only service account payments in namespace prod to assume a specific AWS role. Which trust-policy scope is most important?

1. Require the EC2 node private IP address
2. Add the namespace name to an IAM group
3. Restrict the OIDC token subject claim to system:serviceaccount:prod:payments
4. Allow any subject from the cluster’s OIDC issuer

Correct Answer(s)

 

C

Rationale

1. This choice does not enforce the needed condition because IRSA authentication is based on the pod’s OIDC token and service-account identity; node source IP is not the intended workload identity boundary. That leaves EKS IRSA unresolved. The architecture therefore needs a different control at the IAM decision point.
2. The scenario’s security boundary is elsewhere because Kubernetes service accounts are not IAM users and cannot be members of IAM groups. That leaves EKS IRSA unresolved. This fails to satisfy the stated combination of functionality and least privilege.
3. The access path is correctly secured because The OIDC subject identifies the Kubernetes service account, so constraining that claim prevents other namespaces or service accounts from using the role. That directly addresses EKS IRSA. This approach makes the authorization decision explicit and auditable.
4. The design would still depend on an inappropriate credential or control because Trusting the entire issuer without a subject restriction could let unrelated service accounts in the cluster obtain credentials for the sensitive role. That leaves EKS IRSA unresolved. The identity lifecycle or role assumption behavior would remain unresolved after this change.

 

Question 9

A security review finds a policy with an Allow for s3:* on a bucket and a separate explicit Deny for s3:DeleteObject on that bucket under the same applicable context. What is the effective result for DeleteObject?

1. The result is random when two statements conflict
2. DeleteObject is allowed because s3:* is broader
3. DeleteObject is denied because an applicable explicit Deny overrides an Allow
4. DeleteObject is allowed only for role sessions

Correct Answer(s)

 

C

Rationale

1. The result would not be least-privileged because IAM policy evaluation is deterministic; explicit Deny has defined precedence over Allow when both apply. That leaves same resource unresolved. The design would continue carrying unnecessary risk or administration overhead.
2. The proposed control does not govern the relevant request because Statement breadth does not override the policy evaluation rule; an applicable explicit Deny wins over an otherwise matching Allow. That leaves same resource unresolved. This would not centralize or constrain the access model in the manner required.
3. The required account-access behavior is delivered because AWS policy evaluation gives an explicit Deny precedence over applicable Allows, so the delete action remains blocked even though another statement is broad. That directly addresses same resource. The control is directly enforceable by AWS at request or session creation time.
4. This does not align with the requested credential lifecycle because Using temporary credentials does not bypass an applicable explicit Deny in IAM policy evaluation. That leaves same resource unresolved. The option does not govern the principal-to-resource authorization decision described.

 

Question 10

A role has an identity policy allowing EC2, S3, and DynamoDB actions. Its permissions boundary allows only EC2 and S3. There are no other relevant denies. Which service actions can the role receive from these two policy types?

1. EC2, S3, and DynamoDB because the identity policy grants them
2. Only DynamoDB because it is absent from the boundary
3. No actions, because attaching a permissions boundary always denies everything
4. Only the EC2 and S3 actions allowed by both the identity policy and the permissions boundary

Correct Answer(s)

 

D

Rationale

1. The option cannot express the required authorization relationship because The boundary caps maximum permissions, so the DynamoDB grant in the identity policy cannot become effective when the boundary does not allow it. That leaves identity policy EC2/S3/DynamoDB unresolved. This cannot substitute for the trust, permission, or federation control the scenario calls for.
2. This approach would add complexity without solving the IAM requirement because Absence from the boundary prevents the DynamoDB permission rather than granting it. That leaves identity policy EC2/S3/DynamoDB unresolved. The core requirement is enforceable IAM authorization, which remains absent with this choice.
3. The central security requirement remains unsatisfied because A boundary is not an automatic deny-all; actions allowed by both the identity policy and the boundary can be effective when no other policy blocks them. That leaves identity policy EC2/S3/DynamoDB unresolved. The scenario needs a narrower, identity-aware control to meet the stated objective.
4. The security objective is fulfilled at the right layer because For an IAM role with a permissions boundary, effective identity permissions are limited to the intersection of what the identity policy grants and what the boundary permits. That directly addresses identity policy EC2/S3/DynamoDB. This keeps identity authorization separate from unrelated transport or resource settings.

 

Question 11

A platform service needs AWS to create and manage a role whose permissions and trust are predefined for that AWS service, with the role lifecycle tied to the service. Which IAM construct should the architect prefer when the service supports it?

1. A service-linked role
2. A permissions boundary without any role
3. An IAM group containing the service principal
4. An IAM user with console access

Correct Answer(s)

 

A

Rationale

1. This choice fits the stated access boundary because A service-linked role is a service-owned IAM role type with predefined permissions and trust to an AWS service, designed so the service can create or manage required resources. That directly addresses AWS service integration. This addresses the requirement without introducing a broader standing credential.
2. This mechanism is not the required authorization control because A boundary only limits an IAM entity and cannot itself provide credentials or a trust relationship for an AWS service. That leaves AWS service integration unresolved. The scenario needs an enforceable authorization rule, not merely an adjacent operational setting.
3. The scenario would remain exposed with this choice because IAM groups can contain IAM users only; AWS service principals are not group members. That leaves AWS service integration unresolved. Using this would leave either credentials, trust, or effective permissions broader than intended.
4. Although plausible, this does not solve the stated identity problem because A user represents a person or long-lived application identity and is not the AWS-managed role type intended for supported service integrations. That leaves AWS service integration unresolved. A different AWS identity control is needed to govern the principal and the requested action.

 

Question 12

A CloudFormation deployment must create application resources using a tightly controlled permission set even when the engineer starting the stack has broader personal permissions. Which design best separates deployment permissions from the engineer’s identity?

1. Use a security group as the stack permission boundary
2. Use a dedicated CloudFormation service role with least-privilege permissions for stack operations
3. Give the engineer root credentials for the deployment window
4. Attach an IAM user group directly to the CloudFormation stack

Correct Answer(s)

 

B

Rationale

1. This does not produce the required IAM behavior because Security groups regulate network traffic and do not determine which AWS APIs CloudFormation may call during deployment. That leaves CloudFormation deployment unresolved. The solution needs to narrow the actual AWS authorization path rather than change unrelated infrastructure.
2. The security requirement maps directly to this mechanism because CloudFormation can assume a service role to perform stack actions, letting the deployment run with a controlled authorization set rather than inheriting the initiator’s broader permissions. That directly addresses CloudFormation deployment. The result is a narrower and more maintainable authorization path.
3. The main limitation is that Root use maximizes rather than limits authority and creates unnecessary risk for a task that can be delegated through a service role. That leaves CloudFormation deployment unresolved. This does not remove the standing risk or provide the requested temporary authorization behavior.
4. This alternative operates at the wrong layer because Stacks are not IAM users and cannot receive permissions through membership in an IAM group. That leaves CloudFormation deployment unresolved. The stated requirement concerns who may act and under what conditions, which this does not control.

 

Question 13

A developer can launch EC2 instances and is allowed to use iam:PassRole. Security wants to ensure the permission can pass a particular role to EC2 but not to unrelated services. Which additional condition is most appropriate?

1. Use aws:RequestedRegion with the developer’s home Region
2. Use s3:x-amz-server-side-encryption
3. Use aws:MultiFactorAuthAge only on the EC2 security group
4. Use iam:PassedToService with ec2.amazonaws.com

Correct Answer(s)

 

D

Rationale

1. This control cannot satisfy the scenario on its own because Region conditions limit request context but do not identify the service that is allowed to receive the passed role. That leaves developer PassRole unresolved. The design therefore needs the IAM feature that directly controls role, session, or policy evaluation.
2. The proposed mechanism is related but not decisive because That condition key applies to S3 request behavior and has no meaning for IAM PassRole authorization. That leaves developer PassRole unresolved. That mismatch makes it unsuitable even though the service may be useful elsewhere in the architecture.
3. This choice would leave the key requirement unresolved because Security groups cannot evaluate IAM global condition keys or control the PassRole API. That leaves developer PassRole unresolved. The requested outcome depends on identity context that this option does not supply or evaluate.
4. This mechanism matches the operational requirement because The iam:PassedToService condition can constrain PassRole so the approved role may be passed only to the intended AWS service, reducing misuse with other services. That directly addresses developer PassRole. This avoids shifting the problem to an unrelated network or storage control.

 

Question 14

Security wants to know which IAM roles and users have permissions that have not been used within a defined tracking period so the team can review stale access across the account. Which IAM Access Analyzer capability is designed for this?

1. Policy generation only
2. An unused access analyzer
3. Network Access Analyzer
4. An external access analyzer only

Correct Answer(s)

 

B

Rationale

1. The scenario specifically needs an identity control, while Policy generation derives candidate permissions from observed activity; it is different from continuously identifying unused access findings across IAM identities. That leaves stale IAM access unresolved. The scenario’s trust boundary remains unchanged, so the unwanted access would still be possible.
2. The proposed control is aligned with AWS IAM evaluation because Unused access analysis can produce findings for unused roles, unused access keys or passwords, and unused permissions so teams can identify stale access for review. That directly addresses stale IAM access. This gives security an enforceable control rather than a documentation-only convention.
3. The authorization requirement is not met because VPC Network Access Analyzer evaluates network paths and does not report stale IAM role or permission usage. That leaves stale IAM access unresolved. The correct approach must act on the target identity relationship rather than on a separate service.
4. This alternative is too broad or unrelated because External access analysis focuses on resource access outside a defined zone of trust rather than detecting permissions or identities that have gone unused. That leaves stale IAM access unresolved. The security team would still lack a durable control over the relevant AWS API authorization.

 

Question 15

A company wants to apply department attributes from its external identity provider to authorization decisions in AWS accounts managed through IAM Identity Center. Which design supports scalable workforce ABAC?

1. Encode department names in IAM access keys
2. Create a separate permission set for every employee
3. Configure attributes for access control in IAM Identity Center and reference principal tags in IAM policies
4. Use security group tags as the employees’ authentication credentials

Correct Answer(s)

 

C

Rationale

1. The design would still depend on an inappropriate credential or control because Access keys are credentials, not an attribute-distribution mechanism, and embedding organizational data in long-lived keys would not implement ABAC. That leaves external IdP attributes unresolved. The identity lifecycle or role assumption behavior would remain unresolved after this change.
2. The operational goal remains unmet because Per-employee permission sets do not leverage identity attributes and create management overhead that scales poorly as the workforce changes. That leaves external IdP attributes unresolved. The access path would still require a more specific IAM control to become secure and maintainable.
3. The chosen control operates at the correct IAM layer because Identity Center can pass selected workforce attributes into sessions as principal tags, enabling policies to authorize resources according to attributes such as department. That directly addresses external IdP attributes. This is the narrowest control that still satisfies the stated operational requirement.
4. This option changes something other than the required IAM decision because Resource tags can participate in policy conditions, but they are not workforce credentials and cannot replace the identity-source attributes used for the session. That leaves external IdP attributes unresolved. The prompt requires a policy-enforced restriction, which this option cannot provide.

 

Question 16

A role trust policy allows a deployment role to be assumed by a CI principal. The role’s permissions policy allows cloudformation:CreateStack, but the CI principal itself has no sts:AssumeRole permission for that role. What is required?

1. Grant the CI principal identity permission to call sts:AssumeRole on the deployment role
2. Add cloudformation:CreateStack to the trust policy
3. Add the CI principal to an IAM group in the target role
4. Create a security group rule for the STS endpoint

Correct Answer(s)

 

A

Rationale

1. The authorization boundary is preserved because A role trust relationship establishes who the role trusts, while the caller generally also needs authorization to make the AssumeRole request when using an IAM principal. That directly addresses trust already allows caller. The design can be reviewed and maintained as a clear least-privilege rule.
2. The scenario’s security boundary is elsewhere because Trust policies govern role assumption, not the service actions the role session may perform after credentials are issued. That leaves trust already allows caller unresolved. This fails to satisfy the stated combination of functionality and least privilege.
3. This mechanism cannot replace the required role, policy, or federation behavior because Roles are not containers for IAM group membership, and group membership cannot replace the caller’s AssumeRole authorization. That leaves trust already allows caller unresolved. The requested condition must be evaluated during authorization or session issuance, not here.
4. The proposed control does not govern the relevant request because Network reachability does not grant the IAM permission needed to call the AssumeRole API. That leaves trust already allows caller unresolved. This would not centralize or constrain the access model in the manner required.

 

Question 17

A company uses IAM Identity Center with an external IdP. An employee is deleted and later recreated in the IdP with the same display name, but old account assignments no longer work. The recreated user has a new underlying identity identifier. What is the most appropriate remediation?

1. Remove the stale assignment and reassign the recreated user or group so the new identity identifier is referenced
2. Create a root access key for the user
3. Change the VPC DNS resolver settings
4. Rename the IAM Identity Center AWSReservedSSO role in every account

Correct Answer(s)

 

A

Rationale

1. The control is suitable for this exact context because Identity Center assignments reference internal identity identifiers, so deleting and recreating an IdP object can require removing the old assignment and assigning the new object. That directly addresses external IdP. The design remains compatible with centralized federation and role-based access.
2. This alternative leaves the principal or session handling unchanged because Root credentials are unrelated to the IdP synchronization problem and would bypass the intended federated workforce access model. That leaves external IdP unresolved. The required AWS identity semantics are not created by this mechanism.
3. The option cannot express the required authorization relationship because DNS configuration does not update the identity identifier stored in an IAM Identity Center assignment. That leaves external IdP unresolved. This cannot substitute for the trust, permission, or federation control the scenario calls for.
4. The result would not be least-privileged because Those roles are managed by Identity Center; renaming them is not the correct way to update a stale workforce identity reference. That leaves external IdP unresolved. The design would continue carrying unnecessary risk or administration overhead.

 

Question 18

A security engineer writes a resource policy with a Deny and NotPrincipal to exclude most principals, but some intended IAM roles use permissions boundaries. AWS guidance warns this pattern can unexpectedly deny those principals. Which safer policy pattern should the engineer prefer?

1. Convert the affected roles into IAM users
2. Remove every permissions boundary from the roles
3. Use a condition such as ArnNotEquals with aws:PrincipalArn instead of Deny with NotPrincipal
4. Replace the resource policy with a security group

Correct Answer(s)

 

C

Rationale

1. Although plausible, this does not solve the stated identity problem because Changing temporary role access to long-lived user credentials would not solve the policy-design issue and would worsen credential management. That leaves resource policy unresolved. A different AWS identity control is needed to govern the principal and the requested action.
2. The central security requirement remains unsatisfied because Boundaries are valuable permission ceilings; eliminating them merely to preserve a fragile resource-policy pattern weakens delegated-administration controls. That leaves resource policy unresolved. The scenario needs a narrower, identity-aware control to meet the stated objective.
3. The intended credential lifecycle is supported because AWS recommends principal-ARN conditions rather than a Deny with NotPrincipal for IAM principals that use permissions boundaries, avoiding the documented overbroad deny behavior. That directly addresses resource policy. The resulting access can be limited, audited, and changed from the intended control plane.
4. This option addresses a different control plane: Security groups cannot express IAM principal authorization and therefore cannot replace a resource policy’s identity-based access control. That leaves resource policy unresolved. The correct design must enforce the requirement through the appropriate IAM identity, policy, or session mechanism.

 

Question 19

A workforce team needs both read-only and database-admin access in the same AWS account, but users should select the least-privilege role appropriate for each task. How should IAM Identity Center model this?

1. Combine both permission sets into one AdministratorAccess IAM user
2. Create one permission set that always grants the union of both privilege levels
3. Use different VPC route tables to represent the two job functions
4. Assign separate permission sets for the two job functions and grant users only the sets they are eligible to use

Correct Answer(s)

 

D

Rationale

1. The scenario would remain exposed with this choice because Merging privileges into a permanent user removes the least-privilege choice and abandons centralized federated account access. That leaves same AWS account unresolved. Using this would leave either credentials, trust, or effective permissions broader than intended.
2. This is insufficient for the requested access model because A single broad role forces every session to carry database-admin permissions even for read-only tasks, increasing unnecessary privilege. That leaves same AWS account unresolved. The required least-privilege decision must be made in IAM or the federation path instead.
3. The main limitation is that Routing tables control network paths, not the authorization level of a workforce user’s AWS account session. That leaves same AWS account unresolved. This does not remove the standing risk or provide the requested temporary authorization behavior.
4. The requested least-privilege outcome is met because Multiple permission sets can represent distinct role profiles, allowing a user to choose the narrower read-only role when elevated database administration is unnecessary. That directly addresses same AWS account. That gives the requested control while preserving the existing identity model.

 

Question 20

A company is designing federated console access from a SAML-compatible corporate IdP directly to AWS roles. Which two elements are required for AWS to trust the SAML authentication and map users into role sessions? Choose TWO. (Choose 2.)

1. A role trust policy that allows the SAML provider to call sts:AssumeRoleWithSAML
2. A VPC peering connection between the IdP and AWS STS
3. An IAM SAML identity provider created from the corporate IdP metadata
4. An IAM access key embedded in the SAML assertion

Correct Answer(s)

 

A, C

Rationale

1. The access-control objective is achieved because The target role must trust the configured SAML provider for the federation action so validated assertions can be exchanged for temporary role credentials. That directly addresses direct SAML federation. The control therefore acts on the exact decision point described in the prompt.
2. This control cannot satisfy the scenario on its own because SAML trust is established through identity-provider metadata and IAM role trust, not by creating private network peering to STS. That leaves direct SAML federation unresolved. The design therefore needs the IAM feature that directly controls role, session, or policy evaluation.
3. The scenario’s identity model is satisfied because AWS needs the SAML provider configuration and signing metadata so it can validate assertions issued by the corporate identity provider. That directly addresses direct SAML federation. This preserves the least-privilege intent while meeting the operational need.
4. The option fails the stated least-privilege constraint because SAML federation is designed to avoid long-lived AWS keys; the assertion is exchanged for temporary credentials rather than carrying an IAM user’s access key. That leaves direct SAML federation unresolved. This would not reliably prevent the unwanted access pattern described in the prompt.

• < Amazon AWS SAA-C03 IAM, Federation, Identity Center, and Least-Privilege Access Practice Test 1
• Amazon AWS SAA-C03 IAM, Federation, Identity Center, and Least-Privilege Access Practice Test 3 >