Identity and Access Management practice questions

Create an IAM user with read-only permissions and provide the auditor with the access keys.

Why wrong: Providing long-term access keys is a major security risk. IAM users require permanent credentials that must be managed, rotated, and protected. If the auditor's workstation is compromised, these static credentials could be exploited to access sensitive data until manually revoked, violating the principle of least privilege.

Attach a bucket policy that grants access to the auditor's specific IP address range.

Why wrong: Relying solely on IP-based restrictions in a bucket policy is insufficient for secure access management. IP addresses can be spoofed or shared, and this method does not provide a formal identity context. It fails to leverage IAM's robust session-based security features, making it harder to track specific auditor activities.

Generate a pre-signed URL for every object in the bucket and share them with the auditor.

Why wrong: Generating pre-signed URLs for an entire bucket is operationally inefficient and difficult to manage. Managing expiration times and access lists for thousands of individual objects is prone to human error and does not provide an identity-based audit trail, making it unsuitable for comprehensive auditing requirements.

The policy is missing the 's3:ListAllMyBuckets' action.

Why wrong: Accessing a specific bucket does not require the ability to list all buckets in the account. This permission is only needed if the user needs to browse the S3 console's global view. The existing policy is sufficient for accessing the specified bucket directly, provided no other constraints are active.

The resource ARN for 's3:GetObject' is incorrect.

Why wrong: The ARN 'arn:aws:s3:::my-secure-bucket/*' is the correct format for object-level actions. It correctly points to all objects within the bucket. The syntax is valid, so this is not the cause of the failure. The error lies elsewhere, specifically in the interaction with other AWS services like KMS.

The policy is missing an 'Effect: Deny' statement.

Why wrong: A policy does not require a Deny statement to be functional. In AWS, the absence of an Allow is an implicit deny. Adding a Deny statement would only be necessary if there were a need to explicitly override other permissions, which is not the case in this simple access scenario.

The user must have the AdministratorAccess managed policy attached.

Why wrong: Administrator access is not required to assume a role. The user only needs permission to perform the 'sts:AssumeRole' action. Granting administrative privileges would be a significant security risk, violating the principle of least privilege, as it allows the user to do far more than just assume the intended role.

The trusting account must share the root user password with the trusted account.

Why wrong: Sharing passwords is a catastrophic security failure and is never required. IAM roles are specifically designed to allow cross-account access without sharing any credentials. The trust relationship is managed through metadata (ARNs and account IDs) in the IAM trust policy, keeping each account's authentication domain strictly separate and secure.

IAM User Access Keys.

Why wrong: IAM user access keys are long-lived and require manual rotation. Using them for external applications increases the risk of credential leakage and makes it significantly harder to manage security. They are not intended for short-term access and should be avoided in favor of temporary, STS-issued credentials for any external integration.

IAM Managed Policies.

Why wrong: Managed policies define permissions; they do not provide credentials themselves. They are a component of the IAM permission framework, not a tool for issuing temporary session keys. To get credentials, you still need an IAM user, role, or an STS request to associate those policies with a specific, temporary session.

AWS Secret Manager.

Why wrong: Secret Manager is for storing and rotating existing secrets, like database passwords or API keys. While it can store credentials, it is not an identity service that issues temporary AWS session tokens. STS is the appropriate service for generating temporary credentials for programmatic access to AWS resources.

The user can perform all actions, including deleting the production bucket.

Why wrong: The Deny statement is explicit and targets the specific resource. Since explicit Deny overrides all Allow statements, the user cannot delete the bucket. This is a common test of understanding the priority of policy evaluation in AWS, where restrictive logic is designed to be stronger than permissive logic.

The user cannot perform any S3 actions because the Deny statement takes precedence.

Why wrong: A Deny statement only applies to the specific action and resource defined within that statement. The rest of the policy's Allow statement remains in effect for other actions. This policy is a valid example of how to grant broad access while explicitly carving out specific, sensitive actions for protection.

The policy is invalid due to conflicting statements.

Why wrong: The policy is syntactically and logically correct. AWS allows conflicting statements, and the policy evaluation engine handles them according to established rules (Deny wins). There is no conflict that would render the policy invalid; it is a standard approach for defining granular permissions within a single IAM policy document.

Use an SCP to globally deny modification of IAM policies.

Why wrong: An SCP is too broad. It would prevent everyone in the organization, including high-level administrators, from modifying any IAM policies. You need a granular solution that targets only the specific user's ability to modify their own permissions while still allowing them to perform their legitimate administrative duties on other accounts.

