TL;DR: Learn the mapping in ten minutes, then learn the two things that are actually different. GCP's VPC is global with regional subnets, so one network spans regions without peering. And IAM binds roles to members at a level of the resource hierarchy, inheriting down, rather than attaching policies to users and roles.
How to approach it
Say the mapping is the easy part and move past it quickly, because an interviewer asking this wants to know whether you will make structural mistakes rather than whether you can recite that Cloud Storage is S3. Lead with global networking and the IAM model, and be honest that most of your AWS knowledge transfers.
A strong answer
The mapping, briefly: EC2 is Compute Engine, S3 is Cloud Storage, RDS is Cloud SQL, Lambda is Cloud Functions or Cloud Run, EKS is GKE, DynamoDB is roughly Firestore or Bigtable, CloudWatch is Cloud Monitoring and Logging, Route 53 is Cloud DNS. Learning that takes an afternoon.
Then the differences that change designs.
The VPC is global. In AWS a VPC exists in one region, and connecting regions means peering or a transit gateway. In GCP a VPC is a global resource with subnets in regions, so an instance in europe-west1 and one in us-central1 are on the same network, routing to each other over private addresses with no peering at all. That simplifies multi-region architectures considerably, and it changes the blast radius conversation, because a network-level mistake now has a wider reach than an AWS engineer's instincts expect. Firewall rules are also VPC-wide with target tags and service accounts rather than per-instance security groups, so the mental model for "what can talk to what" is different.
IAM is bindings on a hierarchy. AWS attaches policies to users, groups and roles, and evaluates them against the resource. GCP has Organisation, then Folders, then Projects, then resources, and you create a binding of a role to a member at one of those levels. It inherits downward and there is no deny by default in the basic model, so permissions are additive as you go down the tree. Two consequences: granting at the project level is the common over-permission mistake, since it covers everything in the project, and a service account is itself both an identity and a resource, so you can grant someone permission to impersonate one. Service account impersonation is idiomatic in GCP in a way that assuming a role is in AWS, and it is how short-lived credentials are obtained.
Projects are the unit. A GCP project is roughly an AWS account: a billing and quota boundary, a permission boundary, and cheap to create. The idiomatic pattern is many projects, often one per application per environment, whereas AWS shops historically used fewer accounts and more separation inside them. Folders group projects the way organisational units group accounts.
Some smaller differences worth knowing. Live migration means Compute Engine instances survive host maintenance without a reboot, which removes a class of planned disruption AWS engineers plan around. Sustained use discounts apply automatically without a commitment, so the cost model rewards steady usage without reservations. And BigQuery has no real AWS equivalent in the way it is used: serverless, separating storage from compute, priced on bytes scanned, which makes a careless query expensive in a way people are not braced for.
Finally, GKE is generally regarded as the most polished managed Kubernetes, and Autopilot mode removes node management entirely. If the role is Kubernetes-centred, that is a real advantage rather than marketing.
What interviewers probe next
"How do you give a workload permissions on GCP?" A service account attached to the resource, with roles bound as narrowly as possible, and Workload Identity for GKE so a Kubernetes service account maps to a Google one without a key file. Downloading a service account key is the thing to avoid, and it is still the most common way credentials leak.
"What are predefined versus custom roles?" Predefined roles are maintained by Google and usually broader than you need. Custom roles are yours to define and to maintain as the API surface changes. Start predefined, narrow to custom where the excess actually matters.
"Does the global VPC have a downside?" Yes. A misconfigured firewall rule or route has a wider reach than the regional equivalent, and quota and limits now apply across a larger scope. It removes complexity and concentrates risk.
Common mistakes
Assuming a VPC is regional and designing peering that GCP does not need.
Binding roles at the project level because it works, which grants far more than intended.
Downloading service account keys instead of using attached service accounts or Workload Identity.
Treating a project as a namespace rather than as the account-equivalent boundary it actually is.