Running Q Developer in VS Code. Every other suggestion wants to push an AWS service we don't have clearance to use.
Example from today. Asked for a secure way to store app config.
```python
# What I asked for: A way to manage environment variables.
# What Q suggested:
import boto3
from botocore.exceptions import ClientError
def get_secret():
secret_name = "prod/app/config"
region_name = "us-east-1"
# Create a Secrets Manager client
session = boto3.session.Session()
client = session.client(
service_name='secretsmanager',
region_name=region_name
)
# ... rest of AWS Secrets Manager code ...
```
We're only approved for EC2 and S3. No Secrets Manager, no Parameter Store, no Bedrock, no RDS.
* Constantly suggests AWS SDK calls we can't implement.
* Ignores simple, local `.env` file solutions.
* Assumes full AWS ecosystem access by default.
Is there a setting or prompt to lock this down? Or do I just have to prep every query with "Without using unauthorized AWS services..."?
- bench_beast
Benchmarks don't lie.
I get this exact thing. It's obsessed with AWS solutions. But for your specific config problem, couldn't you use S3? I know you're approved for it.
You could store an encrypted config file in a private S3 bucket. The app pulls it on startup with boto3. It's more work than a .env file, but it's way better than hardcoding and uses a service you *can* use. Just a thought.
Is there really no setting to tell Q "only use EC2 & S3"? That's so annoying.
Containers are magic, but I want to know how the magic works.
That's a solid workaround using S3. I was actually thinking along the same lines, but the key detail I'd add is about managing the encryption key itself. If you're encrypting the config file before storing it, you'd need to store that key somewhere the app can access. That brings you back to a similar problem, doesn't it? Hardcoding that or using an environment variable partly defeats the purpose.
I'm wondering if there's a way to use S3 bucket policies and IAM roles on the EC2 instance so the file can be stored in plaintext but access is locked down tight. That would avoid the secondary key management issue. Have you tried that approach?
And to your last point, I haven't found a setting either. It seems like Q just defaults to the most "managed" AWS service for a given task, without considering governance constraints. A simple allow-list for services in its config would be so useful.
No setting for that. It's trained on general AWS docs and defaults to managed services.
I've tested this. You have to be explicit in the prompt. Start with your constraints.
For config, your fallback is S3 with IAM roles as mentioned. Use the instance profile. No keys in the file. Your bucket policy should only allow that role.
But you're right, it should ask about environment first.
Benchmarks don't lie.
Being explicit about constraints is the only way, but that's the whole problem.
If I have to debug and rewrite every prompt to list every AWS service we *can't* use, Q isn't saving time. It's creating more work.
The issue isn't our prompting. The tool defaults to the most expensive, lock-in option and forces us to fight it. That's a design failure.
If it's not a retention curve, I don't care.
I get where you're coming from. The frustration is real when the tool pushes you toward solutions you can't use. I think your point about "creating more work" hits the nail on the head.
However, I've found some success by making my initial prompt include a "constraint statement" that I reuse. For example, I often start with "We are restricted to EC2 and S3 only. Do not suggest any other AWS services." That's become my copy-paste boilerplate. It's not ideal that we need that, but it does cut down on the back-and-forth significantly.
The design definitely assumes you're working with a full AWS suite, which feels like a blind spot for teams with stricter cloud governance.