Create a separate IAM user for the administrator with read-only access.

Why wrong: This doesn't solve the problem; it just creates a second user. The administrator still has the original user with full permissions. You need to restrict the primary account's capabilities. Providing a separate, restricted user does not prevent the administrator from simply using the original, unrestricted account to make unauthorized changes.

Enable MFA on the administrator's account for all IAM changes.

Why wrong: While MFA is a great security practice, it does not stop the user from using their own valid credentials and MFA to modify their own policy. An explicit 'Deny' condition in the IAM policy itself is the only way to programmatically restrict what an authenticated user can do.

Create a new IAM user with an access key and secret key specifically for the third-party auditor's use.

Why wrong: IAM user credentials lack the temporary nature and cross-account isolation provided by roles. Providing a static access key to a third party increases the risk of long-term credential leakage and does not solve the identity validation issues inherent in multi-tenant third-party integrations or services requiring cross-account access.

Add a resource-based policy to the S3 bucket that allows the third-party's AWS account ID directly.

Why wrong: Resource-based policies for CloudTrail logs direct access do not provide a mechanism for the third party to assume a specific identity within your account. This approach bypasses the centralized management of permissions and auditability that IAM roles provide when managing third-party access to sensitive data and logs.

Restrict the trust policy of the IAM role to only allow the specific IP address of the auditor's office.

Why wrong: IP address restrictions in a trust policy are useful for network security but do not prevent the confused deputy problem. If multiple customers use the same third-party service originating from the same IP range, the service could still misidentify which account it is accessing for which client.

ABAC allows for the use of Service Control Policies (SCPs) which are not supported in an RBAC model.

Why wrong: Service Control Policies are a feature of AWS Organizations used to set maximum permissions at the account level. They are entirely independent of whether the underlying accounts use RBAC or ABAC for their internal identity management, making this statement technically incorrect regarding the specific benefits of ABAC.

ABAC eliminates the need for IAM trust policies when performing cross-account access between organizational accounts.

Why wrong: Even when using ABAC, cross-account access still requires a trust relationship defined in an IAM role's trust policy. ABAC changes how permissions within the session are evaluated, but it does not remove the fundamental requirement for a trust relationship to exist between two different AWS accounts.

ABAC provides a built-in mechanism for multi-factor authentication (MFA) enforcement that RBAC lacks.

Why wrong: MFA enforcement is a condition that can be applied to both RBAC and ABAC policies using the 'aws:MultiFactorAuthPresent' key. It is not a benefit unique to ABAC, as both models rely on the same IAM condition evaluation logic to ensure that users have authenticated with a second factor.

AWS Directory Service for Microsoft Active Directory to create a trust relationship with the on-premises domain.

Why wrong: While AWS Directory Service can link on-premises identities to AWS, it is primarily used for user authentication rather than machine-to-machine service access. It does not natively use X.509 certificates from an internal CA to provide temporary credentials to on-premises servers as efficiently as IAM Roles Anywhere does.

AWS PrivateLink to establish a private connection between the on-premises data center and IAM endpoints.

Why wrong: AWS PrivateLink provides private connectivity to AWS services but does not handle identity or credential management. It would allow the servers to reach the IAM API privately, but it would not solve the problem of avoiding long-term access keys for those servers to authenticate themselves.

AWS Systems Manager Hybrid Activations to manage the on-premises servers as Managed Instances.

Why wrong: Systems Manager Hybrid Activations allow you to manage on-premises servers and can provide them with an IAM role. However, the initial activation process still requires credentials, and it is a management tool rather than a dedicated identity federation solution for certificate-based authentication and credential exchange.

IAM Groups with managed policies attached.

Why wrong: IAM Groups are used to organize users and assign common permissions, but they do not provide a mechanism to limit the permissions of roles that those users might create. They do not act as a filter or a boundary for the creation of new identities by the group members.

Service Control Policies (SCPs) at the OU level.

Why wrong: While SCPs can limit what can be done in an account, they are not designed to specifically control the creation of IAM roles with restricted permissions in the same way boundaries do. SCPs apply to the whole account, whereas boundaries are applied to specific IAM principals and roles.

Resource-based policies on S3 and DynamoDB.

Why wrong: Resource-based policies control who can access a specific resource. They do not restrict what permissions an IAM administrator or project lead can assign when they are creating new roles. They are a method of granting access, not a method of delegating and limiting IAM administrative powers.

Apply an SCP to the root of the organization that grants S3 access to the Compliance role.

