You need to change an engine setting such as PostgreSQL's log_min_duration_statement on an Amazon RDS instance, but RDS gives you no shell and no true superuser. How do you change it, and why might your change not take effect right away?
answer
- there is no config file to edit
- the AWS-supplied group is read-only
- every parameter has an apply type
- some values wait for a restart
- swapping groups also needs a reboot
basics
~20 sEngine settings on RDS live in a DB parameter group attached to the instance. You cannot edit the default group, so you create a custom one, set the value, and attach it. Dynamic parameters apply right away; static ones need an instance reboot.
solid answer
~50 sRDS is a managed service, so there is no host to SSH into and no `postgresql.conf` to edit — the configuration file is replaced by a **DB parameter group**, a named set of engine settings you attach to an instance. AWS-provided *default* parameter groups are read-only, so the first step is always creating a custom group for your engine family, changing the values there, and modifying the instance to use it. Each parameter has an apply type: **dynamic** parameters (like `log_min_duration_statement`) take effect without downtime, while **static** ones (like `shared_preload_libraries`) are only picked up on the next reboot, and the console shows the instance in a `pending-reboot` state until then. Switching an instance from one parameter group to another also requires a reboot before the new group is in force. Engine-level add-ons for Oracle, SQL Server and MySQL are configured separately through option groups.
go deeper
Recall that RDS engine settings live in a DB parameter group rather than a file on disk, and that you must create your own group because the default one is read-only.
Explain apply types — which parameters change live and which sit in pending-reboot — and know that swapping an instance to a different group also requires a reboot.
Show that you plan static-parameter changes into a maintenance window, keep per-role groups so a shared edit cannot hit unrelated instances, and verify with describe-db-parameters rather than trusting the console.
Own configuration as code across the fleet: standard baseline groups per engine family, a review path for changes that require reboots, and a rule for when an instance earns its own group.
## Why the usual answer does not work On a self-managed database you would edit a configuration file on the host — `postgresql.conf`, `my.cnf` — or issue a privileged `ALTER SYSTEM`. On RDS you can do neither. There is no shell: AWS owns the operating system, and the account you are given (the *master user*) is deliberately not a full superuser. On RDS for PostgreSQL the master user holds the `rds_superuser` role, which grants a curated subset of privileges; anything AWS considers part of managing the fleet is withheld. That is the whole bargain of a managed database, and the interviewer is checking that you know what replaces the file. ## Parameter groups are the configuration file A **DB parameter group** is a named collection of engine settings that you attach to a DB instance. Its analogue is the config file; its lifecycle is an AWS API object. Three facts do most of the work in an interview: 1. **Every instance has one.** If you did not choose one, it has the AWS *default* group for its engine family, for example `default.postgres16`. 2. **Default groups cannot be modified.** Trying to change a value on one fails. You must `create-db-parameter-group` from the right family, edit that, and `modify-db-instance --db-parameter-group-name` to attach it. 3. **A group is attached to many instances.** Changing a value affects every instance using that group, which is convenient for fleet-wide standards and dangerous when one instance is special. ```bash aws rds create-db-parameter-group \ --db-parameter-group-name app-pg16 \ --db-parameter-group-family postgres16 \ --description "application defaults" aws rds modify-db-parameter-group \ --db-parameter-group-name app-pg16 \ --parameters "ParameterName=log_min_duration_statement,ParameterValue=500,ApplyMethod=immediate" ``` ## Dynamic versus static, and the reboot This is the part candidates miss and the reason the question includes "why might it not take effect". Every parameter carries an **apply type** that you can read with `describe-db-parameters`: - **dynamic** — the engine can change it at runtime. With `ApplyMethod=immediate` the new value reaches the running instances that use the group within moments. `log_min_duration_statement` is dynamic, so slow-query logging starts without downtime. - **static** — the engine only reads it at startup. `shared_preload_libraries` (the parameter you must edit to load `pg_stat_statements` or `pgaudit`) and `rds.force_ssl` are static. The value is stored immediately but the instance reports `pending-reboot`, and nothing changes until you call `reboot-db-instance`. A second, subtler reboot rule: **attaching a different parameter group to an instance requires a reboot** before the new group takes effect, even if every parameter in it is dynamic. So the sequence "created a custom group, attached it, nothing happened" is a normal, expected outcome, not a bug. ```bash aws rds describe-db-parameters \ --db-parameter-group-name app-pg16 \ --query "Parameters[?ParameterName=='shared_preload_libraries'].[ParameterName,ApplyType,Value]" ``` ## Cluster-level parameter groups For cluster-shaped deployments RDS also has **DB cluster parameter groups**, which hold the settings that must be identical across every instance in the cluster; instance-level groups still exist alongside them for per-instance settings. When a value seems to be ignored, checking whether it belongs at cluster or instance scope is a standard step. ## Option groups are a different thing An **option group** configures optional engine *features* rather than scalar settings — for example Oracle and SQL Server capabilities such as transparent data encryption, or MySQL plugins like the audit plugin. RDS for PostgreSQL has no option groups; PostgreSQL extensions are enabled by listing the library in `shared_preload_libraries` in the parameter group (where required) and then running `CREATE EXTENSION` inside the database. Knowing which knob lives where — parameter group, option group, or SQL statement — is the practical skill. ## The habit worth showing Never leave production on a default parameter group. Create a custom group from day one even if it starts identical to the default, because the day you need to change a value under incident pressure is not the day you want to discover that attaching a new group costs you a reboot. Version-control the intended values, know which of them are static, and batch static changes into a single planned reboot.
- You set a static parameter and rebooted, but the value still is not active. What would you check?Whether the instance is actually using the group you edited — `describe-db-instances` shows the attached group and its apply status. Also check scope: cluster-wide settings belong in a DB cluster parameter group, and an instance-level entry for them is ignored. Finally confirm the group family matches the engine major version, since a group built for a different family cannot be attached.
- What is the risk of editing a parameter group that several RDS instances share?The change lands on all of them at once. A dynamic parameter propagates to every attached instance immediately, so a value tuned for a large production writer can be applied to a small staging instance in the same breath. Give instances with different sizing or roles their own groups, and treat a shared group as a fleet-wide change.
saying these in an interview costs you the question
- Just SSH into the RDS host and edit the config file
- The master user on RDS is a full engine superuser
- All parameter changes take effect immediately
- You can edit the AWS default parameter group directly
- Attaching a new parameter group applies instantly with no reboot