Multi-Service Tradeoff — AWS Security Specialty (SCS-C03)
Every Service Is Right Until You Apply the Constraint
Lambda, ECS, EKS, and SQS all appear in security architecture scenarios, usually as components of a detection or remediation pipeline. The tradeoff question is never 'which service can do this' — it's 'which combination satisfies the latency, blast radius, and operational overhead constraint simultaneously.' Lambda suits event-driven, short-duration remediation. ECS and EKS carry container management overhead. SQS introduces decoupling but adds queue depth monitoring. Identify the dominant constraint first; the service selection follows.
What This Pattern Tests
The exam gives you a decoupling requirement and tests whether you pick the right messaging service. SQS is point-to-point with at-least-once delivery (Standard) or exactly-once (FIFO, 3,000 msg/s with batching). SNS is pub/sub fan-out to multiple subscribers. EventBridge is content-based routing with schema registry and 35+ AWS service sources. The trap is choosing SQS for fan-out (use SNS) or SNS for ordered processing (use SQS FIFO). DynamoDB vs. Aurora vs. ElastiCache follows the same pattern: key-value at any scale vs. relational joins vs. microsecond reads from memory.
Decision Axis
Communication pattern (point-to-point vs. fan-out vs. content routing) and data access pattern (key-value vs. relational vs. cache) determine the service.
Associated Traps
Decision Rules
Choose between AWS Step Functions (parallel-state orchestration with built-in audit trail satisfying simultaneous containment + evidence-preservation within MTTR) versus AWS Systems Manager Automation (sequential runbook execution that cannot natively parallelize isolation and snapshot steps, risking evidence loss or MTTR breach).
Whether to use AWS Fault Injection Service with native experiment templates and CloudTrail audit integration to drive IR plan validation, or build a custom Lambda plus EventBridge plus DynamoDB state-tracking harness that replicates the same fault-simulation capability at significantly higher operational complexity.
Which architecture satisfies both the 15-minute mean-time-to-respond SLA and the forensic evidence preservation requirement using the least custom state-management infrastructure?
Whether to orchestrate containment and evidence-collection as parallel managed states in Step Functions (correct) versus building equivalent logic inside a single Lambda function backed by a DynamoDB state table (over-engineered) or using a single SSM Automation document that executes steps sequentially (near-right, fails parallel-execution and audit-granularity constraints).
Whether to use IAM Identity Center as the managed workforce SSO orchestration layer (centralized MFA enforcement, AD sync, permission sets) or configure per-account SAML federation directly through STS (functionally valid but operationally over-engineered for this population and scale).
Whether to enforce per-tenant data isolation by attaching an inline session policy to the STS AssumeRole call versus applying IAM permission boundaries to the shared role — one scopes the effective credentials to the tenant context at issuance time, the other only caps the permission ceiling and requires an identity policy to grant anything, providing no session-level tenant isolation.
Whether the identity population is the organization's own workforce or an external third party determines whether IAM Identity Center or Cognito (User Pools + Identity Pools) is the correct managed service for MFA-enforced temporary credential issuance — the two services overlap on capabilities but diverge sharply on intended identity population boundary.
Whether to use IAM Identity Center permission sets (centralized RBAC provisioned automatically per assignment) or IAM ABAC with tag-based conditions when the access pattern is role-static and role proliferation must be minimized — ABAC is the near-right architecture because it reduces role count in the general case but adds tag-governance overhead that provides zero least-privilege improvement when no resource-attribute variance exists.
Should MFA enforcement be delegated to the IdP SAML assertion and trusted by STS, or enforced independently at the AWS authentication boundary before credentials are issued?
Whether STS AssumeRole with an inline session policy containing tenant-scoped resource conditions, or an IAM permission boundary attached to the shared execution role, satisfies both the anti-role-proliferation constraint and the compliance requirement for per-request authorization enforcement evidence.
Whether to use IAM Identity Center with AD Connector as a managed multi-account workforce identity orchestration layer or manually configure per-account IAM SAML providers with STS AssumeRoleWithSAML federation—selecting the option that satisfies least-privilege credential vending while minimizing identity lifecycle operational burden at multi-account scale.
When authorization requires evaluating two independent dynamic user attributes (tenant identity and clearance level) per request without role proliferation, does IAM ABAC with resource-tag conditions or Amazon Verified Permissions Cedar policies better satisfy the least-privilege constraint — and which option over-engineers the authorization infrastructure?
Whether to deploy IAM Identity Center with the corporate OIDC provider as an external identity source—gaining managed MFA enforcement, centralized permission sets, and automatic multi-account propagation—or to federate through Amazon Cognito user pool federation feeding per-account STS AssumeRoleWithWebIdentity, which is technically functional but misclassifies the identity population and demands custom MFA orchestration and per-account role mapping.
When tenant isolation maps statically and exclusively to a resource-path prefix, STS AssumeRole with an inline session policy is the minimal sufficient control — it scopes the vended credential at assumption time, requires no tag governance pipeline, no additional service, and no role proliferation, directly satisfying least-privilege with the lowest operational overhead.
Choose Amazon Cognito Identity Pools as the managed credential broker over a custom Lambda token vending machine backed by raw STS AssumeRoleWithWebIdentity calls — because Cognito natively enforces TTL, handles token refresh, maps external identity to IAM role, and requires zero custom orchestration code, directly satisfying the no-custom-token-management constraint.
Whether to use IAM Identity Center native ABAC — propagating the IdP business-unit attribute as a principal tag and enforcing isolation via a single tag-condition permission set — or a custom Lambda-brokered STS AssumeRole pattern that generates per-business-unit inline session policies at query time.
Whether the stated FIPS 140-2 Level 2 HSM requirement and CloudTrail audit obligation for S3 encryption at rest is fully satisfied by a KMS customer-managed key with SSE-KMS, or whether it requires a dedicated CloudHSM cluster — with the correct answer hinging on the precision of 'Level 2' versus 'Level 3' in the compliance language.
When a compliance mandate explicitly names FIPS 140-2 Level 3 hardware key custody AND requires automated rotation without manual re-import, CloudHSM is the correct service boundary — standard KMS operates at Level 2 and KMS imported key material does not support automatic rotation, requiring manual re-import on every rotation cycle.
Whether a KMS customer-managed key with S3 SSE-KMS plus S3 Object Lock in compliance mode fully satisfies the HIPAA encryption-at-rest and WORM retention requirements, or whether the phrase 'customer-managed key' triggers a CloudHSM hardware-custody architecture that over-engineers beyond the regulatory mandate.
When a compliance mandate simultaneously imposes FIPS 140-2 Level 3 key custody AND automated rotation, CloudHSM satisfies both constraints; KMS with imported key material satisfies the custody cue but is disqualified by the rotation-automation-requirement because imported keys cannot be automatically rotated in KMS and require manual re-import on every cycle.
Domain Coverage
Difficulty Breakdown