Braket's errors are different in character from Qiskit's, Cirq's, or PennyLane's, because Braket rides on top of AWS infrastructure. Most problems aren't about circuit construction. They're about AWS account setup, permissions, and the operational realities of submitting jobs to hardware you don't control the schedule of.
NoCredentialsError
from braket.aws import AwsDevice
device = AwsDevice("arn:aws:braket:::device/quantum-simulator/amazon/sv1")
device.run(circuit, shots=100) # botocore.exceptions.NoCredentialsError
Braket's SDK authenticates through the same credential chain as any AWS SDK (boto3), not through its own login system. If credentials aren't configured, either via aws configure, environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY), or an attached IAM role if you're running inside AWS infrastructure, every Braket call fails at the authentication step regardless of what the circuit does. Run aws configure once locally, or verify credentials are present with aws sts get-caller-identity before debugging anything circuit-related.
AccessDeniedException on a device or S3 bucket
Braket needs two separate permission grants: access to submit tasks to the specific device or simulator ARN, and write access to the S3 bucket where results get stored. An IAM policy that grants one but not the other produces an access-denied error that names the resource but not always clearly which permission is missing. Check that your IAM role or user has both braket:* permissions scoped to the device you're targeting and s3:PutObject/s3:GetObject on the results bucket.
S3 bucket region mismatch
device.run(circuit, s3_destination_folder=("my-bucket", "results"))
# ClientError: bucket must be in the same region as the device
Braket requires the S3 bucket storing results to be in the same AWS region as the device you're submitting to. A bucket created in us-east-1 won't work with a device only available in us-west-1, and the error names the mismatch but not always which region the device needs. Check the device's region with AwsDevice(...).properties or the Braket console before creating the results bucket, not after.
A task that looks stuck but is only queued
Real QPU devices on Braket (Rigetti, IonQ, QuEra, and others available through it) run on availability windows, not on-demand. A task submitted while a device is offline doesn't error, it queues indefinitely until the device's next window opens, which from the caller's side looks identical to a hang. Check device.status before submitting, and check the specific device's availability schedule on the Braket console rather than assuming a task.result() call that hasn't returned means something broke.
Unexpected cost on a QPU task
Simulator tasks on Braket are billed per-task at a flat rate. Real QPU tasks are billed per-shot on top of a per-task fee, and it adds up faster than the free-tier mental model most people bring from IBM Quantum's free minutes. A circuit debugged locally with shots=10000 on a free simulator, then pointed at a real QPU device without adjusting shot count, produces a real, sometimes surprising, charge. Set AWS Budget alerts on the Braket service specifically before running QPU tasks at any real shot count, and test circuit logic on LocalSimulator() or the managed simulators (SV1, DM1, TN1) before switching the device ARN to hardware.
The pattern behind most of these
Braket's errors are mostly AWS errors wearing a quantum computing costume: credentials, IAM policy, S3 region matching, and billing are the same categories of problem you'd hit running any AWS service, and debugging them means checking the AWS side of the stack before assuming the circuit or the SDK call is wrong.