5 exercises — Practice cloud security vocabulary in English: IAM, RBAC, ABAC, least privilege, VPC, security groups, KMS, WAF, CSPM, and assume role patterns.
Core cloud security vocabulary clusters
Identity: IAM user, role, group, policy, principal, assume role, service account, OIDC federation
Access control: RBAC (role-based), ABAC (attribute-based), least privilege, permission boundary, SCPs (Service Control Policies)
A cloud architect explains IAM roles to a developer who has been using long-lived access keys: "Stop using access keys for your EC2 instances. Attach an IAM role to the instance instead. The instance metadata service vends temporary credentials — access key, secret key, and session token — that rotate automatically every hour. Your application uses the AWS SDK, which picks up these credentials automatically. No secrets in code, no secrets in environment variables. If credentials leak, they expire within an hour. This is the correct way to grant AWS permissions to workloads running in AWS." What is the security advantage of an IAM role over long-lived IAM access keys?
IAM role temporary credentials: generated by STS (Security Token Service). Consist of AccessKeyId, SecretAccessKey, SessionToken, and Expiration (typically 1 hour). The SDK refreshes them automatically before expiry. Long-lived access keys: static credentials tied to an IAM user. If leaked (in code, GitHub, logs), they remain valid until manually rotated or deleted. Rotation is manual and error-prone. IAM entity types: User: represents a person or application. Has permanent credentials (password, access keys). Group: collection of users, policies attached to the group apply to all members. Role: assumed by a principal (EC2 instance, Lambda function, another AWS account, OIDC federated identity). Issues temporary credentials. Policy: JSON document defining allowed/denied actions. Assume role vocabulary: sts:AssumeRole: API call to get temporary credentials for a role. Trust policy: the role's policy that specifies who can assume it. Session policies: optional inline policy further restricting the assumed role's permissions. Cross-account: RoleA in Account A trusts Account B — Account B's principals can assume RoleA. Used for multi-account architectures. OIDC federation: GitHub Actions, Kubernetes service accounts, and other OIDC providers can assume AWS roles without storing long-lived credentials. In conversation: 'Every access key in a codebase is a potential breach waiting to happen. Instance roles are the first thing we enforce in our cloud security baseline.'
2 / 5
A security engineer explains access control models during an architecture review: "We're debating RBAC versus ABAC for our multi-tenant SaaS. With RBAC — Role-Based Access Control — you assign roles to users and attach permissions to roles. 'Admin', 'Editor', 'Viewer'. Simple, auditable. But it doesn't scale when you need fine-grained control: 'Editor can edit documents they own in their organization but not others'. For that you need ABAC — Attribute-Based Access Control. The policy evaluates attributes: user.organization must equal resource.organization AND user.role must include 'Editor'. AWS IAM conditions implement ABAC." What is the key difference between RBAC and ABAC?
RBAC: permissions are attached to roles, roles are assigned to users. Predictable and auditable. Scales poorly when roles proliferate (role explosion: hundreds of fine-grained roles). ABAC: access decisions use conditions on attributes — user tags, resource tags, environment context. AWS IAM ABAC example: tag resources with Project=Alpha, tag users with Project=Alpha. IAM policy condition: StringEquals: {"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"}. Users can only act on resources with the same Project tag. No need to create per-project roles. Least privilege vocabulary: Principle of least privilege: grant only the minimum permissions needed for the task. Review and reduce over time. Permission boundary: an IAM policy that caps the maximum permissions a user or role can have, even if attached policies grant more. Useful for delegated admin — developers can create roles but not grant more than their own permissions. Service Control Policy (SCP): applied at AWS Organizations level. Limits maximum permissions across all accounts in an OU. Cannot grant permissions, only restrict. Resource policy: attached to the resource (S3 bucket policy, KMS key policy) specifying who can access it. Identity policy + Resource policy both must allow for cross-account access. In conversation: 'RBAC is fine until you have 50 tenants and need isolation between them. ABAC with resource tags scales to thousands of tenants with a single policy.'
3 / 5
A cloud security engineer reviews a network architecture: "Your database should be in a private subnet — no route to the internet gateway. EC2 instances in the public subnet talk to the database via a security group rule: allow port 5432 from the EC2 security group ID. Security groups are stateful — you only need an inbound rule; the response traffic is automatically allowed. NACLs are stateless — you need explicit inbound AND outbound rules. VPC endpoints let your Lambda functions call S3 and DynamoDB without going to the internet, even though they're in a VPC. PrivateLink lets you consume services in another VPC as if they were in yours." What is the difference between a security group and a network ACL (NACL) in AWS?
Security group: virtual firewall at the instance/ENI level. Stateful: if you allow inbound TCP 443, the response traffic is automatically allowed regardless of outbound rules. Only allow rules (no explicit deny). Rules can reference other security groups (e.g., allow from sg-0abc123 on port 5432). Default: all inbound denied, all outbound allowed. NACL (Network ACL): firewall at the subnet level. Stateless: must explicitly allow both inbound request AND outbound response. Rules evaluated in order by rule number. Supports both allow and deny rules. Default NACL: allows all traffic. Custom NACL: denies all until you add rules. When to use each: Security groups for micro-segmentation (instance-level isolation). NACLs for blocking specific IPs or CIDR ranges across a subnet (e.g., blocking a known malicious IP). VPC network vocabulary: Internet Gateway (IGW): enables internet connectivity for public subnets. NAT Gateway: allows private subnet resources to initiate outbound internet connections without being reachable inbound. VPC endpoint (Gateway): private route to S3 and DynamoDB without internet. Free. VPC endpoint (Interface): PrivateLink-based ENI in your subnet for other AWS services (SSM, KMS, etc.). VPC peering: non-transitive private connection between two VPCs. Transit Gateway: hub-and-spoke for connecting many VPCs and on-premises networks. In conversation: 'Security groups are your primary tool. NACLs are a secondary layer — use them for blocking known-bad IPs across an entire subnet, not for micro-segmentation.'
4 / 5
A security architect explains key management to the engineering team: "Never store encryption keys alongside the data they encrypt. We use AWS KMS for key management. KMS holds the Customer Master Key (CMK) — it never leaves KMS. We use envelope encryption: generate a unique data key for each object, encrypt the data with the data key, encrypt the data key with the CMK. Store the encrypted data key next to the encrypted object. To decrypt: call KMS to decrypt the data key (KMS checks your IAM permissions), then use the plaintext data key to decrypt the object locally. The plaintext data key exists in memory only for the duration of the operation." What is envelope encryption and why is it used with KMS?
Envelope encryption: a two-tier key hierarchy. Tier 1: KMS Customer Master Key (CMK) — stays in KMS, never exported. Tier 2: Data Encryption Key (DEK) — generated per-object, used for actual data encryption (AES-256), then encrypted with the CMK. Why: KMS has a 4KB API limit — you cannot send a 1GB file to KMS to encrypt. Envelope encryption encrypts the large file locally using a random DEK (fast AES), then only sends the 32-byte DEK to KMS for wrapping (key encryption). Decryption flow: (1) retrieve encrypted DEK from storage, (2) call KMS Decrypt API — KMS checks IAM permissions, decrypts DEK with CMK, returns plaintext DEK, (3) use plaintext DEK to decrypt data locally, (4) zero the plaintext DEK from memory. Key management vocabulary: CMK (Customer Master Key) / KMS Key: master key that never leaves KMS. Can be AWS-managed (free tier) or customer-managed (more control, key policy, audit). Key policy: resource policy on the KMS key. Must explicitly allow the account root to use it. Key rotation: AWS can auto-rotate CMK annually. Old key material retained to decrypt old ciphertext. Multi-region key: same key material in multiple regions — for disaster recovery or global data replication. SSE-S3 vs SSE-KMS: SSE-S3 uses AWS-managed key (no audit trail, no policy); SSE-KMS uses CMK (CloudTrail logs every decrypt, key policy controls access, cross-account possible). In conversation: 'SSE-KMS adds ~1ms latency per decrypt but gives you an audit trail of every access. For sensitive data, that visibility is worth it.'
5 / 5
A cloud security engineer presents their detection and posture management stack: "We have three layers. First, AWS WAF in front of our ALB — blocks OWASP Top 10 attacks, rate limits, and allows/blocks based on IP reputation lists and geographic rules. Second, GuardDuty for threat detection — it analyzes CloudTrail, VPC Flow Logs, and DNS logs with ML to detect anomalies: unusual API calls, crypto mining traffic, compromised credentials. Third, AWS Security Hub / a CSPM tool continuously scans our configuration for misconfigurations: public S3 buckets, overly permissive security groups, unencrypted volumes. These are detective controls — they don't prevent misconfigs, they find them fast." What is CSPM and how does it differ from a WAF?
CSPM (Cloud Security Posture Management): continuously monitors cloud configurations against security benchmarks (CIS Benchmarks, AWS Foundational Security Best Practices). Finds: S3 buckets with public access, security groups with 0.0.0.0/0 on port 22, EC2 instances without encrypted EBS, IAM users without MFA, exposed secrets in environment variables. Tools: AWS Security Hub, Prisma Cloud, Wiz, Orca Security. WAF (Web Application Firewall): sits in front of HTTP endpoints. Inspects each request against managed rule groups (OWASP Top 10, bot control, IP reputation). Blocks matching requests. Actions: allow, block, count, challenge (CAPTCHA). AWS WAF vocabulary: Rule group: a collection of rules (AWS managed or custom). Web ACL: a set of rule groups attached to an ALB, CloudFront, or API Gateway. Rate-based rule: blocks IP addresses that exceed a request rate. Regex match condition: inspect specific request fields for patterns. Security tooling landscape: SIEM (Security Information and Event Management): aggregates logs from all sources, correlates events, generates alerts. Examples: Splunk, Sumo Logic, AWS Security Lake + OpenSearch. SOAR (Security Orchestration, Automation, Response): automates response to security events. IDS/IPS: intrusion detection/prevention. Network-level (AWS Network Firewall, Suricata). Secrets manager: AWS Secrets Manager, HashiCorp Vault — store and rotate credentials programmatically. In conversation: 'CSPM told us we had 14 public S3 buckets we didn't know about. WAF told us we were getting 50,000 SQLi attempts per hour. You need both.'