Why wrong: SCPs cannot grant permissions; they can only act as a filter to restrict them. To allow access, you must use an identity-based policy on the Compliance role itself. An SCP could be used to 'Deny' access to everyone except the Compliance role, but it cannot perform the 'Allow' action.

Enable S3 Block Public Access at the organization level for all buckets.

Why wrong: S3 Block Public Access prevents accidental public exposure but does not help with internal granular access control between different teams. It would not distinguish between the Compliance team and any other internal team or role that has S3 permissions within the accounts of the organization.

Create a Resource Group for all restricted buckets and assign the role to that group.

Why wrong: AWS Resource Groups are used for organizing and managing resources collectively but are not an access control mechanism. You cannot assign an IAM role to a Resource Group to grant permissions; permissions must be managed through IAM policies, bucket policies, or access control lists.

The production account's role must have a resource-based policy allowing the 'iam:TagSession' action.

Why wrong: The correct action for passing session tags is 'sts:TagSession', not 'iam:TagSession'. Additionally, this permission is granted in the trust policy of the role being assumed, which dictates who can assume the role and what conditions (like tagging) must be met during that assume-role operation.

The user in the identity account must have the 'iam:AddUserToGroup' permission for the production group.

Why wrong: Adding users to groups is a management task for local IAM users and does not relate to the STS process of passing session tags during a cross-account role assumption. Session tags are transient and exist only for the duration of the temporary credentials session created by STS.

The department name must be added as a permanent tag to the IAM role itself in the production account.

Why wrong: Tagging the role itself is a form of resource tagging, not session tagging. Session tags are dynamic and passed at the time of the request, allowing different users to use the same role but with different attributes (like their own department) associated with their specific temporary session.

Create an IAM policy that denies all actions for the root user to prevent accidental changes.

Why wrong: It is impossible to restrict the root user using IAM policies. The root user exists outside of the IAM system's control for its own account and always has full administrative permissions. Security for the root user must be managed through access control (MFA) and physical security of credentials.

Share the root user credentials with all senior administrators so that there is always a backup available.

Why wrong: Sharing root credentials is a severe security violation. It circumvents accountability and increases the risk of credential compromise. Instead, senior administrators should have their own IAM users or roles with the necessary permissions, and the root credentials should be stored in a secure, physical location.

Generate an access key for the root user and use it for automated scripts that require high privileges.

Why wrong: Root access keys should be avoided entirely. If an access key for the root user is compromised, the attacker has full control over the account and cannot be blocked by IAM. Automation should always use IAM roles with the principle of least privilege rather than root-level access.

Disabling the automatic rotation of secrets to prevent accidental application downtime.

Why wrong: Disabling rotation actually decreases security. Regular rotation is a primary benefit of Secrets Manager, as it limits the useful life of a secret if it were to be leaked. Security posture is improved by enabling and testing rotation, not by disabling it to avoid potential configuration issues.

Storing the secrets in an S3 bucket with versioning enabled and using that as the primary source.

Why wrong: While S3 can store data, AWS Secrets Manager is the dedicated service for this purpose. Secrets Manager offers features like built-in rotation and specialized API calls for secret retrieval that S3 lacks. Using S3 for secrets management is generally considered a less secure and more manual alternative.

Create an IAM user for the partner with programmatic access keys, and attach an inline policy restricted to the specific S3 buckets.

Why wrong: Long-term credentials increase the risk of accidental exposure or compromise over time. Security best practices strongly discourage creating static IAM users for external third parties when temporary security credentials via assumed roles can be used instead.

Provision an IAM role in the partner account and configure an S3 bucket policy in the enterprise account trusting the external account.

Why wrong: Relying solely on an S3 bucket policy trusting an external account does not provide fine-grained control over the temporary session duration or require external IDs. Roles should be instantiated within the resource account and assumed by the trusted principal.

Configure cross-account resource sharing using AWS Resource Access Manager to directly share the S3 buckets with the partner AWS account.

Why wrong: AWS Resource Access Manager does not currently support direct sharing of Amazon S3 buckets. Resource sharing via RAM is typically reserved for services like VPC subnets, transit gateways, and Route 53 resolvers, making this method technically invalid for S3.

The bucket policy lacks a corresponding explicit deny statement to override implicit denies from other global accounts.

Why wrong: An explicit deny is not required to override implicit denies; an allow statement with a matching condition is sufficient to grant access. The issue stems from evaluation mechanics rather than missing explicit deny statements.

