Topic 01 Practice Test 3 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
An EC2 administrator needs shell access to private instances for troubleshooting, but the security team wants to eliminate inbound SSH rules and shared private keys. Which access design best aligns with IAM-based least privilege?
- Use AWS Systems Manager Session Manager with IAM-authorized operator access
- Create an IAM user on each EC2 instance
- Attach AdministratorAccess to the EC2 instance profile
- Open TCP 22 from 0.0.0.0/0 and rotate one shared SSH key weekly
Correct Answer(s)
A
Rationale
- For the described workforce or workload path, Session Manager can broker interactive access through Systems Manager while IAM policies control who may start sessions, removing the need for inbound SSH exposure and shared host keys. That directly addresses private EC2. This is the supported AWS identity pattern for the described constraint.
- The access model would still be incorrect because IAM users are AWS identities rather than operating-system accounts and do not directly provide host shell access inside an EC2 instance. That leaves private EC2 unresolved. This would not create the necessary temporary credentials or least-privilege enforcement point.
- This alternative is too broad or unrelated because The instance profile controls what the instance can call in AWS; it does not authenticate human operators to the operating system and would add excessive workload permissions. That leaves private EC2 unresolved. The security team would still lack a durable control over the relevant AWS API authorization.
- This choice would leave the key requirement unresolved because Frequent key rotation does not offset the risk of broad inbound exposure or shared credentials, and it does not provide IAM-controlled session authorization. That leaves private EC2 unresolved. The requested outcome depends on identity context that this option does not supply or evaluate.
Question 2
A Lambda function is invoked by EventBridge and needs read access to one Secrets Manager secret. Which two IAM relationships are distinct and both necessary? Choose TWO. (Choose 2.)
- An IAM group containing the Lambda function
- A resource policy or service integration permission that allows EventBridge to invoke the Lambda function
- A root access key stored in the function environment
- A Lambda execution role policy that permits secretsmanager:GetSecretValue on the specific secret
Correct Answer(s)
B, D
Rationale
- This would not establish the requested trust or permission boundary because IAM groups contain users, not Lambda functions, and therefore cannot supply runtime permissions or invocation trust. That leaves EventBridge invokes Lambda unresolved. This does not provide the workforce or workload identity behavior the scenario explicitly requires.
- The design remains least-privileged because Invocation authorization determines whether the event source may call the Lambda function and is separate from what the function can do after it starts. That directly addresses EventBridge invokes Lambda. This preserves centralized governance while still allowing the required task.
- The operational goal remains unmet because Root credentials are unnecessary, long-lived, and far broader than the two narrow authorization relationships required. That leaves EventBridge invokes Lambda unresolved. The access path would still require a more specific IAM control to become secure and maintainable.
- The requirement is specifically addressed because The execution role supplies the function’s AWS API permissions, so it must authorize the secret read independently of the function’s invocation permission. That directly addresses EventBridge invokes Lambda. The requested behavior follows from this IAM mechanism rather than from infrastructure placement.
Question 3
A web application running on EC2 needs temporary database authentication to an RDS MySQL database without storing a database password. The database engine and configuration support IAM database authentication. Which design is best?
- Store the master database password in EC2 user data
- Use the EC2 workload role to generate short-lived RDS IAM authentication tokens and authorize the database user for IAM authentication
- Create an IAM user access key and use it directly as the MySQL password
- Grant the EC2 security group AdministratorAccess
Correct Answer(s)
B
Rationale
- The design would still depend on an inappropriate credential or control because User data is not an authentication service and can expose a persistent high-value secret; it also uses broader credentials than a scoped database user. That leaves EC2 application unresolved. The identity lifecycle or role assumption behavior would remain unresolved after this change.
- The access path is correctly secured because IAM database authentication can use temporary signed tokens derived from the workload’s AWS credentials, reducing reliance on a stored database password for supported engines. That directly addresses EC2 application. This approach makes the authorization decision explicit and auditable.
- This choice does not enforce the needed condition because AWS access keys are not static database passwords; IAM database authentication uses generated tokens rather than placing the key material into the database password field. That leaves EC2 application unresolved. The architecture therefore needs a different control at the IAM decision point.
- The scenario’s security boundary is elsewhere because Security groups are network controls and cannot grant AWS IAM or database-user permissions. That leaves EC2 application unresolved. This fails to satisfy the stated combination of functionality and least privilege.
Question 4
A security team wants to trace which original workforce user initiated actions after assuming a shared operational role, even when CloudTrail records the role session rather than a permanent IAM user. Which STS feature can improve attribution when enforced through role assumption?
- Disable CloudTrail management events
- Create a shared IAM user for the operations team
- Reuse the same role session name for every administrator
- Require and record a source identity for the role session
Correct Answer(s)
D
Rationale
- This does not align with the requested credential lifecycle because Removing management-event logging would eliminate evidence needed to investigate role activity and would not add any session attribution. That leaves shared operations role unresolved. The option does not govern the principal-to-resource authorization decision described.
- The result would not be least-privileged because A shared long-lived identity hides the individual actor and works against the requested per-user audit trail. That leaves shared operations role unresolved. The design would continue carrying unnecessary risk or administration overhead.
- The proposed control does not govern the relevant request because A shared session name reduces rather than improves attribution because multiple users would appear under the same chosen identifier. That leaves shared operations role unresolved. This would not centralize or constrain the access model in the manner required.
- The required account-access behavior is delivered because STS source identity lets an administrator require a stable identifier when a role is assumed, and AWS can carry that value into role-session context for audit attribution. That directly addresses shared operations role. The control is directly enforceable by AWS at request or session creation time.
Question 5
An application assumes RoleA and then RoleB. Security wants a Project tag attached to the first role session to remain available for ABAC decisions after the second role assumption. What should the first session do?
- Create an IAM access key named Project
- Mark the Project session tag as transitive when assuming the role
- Store Project only in the RoleA description field
- Add Project to an EC2 security-group description
Correct Answer(s)
B
Rationale
- The central security requirement remains unsatisfied because Access keys have identifiers but do not encode reusable ABAC session attributes. That leaves RoleA then RoleB unresolved. The scenario needs a narrower, identity-aware control to meet the stated objective.
- The security objective is fulfilled at the right layer because Transitive session tags can be carried forward during supported role chaining, allowing the downstream role session to retain the attribute used by ABAC policies. That directly addresses RoleA then RoleB. This keeps identity authorization separate from unrelated transport or resource settings.
- The option cannot express the required authorization relationship because Role descriptions are administrative metadata and are not propagated as principal tags into a downstream STS session. That leaves RoleA then RoleB unresolved. This cannot substitute for the trust, permission, or federation control the scenario calls for.
- This approach would add complexity without solving the IAM requirement because Security-group metadata has no relationship to STS session attributes and cannot participate as the caller’s principal tag. That leaves RoleA then RoleB unresolved. The core requirement is enforceable IAM authorization, which remains absent with this choice.
Question 6
A company wants developers to create roles for Lambda functions but only if every new role includes the company’s approved permissions boundary. Which delegated-administration policy technique best enforces the requirement at role creation?
- Allow iam:CreateRole only when the request specifies the approved permissions boundary ARN
- Rely on a naming convention such as Lambda-* without any policy condition
- Require developers to use the root user when creating roles
- Put the Lambda functions in a private subnet
Correct Answer(s)
A
Rationale
- This choice fits the stated access boundary because IAM condition keys for permissions boundaries can make delegated role creation conditional on attaching the required boundary, preventing unbounded roles from being created through that path. That directly addresses developers create Lambda roles. This addresses the requirement without introducing a broader standing credential.
- Although plausible, this does not solve the stated identity problem because Names improve organization but do not impose an authorization ceiling or prevent a developer from creating a broadly privileged role. That leaves developers create Lambda roles unresolved. A different AWS identity control is needed to govern the principal and the requested action.
- This mechanism is not the required authorization control because Root is unrestricted and would bypass the delegated least-privilege model rather than enforce the required boundary. That leaves developers create Lambda roles unresolved. The scenario needs an enforceable authorization rule, not merely an adjacent operational setting.
- The scenario would remain exposed with this choice because Network placement does not determine whether a newly created IAM role has a permissions boundary. That leaves developers create Lambda roles unresolved. Using this would leave either credentials, trust, or effective permissions broader than intended.
Question 7
A team is testing a policy that should permit read access to one S3 prefix but deny writes. They want to evaluate how IAM would decide representative API requests before attaching the policy to a production role. Which tool is most suitable?
- AWS Trusted Advisor
- VPC Reachability Analyzer
- Amazon Inspector
- IAM policy simulator
Correct Answer(s)
D
Rationale
- This alternative operates at the wrong layer because Trusted Advisor provides checks and recommendations but is not an interactive IAM policy evaluation simulator for proposed request contexts. That leaves proposed IAM policy unresolved. The stated requirement concerns who may act and under what conditions, which this does not control.
- This does not produce the required IAM behavior because Reachability Analyzer models network connectivity paths and cannot determine whether an IAM policy allows s3:GetObject or denies s3:PutObject. That leaves proposed IAM policy unresolved. The solution needs to narrow the actual AWS authorization path rather than change unrelated infrastructure.
- The main limitation is that Inspector assesses supported workloads for vulnerabilities and exposure; it does not simulate IAM authorization decisions for arbitrary API actions. That leaves proposed IAM policy unresolved. This does not remove the standing risk or provide the requested temporary authorization behavior.
- The security requirement maps directly to this mechanism because The IAM policy simulator can evaluate selected actions and resources against policy logic to help verify expected allow or deny outcomes before changing a production identity. That directly addresses proposed IAM policy. The result is a narrower and more maintainable authorization path.
Question 8
An operations team uses IAM Identity Center. A permission set was updated to remove a powerful policy, but an engineer already has an active AWS account session that was created earlier. What design principle should the team consider for high-risk access?
- Increase the permission set session duration to twelve hours
- Create permanent IAM-user keys in addition to the Identity Center session
- Use short permission-set session durations so elevated sessions expire and must be reissued under current permissions
- Disable CloudTrail until the old session expires
Correct Answer(s)
C
Rationale
- This choice would leave the key requirement unresolved because A longer duration increases the window in which an already issued privileged session can remain usable. That leaves permission set privilege removed unresolved. The requested outcome depends on identity context that this option does not supply or evaluate.
- This control cannot satisfy the scenario on its own because Long-lived credentials would extend exposure and bypass the centralized session lifecycle that the organization is trying to control. That leaves permission set privilege removed unresolved. The design therefore needs the IAM feature that directly controls role, session, or policy evaluation.
- This mechanism matches the operational requirement because Shorter session lifetimes reduce how long previously issued temporary credentials remain usable after access changes, which is valuable for elevated roles. That directly addresses permission set privilege removed. This avoids shifting the problem to an unrelated network or storage control.
- The proposed mechanism is related but not decisive because Turning off audit logging provides no revocation benefit and removes evidence of how the active session is being used. That leaves permission set privilege removed unresolved. That mismatch makes it unsuitable even though the service may be useful elsewhere in the architecture.
Question 9
A security team is building an IAM policy for support engineers. Engineers should terminate only EC2 instances tagged Environment=Dev, while instances without that tag or tagged Production must be protected. Which design is most direct?
- Allow ec2:TerminateInstances on * and document that Production is off limits
- Put Production instances in a different Availability Zone
- Allow ec2:TerminateInstances only when the target resource has the required Environment=Dev tag
- Use a CloudWatch alarm named DoNotTerminate
Correct Answer(s)
C
Rationale
- This alternative is too broad or unrelated because Documentation does not enforce the intended security boundary, so a mistake or compromised credential could still terminate protected instances. That leaves support engineers unresolved. The security team would still lack a durable control over the relevant AWS API authorization.
- The scenario specifically needs an identity control, while Availability Zones are fault-isolation locations and do not restrict IAM authorization for EC2 API calls. That leaves support engineers unresolved. The scenario’s trust boundary remains unchanged, so the unwanted access would still be possible.
- The proposed control is aligned with AWS IAM evaluation because A resource-tag condition can make the terminate permission depend on the instance’s classification, directly aligning the API authorization with the environment boundary. That directly addresses support engineers. This gives security an enforceable control rather than a documentation-only convention.
- The authorization requirement is not met because Alarm names are monitoring metadata and cannot deny an EC2 termination request. That leaves support engineers unresolved. The correct approach must act on the target identity relationship rather than on a separate service.
Question 10
A data-science role should be allowed to create SageMaker training jobs only when the request includes an approved CostCenter tag so downstream governance can identify ownership. Which IAM technique best enforces this at request time?
- Use a Network ACL named CostCenter
- Create a second AWS account access key for tagging
- Add the CostCenter value to the role description
- Use a policy condition on the request tag and require the CostCenter tag key
Correct Answer(s)
D
Rationale
- This option changes something other than the required IAM decision because Network ACLs filter subnet traffic and have no mechanism for validating resource-creation tags in an AWS API request. That leaves SageMaker job creation unresolved. The prompt requires a policy-enforced restriction, which this option cannot provide.
- The design would still depend on an inappropriate credential or control because Additional credentials do not enforce that the original create request contains the required governance tag. That leaves SageMaker job creation unresolved. The identity lifecycle or role assumption behavior would remain unresolved after this change.
- The operational goal remains unmet because A role description is static metadata and does not require the API request to tag each newly created training job. That leaves SageMaker job creation unresolved. The access path would still require a more specific IAM control to become secure and maintainable.
- The chosen control operates at the correct IAM layer because Request-tag and tag-key condition keys can make API authorization contingent on supplying the required attribute when the resource is created. That directly addresses SageMaker job creation. This is the narrowest control that still satisfies the stated operational requirement.
Question 11
A company uses IAM Identity Center with group-based assignments. A contractor should receive access for a short project and then lose all account assignments when removed from the contractor group in the identity source. Which operational model best supports this?
- Assign the contractor group to permission sets and manage membership in the authoritative identity source
- Create an S3 ACL entry for the contractor group name
- Create the contractor as a local IAM user in every account
- Share one IAM role password among all contractors
Correct Answer(s)
A
Rationale
- The authorization boundary is preserved because Group-based assignments centralize entitlement management, so changing authoritative group membership can remove future access without editing separate per-account IAM users. That directly addresses contractor project. The design can be reviewed and maintained as a clear least-privilege rule.
- The proposed control does not govern the relevant request because S3 ACLs cannot consume workforce group membership from IAM Identity Center as a general AWS account-access mechanism. That leaves contractor project unresolved. This would not centralize or constrain the access model in the manner required.
- The scenario’s security boundary is elsewhere because Per-account users create independent credential and deprovisioning work and can remain active after the corporate group membership is removed. That leaves contractor project unresolved. This fails to satisfy the stated combination of functionality and least privilege.
- This mechanism cannot replace the required role, policy, or federation behavior because IAM roles do not have reusable passwords, and shared credentials would prevent individual lifecycle control and accountability. That leaves contractor project unresolved. The requested condition must be evaluated during authorization or session issuance, not here.
Question 12
A security architect wants an IAM role that an AWS service can assume. The role’s permissions policy is correct, but the service receives an access-denied error when trying to assume it. Which policy should be checked first for the missing service principal?
- The role’s permissions boundary
- The role’s trust policy
- An S3 bucket lifecycle policy
- The account’s default VPC route table
Correct Answer(s)
B
Rationale
- The result would not be least-privileged because A boundary limits actions after credentials exist and does not itself identify which service principal may assume the role. That leaves AWS service must assume role unresolved. The design would continue carrying unnecessary risk or administration overhead.
- The control is suitable for this exact context because The trust policy specifies which principals, including AWS service principals, are allowed to assume the role; missing trust prevents the service from obtaining the role session. That directly addresses AWS service must assume role. The design remains compatible with centralized federation and role-based access.
- This alternative leaves the principal or session handling unchanged because S3 lifecycle rules control object storage transitions and expiration, not STS role assumption. That leaves AWS service must assume role unresolved. The required AWS identity semantics are not created by this mechanism.
- The option cannot express the required authorization relationship because Routing can affect network paths but cannot substitute for the IAM trust relationship required to assume the role. That leaves AWS service must assume role unresolved. This cannot substitute for the trust, permission, or federation control the scenario calls for.
Question 13
An IAM Identity Center administrator sees roles named with the AWSReservedSSO_ prefix in member accounts. A team proposes editing those roles directly to add permissions. What is the best recommendation?
- Convert the AWSReservedSSO role to an IAM user
- Attach permissions to the account root user so the role inherits them
- Rename the AWSReservedSSO role and then edit it
- Modify the corresponding permission set in IAM Identity Center instead of manually editing the managed role
Correct Answer(s)
D
Rationale
- This option addresses a different control plane: Roles and users are different IAM identity types, and conversion would discard the federated temporary-session model. That leaves AWSReservedSSO role unresolved. The correct design must enforce the requirement through the appropriate IAM identity, policy, or session mechanism.
- Although plausible, this does not solve the stated identity problem because IAM roles do not inherit root permissions; root authority is not a parent policy for Identity Center roles. That leaves AWSReservedSSO role unresolved. A different AWS identity control is needed to govern the principal and the requested action.
- The central security requirement remains unsatisfied because Changing a service-managed role is not the supported source of truth and can interfere with Identity Center’s ability to manage account assignments consistently. That leaves AWSReservedSSO role unresolved. The scenario needs a narrower, identity-aware control to meet the stated objective.
- The intended credential lifecycle is supported because The AWSReservedSSO roles are created and controlled by IAM Identity Center from permission-set assignments, so permissions should be managed at the permission-set source. That directly addresses AWSReservedSSO role. The resulting access can be limited, audited, and changed from the intended control plane.
Question 14
An automation principal is allowed to assume a deployment role. The caller now needs to pass a Project session tag during AssumeRole, but tagged role assumptions are denied while untagged assumptions succeed. Which trust-policy permission is additionally required?
- Attach AmazonS3FullAccess to the deployment role
- Allow sts:TagSession for the trusted principal
- Allow iam:TagRole on the deployment role
- Allow sts:GetCallerIdentity for all principals
Correct Answer(s)
B
Rationale
- AmazonS3FullAccess changes permissions available after the role is assumed. It does not change whether STS accepts session tags during AssumeRole, and broad storage permissions would unnecessarily expand the deployment role’s effective access.
- Passing session tags during role assumption requires authorization for sts:TagSession in the role trust policy in addition to the relevant role-assumption action. Adding that permission addresses why untagged sessions work while tagged sessions are rejected.
- iam:TagRole changes persistent tags on the IAM role resource. The scenario concerns tags attached to an STS role session at assumption time, so role-tagging permission does not authorize the caller to submit session tags.
- sts:GetCallerIdentity returns details about the current identity and can help diagnostics, but it does not authorize session-tag propagation. The failing action is the tagged role assumption, which requires the trust policy to permit sts:TagSession.
Question 15
A role permits s3:GetObject on arn:aws:s3:::reports/* only when aws:PrincipalTag/Department equals Finance. A user in the Finance workforce group assumes the role through IAM Identity Center, but the expected principal tag is absent. What configuration area should be reviewed?
- The S3 bucket’s storage class
- The VPC DHCP option set
- IAM Identity Center attributes for access control and the identity-source attribute mapping
- The role’s EC2 instance profile
Correct Answer(s)
C
Rationale
- This does not produce the required IAM behavior because Storage class affects object cost and retrieval characteristics, not the principal tags carried in an IAM role session. That leaves Identity Center workforce unresolved. The solution needs to narrow the actual AWS authorization path rather than change unrelated infrastructure.
- The option fails the stated least-privilege constraint because DHCP settings affect network configuration and do not create IAM principal tags from workforce identity attributes. That leaves Identity Center workforce unresolved. This would not reliably prevent the unwanted access pattern described in the prompt.
- The scenario’s identity model is satisfied because Workforce ABAC depends on Identity Center passing selected attributes into the role session as principal tags, so missing mappings can prevent the condition from matching. That directly addresses Identity Center workforce. This preserves the least-privilege intent while meeting the operational need.
- This control cannot satisfy the scenario on its own because Instance profiles attach roles to EC2 instances and are unrelated to workforce sessions created by IAM Identity Center. That leaves Identity Center workforce unresolved. The design therefore needs the IAM feature that directly controls role, session, or policy evaluation.
Question 16
A team wants a temporary support role to be assumable for at most one hour even though the role’s general maximum session duration is longer. The calling process can request a duration when it calls STS. Which approach best meets the support workflow?
- Request a one-hour DurationSeconds value when calling AssumeRole and keep the role maximum at or above that value
- Change the account root password after the support task
- Use an EC2 security group with a one-hour TTL
- Create a permanent IAM user whose access key is deleted after one hour
Correct Answer(s)
A
Rationale
- For the described workforce or workload path, STS can issue a role session shorter than the role’s configured maximum, so the caller can deliberately request the narrower lifetime required by the support process. That directly addresses temporary support role. This is the supported AWS identity pattern for the described constraint.
- The access model would still be incorrect because Root credential rotation does not control the lifetime of an STS role session and is unrelated to delegated support access. That leaves temporary support role unresolved. This would not create the necessary temporary credentials or least-privilege enforcement point.
- This alternative is too broad or unrelated because Security groups do not have a TTL that sets STS credential expiration. That leaves temporary support role unresolved. The security team would still lack a durable control over the relevant AWS API authorization.
- This choice would leave the key requirement unresolved because Manual deletion is less reliable than native temporary credentials and introduces a long-lived key during the interval. That leaves temporary support role unresolved. The requested outcome depends on identity context that this option does not supply or evaluate.
Question 17
A security team wants to prevent developers from creating access keys for a set of IAM users while still allowing them to update the users’ tags. Which policy principle should be applied?
- Grant only the specific tag-management actions and omit access-key creation permissions
- Use a VPC network ACL to block the CreateAccessKey API
- Grant iam:* and rely on developers not to call CreateAccessKey
- Give developers the users’ passwords instead
Correct Answer(s)
A
Rationale
- The design remains least-privileged because IAM authorization is action-specific, so least privilege means allowing only the APIs needed for tag maintenance rather than broad user-administration permissions. That directly addresses developers manage IAM user tags. This preserves centralized governance while still allowing the required task.
- The operational goal remains unmet because Network ACLs filter IP traffic and cannot selectively deny one IAM API action while allowing another. That leaves developers manage IAM user tags unresolved. The access path would still require a more specific IAM control to become secure and maintainable.
- The authorization requirement is not met because A broad wildcard explicitly authorizes the sensitive operation and relies on procedure rather than enforcing the security boundary. That leaves developers manage IAM user tags unresolved. The correct approach must act on the target identity relationship rather than on a separate service.
- This would not establish the requested trust or permission boundary because Sharing credentials increases risk and does not create an authorization boundary around IAM administrative actions. That leaves developers manage IAM user tags unresolved. This does not provide the workforce or workload identity behavior the scenario explicitly requires.
Question 18
A company must let an internal automation service assume a role, but security also wants to ensure the role cannot be assumed by ordinary human users even if they somehow receive sts:AssumeRole permission. Which control is decisive on the target role side?
- Attach a broader identity policy to the automation service
- Place the role in a separate IAM path
- Limit the role trust policy Principal to the automation service identity and required conditions
- Create a CloudWatch dashboard for role usage
Correct Answer(s)
C
Rationale
- The design would still depend on an inappropriate credential or control because The caller needs permission, but broadening its policy does not prevent other trusted principals from assuming the target role. That leaves automation-only role unresolved. The identity lifecycle or role assumption behavior would remain unresolved after this change.
- This choice does not enforce the needed condition because IAM paths organize names and can support policy patterns, but a path alone does not decide which principals the role trusts. That leaves automation-only role unresolved. The architecture therefore needs a different control at the IAM decision point.
- The access path is correctly secured because The target role’s trust policy defines which principals are accepted for role assumption, so excluding human principals provides a target-side trust boundary. That directly addresses automation-only role. This approach makes the authorization decision explicit and auditable.
- The scenario’s security boundary is elsewhere because Monitoring can reveal activity but does not prevent an unauthorized principal from establishing the role session. That leaves automation-only role unresolved. This fails to satisfy the stated combination of functionality and least privilege.
Question 19
An architect is choosing between an IAM role and an IAM user for a new machine-to-machine integration running outside AWS. The external platform supports OIDC federation with AWS STS. Which choice best follows AWS security practice?
- Share the account root access key with the platform
- Use an IAM group because groups can be assumed by OIDC
- Create an IAM user with an access key that never expires
- Use OIDC federation to an IAM role and issue temporary credentials
Correct Answer(s)
D
Rationale
- This does not align with the requested credential lifecycle because Root keys provide unrestricted account authority and are not an acceptable machine-to-machine integration credential. That leaves external machine workload unresolved. The option does not govern the principal-to-resource authorization decision described.
- The result would not be least-privileged because IAM groups are collections of IAM users and are not assumable identities for web-identity federation. That leaves external machine workload unresolved. The design would continue carrying unnecessary risk or administration overhead.
- The proposed control does not govern the relevant request because A permanent access key creates a standing secret that must be protected indefinitely and is unnecessary when federated temporary credentials are available. That leaves external machine workload unresolved. This would not centralize or constrain the access model in the manner required.
- The required account-access behavior is delivered because When the external workload can present a trusted OIDC token, STS federation avoids long-lived IAM-user keys and allows trust conditions to constrain the workload identity. That directly addresses external machine workload. The control is directly enforceable by AWS at request or session creation time.
Question 20
Security wants a role policy to allow reading objects only when the request uses TLS. Which IAM condition strategy directly expresses that transport requirement?
- Set the role maximum session duration to fifteen minutes
- Use a condition on aws:SecureTransport and deny requests where it is false
- Require the caller’s IAM username to contain TLS
- Use the resource’s Availability Zone as the condition
Correct Answer(s)
B
Rationale
- The central security requirement remains unsatisfied because Short sessions reduce credential exposure time but do not enforce TLS on individual API requests. That leaves role reads objects unresolved. The scenario needs a narrower, identity-aware control to meet the stated objective.
- The security objective is fulfilled at the right layer because The global aws:SecureTransport context key indicates whether the request used TLS, so a deny on false can enforce encrypted transport for applicable service requests. That directly addresses role reads objects. This keeps identity authorization separate from unrelated transport or resource settings.
- The option cannot express the required authorization relationship because A username is identity metadata and does not indicate whether the current API request traveled over an encrypted transport. That leaves role reads objects unresolved. This cannot substitute for the trust, permission, or federation control the scenario calls for.
- This approach would add complexity without solving the IAM requirement because Availability Zone placement does not reveal the transport security state of the API request. That leaves role reads objects unresolved. The core requirement is enforceable IAM authorization, which remains absent with this choice.