Amazon SES and Pinpoint

By the end of this lesson you will be able to

• Explain what Amazon SES is for (transactional, marketing and bulk email, sending and receiving), and send through the SES API or the SMTP interface.
• Get an account out of the SES sandbox, verify a domain, and set up SPF (custom MAIL FROM), DKIM (Easy DKIM) and DMARC so that mail lands in the inbox and forgeries do not.
• Protect sending reputation: bounce and complaint rates and the thresholds where SES reviews or pauses an account, the suppression list, shared vs dedicated IP addresses, configuration sets and event publishing.
• Receive email with receipt rules (S3, Lambda, SNS) and know where Mail Manager and Virtual Deliverability Manager fit.
• Tell SES apart from SNS precisely, and correct the notes' “SES only email, SNS only app-to-app or SMS”.
• Explain what Amazon Pinpoint did, its end of support on 30 October 2026, what continues as AWS End User Messaging, what moves to Amazon Connect, and what the exam may still expect.
• Pick SES, SNS, End User Messaging, Amazon Connect or SQS from the keywords of a scenario.

#Why: email and text messages are harder than they look

Almost every application has to talk to people: “your order is confirmed”, “here is your password reset link”, “your OTP is 482913”, “Eid sale starts tonight”. It looks simple. Install a mail server, connect to port 25, send. In practice it is one of the hardest things to run yourself:

• Mailbox providers do not trust strangers. A new server with no history, no SPF, DKIM or DMARC records and no reputation goes straight to spam, or is refused.
• Port 25 is throttled on EC2 by default, exactly because spammers love fresh cloud servers.
• One bad list poisons everything. If a marketing blast hits thousands of dead addresses, the same IP address then fails to deliver your password resets.
• Bounces, complaints and unsubscribes must be processed, or providers block you.
• SMS is a different world: per-country rules, registered sender IDs, carriers, prices per message.

AWS has managed services for each piece. This lesson covers the two that the SAA-C03 exam names, Amazon SES and Amazon Pinpoint, plus what replaced Pinpoint in 2026, and how they differ from SNS (lesson 13.4), which also sends email and SMS.

#Amazon SES

Amazon Simple Email Service (SES) is a fully managed, pay-per-use service to send and receive email at any scale, from your application, through an API or SMTP. You pay about 0.10 USD per 1,000 emails sent, with no servers, no minimum and no mail software to patch. It runs per Region: identities, quotas, the sandbox and reputation all belong to one account in one Region (Singapore ap-southeast-1 and Mumbai ap-south-1 are the usual choices from Bangladesh).

#Transactional, marketing and bulk email

SES handles both kinds of email that applications send, and AWS asks you which one is the majority when you request production access:

The distinction matters in practice: a bad marketing list can damage the reputation that your password resets depend on, so mature senders keep the two in separate configuration sets, often on separate dedicated IP pools, and sometimes in separate accounts.

#Two ways to send: the API or SMTP

• SES API (SDK or CLI): SendEmail in API v2 (aws sesv2). Authenticated with IAM like every AWS call (lesson 2.4), so a Lambda function or EC2 instance uses its role, and the policy can limit ses:SendEmail to one identity. You can send a simple message (subject, text, HTML), a raw MIME message you build yourself (custom headers, attachments), or a template with placeholders. A message can be up to 40 MB including attachments.
• SMTP interface: SES offers SMTP endpoints such as email-smtp.ap-southeast-1.amazonaws.com on ports 25, 587 or 2587 (STARTTLS) and 465 or 2465 (TLS wrapper). Use it when existing software (WordPress, an ERP, a printer, an old Java application) can only speak SMTP. It needs SMTP credentials, a user name and password derived from an IAM identity, which are not the same as an access key.

The console can also send test mail, which is how most people meet the sandbox.

#The sandbox and production access

Every new account starts in the SES sandbox, separately in each Region. In the sandbox you can use every feature, but:

• you can send only to verified addresses or domains (or to the mailbox simulator, a set of test addresses that simulate a delivery, bounce, complaint or suppression);
• at most 200 messages per 24 hours and 1 message per second.

