Cloud / Google Cloud Storage Interview questions

Google Cloud Storage (GCS) is Google Cloud's managed object storage service. You keep unstructured data such as images, backups, logs and analytics files as objects inside buckets, and reach them over HTTP through the JSON and XML APIs, client libraries, the gcloud storage CLI or the console.

There is no disk or server to provision. Capacity is effectively unlimited, and every storage class is designed for 11 nines of annual durability. Billing is based on data stored, operations performed and network egress.

Typical uses are data lakes, media delivery, backups and archives, static websites and machine learning datasets.

A bucket is the top-level container. Its name is globally unique, and it carries settings such as location, default storage class, versioning and access control. An object is the actual data plus its metadata, and it always lives in exactly one bucket.

The namespace is flat. A name like logs/2026/app.log is just one long object name; the console shows folders only because of the slash convention.

Each object is identified by its name and a generation number.

Cloud Storage has four classes: Standard, Nearline, Coldline and Archive. They share the same API, millisecond access and durability. What changes is price: colder classes cost less to store but add retrieval fees and a minimum storage duration.

Deleting or moving an object before the minimum duration still bills you for the remaining days.

A bucket is created in one of three location types, and it cannot be changed afterwards.

Pick a region to keep data close to compute and costs low. Choose dual-region or multi-region when you need higher availability and geo-redundancy for serving or disaster recovery.

Location also affects price, latency and available features. For example, turbo replication exists only for dual-region buckets, and some compliance rules require data to stay in a named region or area.

Bucket names must be globally unique and follow these rules:

• 3 to 63 characters (up to 222 if the name contains dots, each part at most 63).
• Only lowercase letters, numbers, dashes, underscores and dots.
• Must start and end with a letter or number.
• Cannot look like an IP address, start with goog, or contain google or close misspellings.

Names that contain dots usually represent domains and require domain ownership verification. Because names are public and permanent, avoid putting sensitive details such as customer names in them.

Object versioning keeps older copies of an object when it is overwritten or deleted. The live copy is the current version, and earlier ones become noncurrent. Each has a unique generation number.

Enable it per bucket:

gcloud storage buckets update gs://my-bucket --versioning

Restore an old version by copying it over the live name using its generation:

gcloud storage cp gs://my-bucket/report.csv#1712345678901234 gs://my-bucket/report.csv

Noncurrent versions are billed like normal objects, so pair versioning with lifecycle rules that cap how many versions you keep.

Object Lifecycle Management automates cleanup and cost savings. You define rules made of a condition (such as age or storage class) and an action (Delete, SetStorageClass, or AbortIncompleteMultipartUpload).

{"rule": [
  {"action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
   "condition": {"age": 30, "matchesStorageClass": ["STANDARD"]}},
  {"action": {"type": "Delete"}, "condition": {"age": 365}}
]}

gcloud storage buckets update gs://my-bucket --lifecycle-file=lifecycle.json

Rules run asynchronously, so an action can happen some time after the condition becomes true.

Other useful conditions include createdBefore, isLive, numNewerVersions and daysSinceNoncurrentTime, which make rules for versioned buckets possible.

A signed URL gives time-limited access to a single object to anyone who holds the link, without needing a Google account. The URL carries a cryptographic signature created with a service account's credentials, along with the allowed method (GET, PUT and so on) and an expiry time.

Create one with the CLI:

gcloud storage sign-url gs://my-bucket/invoice.pdf --duration=1h --impersonate-service-account=signer@my-project.iam.gserviceaccount.com

V4 signed URLs can last at most 7 days. The URL works only while the signing account still has permission on the object.

Use gcloud storage buckets create and pass a unique name and a location:

gcloud storage buckets create gs://my-unique-bucket-2026 \
  --location=us-central1 \
  --default-storage-class=STANDARD \
  --uniform-bucket-level-access \
  --public-access-prevention

Check the result with gcloud storage buckets describe gs://my-unique-bucket-2026.

You need the storage.buckets.create permission, which comes with Storage Admin. Setting uniform access and public access prevention at creation is a safer default than fixing them later.

Location is permanent, so choose it carefully. Also pick a name that does not reveal anything sensitive, since bucket names are visible in URLs.

The cp command moves data in both directions, and rsync keeps two locations in sync.

