Protect the AWS Account

Situation and constraints

Juniper Works has opened its first AWS account. Five employees sign in with the account's root email address and a shared password. A root access key is stored in a team spreadsheet so a deployment script can call AWS APIs. Former contractors may still know the password, and no one can reliably explain which person changed a resource.

This setup is convenient only until something goes wrong. The root user has unrestricted access to the account and can perform sensitive account-level tasks. Shared credentials remove individual accountability. Long-lived keys can be copied, leaked, or forgotten. Broad access makes one compromised credential far more damaging than it needs to be.

Juniper does not need an advanced identity architecture. It needs a defensible foundation: protect the root user, give people individual access, require strong authentication, grant only necessary permissions, and use temporary credentials wherever possible.

The decision to make

Juniper must replace one powerful shared identity with separate access paths for account recovery, workforce users, and workloads.

The target model is straightforward:

• the root user is protected and reserved for the few tasks that require it;
• employees authenticate as themselves, preferably through federation and AWS IAM Identity Center;
• permissions follow least privilege rather than job-title guesswork or blanket administrator access;
• workloads use IAM roles and temporary credentials instead of embedded access keys; and
• multi-factor authentication adds another factor beyond a password.

This is not only about preventing an attacker from signing in. Individual identities and scoped roles improve accountability, make offboarding safer, and limit the effect of mistakes.

A practical mental model

Think of the AWS account as a building with one master key, employee badges, and temporary visitor passes.

The root user is the master key. It can reach nearly everything and is needed for a small number of account tasks. It should be secured, monitored, and stored for exceptional use—not copied for daily work.

Federated workforce access is like issuing each employee a named badge based on their company identity. Employees sign in through a trusted identity source, and AWS grants an approved level of access. When someone changes teams or leaves, administrators can change access centrally.

An IAM role is like a time-limited visitor pass for a particular purpose. A person, AWS service, or workload can assume the role and receive temporary credentials. The role does not need a permanent password or access key attached to the application.

The analogy breaks down if it suggests that every badge should open every door. Least privilege means granting only the actions and resources needed for the task, under the appropriate conditions. Permissions should be reviewed and narrowed as Juniper learns how access is actually used.

Compare the options without hiding the tradeoffs

Continue sharing the root user

This requires almost no setup, but it gives daily activity the account's most powerful identity. It also prevents reliable attribution, complicates offboarding, and turns one leaked password into an account-wide incident.

Create a permanent access key for every person and application

Individual keys are better than a shared root key, but they are still long-lived secrets that must be protected and rotated. Keys embedded in source code, documents, or local scripts can escape the team's control. AWS recommends temporary credentials for human and workload access when possible.

Use federated workforce access and roles

Federation lets Juniper use identities from an external identity provider rather than creating a separate long-lived AWS password for every person. AWS IAM Identity Center can centrally connect workforce identities to AWS accounts and applications. Permission sets map job needs to account access, and sessions use temporary credentials.

For workloads, IAM roles provide permissions without storing permanent AWS access keys in code. A workload receives temporary credentials, which expire and reduce the lifetime of a stolen credential.

Temporary does not mean harmless. A temporary credential can still be abused while valid, so least privilege, secure configuration, monitoring, and short appropriate sessions still matter.

Recommended reasoning

Juniper should begin with the root user because every other control can be undermined if root access is weak.

Use a unique, strong root password and protect the root email account. Register multi-factor authentication for the root user and keep recovery details current. AWS currently requires MFA for root users; registering more than one supported MFA device can also reduce the chance that a single lost device blocks recovery. Do not create root access keys, and remove the existing one after the deployment is moved to a role. Root should be used only when a task specifically requires root credentials.

Next, give people individual workforce access. For an organization with multiple accounts or an existing identity provider, IAM Identity Center is the preferred central access direction. Users can authenticate through the organization's identity source, while administrators assign permission sets to people or groups for particular AWS accounts.

Then apply least privilege. Start from the work a person or workload must perform. Grant the required actions on the required resources, and avoid a permanent administrator policy simply because it is quick. Review access as responsibilities change.

Finally, separate human and workload access. A developer signs in as a human through the workforce access path. An application running on AWS assumes an IAM role. The application should not reuse the developer's credentials or read a permanent access key from source code.

For the underlying vocabulary—users, groups, roles, and policies—use IAM Foundations. The comparison in IAM Users Versus Roles explains why roles are the normal choice for workloads.

Where the manifest services fit

AWS Identity and Access Management (IAM) controls authentication and authorization for AWS resources. IAM policies define allowed or denied actions. IAM users can represent specific long-term identities when they are genuinely needed, groups organize permissions for IAM users, and roles provide assumable access with temporary credentials.

IAM is not a place to store application passwords or customer identities. In this scenario, its central purpose is to define permissions and roles for access to AWS resources.

AWS IAM Identity Center helps centrally manage workforce access to multiple AWS accounts and supported applications. It can use its own identity store or connect to an external identity provider. Administrators assign people or groups to AWS accounts through permission sets, and users receive temporary access after signing in. The shared AWS IAM Identity Center reference covers the service in more detail.

The two services are complementary. Identity Center provides a workforce access experience and centralized assignments. IAM supplies the underlying roles and permissions used inside AWS accounts. “Use Identity Center” does not mean IAM policies disappear.

Common exam confusion

• Root user versus an administrator: An administrator can have broad permissions, but the root user is the original account identity and retains account-level powers. Daily administration should not use root.
• Password plus another password versus MFA: MFA combines different factor types, such as something known and something possessed. It is not merely two passwords.
• Authentication versus authorization: Authentication establishes who or what is signing in. Authorization determines what that identity may do.
• IAM user versus IAM role: A user can have long-term credentials. A role is assumed and supplies temporary credentials.
• Federation versus copying users: Federation trusts an external identity system so people can use their existing organizational identity to access AWS.
• Temporary credentials versus least privilege: Expiration reduces credential lifetime. Least privilege limits capability. A sound model uses both.
• IAM versus IAM Identity Center: IAM defines AWS permissions and roles. IAM Identity Center centralizes workforce access and account assignments.
• MFA versus permission: MFA strengthens sign-in. It does not decide which AWS actions are allowed after sign-in.

Recall prompts

1. Why should Juniper avoid using the root user for daily work?
2. What does MFA add to password-based authentication?
3. How does least privilege reduce the impact of mistakes or stolen credentials?
4. Why are IAM roles better than embedded long-lived keys for AWS workloads?
5. What is federation?
6. How do IAM and IAM Identity Center work together for workforce access?
7. Why are temporary credentials helpful but not sufficient on their own?

Summary

Juniper should protect the root user with strong recovery controls and MFA, remove root access keys, and reserve root for the few tasks that require it. Employees should have individual, federated access through IAM Identity Center where appropriate. Permissions should follow least privilege, and workloads should assume IAM roles to receive temporary credentials rather than store long-lived keys.

The foundational security model is separation: an exceptional root identity, named human access, scoped permissions, and purpose-built workload roles. That model improves both security and accountability without requiring Cloud Practitioner learners to design a complex identity system.

Official references: CLF-C02 Domain 2, IAM security best practices, root user best practices, temporary security credentials, and IAM Identity Center.