To leave it, you request production access in the console or with aws sesv2 put-account-details --production-access-enabled: say whether the mail is mostly marketing or transactional, give the website URL, and confirm that you send only to people who asked for it and that you handle bounces and complaints. AWS gives an initial answer within about 96 hours; verifying your domain first helps. After approval the account gets a higher quota that AWS sets per account (50,000 a day is a commonly reported starting value, not a published default), which grows with good sending or on request, and you can mail any recipient. The From address must still belong to a verified identity.

#Verified identities: a domain or one address

An identity is what you are allowed to send from:

• Email address identity: SES sends a verification link to that address; click it and you can send from that one address. Good for a quick test.
• Domain identity: you prove you control the domain by publishing DNS records (with Easy DKIM, the three DKIM CNAME records do the verification). Then you can send from any address at that domain (orders@, no-reply@, support@) and its mail can be DKIM-signed. This is what production uses.

Identities are per Region; a domain verified in Singapore must be verified again in Mumbai (the same DNS records can be reused if you bring your own DKIM key, otherwise Easy DKIM issues new tokens per Region).

#Proving the mail is really yours: SPF, DKIM and DMARC

Email was designed without any check on the From line: any server can write From: no-reply@shop.example. Three DNS-based mechanisms fix this. You met their record types in lesson 8.1 (TXT and CNAME); here is what they do for SES.

#SPF and the custom MAIL FROM domain

SPF (Sender Policy Framework) is a TXT record that lists which servers may send mail for a domain. The receiver checks it against the MAIL FROM (envelope sender, also called Return-Path) domain, not the visible From line.

By default SES uses its own MAIL FROM, a subdomain of amazonses.com, so SPF passes, but for amazonses.com, not for your domain. To make SPF pass for your domain, set up a custom MAIL FROM domain, a subdomain such as mail.shop.example, with two records:

mail.shop.example.   MX   10 feedback-smtp.ap-southeast-1.amazonses.com
mail.shop.example.   TXT  "v=spf1 include:amazonses.com ~all"

The MX record is where bounces come back to SES; the TXT record is the SPF policy.

#DKIM and Easy DKIM

DKIM adds a digital signature to every message, made with a private key; the public key sits in DNS under <selector>._domainkey.<domain>. The receiver checks the signature, which proves the message really came from the domain owner and was not changed on the way.

With Easy DKIM, SES generates and holds the key pair. When you create a domain identity, SES gives you three CNAME records:

abc123._domainkey.shop.example.   CNAME   abc123.dkim.amazonses.com
def456._domainkey.shop.example.   CNAME   def456.dkim.amazonses.com
ghi789._domainkey.shop.example.   CNAME   ghi789.dkim.amazonses.com

Once SES sees them, the domain is verified and every message from it is signed. If you must control the key yourself, BYODKIM (bring your own DKIM) lets you import a private key and publish its public key as a TXT record.

#DMARC: alignment and policy

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.<domain>. It tells receivers two things:

1. Pass rule (alignment). A message passes DMARC if SPF passes for a domain that matches the From domain, or DKIM passes with a signature from a domain that matches the From domain. One is enough.
2. Policy for failures. p=none (only report), p=quarantine (spam folder) or p=reject (refuse), plus rua= where daily aggregate reports go.

_dmarc.shop.example.   TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@shop.example"

