Secure Claims Data Lake IAM MFA

Introduction

30 Second Summary

Sensitive insurance claims often sit beside records that need extra review. A permission that reaches too far can expose quarantined files or let a new teammate change data by mistake.

In this project, you will build a safe onboarding flow for a claims-data trainee with AWS Identity and Access Management (IAM). The finished flow proves least privilege under MFA without creating a real data lake.

What You'll Build

You'll demo a trainee's access matrix in IAM Policy Simulator, where MFA-authenticated approved reads are allowed while quarantine access and writes remain denied.

By the end of this project, you'll have:

• A group-managed trainee identity whose permissions can be traced through one IAM group.
• An authorization proof that shows approved reads as allowed, quarantine access as denied, writes as denied, and requests without MFA as explicitly denied.
• A confirmed billing email alert that watches worldwide estimated charges through Amazon CloudWatch and Amazon SNS.
• Secret Mission: Isolate the MFA policy in a what-if simulation and prove which control changes the approved read decision.

Are there any prerequisites?

You'll need a standard AWS account with root-user access, a Windows device with browser access, an accessible email inbox, and an MFA-capable phone running Microsoft Authenticator or another compatible authenticator app.

This focused lab uses one IAM user for practice. Mature environments generally use federated access for people.

Before We Start

This step locks in the safe onboarding path before any hands-on work begins. The agreed path is one IAM group granting the console-enabled claims-data trainee MFA-protected read access only to the insurance-claims-data-lake approved claims path.

Secure the Starting Point

Your onboarding plan begins from the AWS Management Console's most powerful identity: the root user. Protecting that session first prevents a stolen password from becoming the single key to the account.

This step also enables billing metrics before the IAM exercises begin. The metric can take about 15 minutes to appear, so that wait starts in the background.

In this step, get ready to:

• Prepare an authenticator app that can scan QR codes.
• Assign a virtual MFA device to the root user and test a fresh sign-in.
• Confirm the billing alarm preflight and enable billing metrics.

Prepare Microsoft Authenticator

A virtual MFA app generates a six-digit one-time code for sign-in. This walkthrough uses Microsoft Authenticator on your mobile device.

Choose the tab that matches the authenticator setup you have now.

✔️ Microsoft Authenticator is installed

• Open Microsoft Authenticator on your mobile device.
• Select the plus icon.
• Confirm that Other account appears as an option.
• Return to the app's main screen.

Your app is ready to scan the root user's QR code.

ⓧ I need to install Microsoft Authenticator

• Open the Apple App Store or Google Play Store on your mobile device.
• Search for Microsoft Authenticator.
• Install the official Microsoft Authenticator mobile app from Microsoft.
• Open Microsoft Authenticator.
• Select the plus icon.
• Confirm that Other account appears as an option.
• Return to the app's main screen.

Your app is ready to scan the root user's QR code.

ⓧ I use another compatible app

AWS accepts compatible authenticator apps that produce six-digit one-time codes.

• Open your compatible authenticator app on your mobile device.
• Find its option for adding an account with a QR code.
• Confirm that its QR-code scanner is ready.
• Return to the app's main screen.

Keep this app nearby for the root MFA setup.

Can't find the account option?

Confirm that you installed Microsoft Authenticator on your mobile device. The app is unavailable for PC or Mac.

Select the plus icon before looking for Other account.

Ask for help if the option is still missing: help me prepare Microsoft Authenticator to scan an AWS virtual MFA QR code.

Protect the root user with MFA

Root access is sensitive because it can change account-wide security controls. The only account change in this substep is the second sign-in factor.

• Press the Windows key to open Windows search.
• Type the name of your browser into the search field.
• Press Enter to open the browser.
• Go to the AWS Management Console sign-in page.
• Select Root user.
• Enter the email address for your AWS account.
• Enter your root-user password.
• Complete the sign-in process.

You are now using the administrative session that needs MFA protection.

• Choose your account name in the upper-right navigation bar.
• Choose Security credentials.
• Check the root user's MFA section for an assigned device.

Choose the tab that matches what the MFA section shows.

✔️ An MFA device is already assigned

• Confirm that the root user's MFA section lists an assigned virtual MFA device.
• Keep the associated authenticator app ready for the fresh sign-in test.

The existing device can protect the root session without another registration.

ⓧ No MFA device is assigned

• Choose Assign MFA device.
• Choose Authenticator app.
• Choose Next.
• Open your prepared authenticator app.
• Select its option for adding an account with a QR code.
• Scan the QR code shown by AWS.
• Enter the current six-digit code in MFA code 1.
• Wait for the authenticator to generate the next code.
• Enter the new six-digit code in MFA code 2.
• Choose Add MFA.

The root user's security credentials now list the assigned virtual MFA device.

Before you test the new sign-in, do you expect the root password alone to be enough?

