SQL Server 2012. Update second table based on input from first table
There are two options that come to mind. The first you have identified as a trigger that you could implement in TSQL for real-time synchronization of data. Depending on the activity of your system, the quality of your hardware (particularly I/O subsystem).

Synchronous approach

A trigger, implemented something like this. You would know better specifically what logic you need but the heart will be an AFTER trigger on the table in the system of record.

CREATE TRIGGER dbo.tr_TableSync
ON dbo.Table1
AFTER INSERT, UPDATE
BEGIN
    SET NOCOUNT ON;

    -- sync existing
    UPDATE
        T2
    SET
        RefVal = I.Val
    FROM
        T2
        INNER JOIN
            inserted AS I
            ON I.SK = T2.SK;

   -- Add new stuff
   INSERT INTO
       T2
   (
       SK
   ,   RefVal
   )
   SELECT
       I.SK
   ,   I.Val
   FROM
       inserted AS I
   EXCEPT
   SELECT
       T2.SK
   ,   T2.RefVal
   FROM
       T2;

   -- Do we need to account for deleted items?
   -- If so, need to add to declaration above 
   -- and code here
END


Asynchronous approach

The challenge around the trigger is that it can have a heavy footprint on performance to data manipulation operations in that table. SQL Server offers two approaches for asynchronous operations that provide a lighter footprint. You can look at implementing Service Broker or creating a CLR trigger.

Service Broker is a message queue. You'd create a message in your AFTER trigger (unless you can guarantee all manipulation is only performed through a proc or some other codified method) which will then get parsed when the system has a "chance to breathe" but it is guaranteed to happen just not RIGHT NOW DO IT NOW I'M WAITING ARE YOU DONE like the synchronous approach above forces.

I've never had cause to implement a CLR trigger before but it's possible and in your case, it'd be much like implementing your own message queue.

Final thought

Everyone loves to say "it needs to be instantaneous/real-time" but when they learn what that can cost to implement correctly, near-real-time of a few minutes to a day (yes, I've had people go from it must be accurate to the nano-second to as long as it's within 24 hours, we'll be fine). If that can satisfy your business needs, then you have even more doors opened (a SQL Agent job that fires SQL statements or SSIS or a custom .NET app every N interval).