With SES, Easy DKIM on your domain is enough to pass DMARC (the signature's domain is yours). A custom MAIL FROM makes SPF align too, a second path if DKIM ever breaks. Start with p=none, read the reports for a few weeks to find every system that sends as your domain (the CRM, the helpdesk, the payroll system), then move to quarantine and reject.

#Reputation: bounces, complaints and the suppression list

Mailbox providers decide where your mail goes mostly from reputation: how many of your messages bounce, how many people mark them as spam, how consistently you send. SES shares IP addresses between many customers, so it protects everyone by watching each account closely.

#Bounces and complaints

• A hard bounce is a permanent failure: “550 user unknown”, the domain does not exist. Only hard bounces count towards the bounce rate. A soft bounce (mailbox full, server busy) is temporary and SES retries it for a while.
• A complaint is a recipient pressing “Report spam”. Providers that run a feedback loop send the complaint back to SES, which counts it in the complaint rate and can notify you.

SES publishes both rates for the account as the CloudWatch metrics Reputation.BounceRate and Reputation.ComplaintRate, calculated over a representative volume of your recent sending rather than one fixed day.

#When SES reviews or pauses an account

The numbers SES documents (checked for this lesson):

• Under review: SES emails the account owner and opens a support case. You can still send, but must fix the cause (stop the bad campaign, clean the list) before the review period ends, and reply to the case with what you changed.
• Paused: the account can no longer send in that Region, transactional mail included. You must fix the problem and ask for a review. aws sesv2 get-account shows EnforcementStatus (HEALTHY, PROBATION, SHUTDOWN).
• Serious abuse (phishing, spam traps, a manual investigation) can lead to a pause without a review first.

Put CloudWatch alarms on both metrics well below the review lines (for example 3% bounce and 0.05% complaint), and consider an automatic “stop the marketing configuration set” action, so a bad campaign cannot take down your password resets.

#The suppression list

The account-level suppression list stores addresses that hard-bounced or complained. When it is on (for BOUNCE, COMPLAINT or both), SES automatically adds such addresses and then refuses to send to them again without contacting the provider, so a dead address cannot hurt your bounce rate twice. You can add or remove addresses yourself (put-suppressed-destination, delete-suppressed-destination), import lists in bulk once out of the sandbox, and override the setting per configuration set. It complements, not replaces, your own handling: your application should also mark the address invalid.

#Shared, dedicated and managed IP addresses

Dedicated IP pools let you split traffic: one pool for transactional mail, another for marketing, chosen per configuration set. SES also supports bringing your own IP range for large senders.

#Configuration sets and event publishing

A configuration set is a named bundle of rules that you name when you send (ConfigurationSetName). It can:

• turn on open and click tracking (SES inserts a tiny image and rewrites links through its tracking domain, which you can replace with your own domain);
• choose the dedicated IP pool, override suppression settings, set a custom tracking domain and require TLS for delivery;
• publish events to event destinations.

The events are SEND, REJECT, DELIVERY, BOUNCE, COMPLAINT, DELIVERY_DELAY, RENDERING_FAILURE (a template variable was missing), OPEN, CLICK and SUBSCRIPTION. The destinations:

You can also set simpler identity-level feedback notifications (bounces, complaints, deliveries to an SNS topic, or forwarded by email) without a configuration set.

#Virtual Deliverability Manager

Virtual Deliverability Manager (launched November 2022) is an opt-in SES feature, charged per email, that adds a deliverability dashboard (delivery, open, click, bounce and complaint rates by mailbox provider, sending identity and configuration set) and an advisor that finds problems such as missing DKIM or DMARC records and tells you how to fix them. A newer “global deliverability” part adds inbox placement tests and blocklist monitoring. It replaced Pinpoint's old deliverability dashboard. The exam does not ask for it by name; it is the answer in real life to “why is our mail going to spam at one provider?”.

#Receiving email

The notes' keyword “inbound email routing” is about SES as a receiver: SES can accept mail for your domain and hand it to your code. There is no mailbox and no IMAP or POP3: if people need to read mail in Outlook, that is a mail service such as Amazon WorkMail or a SaaS product, not SES.

#Receipt rules

1. Verify the domain, then point its MX record at the SES receiving endpoint of a Region that supports receiving, for example 10 inbound-smtp.ap-southeast-1.amazonaws.com (Singapore and Mumbai both do; not every Region does).
2. Create a receipt rule set and make it active (only one is active per account and Region).
3. Add receipt rules, each with recipient conditions (an address, a domain or a subdomain) and an ordered list of actions:

SES checks SPF, DKIM and DMARC of incoming mail and scans it for spam and viruses (on by default per rule); it only reports the verdicts, your rules or Lambda code decide what to do. IP address filters block or allow sender IP ranges during the SMTP conversation, so blocked mail is never stored or billed; receipt rules run after the message is accepted.

#Mail Manager (2024)

Mail Manager (2024) is a newer SES email gateway for organisations' inbound and outbound mail flows: ingress endpoints (open, or authenticated for trusted SMTP servers) with traffic policies (allow or deny by sender IP, TLS version, recipient), rule sets that route, archive, relay to another SMTP server (such as Microsoft 365) or write to S3, built-in archiving with search and retention for compliance, and add-ons for extra security scanning. Think of receipt rules as “mail for my application” and Mail Manager as “mail flow for my company”. It is a verified side note: the exam answer for inbound processing remains SES receiving with receipt rules.

#SES or SNS? Correcting the notes

The notes say: “SNS is for messages or notifications (app-to-app or SMS); SES is only for email.” The second half is right, the first is incomplete. SNS also sends email, and SNS is not the only AWS service that sends SMS: AWS End User Messaging does too. The real line is between notifications to subscribers and real email or text to customers:

And for the rest of the notes' sentence:

• SNS does app-to-app (A2A: SQS, Lambda, Firehose, HTTP/S) and app-to-person (A2P: email, SMS, mobile push) through topics with fan-out.
• SMS from SNS is delivered by AWS End User Messaging SMS underneath (lesson 13.4). For OTPs and one-to-one transactional SMS, calling End User Messaging directly gives you sender IDs, phone pools, spend limits and delivery events.
• SES is email only, but both outbound and inbound.

#Amazon Pinpoint, and what happened to it

#What Pinpoint did

Amazon Pinpoint was AWS's marketing and customer engagement service. Where SES and SNS send each message you hand them, Pinpoint owned the whole campaign:

• Endpoints and segments: every customer as an endpoint (email, phone, device) with attributes (city, last purchase), and segments built from them (“customers in Dhaka who bought last Eid”).
• Campaigns (one message to a segment, once or on a schedule) and journeys (multi-step flows: wait, branch on opened or not, switch channel).
• Templates, A/B testing of message variants, quiet hours and frequency caps.
• Channels: email, SMS, mobile push, voice, in-app messages, with two-way SMS so customers could reply.
• Analytics: opens, clicks, conversions, and event streams to Kinesis or Firehose.

The notes' exam trick: “Targeted multi-channel marketing campaigns”, “user engagement”, “A/B testing for messages” → pick Pinpoint “with your eyes closed”. The slides add that Pinpoint scaled to billions of messages a day, could receive replies, and streamed events such as TEXT_SUCCESS and TEXT_DELIVERED.

#End of support: 30 October 2026

The status, checked against the Pinpoint migration guide on the day this lesson was written (1 November 2026):

• 20 May 2025: Pinpoint stopped accepting new customers.
• 30 October 2026 (two days ago as this is written): end of support. The Pinpoint console and the engagement features, endpoints, segments, campaigns, journeys, analytics and its metrics APIs, in-app messaging and recommenders, are no longer available.
• What continues: the message-delivery APIs, renamed AWS End User Messaging in Q3 2024: SMS, MMS, voice, mobile push, WhatsApp, the OTP APIs (SendOTPMessage, VerifyOTPMessage) and phone number validation. Push, OTP and phone validation work for all accounts; SMS, voice and email sending through the Pinpoint API keep working only for customers who signed up before 20 May 2025, and AWS points them to End User Messaging and SES; event and metric delivery to Kinesis, Firehose and CloudWatch continues for direct sends.
• Where engagement went: AWS recommends Amazon Connect (outbound campaigns, which now also run journeys, and Customer Profiles) for segments, campaigns and journeys; Amazon SES for email (and SES Virtual Deliverability Manager for the deliverability dashboard); Kinesis for event collection.

So in 2026 a new project that wants “Pinpoint” builds it from three services:

Amazon Connect is AWS's cloud contact centre (lesson 18.1): phone numbers, queues and agents. Its outbound campaigns can run journeys across voice, SMS, email and WhatsApp with or without agents. That is why the engagement half of Pinpoint moved there.

#Choosing a messaging service

The comparison the exam keeps asking for, with SQS for contrast (it sends to programs, not people; lesson 13.1):

#What goes wrong

#Messaging in system design

• Never send email inside the user's request. Write the order, publish an event (DynamoDB Streams, SNS, EventBridge or SQS), and let a worker call SES. Sign-up and checkout stay fast and do not fail when email has a bad minute (lessons 15.5 and 15.8).
• Put a queue in front of SES for bursts. A flash sale can produce more emails than the per-second quota; an SQS queue with a Lambda consumer at controlled concurrency sends at a steady rate and retries throttles.
• Separate reputations. Transactional and marketing mail in different configuration sets, IP pools or accounts; a marketing mistake must not stop password resets.
• Close the feedback loop. Bounce and complaint events → SNS or EventBridge → a function that marks addresses invalid; alarms on the reputation metrics.
• Authenticate the domain once, for every sender. Every system that sends as your domain needs DKIM (and ideally SPF alignment); then DMARC can move to reject.
• Multi-Region: identities, quotas and sandbox status are per Region. For DR, verify the domain and get production access in a second Region before you need it.
• Do not confuse channels with campaigns. SES and End User Messaging deliver messages; segments, journeys and agents belong in Amazon Connect (or a marketing platform).
• Cost: SES is roughly 0.10 USD per 1,000 emails; SMS is priced per message per country and is far more expensive per message, which is one reason OTPs are often sent by email or push where acceptable.

#Try it yourself

These commands use ap-southeast-1 (Singapore), the domain shop.example and account 111122223333. Use your own domain, and remember that sandbox accounts can only send to verified addresses.

# 1. Verify a domain identity; Easy DKIM returns three tokens to publish as CNAME records
aws sesv2 create-email-identity --email-identity shop.example
# {
#   "IdentityType": "DOMAIN",
#   "VerifiedForSendingStatus": false,
#   "DkimAttributes": {
#     "SigningEnabled": true,
#     "Status": "PENDING",
#     "Tokens": ["abc123exampletoken", "def456exampletoken", "ghi789exampletoken"],
#     "SigningAttributesOrigin": "AWS_SES"
#   }
# }
# Publish: abc123exampletoken._domainkey.shop.example CNAME abc123exampletoken.dkim.amazonses.com (and the other two)

# 2. A custom MAIL FROM domain (then publish its MX and SPF TXT records)
aws sesv2 put-email-identity-mail-from-attributes --email-identity shop.example \
  --mail-from-domain mail.shop.example --behavior-on-mx-failure USE_DEFAULT_VALUE

# 3. Is the account still in the sandbox? What are the quotas and the enforcement status?
aws sesv2 get-account
# {
#   "SendQuota": { "Max24HourSend": 200.0, "MaxSendRate": 1.0, "SentLast24Hours": 3.0 },
#   "SendingEnabled": true,
#   "ProductionAccessEnabled": false,
#   "EnforcementStatus": "HEALTHY"
# }

# 4. Request production access
aws sesv2 put-account-details --production-access-enabled --mail-type TRANSACTIONAL \
  --website-url https://shop.example --contact-language EN \
  --additional-contact-email-addresses ops@shop.example

# 5. A configuration set that sends bounces and complaints to an SNS topic
aws sesv2 create-configuration-set --configuration-set-name transactional
aws sesv2 create-configuration-set-event-destination --configuration-set-name transactional \
  --event-destination-name feedback-to-sns \
  --event-destination '{"Enabled":true,"MatchingEventTypes":["BOUNCE","COMPLAINT"],
    "SnsDestination":{"TopicArn":"arn:aws:sns:ap-southeast-1:111122223333:ses-feedback"}}'