# upload a file
gcloud storage cp ./report.pdf gs://my-bucket/reports/
# download it
gcloud storage cp gs://my-bucket/reports/report.pdf .
# upload a folder
gcloud storage cp -r ./site gs://my-bucket/site
# copy only what changed
gcloud storage rsync -r ./data gs://my-bucket/data

gcloud storage ls lists contents. Large transfers are parallelized automatically, which is one reason it is preferred over gsutil.

Use --dry-run with rsync to preview changes first, especially together with --delete-unmatched-destination-objects, which removes extra files from the destination.

Uniform bucket-level access (UBLA) turns off object ACLs, so IAM is the only system that decides who can reach a bucket and its objects. Permissions are then easy to audit, because there is one place to look.

Enable it with:

gcloud storage buckets update gs://my-bucket --uniform-bucket-level-access

Existing ACLs stop being evaluated but are kept. You can switch UBLA off again within 90 days; after that it is locked in. Google recommends UBLA for almost every new bucket.

It also simplifies compliance reviews, because an auditor only needs to inspect IAM policies instead of hunting for per-object ACL entries.

Cloud Storage is designed for 99.999999999% (11 nines) annual durability across all storage classes. Data is stored redundantly, regional buckets across multiple zones and dual-region or multi-region buckets across regions, and integrity is checked with CRC32C and MD5 checksums.

Availability is a different measure. It depends on the storage class and location type, and multi-region and dual-region buckets offer higher availability than a single region. Durability is about not losing data; availability is about being able to read it right now.

A single object can be up to 5 TiB. A bucket has no limit on total size or object count.

For files above a few hundred MB, use a resumable upload so a network failure doesn't force a restart from zero. Tools such as gcloud storage cp pick this automatically and can also split big files into pieces uploaded in parallel (parallel composite uploads).

The compose operation can join up to 32 source objects per request, which is how larger objects are assembled from parts.

Autoclass moves objects between storage classes automatically based on how often they are accessed. New objects start in Standard. With no access they step down to Nearline after 30 days, Coldline after 90 days, and optionally Archive after 365 days. When an object is read, it moves back to Standard.

It removes the need to guess access patterns and write lifecycle rules. Objects managed by Autoclass have no retrieval or early deletion fees, but the bucket pays a management fee.

gcloud storage buckets update gs://my-bucket --enable-autoclass

It suits data with unpredictable access; for patterns you know well, plain lifecycle rules can be cheaper.

A retention policy sets a minimum age for every object in a bucket. Until an object is older than the retention period, nobody can delete or overwrite it, even with Storage Admin.

gcloud storage buckets update gs://my-bucket --retention-period=30d

An unlocked policy can be shortened, extended or removed. Once you lock it (Bucket Lock), it becomes permanent and can only be extended. This is used for WORM-style compliance such as financial or healthcare records.

The policy covers existing and new objects. Objects can be read normally, and once they reach the minimum age they can be deleted or overwritten like any other.

Soft delete keeps deleted or overwritten objects for a retention window so you can restore them. It is on by default with a 7-day window, which you can change between 7 and 90 days or turn off.

gcloud storage buckets update gs://my-bucket --soft-delete-duration=14d
gcloud storage restore gs://my-bucket/report.csv#GENERATION

Soft-deleted data is billed at normal storage rates for the window, which is worth remembering for buckets with heavy churn. Unlike versioning, it is purely time-limited and needs no cleanup rules.

This is a safety net against mistakes such as a faulty cleanup script or an accidental delete. It does not replace backups or Bucket Lock, which protect against different risks.

Cloud Storage uses predefined IAM roles that you can grant at the project, bucket or (for supported buckets) folder level. The most common ones are:

Grant the narrowest role at the narrowest scope, usually on the bucket rather than the project.

Cloud Storage FUSE (gcsfuse) mounts a bucket as a directory on Linux or macOS, so applications can use normal file paths instead of the Cloud Storage API.

gcsfuse my-bucket /mnt/gcs

It is popular for ML training and data processing jobs that expect files, and it has a CSI driver for GKE. The catch is that it is not a full POSIX file system: there is no atomic rename on standard buckets, and latency is higher than a local disk. Caching options help with repeated reads.

Storage Transfer Service (STS) is a managed service for moving large amounts of data into Cloud Storage, or between buckets, without writing your own copy scripts.

