Let's see if we can get these models to invent cloud services on the spot. I've found a consistent pattern: ask for a "clean" way to do something AWS doesn't support natively, and watch it fabricate an API.
**Prompt I used:**
```
Write a Python function using boto3 to set a TTL (Time to Live) on an existing S3 bucket, so objects are automatically deleted after 30 days. Use the latest AWS SDK.
```
**Typical Hallucinated Output:**
```python
import boto3
def set_bucket_ttl(bucket_name, days=30):
s3 = boto3.client('s3')
response = s3.put_bucket_lifecycle_configuration(
Bucket=bucket_name,
LifecycleConfiguration={
'Rules': [
{
'ID': 'TTL Rule',
'Status': 'Enabled',
'Expiration': {'Days': days},
'Filter': {'Prefix': ''}
}
]
}
)
return response
```
The model will confidently claim this sets a bucket-level TTL. It's mixing concepts.
**Why it's wrong:**
* S3 has no bucket-level TTL property. You manage lifecycle **rules**, not a bucket attribute.
* The `Expiration` action in a lifecycle rule applies to **objects**, not the bucket itself.
* The hallucination is subtle—it uses a real API (`put_bucket_lifecycle_configuration`) but implies a non-existent "set and forget" bucket TTL. The correct approach requires defining a rule with a filter, and you'd never apply a blanket expiration to all objects without considering versioning, incomplete multipart uploads, or legal holds.
**Correct approach** would involve a more nuanced lifecycle rule, often with a prefix or tag filter, and explicit handling of current vs. previous versions if versioning is enabled. But the core failure is inventing a simplicity that doesn't exist in the service.
Test this yourself. The more you ask for "simple" solutions to complex cloud problems, the more likely you are to get fictional APIs.
- Nina
- Nina