After a user successfully signs in using Google with Firebase Authentication, what is the immediate result in the Firebase system?
Think about what Firebase Authentication provides after sign-in.
Firebase Authentication issues a Firebase ID token after successful sign-in. This token is used to identify the user securely in Firebase services. It does not store passwords or create new projects automatically.
Which Firebase Realtime Database security rule ensures that only authenticated users can read their own data after signing in with Google?
Consider how to restrict data access to the signed-in user only.
The rule "auth != null && auth.uid == $userId" ensures that only authenticated users can read data where their user ID matches the data node. Other options either allow public access or deny access incorrectly.
Which configuration step is essential to enable Google sign-in in a Firebase project?
Think about what must be enabled in Firebase Authentication settings.
To use Google sign-in, you must enable the Google provider in Firebase Authentication and configure OAuth credentials properly. Other options are unrelated or incorrect.
After a user signs in with Google, how does Firebase maintain the user's session on the client side?
Consider how web apps keep users signed in without asking for credentials repeatedly.
Firebase Authentication stores ID and refresh tokens securely on the client (usually local storage or indexedDB) to keep users signed in across sessions. It does not store passwords or require repeated sign-ins on reload.
Firebase API keys are visible in client apps. What is the best practice to keep your Firebase project secure when using Google sign-in?
Think about how Firebase protects data despite public API keys.
Firebase API keys are not secret and are safe to include in client apps. The best practice is to use Firebase security rules to control access based on authentication and user roles. Other options are either impossible or insecure.