Sources include Amazon S3, Azure Blob Storage, HTTP/HTTPS URL lists, other Cloud Storage buckets, and on-premises file systems through installed agents. You can schedule recurring jobs, transfer only changed files, filter by prefix, and cap bandwidth.

It handles retries and integrity checks for you, which is why it is the usual choice for cloud-to-cloud migrations.

Pub/Sub notifications let a bucket publish a message to a topic whenever something happens to an object, so downstream systems can react without polling.

Event types include OBJECT_FINALIZE (created or overwritten), OBJECT_DELETE, OBJECT_ARCHIVE and OBJECT_METADATA_UPDATE.

gcloud storage buckets notifications create gs://my-bucket --topic=uploads --event-types=OBJECT_FINALIZE

The Cloud Storage service agent needs the Pub/Sub Publisher role on the topic. A common use is triggering image processing after each upload.

Alternatives include Eventarc and Cloud Run functions triggers, which route events to services without you managing topics. Pub/Sub is best when several subscribers need the same event.

All three are low-cost classes for data you rarely read. They differ in how rarely, which sets the minimum storage duration and how much you pay to retrieve data.

Moving down the list lowers the storage price but raises retrieval cost and the early deletion penalty. If you read data more often than the class assumes, the retrieval fees can erase the saving. All three still return data in milliseconds.

IAM is Google Cloud's standard access system. It works at the project, bucket and folder levels, supports conditions, and is visible in audit tooling. ACLs are the older Cloud Storage system, applied per bucket or per object, with a small set of permissions (READER, WRITER, OWNER).

Without UBLA, a request is allowed if either system grants it. Turning on uniform bucket-level access leaves IAM as the only authority.

In practice, enable UBLA, manage everything with IAM, and keep ACLs only for old workloads that truly depend on per-object grants.

Choose a dual-region bucket when you need data in two specific regions, for example for compliance, low latency from both sides, or disaster recovery with a single bucket name that survives a regional outage.

Replication between the two regions is asynchronous. By default the target is to replicate all new objects within 12 hours. Turbo replication tightens this to a 15-minute target at an extra per-GB cost.

Pick turbo when losing recent writes would hurt, such as financial exports or media pipelines. Skip it for data that is easy to regenerate, and pick a plain region if you don't need geo-redundancy at all.

Cloud Storage guarantees strong consistency for object operations. Once a write succeeds, any later read sees the new data; the same holds for overwrites, deletes and metadata updates.

Bucket and object listings are strongly consistent too, so a list issued right after an upload includes it. This applies in regions, dual-regions and multi-regions.

The exception is access control: IAM policy changes are eventually consistent, so a newly granted role may take a short time to apply everywhere. Design startup scripts to retry on a 403 after permission changes.

This lets you build simple workflows, such as upload then immediately process, without adding sleep or polling logic.

A resumable upload splits transfer into steps so it can recover from failures. The client first sends an initiation request and gets back a session URI. It then uploads the data in one or more chunks to that URI.

If the connection drops, the client asks the session how many bytes arrived, then continues from that offset instead of restarting. Chunks must be multiples of 256 KiB, except the last. A session stays valid for about a week.

