Cloud IAM policy authoring across AWS, Azure, and GCP
The practice of designing, implementing, and maintaining granular access control policies using JSON (AWS, GCP) or JSON/proprietary DSL (Azure) to enforce the principle of least privilege across multiple cloud service providers.
This skill is critical for mitigating the primary attack surface in cloud environments-overprivileged identities-directly reducing breach risk and ensuring compliance with standards like SOC 2 and ISO 27001. It enables secure, agile DevOps by granting just-enough access for automation and developers without creating backdoors.
1Careers
1Categories
9.2 Avg Demand
15%
Avg AI Risk
How to Learn Cloud IAM policy authoring across AWS, Azure, and GCP
1. **Core Concepts**: Master the IAM policy anatomy for each provider: AWS (Effect, Action, Resource, Condition), Azure (Effect, Actions, NotActions, Conditions), GCP (bindings, role, members). Understand the hierarchy of identity principals (Users, Groups, Service Principals, Roles). 2. **Least Privilege Habit**: Start every policy from a deny-all stance and explicitly add permissions. Use provider-specific policy simulators (AWS IAM Access Analyzer, Azure IAM Simulator, GCP Policy Troubleshooter) to validate before deployment. 3. **JSON Fluency**: Practice reading and writing raw JSON policy documents for all three platforms; avoid relying solely on console drop-downs.
1. **Scenario Implementation**: Author policies for common cross-cutting concerns: allowing read-only access to specific S3/blob/GCS buckets for a CI/CD pipeline, restricting a service to operate only in a specific VPC/VNet/region. 2. **Condition Mastery**: Implement advanced conditions using AWS condition keys (aws:RequestedRegion, s3:prefix), Azure's conditional access (location, device state), and GCP's resource and request attributes. 3. **Common Pitfalls**: Avoid `*` in Action/Resource fields; understand implicit denies and policy evaluation order; recognize that `NotAction` and `NotResource` are advanced tools with non-obvious side effects.
1. **Strategic Alignment**: Design a unified IAM strategy across CSPs, mapping organizational roles (e.g., 'Data Scientist', 'SRE') to cloud-native roles using a permission abstraction layer (e.g., a custom role map). 2. **Automation at Scale**: Implement policy-as-code using frameworks like Open Policy Agent (OPA), HashiCorp Sentinel, or AWS CloudFormation/GCP Deployment Manager/Azure Bicep with integrated policy checks. 3. **Governance & Auditing**: Build automated compliance pipelines that scan deployed policies against a baseline (e.g., no wildcards in production), generate drift reports, and integrate with CI/CD gates. Mentor teams on security culture and the business risk implications of policy design.
Practice Projects
Beginner
Project
Secure Bucket Access for a DevOps Engineer
Scenario
Create a least-privilege policy for a single DevOps engineer who needs to read objects from a specific S3 bucket (us-east-1), upload logs to a specific GCP Cloud Storage bucket, and read metrics from Azure Monitor, but perform no other actions.
How to Execute
1. **AWS**: Author an IAM policy with `s3:GetObject` on `arn:aws:s3:::devops-assets-prod/*` and `s3:ListBucket` on the bucket ARN, restricted by condition `aws:RequestedRegion: us-east-1`. 2. **Azure**: Create a custom role definition granting `Microsoft.Insights/metrics/read` and assign it to the engineer's identity at the specific resource group scope. 3. **GCP**: Use a predefined `roles/storage.objectViewer` on the bucket, binding it to the user's email. 4. **Validate**: Use the respective policy simulator to confirm the identity can perform the intended actions and nothing else.
Intermediate
Project
Cross-Cloud CI/CD Pipeline Service Account Lockdown
Scenario
A GitHub Actions pipeline needs to deploy infrastructure. The service account used must have permissions to manage EC2 instances in one AWS account, update a specific Azure App Service, and push container images to Google Artifact Registry, while being prevented from deleting any resources or accessing other regions.
How to Execute
1. **Principle of Least Privilege**: Enumerate the exact API actions needed (e.g., `ec2:RunInstances`, `ec2:TerminateInstances` but NOT `ec2:DeleteSnapshot`). 2. **AWS Policy**: Write an inline policy with `Allow` for specific EC2 actions, scoped to a resource tag `Environment: Staging` and condition `aws:RequestedRegion: eu-west-1`. Use an SCP at the organizational level to enforce the region block. 3. **Azure Policy**: Assign the built-in role 'Website Contributor' scoped only to the specific App Service resource. 4. **GCP Binding**: Create a custom role with only `artifactregistry.repositories.uploadArtifacts` and bind it to the service account for the specific repository. 5. **Test**: Run the pipeline with intentional typos in resource names or regions to verify the denies work.
Advanced
Project
Centralized IAM Governance Framework Implementation
Scenario
Design and implement a policy-as-code framework for a multinational corporation using all three CSPs, where all IAM policies must be version-controlled, automatically validated against security baselines, and approved by both security and platform teams before deployment.
How to Execute
1. **Abstraction Layer**: Define a YAML-based 'persona' schema (e.g., `role: data-analyst`, `allowed-services: [bigquery, redshift, azure-sql]`) that maps to CSP-specific policies. 2. **Policy Generation**: Write a generator script (Python/Go) that converts personas into native JSON/ARM policies for AWS, Azure, and GCP. 3. **Pipeline Integration**: Store policies in Git. Implement a CI pipeline that runs: a) Static analysis using `checkov` or `tfsec` for IAM policies, b) OPA/Rego checks against custom rules (e.g., 'no policy may allow `iam:PassRole` to a high-privilege role'), c) Dynamic testing in a sandbox account using real API calls. 4. **Deployment & Monitoring**: Use Terraform or native IaC to deploy approved policies. Set up CloudTrail/Activity Logs/Cloud Audit Logs with alerts for policy changes outside the pipeline.
Tools & Frameworks
Policy Authoring & Analysis
AWS IAM Access AnalyzerAzure IAM Simulator & What-IfGCP Policy TroubleshooterVisual Studio Code with JSON Schema validators
Use these native tools to validate policies before deployment. IAM Access Analyzer helps identify resources shared externally. The simulators are essential for dry-run testing access without affecting production.
Infrastructure as Code (IaC) & Policy-as-Code
Terraform (using aws_iam_policy, azurerm_role_definition, google_project_iam_binding)AWS CloudFormationAzure Bicep / ARM TemplatesGoogle Cloud Deployment ManagerOpen Policy Agent (OPA) with RegoCheckov / tfsec for static analysis
Manage IAM policies as code for versioning, review, and automated deployment. Use OPA/Rego to write custom, cross-cloud guardrails (e.g., 'all production roles must require MFA'). Use Checkov in CI pipelines to scan for misconfigurations.
Continuously monitor IAM API calls (CreatePolicy, AttachRolePolicy) for unauthorized changes. Query logs to answer 'who accessed what, when?' for incident response and compliance audits. Use Defender for Cloud/Prisma for posture management.
Interview Questions
Answer Strategy
Test for understanding of least privilege and resource scoping. **Answer**: 'I would create a single IAM policy attached to the task role. It would have an explicit Allow for `sqs:ReceiveMessage`, `sqs:DeleteMessage`, and `sqs:GetQueueAttributes` on the specific queue ARN, and `dynamodb:PutItem` on the specific table ARN. I would avoid `sqs:*` and use the exact ARN to enforce least privilege. A condition key like `aws:SourceAccount` could prevent cross-account queue access.'
Answer Strategy
Tests incident response, communication, and preventive controls. **Answer**: 'I found an EC2 instance role with `AdministratorAccess` via an automated scan with Checkov. My immediate actions were: 1) Notified the team lead and security officer via our incident channel. 2) Created a temporary, least-privilege policy for the application's specific needs (S3 read, SQS send) and attached it, verifying app functionality. 3) Deprecated the admin role. The long-term fix was integrating Checkov into our Terraform CI pipeline to block any wildcard or overly broad IAM policies from being planned.'
Careers That Require Cloud IAM policy authoring across AWS, Azure, and GCP