• Choose your account name in the upper-right navigation bar.
• Choose Sign out.
• Return to the AWS Management Console sign-in page.
• Select Root user.
• Enter the email address for your AWS account.
• Enter your root-user password.
• Enter the current MFA code from your authenticator app when AWS requests it.
• Complete the sign-in process.

You return to the console only after supplying the MFA code. That's the sensitive part secured: your root session now requires a second sign-in factor.

Is the MFA code rejected?

Wait for your authenticator app to generate a fresh six-digit code. Enter that code before it changes.

Confirm that you are reading the code from the account you added using the AWS QR code.

Ask for targeted help if the fresh code still fails: help me troubleshoot a rejected AWS root-user MFA code.

Enable billing metrics after the alarm preflight

Amazon CloudWatch stores the account's worldwide estimated charges in US East (N. Virginia). An empty alarm list leaves clear headroom for the single standard-resolution alarm you create later.

This is the cost checkpoint. The free allowance includes 10 standard-resolution alarm metrics, so the empty preflight keeps this project's later alarm within that allowance.

• Use the Region selector in the AWS Management Console to choose US East (N. Virginia).
• Use the console search field to search for CloudWatch.
• Select CloudWatch from the search results.
• Choose Alarms in the left navigation pane.
• Choose All alarms.
• Confirm that the alarm list contains no pre-existing alarms.

You should see an empty alarm list in US East (N. Virginia). This confirms the account has room for the one project alarm created later.

Do you see an existing alarm?

Do not delete an unfamiliar alarm. This project's cost assumption requires an empty alarm list before the project alarm is created.

Continue with an account that has no existing CloudWatch alarms. You can also remove only an alarm that you own before returning to this preflight.

Ask for help before changing an existing account control: help me assess an existing CloudWatch alarm safely.

The Billing and Cost Management preference makes the EstimatedCharges metric available to CloudWatch. Enabling the preference starts metric collection without creating an alarm or sending a message.

This preference cannot be disabled after activation. Its only role here is to make billing data available for the guardrail you create later.

• Use the AWS Management Console search field to search for Billing and Cost Management.
• Select Billing and Cost Management from the search results.
• Choose Billing Preferences in the left navigation pane.
• Choose Edit beside Alert preferences.
• Select Receive CloudWatch Billing Alerts.
• Choose Save preferences.

Expect billing data to take about 15 minutes to appear after first-time enablement. That propagation can continue while you work through the IAM exercises.

Before the final check, which root-security state and two billing states do you expect to remain confirmed?

• Confirm that Receive CloudWatch Billing Alerts remains selected in Billing Preferences.
• Return to CloudWatch using the AWS Management Console search field.
• Confirm that the Region selector still shows US East (N. Virginia).
• Choose Alarms in the left navigation pane.
• Choose All alarms.
• Confirm that the alarm list still contains no pre-existing alarms.

The root user now requires an MFA code during fresh sign-in. Billing metric collection is enabled, while the CloudWatch alarm list remains empty.

The administrative starting point is secure, and billing data is propagating in the background. Next, you will use the IAM Policy Simulator to expose the risk in a bucket-wide claims policy.

Expose the Over-Broad Policy

Your root session is now protected by multi-factor authentication (MFA). The account's billing metric is propagating while you work on the trainee's access model.

A bucket-wide wildcard looks convenient. You will use the IAM Policy Simulator to test whether that shortcut keeps quarantine data outside the trainee's reach.

In this step, get ready to:

• Load an unsaved temporary policy in Custom mode.
• Compare the approved object path with the quarantine object path in one simulation.
• Document why the wildcard violates least privilege.

Load the temporary broad policy

Custom mode accepts pasted identity policies without saving or attaching them. The simulator returns authorization decisions without sending a service request.

