What is your primary use case for AWS Identity and Access Management?

When attempting to access Windows UNC paths from MoveIt, it will request user ID and access. For instance, if ITS-MoveIt is the local user utilized during installation, that particular user should have read, write, execute, and modify permissions on that particular path. Similarly, when creating the AWS Identity and Access Management role, we provide it to S3 bucket owners and request them to update the KMS key policies and S3 bucket policies. In the policies section, they have actions, bucket details, put bucket detail, and alter some permissions. These are all action items they will have in the AWS Identity and Access Management role. Temporary access is not generally used with AWS Identity and Access Management. When setting up the MoveIt task to access S3 buckets, it becomes a permanent configuration where the AWS Identity and Access Management role is created and shared with S3 bucket owners. They will add the KMS key policy and update the S3 bucket policy accordingly. If there is a business reason to decommission or disable this task, they will remove or revoke that access by removing the AWS Identity and Access Management role from their S3 bucket policy. In our company, creating users and groups is not encouraged. Everything is managed through AWS Identity and Access Management roles. As a member of the prod support team, permissions are limited to updating or creating AWS Identity and Access Management roles and restarting EC2 instances. Deletion of EC2 instances is handled by the security operations team, even if one owns that instance. A notable issue exists in storage gateway when creating SMB file shares and AWS Identity and Access Management roles. When creating subsequent SMB file shares, the KMS key details from the first share appear by default. This requires manual updating of the KMS key through CloudShell in the AWS console, as it does not automatically update while creating AWS Identity and Access Management roles or SMB file shares.

Our primary use case for AWS Identity and Access Management ( /products/aws-identity-and-access-management-reviews ) involves user management. We assign permissions to developers on an AWS ( /products/amazon-aws-reviews ) account, ensuring that the right person has the appropriate level of access without exposing credentials unnecessarily.

As a DevOps engineer, I primarily use AWS services like EC2 instances, S3, Auto Scaling Group, CLB, Route 53, and database services. I also use KMS Key for encryption, and these are the services I use daily.

I used AWS Identity and Access Management for creating, modifying, and deleting users and integrating with one or more other directories. It is used to synchronize with other directories and create new identities for users who need specialized access to organizational tools. Additionally, while creating users, we provide specific permissions.

I use AWS Identity and Access Management mostly as a team leader managing twenty to twenty-five client accounts, primarily on AWS. I handle their accounts and ensure proper access by creating IAM users and roles, assigning specific privileges, particularly when juniors need to work only on certain services like EC2.

I used AWS Identity and Access Management to create a user authenticator and manage subdomains with access to the operating system. I assigned group policies and rules regarding their usage. Additionally, I used IAM for managing group policies and individual policies as part of my cybersecurity domain studies.

I am a cloud engineer and DevOps engineer. I mainly use AWS Identity and Access Management (IAM) for setting some policies for developers, such as granting limited access to specific resources as part of managing permissions. Additionally, roles, policy management, and monitoring and logging are essential, and integration with services like EC2, Lambda, S3, and others.