# 6. Send a simple HTML + text email through the configuration set
aws sesv2 send-email --from-email-address orders@shop.example \
  --destination ToAddresses=success@simulator.amazonses.com \
  --configuration-set-name transactional \
  --content '{"Simple":{"Subject":{"Data":"Order #10234 confirmed"},
    "Body":{"Text":{"Data":"Thank you for your order."},
            "Html":{"Data":"<h1>Thank you!</h1><p>Order <b>#10234</b> is confirmed.</p>"}}}}'
# { "MessageId": "010e019a1b2c3d4e-5f6a7b8c-0000-0000-0000-000000000000-000000" }

# 7. Test a bounce safely with the mailbox simulator, then look at the suppression list
aws sesv2 send-email --from-email-address orders@shop.example \
  --destination ToAddresses=bounce@simulator.amazonses.com \
  --content '{"Simple":{"Subject":{"Data":"test"},"Body":{"Text":{"Data":"test"}}}}'
aws sesv2 put-account-suppression-attributes --suppressed-reasons BOUNCE COMPLAINT
aws sesv2 put-suppressed-destination --email-address old.customer@customer.example --reason BOUNCE
aws sesv2 list-suppressed-destinations --reasons BOUNCE --query 'SuppressedDestinationSummaries[].EmailAddress'
# [ "old.customer@customer.example" ]