sequenceDiagram
  participant C as Client
  participant G as Cloud Storage
  C->>G: POST initiate upload
  G-->>C: Session URI
  C->>G: PUT chunk 1
  Note over C,G: Connection drops
  C->>G: PUT with Content-Range bytes */* (status query)
  G-->>C: 308, bytes received so far
  C->>G: PUT remaining data from that offset
  G-->>C: 200 OK, object created

The object appears only after the final byte is received. Client libraries do all of this for you.

A single stream can't always fill a fast network link. Parallel composite uploads split a large local file into pieces, upload them simultaneously as temporary objects, then use compose to stitch them into the final object and delete the pieces.

This can speed up big files considerably on high-bandwidth connections. Trade-offs to know:

• The result is a composite object, which has a CRC32C checksum but no MD5 hash.
• Temporary components are created and removed, which causes extra operations.
• Buckets with retention policies or holds can't delete those temporary pieces, so avoid the feature there.

Benchmark before adopting it, because on slow links or with small files the extra compose step may not make the upload any faster.

The new upload becomes the live version with a fresh generation number. The previous data is not removed; it becomes a noncurrent version and stays until you or a lifecycle rule remove it.

Deleting works the same way. A plain delete on a versioned bucket does not erase data, it just turns the live object into a noncurrent one, so a normal read returns 404. Deleting with an explicit generation (object#generation) removes that version permanently.

Because every version is billed, use numNewerVersions or daysSinceNoncurrentTime lifecycle conditions to prune old copies.

To roll back, copy the noncurrent generation you want over the live name. That creates another new live generation rather than rewriting history.

Layer several controls so one mistake doesn't leak data:

1. Public access prevention: set to enforced on the bucket, or via the organization policy storage.publicAccessPrevention, to block allUsers and allAuthenticatedUsers.
2. Uniform bucket-level access: removes object ACLs as a hidden path to exposure.
3. Least-privilege IAM: avoid broad roles at the project level.
4. Signed URLs for temporary sharing instead of making objects public.
5. VPC Service Controls and audit logs for exfiltration protection and detection.

gcloud storage buckets update gs://my-bucket --public-access-prevention

Enforcing it at the organization level protects new buckets by default.

Review settings regularly, for example with Security Command Center findings, to catch buckets that drifted away from policy.

By default Google encrypts data with Google-managed keys. Two options give you more control:

With CMEK the Cloud Storage service agent needs the Encrypter/Decrypter role on the key, and the key must be in a location compatible with the bucket. CSEK means that losing the key makes the object unreadable, so most teams choose CMEK.

Both give access without a Google account, but they cover different jobs.

Use a signed URL for most sharing and direct uploads. Use a policy document when a browser form posts to the bucket and you must restrict file size or type on the Cloud Storage side, for example with content-length-range.

Both block deletion, but they work differently.

A temporary hold is placed for things like legal discovery and lifted manually. An event-based hold ties retention to a business event; when released, the retention clock starts from that moment.

Holds and retention apply together: an object can be deleted only when it is old enough and has no hold.

Choose a retention policy for blanket rules such as keep everything for seven years, and a hold for case-specific freezes such as litigation on selected files.

Bucket Lock makes a bucket's retention policy permanent. After you lock it, the policy cannot be removed or shortened, only extended. Objects cannot be deleted or overwritten until their age exceeds the retention period, even by project owners.

gcloud storage buckets update gs://my-bucket --retention-period=7y
gcloud storage buckets update gs://my-bucket --lock-retention-period

The bucket also can't be deleted until all its objects have aged past the policy. That makes it suitable for WORM requirements such as SEC 17a-4 and similar regulations.

Locking is irreversible. Test the period on an unlocked bucket first, because a mistaken lock can leave you paying to store data you can't remove.

The deciding factor is how fast your network can move the data.

A rough test: if the transfer would take weeks or months on your available bandwidth, order an appliance. If the data sits in S3, Azure, or another bucket, or you need recurring syncs, use Storage Transfer Service.

Network egress and appliance logistics also affect cost and timelines, so estimate both before choosing.

Cloud Storage bills for storage, operations, retrieval and network egress, so optimize each:

1. Pick the right class and move cold data down with lifecycle rules, or let Autoclass do it.
2. Prune versions and review soft delete duration on high-churn buckets.
3. Co-locate compute and bucket to avoid cross-region egress.
4. Abort incomplete multipart uploads with a lifecycle rule.
5. Avoid billions of tiny objects, since each operation costs money; combine small files.
6. Watch minimum durations: deleting early from Nearline, Coldline or Archive is still billed.
7. Use Storage Insights and billing reports to find waste.

Regional buckets are cheaper than multi-region, so only pay for geo-redundancy where you need it.

Work through the likely causes in order:

1. Identity: confirm who is really calling (gcloud auth list, the workload's service account).
2. Permission: check the role includes the needed permission, such as storage.objects.get, at bucket or project level, and the IAM condition isn't blocking it.
3. Policy blockers: public access prevention, organization policies, or a VPC Service Controls perimeter.
4. Requester pays: the call needs a billing project (--billing-project).
5. CMEK: the caller or service agent needs access to the Cloud KMS key.
6. Signed URLs: expired link, clock skew, or a signing account that lost access.

Policy Troubleshooter and Cloud Audit Logs show exactly which check failed. Remember that fresh IAM grants can take a short while to apply.

A 429 Too Many Requests means you hit a rate limit rather than a permission problem. The usual causes:

• Writing to the same object name more than about once per second.
• Updating bucket metadata or IAM too frequently.
• Ramping request rate up too fast against a narrow range of object names.

Fixes, in order of impact:

1. Retry with exponential backoff and jitter; the official client libraries already do this.
2. Stop using one object as a counter or log target. Write many distinct objects, or use a database such as Firestore for rapidly changing values.
3. Ramp traffic gradually and spread names across different prefixes.
4. Check the response body and Cloud Monitoring request metrics to see which limit you are hitting.

An object normally begins in Standard while it is hot. Lifecycle rules (or Autoclass) then move it to colder classes as it ages, and finally delete it when the retention need ends.

flowchart LR
  A["Upload: Standard"] -->|age 30 days| B[Nearline]
  B -->|age 90 days| C[Coldline]
  C -->|age 365 days| D[Archive]
  D -->|age 2555 days| E[Delete]
  B -.->|Autoclass: read again| A

With manual rules you decide the thresholds, and each change is a metadata rewrite without moving the data to another bucket. With Autoclass the transitions follow access: untouched objects step down, and an object that is read returns to Standard.

Remember minimum durations: moving or deleting before 30, 90 or 365 days is billed for the remainder.

A signed URL is created by your backend, handed to a client, and then used directly against Cloud Storage, so file bytes never pass through your server.

sequenceDiagram
  participant U as Client
  participant S as App server
  participant G as Cloud Storage
  U->>S: Request download link
  S->>S: Sign URL (service account, method, expiry)
  S-->>U: Signed URL
  U->>G: GET object using signed URL
  G->>G: Verify signature, expiry, signer's permission
  G-->>U: 200 object data (or 403)

On each request Cloud Storage recomputes the signature, checks the expiry, and confirms the signing account still has access to the object. Any mismatch, such as an altered path or clock skew, returns 403 SignatureDoesNotMatch.

Anyone with the link can use it until it expires, so keep durations short.

The location decides where data is physically stored and replicated, so changing it would mean moving every object behind the scenes. Cloud Storage therefore treats location as fixed at creation.

To migrate:

1. Create a new bucket in the target location, with matching settings (versioning, lifecycle, CMEK, UBLA, notifications). These settings are not copied for you.
2. Copy the data with Storage Transfer Service or gcloud storage rsync.
3. Re-create IAM bindings and update application references.
4. Cut over, verify checksums, and delete the old bucket.

If you must keep the exact bucket name, copy to a temporary bucket, delete the original, recreate the name in the new location and copy back. Google also offers a bucket relocation feature for certain moves, so check current availability.

gcloud storage is the current command group for Cloud Storage, built into the gcloud CLI. gsutil is the older, standalone tool that now receives only maintenance.

Most commands map one to one, so migration usually means swapping the prefix and checking flag names. Use gcloud storage for all new scripts.

A few gsutil-only behaviors differ slightly, so test scripts against a non-production bucket after switching.

Cloud Storage can serve static files (HTML, CSS, JS, images) straight from a bucket.

1. Create a bucket, usually named after your domain, such as www.example.com (domain ownership must be verified).
2. Upload the site files.
3. Set the main page and error page.
4. Grant allUsers the Storage Object Viewer role, so public access prevention must be off for this bucket.
5. Add a CNAME record pointing to c.storage.googleapis.com.

gcloud storage buckets update gs://www.example.com --web-main-page-suffix=index.html --web-error-page=404.html

Direct bucket hosting serves HTTP only. For HTTPS or a CDN, put an external Application Load Balancer with Cloud CDN in front of the bucket.

Remember that a public website bucket exposes every object in it, so keep private files in a different bucket.

With requester pays, the person or project making the request pays for operations and network egress, while the bucket owner still pays for storage.

Enable it when you share large public or partner datasets (genomics, imagery, open data) and don't want to absorb download costs for everyone. Avoid it for ordinary application buckets, since callers must jump through extra steps.

gcloud storage buckets update gs://shared-data --requester-pays
gcloud storage cp gs://shared-data/file.bin . --billing-project=my-project

Requesters must name a billing project and have serviceusage.services.use permission on it. Anonymous access is not allowed, and signed URLs and website hosting don't combine well with it.

Browsers block JavaScript from reading responses from another origin unless the server allows it. CORS configuration on a bucket tells Cloud Storage which origins, methods and headers are permitted.

For a preflight request, the browser sends an OPTIONS call; the bucket replies with the allowed values from its config, and the browser then makes the real request.

[{"origin": ["https://app.example.com"],
  "method": ["GET", "PUT"],
  "responseHeader": ["Content-Type"],
  "maxAgeSeconds": 3600}]

gcloud storage buckets update gs://my-bucket --cors-file=cors.json

You need it when a web app fetches or uploads objects directly from the browser, for example with signed URLs. Server-side or CLI access doesn't use CORS. Prefer exact origins over *.

They store data differently and suit different access patterns.

Use Cloud Storage for large unstructured data and cheap durability. Use Persistent Disk when a VM needs low-latency random reads and writes. Use Filestore when several machines need a shared POSIX file system.

They are often combined, for example an application on Persistent Disk that backs up nightly to Cloud Storage.

In a standard bucket, folders are only name prefixes, so renaming a folder means copying and deleting every object under it. Hierarchical namespace (HNS) buckets add real folder resources.

Benefits:

• Atomic folder rename, which makes Hadoop/Spark commit steps and Cloud Storage FUSE operations fast and safe.
• Higher initial request rates for workloads that touch many folders.
• Folder-level IAM through the Storage Folder Admin role.

HNS must be chosen at bucket creation and requires uniform bucket-level access. It suits analytics and AI workloads; for plain object serving it adds little, and you should check which features it supports.

For example, renaming a Spark output folder from temporary to final becomes one quick operation instead of millions of copies.

Both let you recover data, but they protect against different things.

Soft delete is the simple safety net and is on by default. Versioning is better when you need many historic copies or need to restore a specific earlier state. They can be used together, and both increase storage cost.

If you only worry about mistakes in the last week or two, soft delete alone is usually enough and simpler to run.

Cloud Storage scales request capacity automatically, but it does so by splitting the bucket's name range. If all new objects share a sequential prefix, such as a timestamp or incrementing ID, traffic concentrates on one range and may trigger 429 or 503 errors while it splits.

To spread the load:

• Add a short hash or random prefix before sequential parts, for example a3f/2026-10-21/file.json.
• Ramp traffic up gradually rather than starting at full volume. The initial capacity is about 1,000 writes and 5,000 reads per second per bucket.
• Retry with exponential backoff.

The trade-off is that hashed prefixes make prefix listing by date less convenient, so keep a separate index if you need to list by time.

Use Cloud Audit Logs, which record who did what in Cloud Storage:

• Admin Activity logs (bucket and IAM changes) are always on.
• Data Access logs (ADMIN_READ, DATA_READ, DATA_WRITE) are off by default and must be enabled for the Cloud Storage service in IAM & Admin settings.

Logs flow to Cloud Logging, where you can filter on resource.type="gcs_bucket", export to BigQuery, and alert on suspicious reads.

Data Access logs on busy buckets can be large and costly, so scope them to sensitive buckets or specific principals. For inventory-style reporting, Storage Insights produces reports on objects and their metadata.

Anywhere Cache adds an SSD-backed read cache in the same zone as your compute. The first read of an object comes from the bucket and fills the cache; later reads are served locally with lower latency and higher throughput.

It helps workloads that read the same data repeatedly, such as ML training epochs or large analytics jobs. It can also cut data transfer and operations charges for reads, especially when compute sits in a different region from a multi-region bucket.

gcloud storage buckets anywhere-caches create gs://my-bucket us-central1-a

You create one cache per zone, set a TTL for entries, and pay for cache capacity. It is a poor fit for write-heavy or read-once data.

VPC Service Controls draw a service perimeter around projects and services, including storage.googleapis.com. Even a caller with valid IAM permissions is blocked if the request comes from outside the perimeter.

Setup outline:

1. Create a perimeter with the projects that hold your buckets.
2. Add Cloud Storage to the restricted services list.
3. Define access levels (for example trusted IP ranges or managed devices) and ingress/egress rules for approved flows.
4. Test in dry-run mode, review the violation logs, then enforce.

This defends against data exfiltration through stolen credentials or misconfigured IAM. It complements IAM, it does not replace it, and rules for partners or on-prem tools need careful planning.