6.2.5. Tricky Distinctions & Common Pitfalls (Security Focus)

First Principle: Nuanced understanding of seemingly similar cloud security concepts and AWS services, and anticipating common misconfigurations, are critical for designing robust security architectures and avoiding errors.

The AWS SCS-C02 exam tests deep understanding, often through distinguishing between similar security concepts or AWS services and identifying common pitfalls.

Common Areas of Confusion (Security Focus):

• Security Groups (SGs) vs. Network ACLs (NACLs): SGs are instance-level, stateful, allow-only; NACLs are subnet-level, stateless, allow/deny, and rule order matters.
• IAM Identity-Based Policies vs. Resource-Based Policies: Attached to identity vs. attached to resource. Both must allow for access within the same account (unless the principal is the root user). For cross-account, the principal's identity policy and the resource policy must both allow access.
• IAM Policy Evaluation Logic: An explicit Deny always overrides any Allow.
• Service Control Policies (SCPs) vs. IAM Permissions Boundaries: SCPs set the maximum permissions for an entire account (organizational guardrail), while Permissions Boundaries set the maximum for a specific identity (user or role). The effective permission is the intersection of all applicable policies.
• Encryption at Rest vs. Encryption in Transit: Protecting data on storage vs. protecting data in motion over a network.
• AWS KMS Customer Managed Keys (CMKs) vs. AWS-managed keys: Full user control, auditability, and cost vs. AWS-managed simplicity and lower cost.
• CloudWatch vs. CloudTrail vs. VPC Flow Logs: CloudWatch is for performance metrics, operational logs, and alarms. CloudTrail is for auditing API activity. VPC Flow Logs are for capturing IP traffic information.
• Amazon GuardDuty vs. Amazon Inspector: GuardDuty is for threat detection (analyzing logs for malicious behavior). Inspector is for vulnerability scanning (checking for known CVEs and misconfigurations).
• Common Pitfalls:
  • Ignoring Shared Responsibility Model: Not securing the "in the cloud" aspects like data, IAM, and OS patching.
  • Overly Permissive IAM Policies: Granting * permissions instead of applying least privilege.
  • Public S3 Buckets: Accidental data exposure due to misconfigured policies or ACLs.
  • Unpatched OS/Software: Leaving known vulnerabilities on EC2 instances or in container images.
  • Lack of Centralized Logging: Making auditing and incident investigation difficult or impossible.

Scenario: You are presented with an exam question that asks for the best way to control permissions for an EC2 instance and another about how to deny all actions from a specific IP range across an entire organization. You're trying to distinguish between Security Groups vs. NACLs, and IAM Policy evaluation logic vs. SCPs.

Reflection Question: How do you apply a First Principles approach to differentiate between Security Groups and Network ACLs (for instance vs. subnet control), and between IAM Policy evaluation logic and SCPs (for intra-account vs. organizational denies), to avoid common pitfalls and select the correct solution for specific security use cases?