# 8. Receive mail: a rule set that stores support@ mail in S3 and invokes a function
aws ses create-receipt-rule-set --rule-set-name inbound
aws ses create-receipt-rule --rule-set-name inbound --rule '{
  "Name": "support", "Enabled": true, "ScanEnabled": true, "TlsPolicy": "Require",
  "Recipients": ["support@shop.example"],
  "Actions": [
    {"S3Action": {"BucketName": "shop-inbound-mail-example", "ObjectKeyPrefix": "support/"}},
    {"LambdaAction": {"FunctionArn": "arn:aws:lambda:ap-southeast-1:111122223333:function:open-ticket",
                      "InvocationType": "Event"}}]}'
aws ses set-active-receipt-rule-set --rule-set-name inbound
# Then: shop.example MX 10 inbound-smtp.ap-southeast-1.amazonaws.com

# 9. SNS email for comparison: the subscriber must confirm before anything arrives
aws sns subscribe --topic-arn arn:aws:sns:ap-southeast-1:111122223333:ops-alerts \
  --protocol email --notification-endpoint oncall@shop.example
# { "SubscriptionArn": "pending confirmation" }

# 10. An SMS through AWS End User Messaging (the former Pinpoint SMS API)
aws pinpoint-sms-voice-v2 describe-account-attributes
# { "AccountAttributes": [ { "Name": "ACCOUNT_TIER", "Value": "SANDBOXED" } ] }
aws pinpoint-sms-voice-v2 send-text-message --destination-phone-number +8801XXXXXXXXX \
  --origination-identity SHOPBD --message-type TRANSACTIONAL \
  --message-body "Your order #10234 has shipped."
