0Pricing
AWS Solutions Architect · Lesson

Least-Privilege Principle

Apply the least-privilege principle to real scenarios and use AWS-managed policies versus inline policies wisely.

Least-Privilege Principle is a free AWS Solutions Architect lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the AWS Solutions Architect learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What Is Least Privilege?

Least privilege means giving every identity only the permissions it truly needs — nothing extra. If credentials leak, the damage stays small. 🛡️

Starting With Deny-by-Default

AWS makes least privilege easy: a new user or role starts with zero permissions. You add exactly what's needed, instead of taking away what isn't.

Over-Provisioning: The Common Mistake

The classic mistake is handing out AdministratorAccess because it's quick. One bug could then wipe your data. Scope to specific actions and resources instead.

# AVOID: wildcard permissions
{
  'Effect': 'Allow',
  'Action': '*',
  'Resource': '*'
}

# PREFER: scoped permissions
{
  'Effect': 'Allow',
  'Action': ['dynamodb:GetItem', 'dynamodb:Query'],
  'Resource': 'arn:aws:dynamodb:us-east-1:123456789:table/Orders'
}

AWS-Managed vs Customer-Managed Policies

AWS-managed policies are handy but often too broad. Customer-managed policies let you point at exactly the buckets or tables your app actually uses.

# Create a scoped customer-managed policy
aws iam create-policy \
  --policy-name LambdaOrdersReader \
  --policy-document file://orders-reader-policy.json

IAM Access Analyser

IAM Access Analyzer watches for resources exposed outside your account. It can even write tight policies for you by reading what an identity really used.

# Enable IAM Access Analyzer for the account
aws accessanalyzer create-analyzer \
  --analyzer-name MyAccountAnalyzer \
  --type ACCOUNT

Using Conditions to Tighten Permissions

Even when you must allow an action, conditions shrink the risk — require MFA, lock it to your office IP, or limit a user to their own folder. ✨

# Allow users to manage only their own folder in S3
{
  'Effect': 'Allow',
  'Action': ['s3:GetObject', 's3:PutObject'],
  'Resource': 'arn:aws:s3:::shared-bucket/${aws:username}/*'
}

Permissions Boundaries as Guardrails

When you let teams manage their own IAM, a permissions boundary caps what their roles can do. They build freely, but never beyond the limit you set.

Time-Bound Access with Session Policies

When you assume a role, you can pass a session policy that narrows it even further for that session. Perfect for giving a pipeline just-enough access.

# Assume a role with a restrictive session policy
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/DeployRole \
  --role-session-name deploy-session \
  --policy '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"lambda:UpdateFunctionCode","Resource":"arn:aws:lambda:us-east-1:123456789012:function:MyApp"}]}'

Tag-Based Access Control (ABAC)

ABAC grants access by matching tags instead of listing every resource. For example, allow a role to stop only the EC2 instances tagged with its own team.

{
  'Effect': 'Allow',
  'Action': 'ec2:StopInstances',
  'Resource': '*',
  'Condition': {
    'StringEquals': {
      'ec2:ResourceTag/Team': '${aws:PrincipalTag/Team}'
    }
  }
}

Reviewing Unused Permissions

AWS tracks when each permission was last used. Last Accessed data reveals permissions sitting unused for 90+ days — clear candidates to remove.

# Get service last-accessed data for a role
aws iam generate-service-last-accessed-details \
  --arn arn:aws:iam::123456789012:role/MyLambdaRole

# Retrieve the report (use the JobId from above)
aws iam get-service-last-accessed-details --job-id <JobId>

Least Privilege for Data Access

Apply least privilege to data too: limit users to their own S3 folder, scope DynamoDB by user ID, and give each app its own database login.

Quick Check

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

Lesson Recap

Quick recap: least privilege means minimum permissions, Access Analyzer finds unused ones, and conditions plus boundaries keep things tight. Next: IAM best practices and MFA.

Frequently asked questions

Is the “Least-Privilege Principle” lesson free?

Yes — the full text of “Least-Privilege Principle” is free to read here on the web, and the AWS Solutions Architect course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the AWS Solutions Architect course, upgrade to CoddyKit PRO.

What will I learn in “Least-Privilege Principle”?

Apply the least-privilege principle to real scenarios and use AWS-managed policies versus inline policies wisely. You practise AWS Solutions Architect with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start AWS Solutions Architect?

No prior experience is required. AWS Solutions Architect on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Least-Privilege Principle” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this AWS Solutions Architect lesson?

Yes. Every AWS Solutions Architect lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. IAM Users and Groups
  2. IAM Roles and Policies
  3. Least-Privilege Principle
  4. IAM Best Practices and MFA
← Back to AWS Solutions Architect