• Return to the AWS Management Console root session from earlier.
• Use the console search bar to open AWS Identity and Access Management (IAM).
• Choose Policy simulator from the IAM navigation pane.
• Switch the simulator to Custom mode.
• Paste this temporary JSON policy into the custom policy editor:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::insurance-claims-data-lake/*"
    }
  ]
}

What Does This Policy Do?

• The Version value identifies the policy language version.
• The Allow effect permits the s3:GetObject action when the resource matches.
• The wildcard in arn:aws:s3:::insurance-claims-data-lake/* matches every object path beneath the fictional bucket name.

• Confirm that the policy editor accepts the policy without a syntax finding.
• Leave the policy unsaved in Custom mode.

Policy Editor Rejecting the JSON?

Check that every property name uses straight double quotes. Confirm that the opening and closing braces match.

Replace the editor contents with the complete reference below if the pasted structure changed.

help me find the JSON syntax problem

✔️ Awesome, I've got everything!

Your temporary policy is ready in Custom mode. Keep it unsaved while you run the simulation.

ⓧ I'd like to double check the full code

Compare your temporary policy with this complete reference:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::insurance-claims-data-lake/*"
    }
  ]
}

Simulate both object paths

A resource-specific simulation evaluates the same action against each object ARN. This comparison reveals the boundary created by the wildcard.

• Select Amazon S3 from the service list.
• Select s3:GetObject as the action.
• Add arn:aws:s3:::insurance-claims-data-lake/approved/sample.csv as a specific resource.
• Add arn:aws:s3:::insurance-claims-data-lake/quarantine/sample.csv as a second specific resource.

Before you run the simulation, do you think the wildcard distinguishes between the approved path and the quarantine path?

• Run the simulation.

Both resource rows show allowed. The broad wildcard treats the approved object and the quarantine object as equally readable.

Why Did Both Reads Succeed?

The wildcard matches every object path beneath insurance-claims-data-lake. Both simulated ARNs therefore match the policy's resource.

The simulator evaluates authorization without making an Amazon S3 request. This test creates no bucket or object.

Missing One of the Results?

Confirm that both full object ARNs appear as separate specific resources. Each ARN must end with sample.csv.

Check that s3:GetObject is the selected action. A bucket-level action evaluates a different resource format.

help me configure both simulation resources

Document the least-privilege gap

Least privilege gives an identity only the access required for its task. The trainee needs approved claims reads, so a policy that also permits quarantine reads breaks that boundary.

• Compare the resource portion of the two simulated ARNs.
• Trace both matches back to the * in the temporary policy.
• Leave the temporary policy unsaved in Custom mode.
• Keep the temporary policy detached from every identity.

Before your final check, do you expect the temporary wildcard to distinguish between these two paths?

• Review the result for arn:aws:s3:::insurance-claims-data-lake/approved/sample.csv.
• Review the result for arn:aws:s3:::insurance-claims-data-lake/quarantine/sample.csv.

Good catch. You have proved that both paths return allowed under the unsaved wildcard policy.

The exposure is documented without creating a real data lake. Next, you will replace the wildcard with restricted reads and centralize the corrected controls on one group.

Build the Restricted Onboarding Package

Your IAM Policy Simulator test exposed the risk in a bucket-wide wildcard. The policy allowed reads from the approved claims path.

It also allowed reads from the quarantine path. You will now apply least privilege through two reusable policies on one AWS Identity and Access Management (IAM) group.

In this step, get ready to:

• Create the prefix-scoped ClaimsDataReadOnly policy.
• Protect claims access with MFA through the ClaimsDataEngineers group.
• Onboard claims-data-trainee with console-only credentials.

Create the restricted claims policy

A customer managed policy packages permissions into a reusable document. This policy uses an explicit deny to block listing outside the approved prefix.

The object permission is also prefix-scoped. Amazon S3 reads apply only to objects under approved/*.

• Choose Policies in the IAM navigation pane.
• Choose Create policy.

You should see the policy editor for a new customer managed policy.

• Choose JSON in the Policy editor.
• Replace the editor contents with this policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListApprovedClaims",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::insurance-claims-data-lake",
      "Condition": {"StringEquals": {"s3:prefix": "approved"}}
    },
    {
      "Sid": "DenyListOutsideApprovedClaims",
      "Effect": "Deny",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::insurance-claims-data-lake",
      "Condition": {"StringNotEquals": {"s3:prefix": "approved"}}
    },
    {
      "Sid": "AllowReadApprovedClaims",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::insurance-claims-data-lake/approved/*"
    }
  ]
}

What does this policy do?

• The AllowListApprovedClaims statement permits bucket listing when s3:prefix equals approved.
• The DenyListOutsideApprovedClaims statement explicitly denies other prefix values.
• The AllowReadApprovedClaims statement permits object reads only under the approved path.
• No statement permits object writes to the fictional claims bucket.

• Confirm that the editor shows no blocking validation findings.
• Choose Next.

You should see the policy details page where you can name the reusable permission document.

• Enter ClaimsDataReadOnly in Policy Name.
• Choose Create policy.

Good progress. You should see ClaimsDataReadOnly in the customer managed policy list.

Seeing policy validation findings?

Check that every policy key uses double quotes. Confirm that each opening brace has a matching closing brace.

Make sure the object resource ends with /approved/*. The bucket resource for s3:ListBucket has no trailing wildcard.

Help me check my ClaimsDataReadOnly policy.

✔️ Awesome, I've got everything!

Your restricted data policy is saved. Confirm that ClaimsDataReadOnly appears under customer managed policies.

ⓧ I'd like to double check the full code

Compare your complete ClaimsDataReadOnly policy with this document:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListApprovedClaims",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::insurance-claims-data-lake",
      "Condition": {"StringEquals": {"s3:prefix": "approved"}}
    },
    {
      "Sid": "DenyListOutsideApprovedClaims",
      "Effect": "Deny",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::insurance-claims-data-lake",
      "Condition": {"StringNotEquals": {"s3:prefix": "approved"}}
    },
    {
      "Sid": "AllowReadApprovedClaims",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::insurance-claims-data-lake/approved/*"
    }
  ]
}

Add MFA enforcement and centralize the policies

The data policy controls which claims operations are available. The MFA policy blocks protected actions until the console session includes MFA authentication.

The self-management permissions preserve the trainee's ability to enroll a virtual MFA device. An IAM group applies both policies from one central place.

• Choose Policies in the IAM navigation pane.
• Choose Create policy.

You should see a fresh policy editor.

• Choose JSON in the Policy editor.
• Replace the editor contents with the complete MFA-only self-management policy:

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "AllowViewAccountInfo",
      "Effect": "Allow",
      "Action": "iam:ListVirtualMFADevices",
      "Resource": "*"
    },
    {
      "Sid": "AllowManageOwnVirtualMFADevice",
      "Effect": "Allow",
      "Action": ["iam:CreateVirtualMFADevice"],
      "Resource": "arn:aws:iam::*:mfa/*"
    },
    {
      "Sid": "AllowManageOwnUserMFA",
      "Effect": "Allow",
      "Action": ["iam:DeactivateMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:GetMFADevice", "iam:ListMFADevices", "iam:ResyncMFADevice"],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "DenyAllExceptListedIfNoMFA",
      "Effect": "Deny",
      "NotAction": ["iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:ListMFADevices", "iam:ListVirtualMFADevices", "iam:ResyncMFADevice", "sts:GetSessionToken"],
      "Resource": "*",
      "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
    }
  ]
}

How does the MFA guardrail work?

• The AllowViewAccountInfo statement lets the trainee list virtual MFA devices.
• The AllowManageOwnVirtualMFADevice statement permits creation of a virtual MFA device.
• The AllowManageOwnUserMFA statement scopes MFA management to the signed-in user.
• The DenyAllExceptListedIfNoMFA statement denies protected actions when aws:MultiFactorAuthPresent is false.

• Confirm that the editor shows no blocking validation findings.
• Choose Next.

You should see the policy details page for the MFA guardrail.

• Enter RequireMFAForClaimsReaders in Policy Name.
• Choose Create policy.

You should see RequireMFAForClaimsReaders in the customer managed policy list. The MFA guardrail is ready for the group.

MFA policy not saving?

Check the braces around the BoolIfExists condition. Confirm that aws:MultiFactorAuthPresent is nested inside it.

Keep iam:DeleteVirtualMFADevice out of the unauthenticated action list. A cancelled enrollment requires administrator cleanup.

Help me check my MFA enforcement policy.

✔️ Awesome, I've got everything!

The MFA guardrail is saved. Confirm that RequireMFAForClaimsReaders appears under customer managed policies.

ⓧ I'd like to double check the full code

Compare your complete RequireMFAForClaimsReaders policy with this document:

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "AllowViewAccountInfo",
      "Effect": "Allow",
      "Action": "iam:ListVirtualMFADevices",
      "Resource": "*"
    },
    {
      "Sid": "AllowManageOwnVirtualMFADevice",
      "Effect": "Allow",
      "Action": ["iam:CreateVirtualMFADevice"],
      "Resource": "arn:aws:iam::*:mfa/*"
    },
    {
      "Sid": "AllowManageOwnUserMFA",
      "Effect": "Allow",
      "Action": ["iam:DeactivateMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:GetMFADevice", "iam:ListMFADevices", "iam:ResyncMFADevice"],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "DenyAllExceptListedIfNoMFA",
      "Effect": "Deny",
      "NotAction": ["iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:ListMFADevices", "iam:ListVirtualMFADevices", "iam:ResyncMFADevice", "sts:GetSessionToken"],
      "Resource": "*",
      "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
    }
  ]
}

The two policies now cover separate responsibilities. ClaimsDataEngineers combines them into one onboarding package.

• Choose User groups in the IAM navigation pane.
• Choose Create group.

You should see the group creation page with fields for the group name and attached policies.

• Enter ClaimsDataEngineers as the User group name.
• Search for ClaimsDataReadOnly in the policy list.
• Select ClaimsDataReadOnly.
• Clear the policy search.

The first policy should remain selected after you clear the search.

• Search for RequireMFAForClaimsReaders.
• Select RequireMFAForClaimsReaders.
• Confirm that exactly two policies are selected.
• Choose Create group.

You should see ClaimsDataEngineers in the group list. Its permissions should show exactly the two project policies.

Missing a group policy?

Return to the group permissions. Attach the missing customer managed policy by searching for its exact name.

Remove any extra policy before continuing. ClaimsDataEngineers should contain exactly the two project policies.

Help me correct my IAM group policies.

Create the console trainee

This focused lab uses an IAM user so you can observe group inheritance and MFA enforcement directly. AWS recommends federation with temporary credentials for production human access.

Why an IAM user here?

The IAM user makes the onboarding controls visible in one exercise. A mature organization should use federation for human access.

Creating console credentials is sensitive. You stay in control because this trainee receives no access keys.

• Choose Users in the IAM navigation pane.
• Choose Create user.

You should see the user creation form.

• Enter claims-data-trainee as the user name.
• Select Provide user access to the AWS Management Console - optional.

The console access options should now be available.

• Choose I want to create an IAM user.
• Select Autogenerated password.
• Select User must create a new password at next sign-in (recommended).
• Choose Next.

Why no access keys?

The trainee needs browser access for this onboarding flow. Console access provides that path without adding programmatic credentials.

• Choose the option to add the user to a group.
• Select ClaimsDataEngineers from the group list.
• Choose Next.

The review should show console access through an autogenerated password. It should also show membership in ClaimsDataEngineers.

• Confirm that the password must change at the first sign-in.
• Choose Create user.

You should see the Retrieve password page with the trainee's initial sign-in details.

Protect the credential CSV

The credential CSV contains a temporary password. Treat the page and downloaded file as private credentials.

• Download the credential CSV from Retrieve password.
• Store the credential CSV in a private location on your Windows device.
• Confirm that the file contains the console connection URL plus the trainee's initial sign-in details.
• Close the credential details after the file is stored.

Before you check the finished package, which two policies do you expect the trainee to inherit through the group?

• Return to Users in the IAM navigation pane.
• Select claims-data-trainee.
• Confirm that console access is enabled.
• Confirm that the user has no access keys.
• Confirm membership in ClaimsDataEngineers.

The trainee should show console access through the group. No access keys should appear.

• Return to User groups in the IAM navigation pane.
• Select ClaimsDataEngineers.
• Confirm that exactly two customer managed policies are attached.

You should see ClaimsDataReadOnly plus RequireMFAForClaimsReaders on the group. This proves the trainee inherits the complete onboarding package from one central group.

User setup does not match?

If group membership is missing, add claims-data-trainee to ClaimsDataEngineers from the user details.

If an access key appears, remove it before continuing. This project uses console access only.

Help me verify the trainee identity.

That's the onboarding package assembled. Your trainee now inherits restricted claims access plus MFA enforcement from one centrally managed group.

Your restricted onboarding package is ready. Next up, the trainee will encounter the MFA wall before proving the final access decisions.

Enroll MFA and Prove Access

Your onboarding package now gives claims-data-trainee its permissions through ClaimsDataEngineers. Both IAM policies are attached centrally.

A policy design can look correct while its live session context remains untested. This step tests the trainee's first AWS Management Console session before checking every claims decision in the IAM Policy Simulator.

In this step, get ready to:

• Test the trainee's first console session against the current guardrail.
• Complete the trainee's secure sign-in setup.
• Prove the final claims permissions with five simulations.

Test the trainee's first session

The trainee's initial session gives you a clean test of the attached guardrail. Amazon S3 provides the first live access check without creating a bucket.

Working with temporary credentials can feel risky. Keeping the credential CSV local protects the trainee's sign-in details.

• Start a separate private browsing session so your root session stays signed in.
• In File Explorer, locate the downloaded credential CSV.
• Open the downloaded credential CSV in a local spreadsheet viewer.
• Record the CSV's console connection URL here: your IAM user console connection URL.
• Paste your IAM user console connection URL into the private browser session's address bar.
• Press Enter to load the trainee sign-in page.

You should see the IAM user sign-in page for the account listed in the credential CSV.

• Enter claims-data-trainee as the user name.
• Enter the autogenerated password from the credential CSV.
• Submit the sign-in form.
• Create a new unique password when AWS requests the required password change.
• Confirm the new password in the confirmation field.
• Submit the password change.

You should reach the AWS Management Console as claims-data-trainee.

Before you test the service, predict whether this first session can reach the claims controls without a second factor.

• Use the AWS console search bar to search for S3.
• Select Amazon S3 from the search results.

You should see an access-denied result before the S3 console can expose claims data.

That denial is the intended result. You have proved that the MFA guardrail blocks protected actions in a session without MFA.

S3 does not show the planned denial?

• Confirm the private browser session shows claims-data-trainee in the account menu.
• Switch back to the root session to confirm that claims-data-trainee still belongs to ClaimsDataEngineers.
• Confirm that RequireMFAForClaimsReaders remains attached to the group.

help me diagnose why the trainee session is not showing the planned access denial

Enroll the trainee's MFA device

The denial identifies the missing session proof. A virtual MFA device uses Microsoft Authenticator to produce the six-digit codes that complete that proof.

• In the trainee session, choose the user name in the upper-right navigation bar.
• Choose Security credentials.
• Under Multi-factor Authentication (MFA), choose Assign MFA device.
• Choose Authenticator app.
• Choose Show QR code.

You should see the QR code that links the trainee's virtual MFA device to the authenticator.

• Switch back to Microsoft Authenticator on the MFA device from earlier.
• Select the plus icon.
• Choose Other account.
• Scan the QR code shown in the trainee session.
• Enter the current six-digit code in MFA code 1.
• Wait for Microsoft Authenticator to generate the next code.
• Enter the new six-digit code in MFA code 2.
• Choose Add MFA.

You should see the virtual MFA device listed under the trainee's security credentials.

Why does AWS request two codes?

AWS requests two consecutive codes during enrollment. The pair confirms that the authenticator can produce the sequence required for future sign-ins.

Are the MFA codes being rejected?

• Wait for a fresh code before filling MFA code 1.
• Enter the following code in MFA code 2.
• Use the root session to remove an orphaned virtual MFA device if an earlier enrollment was cancelled.

help me fix the trainee's rejected MFA enrollment codes

• Sign out of the trainee session.
• Return to your IAM user console connection URL in the separate browser session.
• Enter claims-data-trainee as the user name.
• Enter the changed password.
• Enter the current six-digit authenticator code when prompted.
• Complete the sign-in.

You should return to the AWS Management Console after the MFA prompt. That closes the trainee's secure sign-in loop.

No MFA prompt at sign-in?

• Confirm that the trainee's security credentials list an assigned virtual MFA device.
• End the previous trainee session completely before using the connection URL again.
• Confirm that the separate browser session shows claims-data-trainee after sign-in.

help me confirm that the trainee is signing in with MFA

Prove the composed permissions

Principal mode evaluates the policies already attached to a selected identity. The simulator returns authorization decisions without sending requests to a real S3 bucket.

• Switch back to the root browser session.
• Return to the IAM Policy simulator from earlier.
• Switch from Custom mode to Principal mode.
• Select claims-data-trainee as the principal.

You should see the policies attached through ClaimsDataEngineers in the principal evaluation. The temporary Custom mode policy remains unattached.

• Add aws:MultiFactorAuthPresent in the global request conditions area.
• Set the condition value to true.

Before you run the checks, predict which claims operations should succeed with the MFA condition set to true.

• Select s3:GetObject for the first simulation.

The simulator should now show the area for specific object resources.

• Add arn:aws:s3:::insurance-claims-data-lake/approved/sample.csv as the first specific resource.
• Add arn:aws:s3:::insurance-claims-data-lake/quarantine/sample.csv as the second specific resource.
• Run the simulation.

The approved object read should show allowed. The quarantine object read should show a denied result.

• Clear the previous action selection.
• Select s3:ListBucket for the next simulation.

The simulator should now show the service-specific condition area for the bucket-list action.

• Set the specific resource to arn:aws:s3:::insurance-claims-data-lake.
• Set s3:prefix to approved.
• Run the simulation.

The approved-prefix list should show allowed.

• Change the s3:prefix value to quarantine.
• Run the simulation again.

The quarantine-prefix list should show a denied result.

Before the final check, predict whether MFA should give the trainee permission to upload an approved claims object.

• Clear the previous action selection.
• Select s3:PutObject for the final simulation.

The simulator should now show the area for a specific destination object.

• Add arn:aws:s3:::insurance-claims-data-lake/approved/sample.csv as the specific resource.
• Run the simulation.

The approved-path write should show a denied result.

What do these results prove?

• The approved object read is allowed because ClaimsDataReadOnly permits s3:GetObject under approved/*.
• The approved-prefix list is allowed because s3:prefix matches approved.
• The quarantine object read reaches an implicit deny because no allow statement matches its object ARN.
• The quarantine-prefix list reaches an explicit deny because the list policy rejects prefixes outside approved.
• The approved-path write reaches an implicit deny because no policy allows s3:PutObject.

You have now proved the full access boundary. MFA unlocks only the claims operations granted by the data policy.

Is an approved action still denied?

• Confirm that claims-data-trainee is the selected principal.
• Confirm that aws:MultiFactorAuthPresent is set to true.
• Confirm that the evaluation shows both group policies.
• Confirm that the approved resource ARN contains /approved/sample.csv.

help me diagnose an unexpected Principal mode decision

Your trainee can now sign in with MFA while remaining confined to approved claims reads. Next, you will turn the account's billing metric into a proactive email guardrail.

Add the Billing Guardrail

Your trainee now signs in with MFA. The IAM Policy Simulator proved that the trainee can read approved claims without reaching quarantine data.

Manual billing checks leave the account unmonitored between visits. Amazon CloudWatch closes that gap by watching the account's worldwide estimated charges.

In this step, get ready to:

• Select the account's estimated charges metric in CloudWatch.
• Create a billing alarm with a one-dollar threshold.
• Connect the alarm to a confirmed Amazon SNS email subscription.

Select the billing metric

CloudWatch stores billing metrics in US East (N. Virginia). The metric covers estimated charges from every AWS Region.

• Switch back to the root-user browser session from earlier.
• Use the Region selector in the top navigation bar to select US East (N. Virginia).
• Enter Amazon CloudWatch in the console search bar.
• Select CloudWatch from the search results.
• Choose Alarms in the left navigation pane.
• Choose All alarms.
• Choose Create alarm.
• Choose Select metric.

The metric picker groups account data by AWS namespace. Billing contains the account-wide estimated charges metric you need.

• Choose Billing under AWS namespaces.
• Choose Total Estimated Charge.
• Select the checkbox beside EstimatedCharges.
• Choose Select metric.

You should see EstimatedCharges on the metric configuration page. This confirms that the alarm will evaluate worldwide estimated charges.

What does EstimatedCharges measure?

AWS sends estimated charges to CloudWatch several times each day. The metric gives the alarm a single account-wide value to evaluate.

Keeping the metric in US East (N. Virginia) is required even when resources run elsewhere.

Can't see the Billing namespace?

Billing data can take about 15 minutes to appear after Receive CloudWatch Billing Alerts is enabled. Your earlier IAM work used most of that waiting period.

• Refresh the metric picker after the propagation window has passed.
• Confirm that the console Region remains set to US East (N. Virginia).

help me find the CloudWatch billing metric.

Configure the alarm and topic

The alarm evaluates each billing datapoint against your threshold. Its notification action sends state changes through an SNS topic to your email inbox.

Your cost guardrail

Creating a billing alert can feel risky when the goal is to avoid surprise charges. Your preflight found no existing CloudWatch alarms.

This project creates one standard alarm metric within the current CloudWatch allowance. It publishes no test message.

• Set the Statistic to Maximum.
• Set the Period to 6 hours.
• Choose Static as the threshold type.
• Choose Greater as the comparison.
• Enter 1 as the USD threshold value.
• Set the alarm requirement to 1 out of 1 datapoints.
• Set the missing-data treatment to Treat missing data as missing.
• Choose Next.

Why these alarm settings?

The Maximum statistic evaluates the highest estimated charge reported during each 6 hours period.

The 1 out of 1 setting lets one breaching datapoint activate the alarm. Missing data stays missing instead of being treated as a safe value.

The next screen connects the alarm to an email destination. CloudWatch creates the notification target as a Standard SNS topic.

• Choose the option to create a new SNS topic in the notification area.
• Enter claims-data-lake-billing-alerts as the topic name.
• Enter the address of your accessible email inbox.
• Choose Create topic.

The new topic becomes the alarm's notification target. The email endpoint still needs confirmation before it can receive notifications.

• Choose Next.
• Enter ClaimsDataLake-Billing-Alert as the alarm name.
• Choose Next.
• Review the alarm summary to confirm every setting from this substep.
• Choose Create alarm.

That is the billing guardrail created. CloudWatch now has an alarm connected to claims-data-lake-billing-alerts.

Why might the alarm activate immediately?

If current estimated charges already exceed 1 USD, the new alarm enters ALARM immediately. That state reflects the existing account estimate.

Confirm the subscription and verify

An email subscription must be confirmed before the endpoint can receive SNS messages. The confirmation link proves that you control the destination inbox.

• Switch to the email inbox you entered in CloudWatch.
• Find the subscription confirmation email from Amazon SNS.
• Open the confirmation email.
• Choose the subscription confirmation link in the email.

You should see a page confirming the subscription. Good work. Your email endpoint can now receive notifications from the billing topic.

The confirmed subscription already proves the notification path exists. A test message would add an unnecessary email delivery.

• Skip publishing a test message.
• Return to the root-user browser session.
• Enter Amazon SNS in the console search bar.
• Select Amazon SNS from the search results.
• Choose Subscriptions in the left navigation pane.
• Locate the subscription for claims-data-lake-billing-alerts.

You should see Confirmed as the subscription status. This proves that the email endpoint is active.

Can't find the confirmation email?

• Check the spam or junk folder in your email inbox.
• Compare the destination address in Subscriptions with the inbox you opened.

help me troubleshoot my SNS confirmation email.

Before the final check, what resources do you expect to find in CloudWatch and Amazon SNS? Keep your prediction in mind.

• Return to Amazon CloudWatch in the root-user browser session.
• Confirm that the Region selector shows US East (N. Virginia).
• Choose Alarms in the left navigation pane.
• Choose All alarms.
• Locate ClaimsDataLake-Billing-Alert in the alarm list.

You should see ClaimsDataLake-Billing-Alert listed in US East (N. Virginia). The SNS subscription you checked shows Confirmed.

Strong finish. Your account now has a proactive billing alarm connected to a confirmed email destination.

Secret mission

Prove Which Policy Enforces MFA

A denial proves that access is blocked. This challenge uses a what-if simulation to identify the exact policy behind that decision without changing the live IAM configuration.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep the training resources active, disable the trainee's console access for later, or delete the package entirely. This project remains at $0 under the preflight you completed.

Resources you used:

• One IAM user: claims-data-trainee.
• One IAM group: ClaimsDataEngineers.
• Two customer managed IAM policies: ClaimsDataReadOnly and RequireMFAForClaimsReaders.
• One virtual MFA association for claims-data-trainee.
• One CloudWatch alarm in US East (N. Virginia): ClaimsDataLake-Billing-Alert.
• One Amazon SNS Standard topic: claims-data-lake-billing-alerts.
• One confirmed email subscription attached to claims-data-lake-billing-alerts.

What stays outside cleanup?

The root user's virtual MFA device stays assigned. It continues to protect the account's administrative sign-in.

The Receive CloudWatch Billing Alerts preference stays enabled. AWS does not let you disable this data collection after activation.

Nothing was created in Amazon S3. There is no claims bucket or object to remove.

Keep everything running

No action needed. Choose this if you want to keep the trainee identity and active billing alert for more practice.

• The claims-data-trainee identity remains available through MFA-protected console access.
• The ClaimsDataEngineers group continues to apply both customer managed policies.
• The ClaimsDataLake-Billing-Alert alarm continues to monitor the account's worldwide estimated charges.
• The claims-data-lake-billing-alerts topic remains connected to your confirmed email subscription.
• The trainee keeps long-term console credentials, so the identity needs regular review.

Pause - I'll come back to this later

This option blocks the trainee's console sign-in. The policies and billing guardrail remain ready for later.

Disable the trainee's console access

• Return to IAM in the AWS Management Console from earlier.
• Choose Users in the navigation pane.
• Select claims-data-trainee.
• Choose the Security credentials tab.
• Find the Console sign-in section.
• Choose Manage console access.
• Choose Disable access.
• Confirm that the console sign-in section now shows that the trainee cannot sign in.

Good call: the trainee's console sign-in is now disabled. Your policies and billing alert remain ready for later.

Delete - I don't want to use this again

These deletions are permanent but limited to the training identity and alert resources named below. Follow the sections in order so each policy is detached before you remove it.

Delete the trainee identity

• Return to IAM in the AWS Management Console from earlier.
• Choose Users in the navigation pane.
• Select claims-data-trainee.
• Choose Delete.
• Enter claims-data-trainee when IAM asks for the user name.
• Confirm the user deletion.

Deleting the user also removes its console password, group membership, and virtual MFA association.

Delete the IAM group

• Choose User groups in the IAM navigation pane.
• Select ClaimsDataEngineers.
• Choose Delete.
• Enter ClaimsDataEngineers when IAM asks for the group name.
• Confirm the group deletion.

Deleting the group detaches both customer managed policies. The policies still exist until you remove them next.

Delete the customer managed policies

• Choose Policies in the IAM navigation pane.
• Select ClaimsDataReadOnly.
• Choose Actions.
• Choose Delete.
• Confirm the policy deletion.
• Repeat these policy deletion steps for RequireMFAForClaimsReaders.

Delete the billing alarm

• Set the console Region to US East (N. Virginia).
• Return to CloudWatch from earlier.
• Choose Alarms in the navigation pane.
• Choose All alarms.
• Select ClaimsDataLake-Billing-Alert.
• Choose Actions.
• Choose Delete.
• Confirm the alarm deletion.

Delete the confirmed email subscription

• Return to Amazon SNS from earlier.
• Choose Subscriptions in the navigation pane.
• Select the confirmed email subscription connected to claims-data-lake-billing-alerts.
• Choose Delete.
• Confirm the subscription deletion.

Delete the SNS topic

• Choose Topics in the Amazon SNS navigation pane.
• Select claims-data-lake-billing-alerts.
• Choose Delete.
• Enter delete me in the confirmation field.
• Confirm the topic deletion.

That closes the lab cleanly: the training identity and billing notification path are gone. Your root MFA protection remains active.

Nice Work!

Nice Work!

You did it! You built an MFA-protected claims-data onboarding package with AWS Identity and Access Management.

You've learned how to:

• Build a group-based onboarding pattern where claims-data-trainee inherits two customer managed policies through ClaimsDataEngineers. Keep the trainee free of access keys.
• Expose an over-broad object wildcard for Amazon S3 with IAM Policy Simulator. Restrict access to the approved prefix. Confirm that quarantine reads stay denied. Confirm that writes stay denied.
• Create a CloudWatch billing alarm that tracks worldwide estimated charges. Connect it to a confirmed email subscription through Amazon SNS.
• Secret Mission: Isolate RequireMFAForClaimsReaders with policy exclusion. Prove that it produces the explicit deny when MFA is absent. Leave the live IAM attachments unchanged.

Ready to quiz yourself?