# { "MessageId": "a1b2c3d4-1111-2222-3333-444455556666" }
# (+8801XXXXXXXXX stands for your own verified test number while the account is sandboxed)

# 11. Clean up
aws ses set-active-receipt-rule-set
aws ses delete-receipt-rule-set --rule-set-name inbound
aws sesv2 delete-configuration-set --configuration-set-name transactional
aws sesv2 delete-email-identity --email-identity shop.example

Also try in the console: open SES, Get set up, and look at the sandbox banner and the production access form; open an identity's Authentication tab to see the DKIM records and their status; open Reputation metrics to see the two rates and their thresholds.

#Summary

Key takeaways

• SES sends and receives email: transactional (order confirmation, password reset) and marketing or bulk; through the API (IAM) or the SMTP interface (SMTP credentials); about 0.10 USD per 1,000 emails; everything is per Region.
• Sandbox (per Region): only verified recipients or the mailbox simulator, 200 per 24 hours, 1 per second; leave it by requesting production access (answer within about 96 hours). The From identity must always be verified.
• Authentication: SPF (custom MAIL FROM subdomain: MX to feedback-smtp, TXT include:amazonses.com), DKIM (Easy DKIM: three CNAMEs, SES signs every message), DMARC (passes if SPF or DKIM aligns with the From domain; p=none, quarantine, reject).
• Reputation: bounce rate best under 2%, review at 5%, pause at 10%; complaint rate best under 0.1%, review at 0.1%, pause at 0.5%. Use the suppression list, alarms on Reputation.* metrics, and separate transactional from marketing.
• Configuration sets: open and click tracking, IP pools, event publishing to CloudWatch, Data Firehose, SNS, EventBridge. Shared IPs by default; dedicated standard (you warm up) or managed (SES warms up and scales).
• Receiving: MX to SES, active receipt rule set, actions S3 (40 MB), Lambda, SNS (150 KB), bounce, stop; IP filters block before acceptance. Mail Manager (2024) is the company-wide email gateway; Virtual Deliverability Manager is the deliverability dashboard and advisor.
• SNS vs SES: SNS email is plain-text notification to confirmed subscribers; SES is real email from your domain to anyone. SNS also does SMS and push (SMS through End User Messaging).
• Pinpoint: segments, campaigns, journeys, A/B tests, multi-channel; no new customers since 20 May 2025, end of support 30 October 2026. Channels continue as AWS End User Messaging (SMS, voice, push, OTP, phone validation); engagement moves to Amazon Connect outbound campaigns and Customer Profiles; email to SES. On the exam, “targeted multi-channel campaigns / A/B testing” → Pinpoint if offered.

Self-check: SES, Pinpoint and messaging30 questions