Requests routed through Interface VPC Endpoints for Amazon S3 preserve the original client private IP, causing the public IP condition to fail.

Why wrong: When accessing S3 via an Interface VPC Endpoint, the source IP evaluated by AWS is the private IP of the instance or the endpoint network interface, not the public NAT gateway IP. This mismatch causes IP-based conditions targeting public ranges to fail.

The action s3:GetObject requires additional list permissions on the bucket level that are absent from the provided policy statement.

Why wrong: Retrieving an object via s3:GetObject only requires permission on the object resource itself. List bucket permissions are not required to fetch a specific object if the exact object ARN is known and targeted by the request.

IAM Access Analyzer

Why wrong: IAM Access Analyzer is used to identify resources that are shared with external entities and to generate least-privilege policies based on access logs. It is a monitoring and auditing tool rather than a proactive enforcement mechanism for limiting the permissions that can be assigned during role creation by an administrator.

Resource-based policies

Why wrong: Resource-based policies are attached to resources like S3 buckets or KMS keys to define who can access that specific resource. They do not control or restrict the creation of IAM roles or the management of identity-based policies. They are effective for cross-account access but not for delegating administrative permissions safely.

Service Linked Roles

Why wrong: Service-linked roles are predefined roles that grant an AWS service permissions to perform actions on your behalf. They are managed by the service and cannot be used to restrict the permissions of other IAM roles or users. They simplify service integration but do not address the requirement of delegating administrative tasks.

It restricts access to the S3 bucket so that it can only be reached through the specified VPC Endpoint 'vpce-1a2b3c4d'.

Why wrong: To restrict access to a specific VPC Endpoint, the policy should use 'StringEquals' with an 'Allow' effect, or 'StringNotEquals' with a 'Deny' effect. As written, the 'Allow' combined with 'StringNotEquals' grants access to everyone except those coming from the specified endpoint, which is likely a security misconfiguration.

It denies all access to the S3 bucket if the request originates from the VPC Endpoint 'vpce-1a2b3c4d'.

Why wrong: While the policy effectively prevents the specified endpoint from using the 'Allow' statement, it does not contain an explicit 'Deny'. If another policy grants access, the endpoint might still have permissions. However, based solely on this statement, the endpoint is excluded from the 'Allow' but not explicitly denied.

It requires that all requests to the S3 bucket must be signed using AWS Signature Version 4 through the VPC Endpoint.

Why wrong: The policy makes no mention of signature versions or authentication protocols. It specifically targets the source VPC Endpoint ID. While S3 requests generally require signing, this specific policy logic is focused on network origin rather than the cryptographic method used to sign the API requests themselves.

SCPs applied to the Management Account restrict the actions of the Management Account's root user.

Why wrong: SCPs do not affect the management (master) account of an organization. They only apply to the member accounts within the organization or specific OUs. This ensures that the management account always retains full control to manage the organization and its policies without accidentally locking itself out.

SCPs can be used to grant permissions to a user who has no identity-based policies attached.

Why wrong: SCPs are strictly 'permission filters' and not 'permission granters'. For a user to perform an action, they must have an 'Allow' in an identity-based or resource-based policy, AND the action must not be denied (and must be explicitly or implicitly allowed) by the applicable SCPs.

SCPs are the only way to enable cross-account access between member accounts in an organization.

Why wrong: SCPs do not facilitate cross-account access; they only restrict it. Cross-account access is achieved through IAM roles with trust policies or resource-based policies. SCPs can be used to prevent such access from being configured, but they are not the mechanism that enables the communication between accounts.

Assign IAM policies directly to the root user of every member account.

Why wrong: Modifying the root user in member accounts is an anti-pattern. The root user should have multi-factor authentication enabled and be locked away. Assigning policies to it does not scale and is unnecessary, as SCPs already provide the required governance across all identities in the account, including the root user.

Configure individual IAM users in every account to ensure fine-grained control.

Why wrong: Managing individual IAM users in every account is a high-maintenance and insecure approach. It is better to use AWS IAM Identity Center to centrally manage identities across all accounts. Manual user creation increases the surface area for credential leaks and makes consistent security posture enforcement nearly impossible at scale.

Enable AWS CloudTrail only in the primary management account.

Why wrong: CloudTrail must be enabled in all accounts to maintain a comprehensive audit log. Logging only in the management account provides zero visibility into actions taken within member accounts. Centralized logging is a non-negotiable security requirement for compliance, detection of unauthorized activity, and incident response within an enterprise-level AWS environment.