Topic 01 Practice Test 1 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-based batch processor currently reads an IAM user’s access key from a configuration file. Security wants the instance to obtain short-lived credentials automatically and eliminate stored AWS secrets. Which design is best?
- Attach an IAM role to the EC2 instance through an instance profile
- Put the access key in an EC2 user-data script
- Store the IAM access key in an encrypted EBS volume
- Create a second IAM user dedicated to the instance
Correct Answer(s)
A
Rationale
- This choice fits the stated access boundary because EC2 can retrieve temporary role credentials from the instance metadata service, so the application no longer stores or rotates an IAM access key. That directly addresses EC2 workload. This addresses the requirement without introducing a broader standing credential.
- The scenario would remain exposed with this choice because User data is not a credential service and can expose the same persistent secret to anyone or anything able to inspect instance bootstrap data. That leaves EC2 workload unresolved. Using this would leave either credentials, trust, or effective permissions broader than intended.
- Although plausible, this does not solve the stated identity problem because Encryption protects the key at rest but still leaves a long-lived credential that must be distributed, retrieved, and rotated by the workload. That leaves EC2 workload 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 A separate user changes credential ownership but still relies on long-lived access keys rather than workload-native temporary credentials. That leaves EC2 workload unresolved. The scenario needs an enforceable authorization rule, not merely an adjacent operational setting.
Question 2
A Lambda function needs to write objects to one S3 bucket and publish metrics to CloudWatch. The function must not contain AWS access keys. What should the architect configure?
- Create an IAM user and place its access key in an environment variable
- Attach a permissions boundary directly to the Lambda function without a role
- Give the Lambda function an execution role scoped to the required S3 and CloudWatch actions
- Add the Lambda service principal only to the S3 bucket policy
Correct Answer(s)
C
Rationale
- The main limitation is that Environment variables do not convert permanent IAM-user keys into temporary credentials, and the function would still depend on a secret that requires rotation. That leaves Lambda workload unresolved. This does not remove the standing risk or provide the requested temporary authorization behavior.
- This alternative operates at the wrong layer because A permissions boundary limits an IAM user or role but does not itself grant a Lambda function credentials or permissions to call AWS APIs. That leaves Lambda workload unresolved. The stated requirement concerns who may act and under what conditions, which this does not control.
- The security requirement maps directly to this mechanism because Lambda assumes its execution role when the function runs and provides temporary credentials; the role policy can be limited to the bucket and required metric operations. That directly addresses Lambda workload. The result is a narrower and more maintainable authorization path.
- This does not produce the required IAM behavior because A bucket policy can authorize S3 access, but it does not provide the function with credentials or CloudWatch permissions for the full required workload behavior. That leaves Lambda workload unresolved. The solution needs to narrow the actual AWS authorization path rather than change unrelated infrastructure.
Question 3
An ECS application runs on a cluster of EC2 container instances. Only one task definition should be allowed to read from a particular DynamoDB table; other tasks on the same hosts must not inherit that access. Which IAM design provides the best isolation?
- Create an IAM group for the ECS tasks
- Assign a dedicated IAM task role to that ECS task definition
- Place the DynamoDB table ARN in the task’s security group
- Grant the DynamoDB permissions to the EC2 instance profile
Correct Answer(s)
B
Rationale
- The proposed mechanism is related but not decisive because IAM groups contain IAM users, not ECS tasks, so a group cannot provide runtime credentials to individual containers. That leaves ECS on EC2 unresolved. That mismatch makes it unsuitable even though the service may be useful elsewhere in the architecture.
- This mechanism matches the operational requirement because ECS task roles deliver credentials to the individual task, allowing table permissions to be isolated from other tasks that share the same container instance. That directly addresses ECS on EC2. This avoids shifting the problem to an unrelated network or storage control.
- This choice would leave the key requirement unresolved because Security groups control network traffic and do not authorize DynamoDB API actions or provide AWS credentials to an ECS task. That leaves ECS on EC2 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 The instance profile applies to the container host and can expose broader permissions to tasks on that host, which defeats the requested per-task isolation. That leaves ECS on EC2 unresolved. The design therefore needs the IAM feature that directly controls role, session, or policy evaluation.
Question 4
An EKS workload must call an AWS API without sharing the node instance role with every pod. The cluster uses an OIDC provider and the application already has a dedicated Kubernetes service account. Which approach should the architect use?
- Grant the service account a Kubernetes ClusterRole only
- Add the API permission to the worker-node instance role
- Create an IAM user for the pod and store its keys in a Kubernetes Secret
- Associate an IAM role with the Kubernetes service account and restrict the role trust to that service account
Correct Answer(s)
D
Rationale
- The authorization requirement is not met because A Kubernetes RBAC role governs Kubernetes API access; by itself it does not authorize calls to AWS service APIs outside the cluster. That leaves EKS pod unresolved. The correct approach must act on the target identity relationship rather than on a separate service.
- This alternative is too broad or unrelated because Expanding the node role makes the permission available at the node level and weakens isolation between workloads that have different AWS authorization requirements. That leaves EKS pod unresolved. The security team would still lack a durable control over the relevant AWS API authorization.
- The scenario specifically needs an identity control, while A Kubernetes Secret can store data, but static IAM-user keys remain long-lived credentials and require independent distribution and rotation. That leaves EKS pod 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 IAM roles for service accounts use the cluster OIDC identity so the targeted pod can obtain temporary AWS credentials without inheriting the broader node role. That directly addresses EKS pod. This gives security an enforceable control rather than a documentation-only convention.
Question 5
A company has 35 AWS accounts and uses Microsoft Entra ID for employees. Security wants one workforce sign-in experience and centrally managed role-based access to selected accounts, without creating IAM users in each account. What is the best design?
- Create matching IAM users in every account and synchronize passwords nightly
- Connect the external IdP to IAM Identity Center and assign groups to permission sets for the required accounts
- Use an IAM user group in the management account for all member-account permissions
- Share the management account root credentials with the cloud administration team
Correct Answer(s)
B
Rationale
- The operational goal remains unmet because Duplicating IAM users creates account-specific long-lived identities and password lifecycle work, contrary to the requested centralized workforce federation model. That leaves 35 AWS accounts 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 IAM Identity Center can federate workforce authentication to the external IdP and centrally map groups to account permission sets that provision controlled IAM roles. That directly addresses 35 AWS accounts. This is the narrowest control that still satisfies the stated operational requirement.
- This option changes something other than the required IAM decision because IAM groups do not span accounts and cannot centrally create temporary workforce sessions in member accounts. That leaves 35 AWS accounts 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 Root credentials are unrestricted account credentials and should not be used as a shared workforce access mechanism for routine administration. That leaves 35 AWS accounts unresolved. The identity lifecycle or role assumption behavior would remain unresolved after this change.
Question 6
A company connects an external SAML identity provider to IAM Identity Center. It wants new and removed employees and group memberships to synchronize automatically into IAM Identity Center. Which additional protocol should be configured?
- SCIM provisioning
- OpenID Connect discovery
- IAM Access Analyzer
- AWS STS AssumeRole
Correct Answer(s)
A
Rationale
- The authorization boundary is preserved because SCIM is the provisioning protocol used to synchronize users and groups from a supported external identity provider into IAM Identity Center for account and application assignments. That directly addresses external SAML IdP. The design can be reviewed and maintained as a clear least-privilege rule.
- This mechanism cannot replace the required role, policy, or federation behavior because OIDC can be used for authentication in other contexts, but it is not the user-and-group provisioning mechanism required for this SAML Identity Center connection. That leaves external SAML IdP unresolved. The requested condition must be evaluated during authorization or session issuance, not here.
- The proposed control does not govern the relevant request because Access Analyzer evaluates access and policies; it does not synchronize identities or group membership from a corporate identity provider. That leaves external SAML IdP unresolved. This would not centralize or constrain the access model in the manner required.
- The scenario’s security boundary is elsewhere because AssumeRole returns temporary AWS credentials for a role session; it does not provision workforce user and group objects from an external directory. That leaves external SAML IdP unresolved. This fails to satisfy the stated combination of functionality and least privilege.
Question 7
Developers may create application roles, but security requires that no role they create can ever gain permissions outside an approved services-and-actions ceiling, even if a developer later attaches a broader identity policy. Which IAM control should security require on the delegated roles?
- A session tag
- An IAM group
- A role trust policy
- A permissions boundary
Correct Answer(s)
D
Rationale
- The option cannot express the required authorization relationship because Session tags add attributes to temporary sessions and can support ABAC, but a tag by itself does not impose a maximum permission ceiling. That leaves delegated role creation unresolved. This cannot substitute for the trust, permission, or federation control the scenario calls for.
- The result would not be least-privileged because Groups organize IAM users and can carry policies, but they do not establish a maximum permission ceiling for roles created by delegated administrators. That leaves delegated role creation unresolved. The design would continue carrying unnecessary risk or administration overhead.
- This alternative leaves the principal or session handling unchanged because A trust policy controls who may assume a role; it does not limit which service actions the assumed role can perform after it is successfully assumed. That leaves delegated role creation unresolved. The required AWS identity semantics are not created by this mechanism.
- The control is suitable for this exact context because A permissions boundary sets the maximum permissions an IAM role or user can receive; an attached identity policy cannot make effective permissions exceed that boundary. That directly addresses delegated role creation. The design remains compatible with centralized federation and role-based access.
Question 8
A finance team assumes a broad read-only audit role, but one automated report should receive only the S3 and Cost Explorer subset of that role’s permissions for a single session. The underlying role must remain unchanged. What should the caller supply when assuming the role?
- A new trust policy statement on the role
- A permissions boundary on the calling user
- A restrictive session policy
- A new IAM user access key
Correct Answer(s)
C
Rationale
- The central security requirement remains unsatisfied because The trust policy determines which principals may assume the role, not which subset of the role’s allowed service actions applies to one session. That leaves existing broad role unresolved. The scenario needs a narrower, identity-aware control to meet the stated objective.
- This option addresses a different control plane: A boundary on the caller caps the caller’s own identity permissions and does not directly narrow the permissions granted to the resulting role session. That leaves existing broad role unresolved. The correct design must enforce the requirement through the appropriate IAM identity, policy, or session mechanism.
- The intended credential lifecycle is supported because A session policy can reduce the permissions available in a particular assumed-role session; effective access is limited by both the role’s permissions and that session policy. That directly addresses existing broad role. The resulting access can be limited, audited, and changed from the intended control plane.
- Although plausible, this does not solve the stated identity problem because Creating permanent credentials does not provide session-specific narrowing and introduces a long-lived secret that the architecture is trying to avoid. That leaves existing broad role unresolved. A different AWS identity control is needed to govern the principal and the requested action.
Question 9
An operations role may be assumed only by a specific IAM role and only when the AssumeRole request originates from the corporate egress CIDR. Where should this restriction be enforced?
- In an IAM user group attached to the target role
- In an EC2 security group on the target account
- In the target role trust policy using the approved principal and an aws:SourceIp condition
- In the target role permissions policy using s3:prefix
Correct Answer(s)
C
Rationale
- This is insufficient for the requested access model because IAM groups can contain users, not roles, and therefore cannot express the trust relationship for assuming another role. That leaves specific trusted role unresolved. The required least-privilege decision must be made in IAM or the federation path instead.
- The main limitation is that Security groups govern network traffic to supported elastic network interfaces; they do not authorize AWS STS role assumption. That leaves specific trusted role unresolved. This does not remove the standing risk or provide the requested temporary authorization behavior.
- The requested least-privilege outcome is met because The role trust policy is evaluated for the AssumeRole request and can limit both the trusted principal and contextual request conditions such as the originating IP address. That directly addresses specific trusted role. That gives the requested control while preserving the existing identity model.
- The scenario would remain exposed with this choice because The role permissions policy controls what an established role session can do; an S3 prefix condition does not restrict who may call AssumeRole. That leaves specific trusted role unresolved. Using this would leave either credentials, trust, or effective permissions broader than intended.
Question 10
Security requires administrators who use an IAM user to supply MFA before they can assume a sensitive break-glass role. The role should reject AssumeRole requests that are not MFA-authenticated. Which policy design directly enforces this?
- Create an IAM access key only after MFA succeeds
- Attach an MFA device ARN to the role permissions policy
- Enable S3 Block Public Access on the account
- Add an MFA-present condition to the sensitive role’s trust policy
Correct Answer(s)
D
Rationale
- This control cannot satisfy the scenario on its own because Access keys are long-lived credentials and IAM does not use access-key creation as the mechanism for requiring MFA on every AssumeRole operation. That leaves IAM-user administrator unresolved. The design therefore needs the IAM feature that directly controls role, session, or policy evaluation.
- This does not produce the required IAM behavior because A permissions policy defines allowed AWS actions after assumption; simply referencing a device ARN there does not make STS require MFA for the role assumption. That leaves IAM-user administrator 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 S3 Block Public Access addresses S3 exposure and has no effect on whether an IAM principal can establish an STS role session. That leaves IAM-user administrator unresolved. This would not reliably prevent the unwanted access pattern described in the prompt.
- The scenario’s identity model is satisfied because The role trust policy can require an MFA-authenticated calling context for AssumeRole, so the role assumption fails when the required MFA context is absent. That directly addresses IAM-user administrator. This preserves the least-privilege intent while meeting the operational need.
Question 11
Engineering wants developers to manage only EC2 instances whose resource tag Project matches the developer’s own Project principal tag. The company wants one reusable policy rather than separate policies for each project. Which authorization model is most appropriate?
- Attribute-based access control using principal and resource tag conditions
- Create a unique IAM policy document for every developer
- Use a security group whose name matches the developer’s project
- Use an S3 bucket ACL for the EC2 instances
Correct Answer(s)
A
Rationale
- For the described workforce or workload path, ABAC compares attributes such as a principal’s project tag with the target resource tag, allowing one policy pattern to scale as projects and principals change. That directly addresses many projects. This is the supported AWS identity pattern for the described constraint.
- This choice would leave the key requirement unresolved because Per-user policies can work, but they create policy sprawl and do not use the requested scalable relationship between identity and resource attributes. That leaves many projects unresolved. The requested outcome depends on identity context that this option does not supply or evaluate.
- The access model would still be incorrect because Security groups filter network traffic; their names do not authorize IAM API operations according to the caller’s identity attributes. That leaves many projects unresolved. This would not create the necessary temporary credentials or least-privilege enforcement point.
- This alternative is too broad or unrelated because S3 ACLs apply to S3 objects or buckets and cannot provide authorization for EC2 management actions. That leaves many projects unresolved. The security team would still lack a durable control over the relevant AWS API authorization.
Question 12
An application team has an existing broad IAM policy. Security wants to derive a narrower policy from the AWS API activity the role actually used during a representative observation period. Which capability best supports this task?
- VPC Reachability Analyzer
- IAM Access Analyzer policy generation from CloudTrail activity
- Amazon Inspector
- AWS Config conformance packs
Correct Answer(s)
B
Rationale
- This would not establish the requested trust or permission boundary because Reachability Analyzer models network paths in a VPC; it does not inspect CloudTrail activity to construct IAM authorization policies. That leaves existing broad role unresolved. This does not provide the workforce or workload identity behavior the scenario explicitly requires.
- The design remains least-privileged because IAM Access Analyzer can generate a policy based on observed CloudTrail activity, giving the team evidence for reducing a broad role toward permissions it actually used. That directly addresses existing broad role. This preserves centralized governance while still allowing the required task.
- The operational goal remains unmet because Inspector identifies software vulnerabilities and exposure on supported workloads; it is not an IAM policy-generation service based on historical API use. That leaves existing broad role unresolved. The access path would still require a more specific IAM control to become secure and maintainable.
- The authorization requirement is not met because Config evaluates resource configuration against rules, but it does not generate a least-privilege IAM policy from the API calls a role performed. That leaves existing broad role unresolved. The correct approach must act on the target identity relationship rather than on a separate service.
Question 13
A CI/CD pipeline proposes updates to a customer managed IAM policy. Security allows the deployment only when the updated policy grants no permissions beyond the currently approved policy version. Which IAM Access Analyzer capability should the pipeline use?
- IAM Access Analyzer policy generation from CloudTrail activity
- Policy validation with ValidatePolicy
- An external access analyzer with the account as its zone of trust
- A custom policy check for no new access
Correct Answer(s)
D
Rationale
- Policy generation derives a candidate least-privilege policy from access activity recorded in CloudTrail. It can help refine permissions, but it does not compare a proposed policy against the approved current version and fail a deployment when new access appears.
- ValidatePolicy checks policy syntax, grammar, security warnings, and AWS best-practice findings. It does not answer the scenario’s comparative question of whether the proposed document grants access beyond the currently approved reference policy.
- An external access analyzer evaluates supported resource policies for access from outside a defined zone of trust. The pipeline instead needs a predeployment comparison between two IAM policy documents, so external-access findings do not enforce this change-control rule.
- A custom policy check can compare the proposed policy with a reference policy and determine whether the update introduces new access. That directly enforces the pipeline’s requirement to reject a permission expansion while allowing equivalent or narrower revisions.
Question 14
An IAM role currently allows many service actions. Security wants evidence about services the role has not accessed recently so unused privileges can be reviewed and removed. Which information is most directly useful?
- Route 53 query logs
- IAM service last accessed information for the role
- EC2 instance status checks
- AWS Budgets utilization reports
Correct Answer(s)
B
Rationale
- The proposed control does not govern the relevant request because DNS query logs show name-resolution activity and do not indicate which AWS service permissions an IAM role has or has not used. That leaves existing broad IAM role unresolved. This would not centralize or constrain the access model in the manner required.
- The required account-access behavior is delivered because Service last accessed data shows when an IAM principal last attempted supported services, helping reviewers identify permissions that may be candidates for removal after appropriate validation. That directly addresses existing broad IAM role. The control is directly enforceable by AWS at request or session creation time.
- This does not align with the requested credential lifecycle because Instance status checks report compute health and do not provide authorization usage history for an IAM principal. That leaves existing broad IAM role unresolved. The option does not govern the principal-to-resource authorization decision described.
- The result would not be least-privileged because Budgets track spend and usage against financial thresholds, not the recency of AWS API permissions exercised by a role. That leaves existing broad IAM role unresolved. The design would continue carrying unnecessary risk or administration overhead.
Question 15
A workforce permission set grants analysts read-only access to an AWS account. Company policy requires account sessions to expire after two hours even if the user’s IdP session remains valid. What should the administrator configure?
- Set the IAM role path to /two-hours/
- Rotate the external IdP signing certificate every two hours
- Set the permission set session duration to two hours
- Set the S3 object expiration lifecycle to two hours
Correct Answer(s)
C
Rationale
- This approach would add complexity without solving the IAM requirement because An IAM role path is an organizational naming namespace and has no effect on STS or IAM Identity Center session lifetime. That leaves workforce permission set unresolved. The core requirement is enforceable IAM authorization, which remains absent with this choice.
- The central security requirement remains unsatisfied because Certificate rotation maintains federation trust material and is unrelated to the desired duration of each provisioned AWS account role session. That leaves workforce permission set unresolved. The scenario needs a narrower, identity-aware control to meet the stated objective.
- The security objective is fulfilled at the right layer because IAM Identity Center permission sets include an AWS account session duration setting, so the resulting role session can be limited independently of the broader workforce portal session. That directly addresses workforce permission set. This keeps identity authorization separate from unrelated transport or resource settings.
- The option cannot express the required authorization relationship because S3 lifecycle expiration affects objects, not the lifetime of temporary credentials created for a workforce user’s AWS account session. That leaves workforce permission set unresolved. This cannot substitute for the trust, permission, or federation control the scenario calls for.
Question 16
A security team wants a permission set that uses the same centrally maintained policy text in every assigned account, and it does not want to pre-create a named customer managed IAM policy in each account. Which permission-set policy option best fits?
- Use an inline policy in the IAM Identity Center permission set
- Place the policy document in an S3 bucket and attach the bucket URL
- Reference a customer managed policy that exists only in the management account
- Create a local IAM group in each member account
Correct Answer(s)
A
Rationale
- This choice fits the stated access boundary because An inline policy is stored with the permission set and is provisioned as part of the Identity Center-managed role, avoiding the need to pre-create a matching customer managed policy in every account. That directly addresses same policy text. This addresses the requirement without introducing a broader standing credential.
- The scenario would remain exposed with this choice because IAM Identity Center permission sets do not attach arbitrary policy documents by URL; permissions must use supported managed or inline policy mechanisms. That leaves same policy text unresolved. Using this would leave either credentials, trust, or effective permissions broader than intended.
- Although plausible, this does not solve the stated identity problem because For a permission set to reference a customer managed policy, a matching policy name and path must exist in each target account where the permission set is assigned. That leaves same policy text 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 Groups apply to IAM users and would reintroduce per-account identity administration rather than centrally managed workforce access through the permission set. That leaves same policy text unresolved. The scenario needs an enforceable authorization rule, not merely an adjacent operational setting.
Question 17
A new AWS account is created for a project. The security team needs one emergency identity for rare account-recovery tasks but wants all normal administration to occur through delegated workforce roles. Which root-user practice is most appropriate?
- Protect the root user with MFA, avoid root access keys, and use it only for tasks that require root credentials
- Create root access keys and store them in the team’s shared password vault
- Use the root user for daily console administration because it cannot be denied by IAM policies
- Add the root user to an IAM group with a read-only policy
Correct Answer(s)
A
Rationale
- The security requirement maps directly to this mechanism because Root has unrestricted account authority, so minimizing its use and protecting it strongly reduces exposure while delegated roles handle routine administration. That directly addresses new account. The result is a narrower and more maintainable authorization path.
- The main limitation is that Root access keys create highly privileged long-lived credentials and are unnecessary for normal administration; they materially increase the account’s credential risk. That leaves new account unresolved. This does not remove the standing risk or provide the requested temporary authorization behavior.
- This alternative operates at the wrong layer because Root’s broad authority is exactly why routine work should use delegated identities; daily root use increases the impact of phishing, session theft, or operational mistakes. That leaves new account 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 The root user is not an IAM user and cannot be constrained by joining an IAM group or receiving an ordinary IAM identity policy. That leaves new account unresolved. The solution needs to narrow the actual AWS authorization path rather than change unrelated infrastructure.
Question 18
A developer must launch an ECS service that uses one preapproved task role. The developer should not be able to pass arbitrary powerful roles to ECS. Which IAM permission design is required?
- Put the developer in the same IAM group as the ECS task role
- Add the developer to the task role trust policy
- Grant iam:PassRole only on the approved task-role ARN and constrain it to the ECS service where appropriate
- Grant iam:* on all roles but deny ecs:RunTask
Correct Answer(s)
C
Rationale
- The proposed mechanism is related but not decisive because IAM groups contain users and cannot make a user a member of a role; group membership also does not replace the required PassRole authorization. That leaves developer launches ECS unresolved. That mismatch makes it unsuitable even though the service may be useful elsewhere in the architecture.
- This choice would leave the key requirement unresolved because The trust policy is for principals that may assume the role; ECS needs to assume the task role, while the developer needs permission to pass it to ECS. That leaves developer launches ECS unresolved. The requested outcome depends on identity context that this option does not supply or evaluate.
- This mechanism matches the operational requirement because PassRole authorization can be restricted to specific role resources and service context, allowing the developer to configure the approved ECS role without passing unrelated privileged roles. That directly addresses developer launches ECS. This avoids shifting the problem to an unrelated network or storage control.
- This control cannot satisfy the scenario on its own because Broad IAM administration would let the developer modify or pass powerful roles and does not satisfy least privilege for the required ECS deployment workflow. That leaves developer launches ECS unresolved. The design therefore needs the IAM feature that directly controls role, session, or policy evaluation.
Question 19
Before deploying a newly written IAM policy, the security engineer wants automated checks for policy syntax problems and AWS security best-practice warnings. Which IAM capability should be used?
- Amazon CloudWatch Synthetics
- AWS Health Dashboard
- EC2 Image Builder
- IAM Access Analyzer policy validation
Correct Answer(s)
D
Rationale
- The authorization requirement is not met because Synthetics runs canaries against endpoints or workflows and does not statically validate IAM policy language. That leaves new IAM policy unresolved. The correct approach must act on the target identity relationship rather than on a separate service.
- This alternative is too broad or unrelated because The Health Dashboard reports AWS service and account events; it does not validate JSON IAM policy semantics or security best practices. That leaves new IAM policy unresolved. The security team would still lack a durable control over the relevant AWS API authorization.
- The scenario specifically needs an identity control, while Image Builder automates machine-image pipelines and has no function for analyzing authorization policy documents. That leaves new IAM policy 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 Access Analyzer policy validation checks IAM policies and returns findings such as errors, security warnings, general warnings, and suggestions before deployment. That directly addresses new IAM policy. This gives security an enforceable control rather than a documentation-only convention.
Question 20
A company still has a small number of legacy IAM users. Security needs a periodic report showing whether each user has a password, whether access keys exist, and the age or rotation status of those credentials. Which IAM feature best provides this account-level inventory?
- AWS Cost and Usage Report
- IAM credential report
- VPC flow logs
- Amazon Inspector findings export
Correct Answer(s)
B
Rationale
- The operational goal remains unmet because The Cost and Usage Report provides billing and usage line items, not password or access-key metadata for IAM users. That leaves legacy IAM users 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 The IAM credential report summarizes password and access-key status for IAM users in the account, supporting reviews of credential age, MFA-related posture, and legacy key exposure. That directly addresses legacy IAM users. This is the narrowest control that still satisfies the stated operational requirement.
- This option changes something other than the required IAM decision because Flow logs capture network traffic metadata and cannot report whether IAM users have console passwords or active access keys. That leaves legacy IAM users 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 Inspector findings focus on workload vulnerabilities and exposure; they are unrelated to IAM-user credential inventory. That leaves legacy IAM users unresolved. The identity lifecycle or role assumption behavior would remain unresolved after this change.