Shared Responsibility Confusion — AWS Cloud Practitioner (CLF-C02)
You put responsibility on the wrong side of the shared responsibility model. Managed services shift the boundary.
Managed doesn't mean AWS owns it
The word "managed" signals AWS handles infrastructure — not identity, not data classification, not access policy. CLF-C02 frequently pairs a managed service scenario with a customer-side control question to see if candidates blur the line. The trigger phrase is usually "who is responsible for" — when you see it, the answer is almost never entirely AWS.
The Scenario
The question asks who is responsible for patching the operating system on an RDS MySQL instance. You answer "the customer" because you manage OS patches on EC2. But RDS is a managed service — AWS handles OS patching, minor engine patches, and the underlying infrastructure. You are responsible for major engine version upgrades, database-level security (users, grants, network access via security groups), and data encryption configuration. The shared responsibility boundary shifts at every service tier: EC2 you patch everything, RDS you manage data-layer security, Lambda you manage code and IAM only.
How to Spot It
- •Map the service to its management level before answering. EC2 = you manage OS and up. RDS = AWS manages OS, you manage engine config and data access. Lambda = AWS manages everything below your function code. Fargate = AWS manages OS and runtime, you manage container image and task config.
- •Encryption at rest responsibility varies. S3 default encryption is automatic with SSE-S3 (AWS manages keys). KMS customer-managed keys shift key policy and rotation responsibility to you. CloudHSM shifts the entire key lifecycle to you. The exam tests which encryption model puts which responsibilities on which side.
- •When the question mentions a managed service (RDS, Aurora, ElastiCache, OpenSearch), your responsibility shrinks to data access control, network configuration (security groups, VPC placement), and application-level security. If your answer includes "patch the operating system" for a managed service, you are wrong.
Decision Rules
Identify 'trading capital expense for variable expense' as the AWS Cloud benefit triggered by an upfront-cost elimination requirement, distinguishing it from a service-level capability and from responsibilities that remain with the customer regardless of automation.
Identify capex-to-opex shift as the correct cloud benefit and reject distractors that either name a service feature (elasticity via Auto Scaling), misplace cost responsibility by implying AWS absorbs the customer's usage charges, or redirect to an unrelated benefit (global reach).
Moving from EC2 to RDS transfers OS and database engine patching responsibility to AWS but never transfers customer accountability for encryption key management, IAM access policy authorship, or data classification.
Determine which operational responsibility (OS and DB engine patching) transfers to AWS when moving from EC2 to RDS, and confirm that encryption key custody via KMS customer-managed keys remains a customer responsibility even on a fully managed service.
Which specific operational responsibilities transfer to AWS when moving a database from EC2 to RDS, and which data-layer controls remain permanently with the customer?
Whether migrating from EC2 to Lambda transfers IAM execution role configuration and function permission boundaries to AWS, or leaves them as a permanent customer responsibility.
Moving to a fully managed storage service offloads infrastructure duties to AWS but never transfers data-layer access control — the customer must configure bucket policies and IAM permissions regardless of S3's managed status.
Moving to Amazon RDS transfers infrastructure and patching duties to AWS but never transfers ownership of KMS key policies, key rotation configuration, or key access grants—those remain exclusively customer responsibilities regardless of how managed the compute or database layer is.
When a scenario requires hybrid connectivity with encryption-in-transit as an inherent service property and cost minimization as the dominant constraint, Site-to-Site VPN wins over Direct Connect because IPsec encryption is built in and there are no dedicated-port charges; Direct Connect fails because it neither encrypts by default nor minimizes recurring cost.
Does the scenario require customer-configured edge caching to offload origin load (CloudFront) or AWS-managed backbone routing that accelerates network paths without caching (Global Accelerator)?
Which party — AWS or the customer — is responsible for configuring the S3 Lifecycle policy that transitions objects to S3 Glacier after 60 days of inactivity?
Select AWS Backup with a defined backup plan and vault lifecycle rule when the retention scope spans EBS and EFS, because S3 lifecycle policies only govern object transitions inside S3 buckets and cannot fulfill cross-service backup retention obligations.
Choose Amazon Comprehend over Amazon SageMaker AI when the task is a standard NLP operation and the team must not own model development or training responsibilities.
Whether Amazon Athena's serverless model eliminates the customer's obligation to configure IAM policies, S3 bucket permissions, and encryption settings, or whether those controls remain permanently customer-owned regardless of the managed-service boundary.
Whether the compliance need requires retrieving AWS's pre-existing certification documentation (AWS Artifact) or automating the collection of the customer's own resource-level compliance evidence (AWS Audit Manager).
Determine whether the compliance need is to obtain AWS's own regulatory documentation (AWS Artifact) or to continuously evaluate the customer's resource configurations against compliance rules (AWS Config).
Is capturing the customer's own account-level API call history the customer's responsibility to configure (AWS CloudTrail), or does AWS's default monitoring infrastructure (Amazon CloudWatch) already satisfy this audit-trail-integrity requirement?
Domain Coverage
Difficulty Breakdown
Related Patterns